The AI velocity comprehension gap is structural debt, not a culture problem

Issue 01. Decoding Scale by Tito Salas.

48% of code is now AI-generated. 55% of engineering leaders say they are losing shared codebase understanding.

Same problem from two angles. Most VPEs at 80 to 200 engineers are about to make the wrong call on it.

The Decision Memo

The instinct, when these two numbers land in front of you, is to treat them as a behavior problem. Engineers are using AI without enough oversight. Reviewers are rubber stamping. Pair programming culture has eroded. The fix in that framing is process. Tighter PR review guidelines. More architectural review meetings. A new RACI for code ownership.

That framing is wrong, and it is expensive.

These numbers are not a behavior signal. They are a structural debt signal. The governance layer your org needed three quarters ago was never installed, because there was no forcing event. AI tooling spread team by team. Velocity metrics looked healthy. No one had a reason to put the brakes on. Now the structural gap is showing up as a comprehension gap, and process interventions are going to fail the same way "more standups" fails when the real issue is org design.

The decision in front of you is not "how do we get engineers to review AI output more carefully." It is "what is the smallest governance layer that produces visibility, differentiation, and atrophy monitoring without slowing throughput."

Most orgs are about to build the wrong one. They are going to bolt a heavyweight review gate onto the PR pipeline, watch lead time tank, and conclude the problem is unsolvable. Or they are going to install a slack channel for "AI concerns" and confuse activity with governance.

The smallest useful governance layer has three components. Each one answers a question the org cannot currently answer. None of them are heavy.

Why the standard response fails

The standard response to a comprehension gap is to slow down the pipeline. Add review steps. Require senior signoff on AI-generated PRs. Mandate architectural docs.

This fails for three reasons.

First, it treats AI-generated code as a static category. It is not. The same engineer using the same tool produces different quality of AI output depending on the task. A boilerplate refactor and a novel data transformation are not the same review surface. A uniform gate over-reviews the safe cases and under-reviews the risky ones.

Second, it relies on humans flagging "this is AI" honestly. Even when the engineer is trying to be transparent, the boundary blurs. Was the function AI-generated, or AI-suggested and then heavily rewritten? Does autocomplete count? Most teams cannot answer this consistently, which means any review process anchored on the label collapses within a quarter.

Third, it scales poorly. A gate that requires a senior engineer to review every AI-touched PR becomes a senior engineer bottleneck. Then the gate gets watered down. Then the gate becomes ceremonial. Then the gate gets removed.

The structural fix has to make those three failures impossible by design.

The 4 places it actually breaks at 80 to 200 engineers

Before the governance layer, you need to know where the comprehension gap actually shows up. Most orgs assume it shows up at the PR level. It does not. PR-level signal is the late signal. The early signal is in four other places.

1. Onboarding uses the codebase as curriculum. New engineers learn from AI-generated code without knowing it is AI-generated. They build mental models on top of code that no human ever fully reasoned about. Three quarters later, you have a population of engineers whose understanding of the system was bootstrapped on artifacts no one owns.

2. Incident response slows on AI-authored modules. When something breaks at 3am, the question is "who knows this code." If the code was largely AI-authored and lightly reviewed, the answer is nobody fully, and the on-call has to reverse engineer it under pressure. MTTR on these modules is structurally higher than on human-authored ones. Most orgs do not track this.

3. Architecture decisions degrade. Without tracking AI-generation concentration by module, the team cannot calibrate risk on structural changes. A refactor that would have been a 2-week project on a fully-understood codebase becomes an 8-week project with surprise breakages on a module where the original reasoning was never fully internalized by humans.

4. PR review is undifferentiated. This is the late signal. The review process built for human-authored code applies the same checklist to AI-authored code. The failure modes are different. Human-authored code fails on logic. AI-authored code fails on context, on subtle assumption violations, on plausible-but-wrong API usage. A reviewer scanning for "does this make sense" misses these failure modes by design.

Note that three of the four are upstream of the PR pipeline. Adding more PR review does not touch them.

The 3-component governance layer

The layer that works has three parts, in order of installation difficulty.

Component 1. Visibility. Track AI-generation percentage by team and by module. Not by PR, by module. The unit of measurement matters. Per-PR data is noisy and gameable. Per-module data shows you where the comprehension risk is concentrating over time.

The threshold to watch: any module where AI-generation percentage crosses 40% AND human review density (reviews per merged commit) drops below 1.2 simultaneously. That intersection is your early warning. It usually shows up 60 to 90 days before the comprehension gap produces a visible incident.

