Guest post by Michael Privat, Chief Data and Engineering Officer.
If you asked your engineers right now to fully explain the last system they shipped, what percentage of them could do it? In most organizations running AI-assisted development, that number is lower than anyone is comfortable admitting.
I lead 500+ engineers across the US and India in healthcare IT. In our environment, that question has a very specific weight: our systems handle clinical data, and when something breaks, the investigation does not care who generated the code. The engineer who owns the system owns the failure, full stop. That accountability has not changed, and it is not going to.
What has changed is how much of that code engineers are actually writing themselves. Close to half of all code in professional engineering environments today involves AI assistance, and the speed gains are real and measurable. But speed and comprehension are not the same thing, and most organizations right now are only measuring one of them.
The Speed Story Has a Gap in It
My teams use AI tools. So do I. The efficiency is genuine, and I am not making an argument against adoption. What I am paying close attention to is the gap between how fast these tools allow teams to generate and how well those same teams understand what they have generated.
The issue tends to show up after the code ships.
AI tools are built to produce output that looks right and compiles cleanly. They are not designed to make sure the engineer accepting that code actually understands what they are accepting. Under deadline pressure, the difference between reviewing something and genuinely understanding it tends to disappear, and most development workflows do not force that understanding to happen before something ships.
A team can post excellent velocity numbers while steadily accumulating a codebase that nobody can fully explain. The sprint review and velocity dashboard are not what catches that. What catches it is production, usually at a very inconvenient moment, and in regulated industries, those moments come with formal names and real consequences.
The piece everyone keeps writing about – AI in software development – is about how much faster teams are shipping. The piece nobody is writing is about what happens when the people responsible for that code can no longer govern it.
The Comprehension Gap
The speed story has a specific casualty, and the data is starting to name it. Engineers who used AI assistance scored 17 percentage points lower on comprehension tests than those who coded without it, finishing the task in roughly the same time but understanding significantly less of what they had built (Source: Anthropic, 2026). The gap was largest in debugging, which is exactly the skill you need when something breaks in production.
In healthcare IT, that gap has a very specific cost. Comprehension failures in production systems surface as compliance failures and security incidents, and they take far longer to unwind than they took to create. The speed gains from the previous quarters start looking very expensive the moment you are sitting across from a regulator.
This is not only a junior engineer problem. It is a process problem, and leadership has to own it. If the people responsible for production systems cannot clearly explain the behavior of what they have shipped, the organization has a governance problem that no velocity dashboard will resolve.
What Engineering Leaders Should Actually Be Measuring
Most engineering metrics were designed for a world where humans wrote all the code. Applied to AI-assisted development, they can actively mislead. A team can show strong velocity numbers while the engineers on that team become progressively less capable of explaining what they own, and nothing in the standard measurement stack catches that before it gets genuinely costly. Most engineering leaders I talk to have not yet designed a process that forces comprehension before shipping, and the absence of that process is a choice with a delayed consequence.
The question I now use when thinking about engineering health is not how fast a team is shipping. It is whether engineers can clearly explain the behavior and implications of what they submit. Are code reviews catching real issues, or are they functionally approvals on AI output that nobody thoroughly interrogated? Is comprehension growing alongside the codebase, or is the system getting more opaque every sprint?
The engineers who will matter most going forward are not the fastest generators. They are the ones who can take what was generated, push on it hard enough to find what it got wrong, and take genuine accountability for what ships. That capability does not show up in deployment frequency, but it is exactly what keeps deployment frequency from becoming a liability.
The Conversation Worth Having
If you lead an engineering organization, the adoption question is probably already settled. AI tools are in the workflow, and that is fine. The question that actually matters now is whether your team is building real comprehension alongside all that output, or quietly accumulating a governance gap that will surface at a very inconvenient moment.
I write about engineering leadership and what it actually takes to build organizations that can sustain what they ship at my Substack. If this connects with challenges you are actively working through, I would welcome the conversation on LinkedIn.
Editor’s note: This article is a guest post by Michael Privat, Chief Data and Engineering Officer. The views and opinions expressed are those of the author and do not necessarily reflect those of The AI Insider or its editorial team
