The coding agent stack

The model can already write the code. The next race is running agents in parallel, serving them cheaply, and trusting what they ship.

Coding is now the killer app for AI agents, and it isn't close. Programming jumped from roughly 11% of all LLM token volume in early 2025 to more than 50% over the course of the year, according to OpenRouter's State of AI 2025 study.

In under a year, writing software became the biggest thing people do with large language models. The revenue followed the tokens: Cursor reached about $4B in annualized revenue in under four years and recently agreed to a $60B all-stock acquisition by SpaceX, and Claude Code crossed a $1B run-rate within six months of launch. Every developer we talk to has a "that demo blew my mind" story.

We think the first wave is basically settled. The model can write the code. The interesting question for the next few years isn't whether agents can generate code, it's everything that happens around the model: how we run agents at scale, how we serve them when compute is scarce, and how we trust what they ship. That is where we are spending our time at Gradient, and where we think the next set of category-defining companies gets built.

As coding adoption deepens, the bottleneck stops being model capability and becomes two things in short supply: human attention and compute. A coder's focus drifts in the minutes an agent takes to finish, and no human can review the volume of code a fleet of agents produces. Compute is the other wall, and coding hits it first because it is the most token-hungry workload on the network.

So phase two opens along three fronts: a reimagined coding interface, an inference stack built for coding economics, and a new layer for verification.

Interface: we'll run coding agents in fleets, not one at a time

The one-developer-one-agent workflow is already breaking. A single agent now takes minutes to hours to finish a task, and by the time it returns, the developer has moved on. The rational move is to spawn many agents across many tasks and spend human attention only on the best outputs, the way a manager runs a team instead of doing all the work themselves.

But a fleet is not 10 terminal windows. Ten parallel Claude Code sessions in tmux produce 10 disconnected PRs that all still need separate human review, which doesn't move the bottleneck at all. Real fleet management decouples the stages of shipping software (plan, code, review, and merge) and orchestrates agents across the whole pipeline, not just the code-gen step. Otherwise the fleet just generates a high volume of mediocre code that sits in PR queues and never ships.

The next generation of interfaces has to be parallel-first, with every agent working in an isolated sandbox. Planning docs become shared artifacts the whole fleet works from. Review and merge stop being human chokepoints: agent reviewers run their own validation loops, and changes trigger CI automatically. A few teams are already building here. Emdash runs a fleet of coding agents on any machine, from a dev server to a cloud VM to a GPU box. Superset is fully scriptable, exposing a GUI, CLI, MCP server, and TypeScript SDK to drive the fleet. Conductor adds a review step to a one-click worktree-to-PR flow. The larger players are moving in too: Cognition recently launched Devin Desktop to manage agent fleets from a single surface.

Once interfaces are designed around swarm semantics, human attention shifts from unpredictable waiting to orchestration, and the work moves up the stack: redesigning microservices, optimizing cost, and choosing better vendors. The job starts to look less like coding and more like running an engineering org.

Infrastructure: coding needs its own inference stack

More parallel agents ship more code, and they push demand against compute far faster than supply can grow, because coding is unusually token-intensive. Even as proprietary models like Sonnet 5 drive down costs, the heaviest coding workloads still break closed-API economics. Every system prompt carries the codebase and tool definitions, running several times higher in input tokens than a typical non-coding task. The strain is already visible. Anthropic has capped Claude Code with weekly usage limits because heavy users on a $200-a-month plan can burn well past that in token cost. Microsoft is canceling internal Claude Code licenses across its Experiences and Devices division and steering engineers to GitHub Copilot, and Uber burned through its entire 2026 AI budget in four months, with per-engineer costs reaching $500 to $2,000 a month for heavy users. Coding demand scales like software, but compute scales like chips and data centers, and that gap is the opening.

As closed-source prices hold and demand accelerates, the market needs another path, and open source is now a real one. MiniMax M2.5 is within a few points of Claude 4.5 Opus on SWE-bench at 10X lower cost, with GLM, Kimi, and DeepSeek close behind, while open-source harnesses like Aider, Cline, and Opencode are already in real engineering workflows. You can now build a fully open coding stack with no proprietary dependency: self-host the model, run a harness on top, and skip the subscription squeeze entirely.

But simply bolting a coding harness onto a generic inference service isn't enough. Coding has inference characteristics that horizontal providers don't optimize for: long, sticky system prompts and a high accuracy bar. The two clearest gaps are prefix caching and quantization. Most of a coding session's system prompt is identical from one turn to the next, but a generic engine treats every request as stateless and recomputes the prefill from scratch, paying up to 10x more on those tokens than a coding-aware engine would. Quantization compounds it: providers run FP4 or INT4 to protect per-token margins, which is fine for generic chat but risky where coding demands exact output like function calls and diffs.

Closing these gaps takes a stack co-designed so the harness, inference engine, and model layer are aware of each other. Done well, a coding-native open stack doesn't just fix caching and accuracy. It can route by request, hot-swapping LoRA adapters per language or task instead of running one big, expensive model for everything. Startups like Synthetic and Crush/Hyper are pairing open-source coding agents with dedicated inference on exactly this bet. Enterprises are already there for their own reasons: JPMorgan runs open-source coding agents in-house because of privacy mandates and because closed-source token pricing breaks at their scale. Whoever builds the open, fully optimized coding serving layer can close the supply-demand gap without sacrificing performance.

Verification: 10x more code demands 10x more trust

Cheaper inference and parallel interfaces let agents ship more code than ever, so the bottleneck moves again, from generating code to trusting it. The reflex is more testing and review, and an AI-native layer already exists: CodeRabbit, Graphite, Greptile, and Qodo review PRs and auto-generate tests. But those tools optimize the workflow, they don't guarantee correctness, and one agent reviewing another is non-deterministic and prone to shared blind spots. Skipping a formal proof of correctness is fine for routine work and dangerous for mission-critical systems. A coding agent has already wiped a company's production database, and a recent study of more than 300,000 AI-authored commits found that over 15% introduced at least one issue, with 24.2% of those issues surviving review and still live in the latest version of the repo. When code “LGTM” but isn't, AI review can't tell the difference.

Two approaches are emerging. Formal verification, led by Harmonic, Logical Intelligence, Theorem.dev, Aretta, and Galilei AI proves code correct against a specification mathematically rather than by testing. Built on theorem provers like Lean 4 and SMT solvers, it turns code into a machine-checkable spec and generates a proof when new code lands. The technique has lived in physical domains like aerospace and chip design, and it can now target software like databases, IAM, and cloud infrastructure, where a single agent-introduced bug can become a nine-figure incident. The second approach is trace verification: the open-source project Maida diffs an agent's execution trace against a baseline and flags behavioral regressions, like unexpected tool calls or new loops, that only show up once the trajectory has quietly broken.

The space is early. Formal methods are compute-costly, since every function needs a spec and a proof. Trace verification flags deviation, not correctness, so a refactor and a regression can look the same. But the direction is clear. Whoever makes verification cheap and adaptive enough to let agents run autonomously while preserving correctness owns the sharpest wedge into the coding agent 2.0 era.

What we're backing at Gradient

The first wave of coding agents answered one question: can the model write the code? It can. The second wave is about everything around that: running fleets in parallel, serving them at lower cost, and trusting what they ship. Those are three distinct company-building problems, and we think the winners in each will matter as much as the model labs themselves.

The model can already write the code. The companies that decide whether we can trust it, at volume and at cost, are the ones still to be built. That's the layer we're backing.