A senior engineer spends two years on a team. He knows the codebase, the conventions, the reasons behind certain decisions. Then the team adopts AI tools at scale. Six months later, he no longer recognises large parts of what he maintains. The code passes the tests. He does not know why it works.
This is not a quality problem in the traditional sense. It is a comprehension problem. And the difference between the two does not show up in productivity dashboards.
What productivity metrics do not show
The metrics that rise with AI adoption are real: more commits, shorter cycles, features shipping faster.
What these metrics do not capture is what Alex Dunlop calls in his analysis of AI's impact on engineering teams knowledge debt. Every line of code accepted without the developer being able to answer "why does this work?" adds to that debt. It appears in no dashboard. It accumulates silently until the first production incident where nobody quite knows what happened.
That moment always comes. A system behaves unexpectedly in an edge case. A bug appears at the intersection of two services nobody wrote themselves. The CTO ends up carrying the comprehension of the whole system alone because they are the only one with enough context to untangle what happened. That does not scale.
How do you maintain code quality when the entire team uses AI to develop? The answer is not in a better review tool or a more restrictive AI usage policy. It is in what precedes the code: the standards that define what a developer must understand before merging anything.
What AI removes without anyone noticing
The repetitive work AI takes over was also the formative work. A junior engineer who no longer writes CRUD endpoints, who no longer debugs basic API calls, who no longer reads legacy code to understand how a system was built, never develops the system instinct that makes tomorrow's seniors. The output is identical. The comprehension is not.
The data collected by Addy Osmani, CTO of Azure, across more than 300,000 AI-authored commits in 6,275 GitHub repositories is explicit: AI-introduced debt grew from a few hundred surviving issues in early 2025 to over 110,000 by February 2026. Copy-pasted code is up 48%, refactored code is down 60%. These are not signals of degraded quality in the traditional sense. They are signals of comprehension eroding at scale.
Why do engineering teams that adopt AI accumulate more technical debt? Because the speed of code generation has far outpaced the capacity for meaningful review. A junior engineer with Cursor can produce 500 lines of code that pass the linter and naming conventions in forty minutes. What the review does not see is whether that engineer understands what they submitted.
In Europe, where Series A engineering teams average between fifteen and thirty developers according to Dealroom 2025 data, this comprehension gap concentrates on a very small number of people. Often the CTO, or one or two seniors. When those people are unavailable, the team's ability to resolve a complex incident collapses.
Standards before tools
The answer to this problem is not to slow down AI adoption. It is to set the conditions under which AI can be used without comprehension eroding.
Those conditions are called standards. Not guidelines sitting in a Confluence doc nobody reads. Operational standards that define what a developer must be able to explain before merging anything: why this architecture rather than another, how this component interacts with the rest of the system, what happens if this service goes down. Questions AI cannot answer on behalf of the developer because they require a contextual understanding AI does not have.
This is what Nightborn brings before writing a single line of code. The first step of every project is not technical, it is organisational: what are the standards that will govern this team's decisions, and how do we make sure everyone understands them before development starts? This is not slowing down. It is the condition for the speed gained with AI to be durable rather than fragile.
AI has made engineering teams faster. It has also made comprehension rarer and more valuable. The CTOs who manage this transition well are not those who use AI the least. They are those who set standards before adopting the tools.
If you want to build that framework before your next hire or your next development cycle, that is where every Nightborn project starts.
.webp)