Litt argues that LLMs collapsed the cost of producing code toward zero, but the cognitive work of understanding whether code is correct, fits the system, and will survive future requirements did not get cheaper — it got more expensive because there is more code to review and less of it was written by anyone on your team. He frames this as a phase change rather than an incremental shift, noting that reviewing AI-generated diffs is a fundamentally different cognitive activity than reviewing your o
By submitting Litt's essay to Hacker News where it accumulated 291 points, sebg surfaced the argument to a wide developer audience. The strong front-page traction on a personal essay with no product or benchmark suggests the framing resonated with practitioners feeling the same friction.
Litt observes that senior engineers read code by recognizing patterns they've written before, but AI generators have no consistent style, no memory of last week's decisions, and no stake in the outcome. This breaks the muscle memory that made experienced developers fast at review, meaning seniority translates less directly into speed when the code came from a model.
The editorial cites a recent METR study measuring experienced open-source developers as 19% slower when using AI assistants on their own repositories, even while those same developers reported feeling faster. This suggests the acceleration narrative is real for greenfield and prototyping work but patchier for maintenance and actively negative where deep context matters.
Geoffrey Litt — Ink & Switch researcher, longtime end-user-programming thinker, and one of the more careful voices writing about LLMs and software — published "Understanding is the new bottleneck" on July 2. It hit the Hacker News front page and stuck there with 291 points, which for a personal essay with no launch, no benchmark, and no product is a signal worth reading.
The thesis is compact. For most of software history, the rate-limiting step was producing code: typing, wiring, plumbing, remembering syntax. LLMs collapsed that cost toward zero. But the other half of the job — understanding what the code does, whether it's correct, whether it fits the system, whether the abstractions will survive contact with next quarter's requirements — did not get cheaper. If anything, it got more expensive, because now there is more code to understand and less of it was written by anyone on your team.
Litt frames this as a phase change, not an incremental shift. Reviewing a 400-line diff you wrote yourself is a different cognitive activity from reviewing a 400-line diff a model produced from a prompt you half-remember writing forty minutes ago. The muscle memory that senior engineers built up over a decade — reading code by recognizing patterns you've written before — partially breaks when the code was generated by a system that has no consistent style, no memory of last week's decisions, and no stake in the outcome.
The timing is what makes the piece land. We are two years into the "AI will write all the code" narrative, and the honest reports from the field are converging on something quieter: the acceleration is real for greenfield work and prototyping, patchier for maintenance, and actively negative in codebases where the reviewer doesn't have deep context. A recent METR study measured experienced open-source developers as 19% slower when using AI assistants on their own repos, even while those same developers reported feeling 20% faster. The gap between felt productivity and measured productivity is exactly the gap Litt is naming.
Compare this to what senior engineers have been quietly saying in Slack DMs for a year: the PRs are getting longer, the tests are passing, the linter is happy, and yet the review queue feels worse. You're not reading code anymore — you're auditing it. And auditing without the mental model that comes from having written the thing is a job humans are demonstrably bad at. Aviation figured this out with autopilot decades ago; the term of art is "vigilance decrement" and it kicks in within twenty minutes.
Litt's contribution is naming the failure mode cleanly enough that you can design against it. The pieces of the job that scale linearly with code volume — reading, tracing, holding invariants in your head, deciding whether a change is safe — do not have a Cursor equivalent yet. The bottleneck isn't the keyboard; it's the working memory of the person who has to sign off.
There's a useful contrast with the EleutherAI-style reproducibility work happening in ML. In that world, the community learned the hard way that generating results is trivial and verifying them is the actual job — hence evaluation harnesses, deterministic seeds, and the whole apparatus of open weights + open eval code. Software engineering is currently rediscovering the same lesson at the application layer. The generation side has a hundred well-funded products. The verification side has, roughly, `git diff`, code review, and vibes.
The community reaction to Litt's post on HN and X splits along a predictable line. One camp reads it as a call to slow down and invest in comprehension tooling — better diff summarizers, provenance tracking, tests that generate themselves from specifications rather than from the code being tested. The other camp reads it as a transitional problem: once agents can review their own code and iterate against a spec, the human comprehension step becomes optional for a growing fraction of work. Both camps are probably right about different segments of the codebase, and that's the interesting part.
Practical implications, if you buy the frame:
Stop measuring PR throughput. If your team ships 3x more diffs but the reviewer bottleneck is the same human, you've moved the queue, not the constraint. Measure time-to-understanding: how long from PR-open to a reviewer who could confidently answer "what breaks if we revert this in six months?" If that number is going up, generation speed is a liability, not an asset.
Invest in the reverse direction — code-to-explanation, not prompt-to-code. The highest-leverage internal tool most teams don't have is a diff explainer that operates on your codebase's actual conventions, not a generic LLM summary. Something that says "this PR touches the billing invariant defined in `lib/pricing.js:47`; here's why the old contract held and why the new one still holds." This is the mirror image of Copilot and roughly nobody is building it well.
Enforce spec-linked changes for anything touching money, auth, or data. The pattern that's working in early-adopter teams: every AI-generated PR must reference a written spec or property test that expresses the intended behavior in a form independent of the code. If the model can't write the spec, it doesn't get to write the code. This is slower on the front end and dramatically faster on the back end when something breaks at 2 AM and someone new is on-call.
Rotate ownership deliberately. The team member who accepted an AI-generated module three months ago probably doesn't understand it any better than a fresh hire would. Assume no institutional memory unless there's a written artifact — a design doc, a diagram, a comment explaining the non-obvious choice. If the only record of a decision is in the model's context window, the decision is unowned.
The next competitive edge in engineering orgs won't be who adopts Cursor or Claude Code first — that race is already run. It'll be who builds the comprehension layer on top: the internal tooling, the review discipline, the specs and invariants that let a team ship AI-generated code without losing the plot. Litt's essay is short and doesn't propose a solution, which is honest — nobody has one yet. But naming the bottleneck is the first move, and the teams that internalize it now will look, in eighteen months, like the ones who took code review seriously in 2014.
We have LLMs try to generate descriptions of PRs for us and they're pretty universally disliked. They're always overly-complex descriptions of the mechanical changes and have no sense of motivation.Also, a huge reason to understand the code yourself is to make sure the LLM isn't wrong
I agree with the problem but not the solutions.The problem pre-dates LLM's: writing code that "works" but breaks the underlying model. Because it works, it always sounds reasonable and doesn't raise any flags.Only someone - human or LLM - who holds the model as the standard would
It's more like this:We've always lacked understanding. However, it didn't feel like a bottleneck; in spite of lacking understanding, we developed huge, complex systems that became hard to maintain and that nobody understood completely.Now we want to scale that orders of magnitude, but
"I read the code." -Mitchell HashimotoGreat code needs great understanding and agents need excellent guidance. Even in my current solo-dev work, I can't imagine making a production commit I haven't read until I understand it. I own the consequences of my code; that's a respo
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I think it funny how much average engineers are beginning to discover the challenges of engineering leadership and program management. This has always been the bottleneck.It's why managers and PMs want to be in standup. It's why slack exists and engineers are constantly being poked on it.