How AI Coding Actually Works now

The most interesting AI coding stats are the boring ones

A recent issue of The Pulse published a set of usage numbers from Cursor. Most coverage of AI coding tools is either a demo or a complaint. This was neither: it was aggregate telemetry from one of the most-used agentic editors, and it quietly answers questions that benchmarks cannot.

The headline number is the one everyone will repeat. The numbers underneath it are the ones worth thinking about.

The productivity spread is enormous, and lines of code are a terrible unit

According to the data, a developer at the 90th percentile ships around 9,000 lines of code per week through Cursor, against roughly 700 for the median user. That is a 13x gap. The top 1% land somewhere between 30,000 and 40,000 lines weekly, comparable to the combined output of about 45 median developers.

Take the framing with care. Lines of code has never measured value, and it measures it less now that a model can produce a thousand plausible lines on request. What the spread does show is that the tool has a very wide skill ceiling. The same product, given to two competent engineers, produces wildly different throughput. That is a statement about workflow design, not about typing speed.

Ninety percent of the tokens go into reading

This is the finding we keep coming back to. Input tokens account for roughly 90% of Cursor's total token consumption. Once you account for caching, the picture sharpens further: cache reads are about 90% of usage, cache writes 2.5%, fresh input 7%, and actual generated output a rounding error at 0.6%.

In other words, an AI coding agent spends almost all of its effort doing what good engineers spend their time on. The report draws the obvious line back to Robert C. Martin's 2008 observation that the ratio of time spent reading code to writing it is well over ten to one.

Output tokens are 0.6% of usage. The other 99.4% is an agent reading your codebase before it dares to touch it.

Cost follows context, not generation

Input tokens are cheaper per unit, but sheer volume makes them roughly 70% of the cost of running a coding agent. The per-model comparisons are also more nuanced than a price list suggests. Anthropic's Opus 4.7 reportedly cost around 10x more per agent request than Cursor's own Composer 2.5. But measured by cost per accepted line, which factors in how often the output survives review, Opus 4.7 matched GPT-5.5 at half the per-request price, while Composer stayed about 5x more efficient than Opus.

These are Cursor's own figures on Cursor's own model, so read the comparison with the appropriate scepticism. The methodological point stands regardless: cost per request is the wrong metric. Cost per accepted change is closer to the truth, because rejected output is pure waste plus the human time spent rejecting it.

The number that should make you pause

Within a single month, the share of developers allowing AI-generated commits to land without manual review reportedly went from about 10% to around 40%, tracking the release of stronger models.

A 4x shift in review behaviour in four weeks is not a considered engineering decision. It is trust moving faster than verification, and it is the part of this dataset with real operational consequences.

How we read this at Birdhouse

We build agent-first, so these numbers describe our own working day rather than someone else's experiment. Three things we take from them:

• Context is the product. If 90% of tokens are reads, then repository structure, naming, docs and clean module boundaries are no longer just human ergonomics. They are agent throughput.

• Caching is architecture. With cache reads at 90% of usage, how you order and reuse context is a cost decision, not an implementation detail.

• Removing review is the wrong saving. Generation is 0.6% of the spend. Dropping human oversight to save on it trades your cheapest resource for your most expensive risk. We keep a person accountable for every merge, and we use adversarial review passes precisely because the output is now fast enough to outrun attention.

The tools got good enough that the bottleneck moved. It is not writing code, and it is not really reading it either. It is deciding what should be true about the system, then checking that what landed matches. That part has not been automated, and we would not want it to be.