You instrument this once. It runs as a background dashboard. No process change required from engineers.

Component 2. Differentiation. Stop reviewing AI-authored code with the human-authored checklist. Build a second checklist for AI-authored code that specifically tests context fit. Three questions, asked by the reviewer, written into the PR template:

What assumptions did the AI-generated code make about adjacent systems? Have you verified each one?

>

Does the code use the codebase's idioms or generic patterns the AI defaulted to? If generic, why is that acceptable here?

>

Is the AI-generated function calling internal APIs the way our internal docs say to call them, or the way the AI guessed?

These questions take 4 to 6 minutes to answer if the engineer actually goes through them, and they expose the dominant AI failure modes. The point is not to slow down the review. The point is to put the reviewer in the right mental frame.

Component 3. Atrophy monitoring. Track human reasoning capacity over critical codebases. This is the longest-horizon component, and the one most orgs skip.

The mechanism: once a quarter, run a "no-AI day" exercise on a critical module. The team that owns the module makes a meaningful change to it without AI assistance. The diff is short. The point is not productivity. The point is to detect when the team's unaided reasoning capacity on their own module has degraded to the point where they cannot extend it without tooling.

If the team can do it but it takes 3x longer than usual, that is a signal. If they cannot do it at all, that is a structural risk that needs leadership attention.

You will get pushback on this exercise. The pushback is the data.

Pattern and anti-pattern

Pattern that works: Governance designed around modules, not PRs. Differentiated review that exposes AI-specific failure modes through prompting the reviewer, not through gating the merge. Quarterly atrophy detection that surfaces structural risk before it produces incidents.

Anti-pattern that fails: Uniform AI review gate at the PR level. Slack channels for "AI concerns." Senior signoff requirements. "AI code review" as a stage in the deployment pipeline. Any process whose success depends on engineers honestly labeling code as AI-generated. Any architecture review meeting added in response to this issue.

The anti-pattern looks like governance. It produces the documentation of governance. It does not produce the visibility, differentiation, or atrophy monitoring the actual structural problem requires.

What to do this week

If you are at 80 to 200 engineers and reading this, three concrete moves:

1. Pull your AI-generation data by module for the last 60 days. If you do not have this, install the visibility layer first. Datadog, Jellyfish, LinearB, your IDE telemetry, or git blame plus a simple AI-attribution heuristic all work.

2. Pick the top 3 modules by AI-generation concentration. Schedule a no-AI exercise on one of them this month. The output is not productivity. The output is calibration on your atrophy risk.

3. Update one PR template with the three differentiation questions. Roll it out to one team for two sprints. Measure whether reviewers actually answer them and whether you catch issues you would have missed. Then expand.

You will not solve the comprehension gap this quarter. You will install the instrumentation that lets you see when it is starting to hurt, and the discipline to act before it produces an incident.

That is the smallest useful version of the work.

The question I want to think through with you

VPEs and engineering Directors at 80 to 200 engineers: in your own org right now, which of the four breakage points is closest to producing an incident? Onboarding, on-call MTTR, architecture decisions, or PR review?

I have a hypothesis on which one shows up first across the orgs I see. I am genuinely curious whether it matches yours.

Reply to this email or find me on LinkedIn. The patterns from the operator conversations show up in future issues.

The Tool: AI Code Governance Readiness Scorecard for 80-200 engineer orgs.

Linked at the bottom of this issue. One page. 12 questions across the three governance components. Print it, take it into a leadership team meeting, and you will have a calibrated answer to "what is the next move" in 30 minutes.

The download lives here: https://decodingscale.com/issue-01/governance-scorecard.pdf

Sources

Jellyfish 2026 State of Engineering Management. 20,000 engineers across 300 companies. AI velocity and PR throughput baseline.

Atlassian 2026 State of Developer Experience. 55% of engineering leaders concerned about shared codebase understanding.

GitHub Octoverse 2025. 32.5% of orgs with formal AI adoption governance.

CodersLink delivery data. 150+ growth-stage engineering organizations placed over 10 years.

Pattern observations across the 80 to 200 engineer cohort, 2024 to 2026.

About Decoding Scale

Decoding Scale is the operator's weekly memo on how AI-native distributed organizations are built, scaled, and managed.

Every Thursday, you get one Decision Memo and one paired framework. Frameworks you can use Monday morning. Built from operator work, Tier 1 research, and pattern observations across 150+ companies.

Written by Tito Salas, founder of CodersLink.

Subscribe at https://decodingscale.com

Always free. Always operator-led.