The author wants to ship at the speed of generation. The CTO ships at the speed of comprehension. The CTO is right, and the gap only grows.
An agent writes a pull request in twenty minutes. The author merges it. The CTO doesn't. The CTO asks: can the team explain this change in front of the business? If the answer is "the agent wrote it," the change waits.
This is the conflict in one sentence: the author wants to ship at generation speed, the CTO ships at comprehension speed. The CTO is right. Here's why.
Two speeds, one queue
Generation speed is the time it takes the agent to produce working code. Comprehension speed is the time it takes the team to understand, verify, and decide to ship that code.
Generation dropped from hours to minutes. Comprehension didn't drop. A reviewer still reads the diff, checks the intent, runs the scenario, and signs off. That takes the same time it always did.
When generation produces ten changes in the time comprehension can process one, nine changes wait in a queue. The author sees throughput. The CTO sees a backlog of unverified code. The queue is the CTO's problem. Managing it is the job. Shipping from it requires comprehension, not generation.
Why the CTO is right
Three reasons. None of them is conservatism.
You can't verify what you don't understand. The agent wrote tests, and they're green. But a test written by the same agent that wrote the code can be wrong alongside it. Independent verification — does the test check the right invariant, does the scenario match the bug — requires a human who understands the code. If no human does, verification is a rubber stamp.
You can't debug what you don't understand. When the change breaks in production, the developer who understands the code localizes the bug from symptoms: knows which module is responsible, which inversion of control might be silent, which consumer might have disappeared. The developer who doesn't understand brings the agent back, and the agent starts by summarizing the architecture instead of finding the cause. Recovery takes longer than generation. The gap in understanding becomes a gap in recovery speed.
You can't answer for what you don't understand. Enterprise doesn't ask how many minutes the agent spent writing the code. Enterprise asks: who can explain why this line is here, what business process it serves, and what breaks if it's removed. If the answer is "the agent wrote that," the next question is "who is responsible for it." No answer, no release.
The constraint isn't about trusting the agent. The agent can write flawless code. The constraint is about accountability for the result. A team that can't explain a change can't be responsible for it.
What "comprehension" means
Comprehension isn't reading the diff and nodding. It's the ability to do three things without the agent in the room:
- Predict the side effects. If I merge this, what else changes? What consumer breaks? What invariant shifts?
- Debug it under pressure. At 3 a.m., with production down, can the on-call engineer trace the bug to this change without asking the agent to explain the code first?
- Answer for it. In a post-mortem, in an audit, in front of the business — can a human on the team explain why this code exists and what it does?
If the answer to any of these is no, the code isn't comprehended. It's generated. The CTO ships comprehended code.
The ratio that matters
The generation-to-comprehension ratio determines the queue length. At 1:1, the team keeps up. At 5:1, the queue grows. At 20:1, the team loses its model of the code entirely.
AWS frames the structure in the AI-Driven Development Life Cycle: "AI creates a plan, asks clarifying questions to seek context, and implements solutions only after receiving human validation" [1]. AI proposes and executes. The human decides. The ratio is built into the framework — the human gate doesn't get faster because generation does.
When the ratio gets high enough, comprehension debt starts compounding. The team's model of the code erodes faster than they can rebuild it. Fixes take longer even when bugs don't increase — the early signal that comprehension is falling behind.
How to move the cap
If the cap is comprehension speed, faster generation doesn't help. What helps is giving the human facts to comprehend faster.
At Explyt we built the agent around the JetBrains IDE as a source of precise facts about the project. Plan mode forces the agent to study the project and produce a plan before generating code — comprehension starts before the diff exists. Auto Review runs as a separate read-only agent that runs IDE inspections on the final diff and reports findings tied to lines. Debug mode sets a breakpoint, stops, and shows variable values and call stack — the human sees the program's behavior, not the agent's summary.
These capabilities don't accelerate generation. They cut the time the human spends comprehending a change. The cap moves.
What to check before merge
- You can explain the change in your own words. If you can't, defer the merge.
- The test the agent wrote fails without the fix. If it passed immediately, it documents the implementation, not the invariant.
- The change is limited to the files you named. A new dependency in the diff means the agent didn't find a solution with the project's existing means.
- You've seen the runtime behavior, not just the agent's description of it. A green build is necessary, not sufficient.
What's next
The CTO ships at comprehension speed. When comprehension debt accumulates — when the team's model of the code erodes faster than they rebuild it — the cap tightens. In The agent wrote the code, and you lost the model we break down how that debt builds over time, and what two independent customer development interviews reported about the one-month timeline.
Get started with Explyt
Reproduce, inspect and fix inside JetBrains IDEs, with the debugger, run configurations and IDE facts as evidence.
Sources
- AWS DevOps blog, Raja SP, "AI-Driven Development Life Cycle: Reimagining Software Engineering", 31 July 2025. https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/
- Reddit: discussions about CTOs, release velocity, and code comprehension (community opinions, not proof of scale).
