Kevin Cushnie is an Senior Engineering and Technology leader at Modus Create, bridging the gap between strategy and execution.
Across the engineering organizations I work with, the same patterns surface in pull request reviews and incident retrospectives. Velocity is climbing, yet senior engineers are quietly hedging their answers more. When asked to explain a change their team shipped two months ago with AI assistance, some cannot.
That gap is widening, and the metrics reporting up the chain are not detecting it. Pull request volume is up 20%. Production incidents per pull request are up 23.5%. Developer trust in AI-generated code accuracy fell from 40% in 2024 to 29% in 2025, even as adoption climbed past 84%. Underneath sits a question most engineering leaders cannot honestly answer for their boards: Can we still safely change this codebase in 12 months?
The phenomenon now has a name: comprehension debt. It is the widening distance between the volume of code in an enterprise and the amount any human on the team genuinely understands. No static analyzer, defect counter or coverage report detects it, and the productivity charts trending up and to the right are the very instruments hiding it. What detects it is observation, specifically four signals that practitioners learn to read.
1. Review Compression
The first signal sits in your team’s pull request analytics, inverted from how most organizations read them. Review time per change is dropping faster than change complexity is dropping. PRs that would have taken 30 minutes of substantive review two years ago now take seven, and the reviewer’s confidence has not earned that compression. Reviews are narrow in intent, while implementation details get waved through.
AI-generated code is verbose, plausibly structured and stylistically consistent enough that surface-level review finds nothing alarming. The reviewer’s eye glides over patterns it has been trained to trust, and the review converges to a ritual approval regardless of risk profile. Liu et al. analyzed 304,362 AI-authored commits across 6,275 repositories and found 24.2% of AI-introduced defects survive to the latest revision. Many passed the review.
Takeaway: Audit review time per line for AI-assisted PRs versus human-authored PRs over the last quarter. If the ratio has narrowed by more than 30%, your review process is compressing. Add a one-question comprehension check to your PR template: Can the reviewer explain how this change works without referring to the prompt?
2. Architecture Decision Drought
The second signal is institutional. Architectural decision records, design review minutes and post-implementation documentation are drying up, despite the same or higher rate of architectural change. New services ship without a recorded rationale. Existing services accumulate changes that nobody documents because nobody can confidently articulate the reasoning that produced them.
AI generates implementation faster than humans can generate intent. Writing decision records for changes you did not personally reason through becomes uncomfortable, so the path of least resistance is to skip the record. The codebase grows while the explanatory layer thins.
Takeaway: Pull a sample of architectural changes from the last quarter and check how many have current, accurate decision records. Below 60% is a warning. Below 40% means architectural intent is no longer being captured anywhere. Pair every AI-assisted architectural change with a mandatory rationale section, written by the approving engineer.
3. Incident Archaeology
The third signal appears in your post-mortem documents. Incident retrospectives increasingly cite “the original intent of the code is unclear” or “the change history does not explain why this was implemented this way” as contributing factors. The post-incident review process runs into walls when the answer to “what was the engineer trying to achieve?” is “the engineer was approving an output, not producing one.”
I argued in “The Archaeology of Code” that legacy modernization is excavating lost intent. AI-assisted development creates the same conditions in services your team shipped this year. Debugging becomes an archaeology of code that is months old, conducted by the engineers who reviewed it. The codebase nobody understands is also the codebase nobody can defend: Industry analysis shows AI-introduced privilege escalation up 322% and architectural flaws up 153%, with attackers chaining vulnerabilities that no human reviewer fully traced.
Takeaway: Review your last six incident post-mortems. Count how many cite unclear intent or untraceable design decisions as contributing factors. More than two means comprehension debt is now showing up in your operational risk profile.
4. The Explanation Hedge
The fourth signal is the hardest to surface through metrics. Senior engineers, asked to walk through systems they nominally own, increasingly hedge. They reach for documentation, open the AI assistant or defer to a teammate before responding. The five-minute confident walk-through has become a 10-minute negotiated reconstruction.
An Anthropic randomized controlled trial of 52 engineers learning a new library found that AI-assisted developers scored 17% lower on comprehension quizzes and showed no statistically significant reduction in completion time. Confidence rises while competence stalls. The hedge is what happens when an experienced engineer’s instinct for system behavior collides with the realization that they no longer have the working mental model they used to.
Takeaway: Sit in on design reviews or incident retrospectives this quarter. Listen for hedging language from senior engineers about systems they own. If you hear it three or four times in a single session, your most experienced people are telling you that the organization’s comprehension floor is dropping. Treat that as architectural intelligence.
What Practitioners Do With Signals
None of these signals appear on dashboards. All are visible to anyone close enough to the work to notice them. That is the practitioner’s structural advantage in the AI era. The senior leaders who detect comprehension debt early are the ones who still review pull requests, sit in incident retrospectives and notice how their teams talk about systems they used to own.
The board question that opened this piece has a clear answer for leaders who get this right. Can we still safely change this codebase in 12 months? Yes, because we built the discipline to read the signals while the code was still ours to understand.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
