fabioz
Joined 11 years ago
Joined 11 years ago
It still leverages agents (people are used to them already) but can deal with executing it on a different vm, dealing with git worktrees, etc (not that coding agents themselves cannot be improved, but I think the sw development infrastructure around it has a lot to improve too).
CORRECTION NOTICE: We've since found a compiler bug in LLVM 19 that artificially boosted the new interpreter's numbers. The numbers are closer to geomean 3-5% speedup. I apologize for reporting incorrect figures previously due to the compiler bug.
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'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.
-- note: I've been full time in Beolis for some months already, feedback welcome ;)
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 ;)
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).
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).
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).
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).
At least that's what I'm using in https://beolis.com (so, you can use the actual harness you like and just have a proper UI to manage agents over it).