"New model economics"

Beagle SCM

"New model economics"

Yesterday, I posted my piece on the Darwinist revision control system for codebase evolution. Surprisingly, Cursor folks posted "Agent swarms and the new model economics" which touches upon agentic swarms, agentic revision control and the development process in general. In particular, they rediscovered the tree-like hierarchical pattern for agentic organization, which is interesting. Given this massive topic overlap, I feel it is worth the time to comment.

The post concludes:

With swarms, the unit of work becomes the spec.<br>For that to work, the swarm has to actually follow the spec, which is what much of this post is about. We gave the swarm 835 pages of prose and it came back with a database. What was scarce in this experiment, and what we expect to be scarce in software engineering going forward, is the right description of intent.<br>Seen this way, the swarm starts to resemble a compiler. A compiler translates source code down to machine code through a series of intermediate steps. The swarm does something similar with intent. Planners parse a goal into task trees, then lower it step by step into executable work. The difference is that a compiler preserves meaning at every step while the swarm is probabilistic at every one. Everything described in this post exists to close that gap.

Whether agents are the new compilers is an old debate, but the interesting question is elsewhere. Or, more precisely, right here. Where did the 835-page spec come from? Was it written out of the blue by Dr. Hipp? Nope. Was it vibed? Nope. So, where did it come from? Right, it co-evolved with the code. Neither was it code→spec nor was it spec→code. Both spiraled into existence based on the objectives, the progress, and the feedback that was channeled into the project by different means.

Essentially, the Cursor folks regenerated half a project (the code) from the other half (the spec), plus sqlite code in the training set, plus all the relevant discussion and textbooks absorbed at that stage.

The code did not face diverse real-world workloads to evolve based on that (primary) feedback. Nor did it absorb real-world expert feedback at any stage. In fact, the authors admit they did not bother to study the resulting code and delegated that work to the reader.

In my previous piece I advocated for letting LLMs automate themselves away in favor of fast, cheap and reliable deterministic tools. But, what do we do if a probabilistically "compiled" solution can not be verified formally? The only convincing response so far comes from natural selection. Try more solutions, see which ones work, then mix and repeat. In fact, fully evaluating a solution is a large and expensive task, so let's optimize that part.

Beagle bets on a tree-of-agents approach, but in a different sense, more like a family tree. Agents pursue different lines of development; the user is free to pick the interesting ones and recombine them. When the effort is this cheap, gradual evaluation and propagation of good finds is most of the work!

RSS feed<br>Beagle SCM GitHub<br>JAB runtime GitHub<br>BlueSky