AI code needs a comprehension budget
Generated code can scale faster than accountable understanding. Treat comprehension as a finite budget spent by unfamiliar change, weak evidence and unclear rollback paths.
1/ Generation is no longer the scarce resource
AI can produce implementation, tests and documentation before an engineer has formed a complete mental model of the change. That is useful capacity. It also moves the bottleneck.
The scarce resource becomes accountable understanding: who can explain the intent, invariants, dependencies and rollback route when the change reaches production?
2/ Review capacity does not scale like inference
More generation is available with more compute. Review still depends on people reconstructing behavior from code, tests and context.
Treating senior review as an unlimited safety net creates a queue that looks like governance but behaves like delayed rubber-stamping. The faster the upstream system writes, the less plausible “someone will read it all” becomes.
3/ Perceived speed is not measured speed
METR's July 2025 randomized study involved 16 experienced open-source developers working in repositories averaging more than 22,000 stars and one million lines of code. With early-2025 AI tools, participants took 19% longer on the studied tasks even though they forecast a 24% speedup beforehand.
That bounded study does not prove AI slows most developers or describe today's tools. It does show why confidence and keystroke velocity are weak productivity measures.
4/ Budget comprehension at the change boundary
A comprehension budget is a limit on unexplained change. Every unfamiliar dependency, broad diff, hidden side effect and ambiguous test spends it.
Small, coherent changes spend less. So do explicit invariants, named failure modes and a clear explanation of why the selected design fits the surrounding system.
5/ Ask for evidence the machine can help produce
Every generated change should arrive with executable evidence: tests tied to the requirement, static checks, relevant benchmarks and a record of changed dependencies.
Evidence does not replace understanding. It reduces the amount a reviewer must infer from prose or apparent confidence.
6/ Make forbidden behavior visible
Prompts usually describe what the code should do. Production incidents often emerge from what nobody said it must not do.
Name the forbidden paths: no external network call, no write outside this transaction, no privilege expansion, no silent fallback, no change to public output. Then test the boundary.
7/ Rollback clarity is part of craft
If the owner cannot say how to disable, revert or isolate a generated change, the team does not understand it well enough for consequential use.
Rollback should include data and side effects, not just source code. A reverted commit does not unsend a message or restore a mutated external record.
8/ Ownership cannot be generated
CareerXperts' craft argument asks what happens when teams become good at producing code they do not fully understand. My answer is to move craftsmanship up a level.
Craft is no longer measured by who typed every line. It is measured by who can defend the boundary, interpret the evidence and own the behavior after the generator is gone.
That ownership includes explaining the change to the next engineer without asking the original chat session to remember what the team never recorded.
Use AI to expand implementation capacity, but never let generated change outrun the team's capacity to explain and recover it.
