The system as a whole is meant to support that use case, where each task (ticket in its jargon) can be tackled using a custom workflow that can each use a different agent/llm (so, it should support local LLMs if you have configured your coding agent to use them).
Sidenote: it's still not where I want, but getting there...
I'm working on a tool to manage developing with Agents for teams, using a UI like a Kanban board and workflows, so the development starts from a given workflow and not from a prompt, the idea being that instead of starting from a prompt/talk with the agent you define the ticket, create a plan, review and then have workflows that cover the implementation -- I find that I have better results than trying to do a chat with the agent for implementing.
I've been full time on it for 4 months already and dogfooding: https://beolis.com -- starting to look for feedback, although I would say it's not where I want to be yet, but getting there.
That's one of the reasons I started https://beolis.com. Now I have a workflow that says to do things in a TDD and run only new tests and related tests but NEVER run the full suite and then when it finishes the workflow runs all the tests -- if it works, great, if it doesn't then the workflow continues, feeds the output to a cheaper LLM to summary the errors and then get another run to actually fix it, based on the failures and the context based on what should be implemented.
-- note: I've been full time in Beolis for some months already, feedback welcome ;)
I'm in the same boat and I'm not a fan on the current way of working of agents, but I think tooling is what needs to catch up.
So, I actually decided to try to tackle it myself and worked some months (full time) on it.
https://beolis.com is the result of that, it's a local cli in a kanban board style with a remote server to keep the team on track (I've been using it myself for some time and actually started to ask some friends to use it just yesterday -- feedback very welcome, I still wanted to do some additional things before asking more people to use it, but oh well, I'm a fan of building in public anyways and it's probably better to have feedback sooner rather than later).
The main point there is that you work mostly in the ticket description (your own spec) and the plan (the spec as the agent sees it, generated with a custom workflow) and then having another custom workflow to implement it (you can choose how you want it -- https://beolis.com/blog/post/custom-coding-workflows has some info on what I'm using myself).
As a result, at least for me, I do spend more time immersed in a flow state (although I'm in that state writing the specs and reviewing code -- although in some cases it's more work to write the spec in a way the agent can work when things get more complicated vs just diving into the code, so, going into "code" mode is something I still have to do, agents are definitely not perfect).
I guess I'm lacking in docs on how to effectively use it. I have plans to create a video next week and post it in the blog, so, if you're interested, keep track of it ;)
I wouldn't trust anything from Claude here image-wise (maybe to get a 2nd opinion on the report itself and treatment it's reasonable), but also, on the cases there is something something serious, go to at least 2 different doctors and if they have different opinions go for a 3rd for a decisive vote, besides doing your own research (it's not that uncommon for hard cases to be badly diagnosed).
Compared to many countries Brazil doesn't have such high taxes (I'd say that if you work remotely for a company outside of Brazil, you'll probably have much lower taxes compared to almost any other country -- working locally the difference isn't as big, but you have higher taxes in many other places).
What it really lacks is access to capital (which is the real "mojo" of the US compared to the rest of the world).
I agree it's hard to get it to output things in different styles... I started doing a side project for writing with LLMs (ailivrum.com -- my main focus being doing some writing/reading for my younger daughter right now, although I'm structuring for others to use it too).
So far what I found is that doing prompt engineering does not yield great results. LLMs just go with their own style regardless and I had not much luck changing it... it can do some interesting stories though, but it's far from just outline + prompt > gen story to get something that's readable (on the good side, there are many LLMs, so testing a different provider may give better results).
Initially I believe Google was known for getting unreliable hardware with good software to manage it (a single laptop probably won't cut it, but a bunch of laptops scattered around the globe could be interesting -- when you grow things fail all the time anyways).
Static analysis of imports should be solved by mypy (or your favorite static analyzer).
I guess you meant "run all imports at startup is desirable to check if they work", but I have a hard time agreeing with that (personally I think having a good test suite is needed, whereas running more code at startup is not wanted).
It'd have been really nice to have that PEP in as it'd have helped me not have to write local imports everywhere.
As it is, top-level imports IMHO are only meant to be used for modules required to be used in the startup, everything else should be a local import -- getting everyone convinced of that is the main issue though as it really goes against the regular coding of most Python modules (but the time saved to start up apps I work on does definitely make it worth it).
I believe this view is actually outdated -- it was actually true in the past, but I know that currently "Cognitive Behavioral Therapy" does define things much more objectively than previous approaches...
It's a bit unfortunate that people out of the psychology area don't even really know that there are multiple different Psychotherapies approaches and that they vary wildly in how problems are tackled/studied (source: my wife works in the area).
Yes, PyLance has a pretty strict license and makes it very clear it cannot be used in forks (and that's not really surprising and pretty standard I'd even say for a corporation such as Microsoft, it's like the current licenses saying this is open source but cannot be used by competitors, what's really surprising for me is that forks are choosing to ignore this):
> INSTALLATION AND USE RIGHTS. a) General. You may install and use any number of copies of the software only with Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server, and successor Microsoft products and services (collectively, the “Visual Studio Products and Services”) to develop and test your applications. b) Third Party Components. The software may include third party components with separate legal notices or governed by other agreements, as may be described in the ThirdPartyNotices file(s) accompanying the software.
One thing I don't understand is how forks (I'm actually talking about Cursor which is one I'm actually evaluatinng) are getting away with scrapping all extensions from the VSCode marketplace... I even e-mailed them but had no official position on that. Maybe they have some separate contract with Microsoft -- they do have OpenAI backing, so, maybe they have some bridge there, does anyone know? Or maybe Microsoft is just waiting to see how they themselves can profit for it and so is taking no legal action at this point?
-- disclaimer: I'm on the author of PyDev and I do have my own Python extension that I publish to VSCode and OpenVSX (https://marketplace.visualstudio.com/items?itemName=fabioz.v...)... it's completely Open Source in Eclipse, but for VSCode it's currently commercial. I discovered that's a nice way to have less people requesting support, even though 99% of it is still Open Source ;)
Particularly, I'd say that it would be awesome and could save sports which are graded based on such rules as the current state of affairs is pretty appalling (I hate seeing competitions which are graded based on subjective things and judge biases, for me it's the opposite -- such biases make seeing these sports maddening for me up to the point that I prefer not watching at all as I'm 100% sure it's unfair from the start).
Well, I'm working on reimplementing the pydevd debugger to use it.
The general idea is that pydevd will be able to use that API instead of relying on sys.settrace (which was perceived as slow in general -- pydevd got by because it had a bunch of tricks to just trace the needed contexts but implementing a fast debugger in Python with it is pretty hard).
My initial results are still mixed -- i.e.: on some cases it's definitely faster -- such as when tracking exceptions, but at this point in all other scenarios it's still slower (it's pending a few profiling sessions and I already have some ideas on where to improve), but I'm still not sure it'll ever be as fast as the version that can hook into the python frame eval and change the bytecode for the function to add programatic breakpoints... time will tell (but that approach is also very hard to keep up to date on new python releases, so, I'll probably end up deprecating it as I don't have enough time/resources to keep it up to date).
Anyways, I have most tests already passing, but I have to do a few profiling sessions before the initial release. I guess there's no much point in saying: here's a new version of the debugger using sys.monitoring -- does the same but is slower ;P
> However, no IDE will show any problem with this code.
That's not entirely True... I just checked it here and Eclipse/PyDev does flag this correctly -- since version 11.0.0 ;)
See: https://www.pydev.org/history_pydev.html (Imports found inside a typing.TYPE_CHECKING will be considered undefined if the scope that uses it requires it to be available when not type-checking).
Actually, you get the speed increase if using threads on python with numpy because numpy will release the GIL internally, so, operations using numpy will actually run in parallel (i.e.: c libraries can release the GIL and do get the performance benefits when using multiple processors -- although yes, when you get back to running python code that won't be parallel due to the GIL).
I did work in Smalltalk in the university and I must say that in practice it was horrible to work with.
It was very common to have the image corrupted -- imagine that you by mistake add a bug to your code. Now the live version you're dealing with is just unworkable and you have to find the last version that worked (because in practice the code you add is live with the code of your whole system in just a single place, so, anything bad you did affected not only your target env it also affected your dev env).
-- version control was basically saving the whole image and no, you didn't have a way to diff 2 different images.
I think that the current state where you edit text files and run your code based on those (and which you can sanely version control) and edit with a separate IDE is a much saner approach.
The system as a whole is meant to support that use case, where each task (ticket in its jargon) can be tackled using a custom workflow that can each use a different agent/llm (so, it should support local LLMs if you have configured your coding agent to use them).
Sidenote: it's still not where I want, but getting there...