What a $1,339 SQLite tells us about the future of engineering
Team Flows in the AI era · July 2026
Last week, Cursor published an experiment with a striking price range. Four teams of AI agents rebuilt SQLite from scratch in Rust, working from its 835-page documentation. No source code, no test suites, no internet access. Graded against sqllogictest — millions of queries with known correct answers — every configuration eventually passed 100%.
The cost to get there ranged from $1,339 (Opus 4.8 as planner, Composer 2.5 as worker) to $10,565 (GPT-5.5 doing everything). Same quality. Eight times the price.
These numbers reward a long look, because they point at something deeper than a benchmark result. They sketch how the economics of AI-assisted engineering are reorganizing — and what role is left for the humans in the loop.
Planners, workers, and the tree
The architectural idea is simple. Two roles: Planner agents, powered by frontier models, decompose a goal into pieces and delegate. Worker agents, powered by cheaper models, execute the pieces. The swarm's shape grows organically to cover the problem's contours.
This is harder to realize than it sounds. Cursor had to build a custom version control system from scratch because the old swarm (Git-based) peaked at 1,000 commits per hour; the new one runs at 1,000 per second. Every change passes through this VCS, so it's where collisions become visible first. The failure modes at that velocity are ones human teams don't routinely see: split-brain design where two planners implement the same concept differently; planner contention where agents fight over the same files; megafiles bloated by many small contributions; ossification where agents learn not to touch core code.
Each got a custom fix. Split-brain got solved through prompting — planners make design decisions themselves rather than delegating them, and must ensure no two subtrees decide the same question. Contention got a shared design doc system with compile-checked references. Megafiles got a flagging mechanism where an outside agent decomposes bloated files. Ossification got licensed intentional breakage — agents that judge a core change worthwhile make a focused patch and leave a comment, and the compiler propagates the change through every dependent piece of work.
The through-line is that coordination costs grow faster than the work itself. The economist Ronald Coase made this argument about firms in 1937: organizations settle into tiers of bounded units because letting everyone talk to everyone doesn't scale. Cursor's swarm infrastructure — the VCS, the reconcilers, the review stack — is doing the same thing for agents, but at a velocity that makes human coordination mechanisms look like postal mail.
Where the money goes
In every run, worker models carried at least 69% of the tokens, and over 90% in most. But the cost split the other way. In the Opus + Composer mix, the planner produced a fraction of the tokens but roughly two-thirds of the bill. Frontier tokens are expensive; worker tokens are cheap.
The workers wrote almost everything, but the planner decided what to write. Only a handful of moments in any large task genuinely demand the full capacity of a frontier model: the initial decomposition, the high-risk design calls, the nuanced trade-offs. Everything downstream is execution. The difference between the cheapest and most expensive runs is essentially the difference between paying for frontier judgment only where it matters versus paying for it everywhere. And since the quality was equivalent, the expensive runs weren't buying better outcomes. They were buying a simpler architecture — one model, no orchestration — at a premium.
The swarm as a probabilistic compiler
The framing that keeps surfacing for me is the compiler analogy. A compiler translates source code through intermediate representations into machine code, preserving meaning at every step. The swarm does the same with intent — parsing a goal into task trees, lowering through steps into executable work — except it's probabilistic at every stage.
That means the gap between what you ask for and what you get has to be closed by engineering infrastructure, not guaranteed by the model. The VCS, the review lenses (multiple decorrelated reviewer agents catching different error classes), the stigmergy-based Field Guide (a folder agents curate collectively, injected into every agent at start), the merge resolver — all of it exists to make the probabilistic pipeline more deterministic.
The Field Guide is the most interesting piece. Cursor describes it through the lens of stigmergy — ant colonies coordinate by shaping their environment, and the shaped environment guides the next ant. The insight is that model weights don't change mid-run, so the only way to get better is to capture surprise encounters as they happen and inject them into the next agent's context. The agents decide what goes into the guide, constrained only by a line budget. They're writing institutional memory for their successors, in real time, because a cheaper next-token prediction beats re-deriving the same lesson.
Specs as the unit of work
The experiment's most provocative finding is about scarcity. The bottleneck isn't compute or model capability — it's the quality of the specification you feed the system.
Each jump in AI capability has raised the abstraction level for engineers. Autocomplete let you work one line at a time. Early chat models raised that to a block of code. Agents raised it to a file or feature. With swarms, the unit of work becomes the spec. You give the system 835 pages of prose and it returns a database.
The practical consequence is that the bottleneck shifts from "can we build this" to "can we describe what we want clearly enough." This is an uncomfortable inversion if you've spent years in engineering culture. Writing specs has historically been the part everyone tries to skip. The code is the truth; the spec is aspirational fiction that drifts. But in a swarm-based workflow, the spec is the only artifact that matters. Everything else is derivative.
The Cursor team built an impressive stack to close that approximation gap. The question their results raise for me is what we build on the human side. If describing intent is the scarce skill, how do we get better at it? How do we teach it? And what happens to engineers whose expertise is in the execution layer that's now being handled by Composer 2.5 at a few dollars per hour?
I don't have answers. But the SQLite experiment makes the question concrete. When you can rebuild a database from its documentation for $1,339, the thing that matters is the quality of the documentation — and the quality of the question you asked to get it written.
The Cursor team's full post is at cursor.com/blog/agent-swarm-model-economics. The public codebase from the Opus 4.8 run is at github.com/cursor/minisqlite.