The Comprehension Economy
Developers spend 58% to 70% of their time understanding code, not writing it. The industry spent three years optimising the smaller half — and increased the load on the constraint.
For fifty years the software industry has optimised the wrong half of the job, and it took making the other half nearly free to expose it.
Study after study on program comprehension lands in the same range: developers spend between 58% and 70% of their time understanding existing code rather than writing new code. Robert Martin's formulation — the ratio of reading to writing is well over ten to one — is a practitioner's version of the same finding.
So when the industry spent the last three years making writing dramatically cheaper, it was optimising something between a tenth and a third of the work.
That would merely be a missed opportunity. What makes it a problem is the second-order effect: cheaper writing produces more code, and more code has to be understood by somebody. The constraint was comprehension. The innovation increased the load on the constraint.
What the data shows happening
DORA's research provides the code-level fingerprints, and they are consistent.
Copy-paste rates rose from 8.3% in 2021 to 12.3% in 2024. Refactoring rates fell from roughly 24% to under 10%. Duplicate code blocks increased about eightfold year over year in 2024.
Each of those is a comprehension signal in disguise.
Copying instead of adapting is what you do when you do not fully understand the thing you are reusing. Adaptation requires knowing which parts are essential; copying does not.
Refactoring collapsing is decisive. Refactoring is the activity that requires comprehension — you cannot safely restructure what you do not understand. A halving of refactoring while code volume rises is a direct statement that understanding is not keeping pace with production.
Duplication compounding is what happens next. Each duplicate is a place where a future change must be made twice, by someone who has to first discover that both exist.
None of this requires assuming AI writes bad code. Assume it writes excellent code. The signals still follow, because the bottleneck was never quality of output — it was the human capacity to absorb it.
The debt that is not technical debt
Technical debt is a well-understood idea: shortcuts taken deliberately, to be repaid later, with interest.
What is accumulating now is different, and it needs a different name. Call it comprehension debt: code that works, is not badly written, and that nobody in the organisation understands well enough to safely change.
It is worse than technical debt in two ways.
It is invisible. Bad code looks bad; a code reviewer can point at it. Code that is fine but unowned looks exactly like code that is fine and owned. Nothing in your static analysis flags it.
And it does not decay gracefully. Technical debt makes changes progressively harder. Comprehension debt is binary: everything is fine until somebody needs to change that part, and then it is a research project. There is no warning slope, only a cliff.
The interest is paid at the worst moment — during an incident, or when the one person who understood it has left.
Why the shortcut does not exist
The tempting fix is to have AI do the comprehension too. Ask it to explain the code.
This works better than it used to and it has a ceiling that matters. Most assistants read code, which means they can tell you what a function does. The comprehension that is actually scarce is not "what does this function do" — it is why does the system behave this way, what depends on this, what happens end to end, what will break. Those answers live between files, and a system reading fragments has to reconstruct the relationships. Reconstruction is where errors are introduced.
METR's controlled trial is the empirical version of this ceiling: sixteen experienced developers, working on repositories they knew well, were 19% slower with AI while believing they were 20% faster. The people with the most comprehension got the least help — because their advantage was exactly the thing the tool could not receive.
What this means for how you run a team
If comprehension is the constraint, several standard practices are aimed at the wrong target.
Velocity is measuring the cheap half. Story points count production. If production has become cheap and comprehension has not, velocity can rise while throughput of finished, trusted work stays flat. Which is precisely what many teams report.
Onboarding is a comprehension problem with a hiring label. "Time to first meaningful contribution" is the purest measurement of comprehension cost in your organisation, and most companies do not track it.
Documentation is the historical attempt and it failed structurally. Not through laziness — because a manual snapshot competing against shipping always loses to the rate of change, and a stale page poisons trust in the fresh ones next to it.
The bus factor is a comprehension metric. How many people could safely change the billing system? If the answer is one, you have comprehension debt with a name attached to it.
What to do
Measure time-to-understanding, not just time-to-merge. For a sample of changes, record how long passed between picking up the work and being confident about what to change. That interval is your comprehension cost and almost nobody tracks it.
Treat rising duplication as a leading indicator. Duplication climbing while refactoring falls is the earliest visible sign that production is outpacing understanding on your team specifically.
Make understanding reusable rather than personal. The default is that each person reconstructs how the system works, privately, and the organisation pays for that reconstruction once per person per question, forever. Anything that makes an established answer reusable — with its evidence attached, so the next person can check rather than re-derive — attacks the actual constraint.
Stop counting production. If you take one thing: the number of lines your team produces has never been less informative than it is now. What matters is how much of your system your organisation can confidently change, and that number has almost certainly not improved in three years.
The reframe
Software has quietly stopped being a production industry and become a comprehension industry. Making things was the constraint for fifty years; it is not any more.
The companies that will move fastest over the next few years are not the ones generating the most code. They are the ones where the largest number of people can confidently answer what happens if we change this — and that is a different investment from the one most engineering budgets are currently making.
Put a number on your own workflow
Bring us the recurring workflow where AI still needs expensive people to supervise, review and correct. We baseline what it costs and put the target in writing before we build. Or connect a repository and see it on your own code first — 1,000 credits free, no card.
Build My Business Case → Start free →Frequently asked questions
How much time do developers actually spend understanding code versus writing it?
Research on program comprehension consistently places it between 58% and 70% of working time, with the reading-to-writing ratio commonly put at more than ten to one. Which means the industry's focus on making code generation faster targeted somewhere between a tenth and a third of the actual job.
What is comprehension debt?
Code that works, is not badly written, and that nobody in the organisation understands well enough to change safely. Unlike technical debt it is invisible to code review and static analysis, and it does not degrade gradually — everything is fine until someone needs to change that part, at which point it becomes a research project.
Why are duplication and refactoring rates useful signals?
Because refactoring requires comprehension — you cannot safely restructure what you do not understand — while copying does not. DORA data shows copy-paste rising from 8.3% to 12.3% between 2021 and 2024, refactoring falling from about 24% to under 10%, and duplicate blocks up roughly eightfold. Together they say production is outpacing understanding.
Can't AI just do the comprehension work too?
Partly. It handles "what does this function do" well. The scarce comprehension is why the system behaves as it does, what depends on a thing, and what will break — answers that live between files and must be reconstructed from fragments. In METR's trial, the developers with the most existing comprehension were slowed the most, because their advantage was the part the tool could not receive.
What should engineering leaders measure instead of velocity?
Time-to-understanding — how long between picking up work and being confident about what to change. Plus time to a new hire's first meaningful contribution, the number of people who could safely change each critical area, and the monthly trend in duplication against refactoring.
Related articles
The 19% Problem: What a Controlled Trial Revealed About AI and Developers
A randomised controlled trial found experienced developers were 19% slower with AI — while estimating they were 20% faster. The detail everyone skips explains why.
Why AI Gets Your Own Codebase Wrong
Your assistant is excellent at code it has never seen and unreliable about code you wrote yourself. The cause is structural: the distance between the way you asked and the form the tool can compute over.
MCP, Explained for Engineering Teams
What the Model Context Protocol actually is, why it turns an N×M integration problem into N+M, and the question to ask a vendor that 'we support MCP' does not answer.