Building in the Agentic Era, Part 2. By Mike
Agents can now write code faster than any team can understand it. That gap is the risk I'd watch most closely right now. I'm not talking about bad code. I'm talking about code that works, passes review, ships, and that nobody on the team can explain when it breaks.
I learned this the hard way. I built a software factory with agents, and at the start I could walk you through every component in detail. I'd picked the architecture and every piece in it. Then I set it up to improve itself. A few days of building later, I realized I didn't know what had actually been built. The way back was the same tool that got me there: I had an AI generate a full set of diagrams from the codebase. That got me back in the door. It also made the lesson hard to miss. If I could lose track of a system I designed myself in a few days, a team running agents across a whole product can lose track of a lot more.
In Issue 02 I wrote that the human hours don't go away when agents build. They move to the plan and the outcome. This week I want to look at what happens when those hours get thin. On Tuesday, Rishi wrote that the engineers who do well hold tight to the destination. That's hard to do when nobody on the team can read the map anymore.
New here? Two engineering leaders on building and leading with AI inside a large enterprise. Every Tuesday and Thursday, free, in your inbox.
The numbers caught up this week
A few things landed at once. On October 3, Futurism ran a piece on engineers who can no longer follow the code their AI tools produce. A few days earlier, a survey from Undo, a debugging company, put a number on it: 35% of AI-generated code reaches production before engineers fully understand it. The same survey found 79% of engineering leaders say their release cycles haven't sped up, even though writing code has never been easier.
Undo doesn't say how many people it surveyed, so I'd hold the exact figures loosely. The direction matches everything else I'm seeing.
Augment's State of AI-Native Engineering report, a survey of 219 engineering leaders, found that 55% rank understanding their codebase as their top concern. The part that stuck with me: almost none of them are doing anything about it beyond code review.
That's the gap. Leaders can feel the problem. Most of us are answering it with the same tool we already had.
Two names for the same problem
Addy Osmani calls it comprehension debt: the growing gap between how much code a system has and how much of it people actually understand. LeadDev calls it cognitive debt, the slow loss of understanding about what a system does and why.
Technical debt lives in the code. You can see it, search for it, and schedule time against it. Comprehension debt lives in what's missing from people's heads. It doesn't show up on a dashboard. Velocity looks great right up until something breaks and the person on call opens a file nobody has ever read closely.
That's when the bill comes. You pay it in time to diagnose, in fixes that miss the root cause, and in the slow loss of confidence that comes from running a system you can't explain.
Why code review won't save you
Code review checks a change. Understanding is about the whole system. Those used to travel together, because the person writing the change had to understand the system around it to write it at all. Agents broke that link. A change can be correct, reviewed, and approved, and still nobody holds the full picture.
Volume makes it worse. In Issue 02 I wrote about the rubber stamp: nobody reads hundreds of anything carefully. Agent-written pull requests show up faster than people can study them, so review drifts toward "looks fine, tests pass."
The newest answer is to have agents review the agents. Several of the big AI vendors now ship automated pull request review. I think that's useful, and it catches defects people miss. What it doesn't do is put understanding back in anyone's head. You end up with code written by a machine, checked by a machine, and understood by no one.
How to tell you're carrying it
You won't find comprehension debt in a report. Watch for these instead:
Incidents take longer to diagnose than they used to, even when the fix turns out to be small.
The answer to "how does this work?" is "let me ask the agent."
People re-prompt to change code instead of reading it first.
One person, or nobody, can walk through a critical flow from memory.
New people can't get up to speed from the docs, because the docs were generated and nobody checked them.
If two or more of those sound familiar, you're carrying the debt. The real question is how much.
What I'd do about it
Not everything needs deep understanding. A throwaway script or a one-time report doesn't need a person who can explain every line. So I'd start with the same grid from Issue 02. Where the cost of being wrong is high and you're slow to detect or roll back, you need people who understand the system. Everywhere else, you can choose to carry more debt, as long as it's a choice.
For the parts that matter:
Make the explanation part of done. A change isn't finished until someone can explain what it does and why, in plain language, without the agent open. The agent can draft that explanation. A person has to be able to defend it.
Name someone who can explain it. Every critical area needs at least one person who can walk through it from memory. Not the person who prompted it. The person who understands it. Two is better.
Read before you re-prompt. When something needs to change, read the code first. It's slower the first few times. That's the point.
Use the agent to teach. Have it generate architecture diagrams from the codebase, then explain the tradeoffs it made, what it considered and rejected, and where it's least sure. That turns the fastest writer on your team into a tutor. Just treat the diagrams as a starting point to check, not the final word.
Practice without the safety net. LeadDev suggests AI-free checkpoints, where people work through a problem before checking with AI. Short walkthroughs or incident drills on agent-built code do the same job.
Measure it. Track time to diagnose and how often the answer is "nobody knows," right next to velocity. If velocity goes up and diagnosis time goes up with it, you're borrowing.
Yes, this costs you some speed
All of this slows you down a little. That's the tradeoff, and I won't pretend it isn't there. Some of the speed agents give you has to go back into understanding what they built.
Teams that skip that step look faster for a while. Then they hit a bad outage, or the one person who understood a critical area leaves, and they find out what they actually saved.
If you try one thing this week: pick your most critical service and ask who can explain how it works without opening an agent. If the answer is nobody, you've found your debt.
A checklist you can steal
Copy it, change it, make it yours.
Before the work starts:
Place it on the cost and rollback grid. Decide how much understanding it needs.
Name the person who will be able to explain it once it ships.
While the agents work:
Ask the agent to explain its choices and the parts it's least sure about.
Read before you re-prompt.
Before you call it done:
Write a plain-language explanation of what it does and why, and make sure a person can defend it.
Ask whether someone on call could understand it at 2 a.m. from what's written down.
Every sprint:
Track time to diagnose next to velocity.
Walk the team through one agent-built area.
If you want to go deeper
Comprehension Debt by Addy Osmani, where the term comes from.
AI coding creates two kinds of debt from LeadDev, on cognitive debt and what it does to how engineers grow.
State of AI-Native Engineering 2026 from Augment, where the 55% comes from.
Coverage of the Undo survey from DIGIT, with the production and release cycle numbers.
AI now writing code humans can't even understand from Futurism, the piece that kicked off this week's conversation.
Next Tuesday, Rishi takes on how you grow your career when writing the code is no longer the hard part. My bet is that understanding the system is a big part of his answer.
I'm curious how other teams are handling this. How do you make sure someone still understands what the agents built? Hit reply and tell me. The best answers will turn into future issues.
Want the next one? Subscribe and you can reply to any issue. We read every reply, and the best questions become future issues.
The opinions expressed here are our own and do not represent any employer, past or present. Nothing in this publication describes any specific company's internal systems, data, vendors, teams, metrics, or plans. Sponsored placements and sponsored briefs are clearly labeled.
Till next time,