The AI Code Nobody on Your Team Can Read

Your team shipped more last quarter than the quarter before, and you cannot find a single person who can explain how half of it works. That is the symptom. AI did not make your people faster at the part that matters; it made them faster at producing things nobody has read closely. This article argues one thing: when AI generates work faster than your team can understand it, you are not banking time, you are borrowing it, and the loan comes due as broken features, outages, and a business that runs on machinery no human on payroll can describe.

The bottleneck in your business was never how fast you could produce code, copy, or customer replies. It was always how fast someone could read that output, understand it, and vouch for it. AI speeds up the first half and quietly leaves the second half exactly where it was. Most owners are paying for speed they can see and ignoring a comprehension bill they cannot, and that bill is the most expensive thing AI has added to small business this year.

The work AI skips is the only work that protected you

Picture a roofing company with three estimators and a small website. The owner starts using an AI assistant to write proposal templates, customer follow-up emails, and the logic behind the online quote form. Output triples. Three months later the quote form starts emailing customers the wrong price, and nobody on staff can say why, because nobody wrote the rule and nobody read it line by line. That is not a hypothetical bug. That is the predictable result of generating faster than you comprehend, and it is illustrative of a pattern researchers have now measured directly.

Anthropic researchers Judy Hanwen Shen and Alex Tamkin ran a randomized controlled trial, published February 3, 2026, on junior engineers learning a new code library. The AI-assisted group finished no meaningfully faster than the group working without it. They did score 17% lower on a comprehension quiz afterward, 50% against 67%. Read that as a hiring cost: you paid for the same hours and got people who understood half of what they touched instead of two-thirds. The gap was widest in debugging, which is the exact skill you need to catch the mistakes the AI makes. So the tool quietly erodes the one ability that would let your team clean up after the tool.

This matters because Anthropic had no product riding on that result. It is a research finding, not a sales pitch dressed as one. When the company building the AI publishes a study showing the people using AI understand less, you should treat that as the cleanest signal in the room. The speed felt real to everyone in that trial. The understanding it cost did not show up until someone gave a quiz, and your business does not run quizzes.

Why every number you track says the AI is working

You walk into it because every dashboard you own rewards the wrong thing. You can see output. You can count proposals sent, articles published, features shipped, tickets closed. You cannot see comprehension on any screen, so it does not exist in your weekly numbers, and what does not show up in the numbers does not get managed. Addy Osmani, a director at Google, named this in a March 14, 2026 piece called "Comprehension Debt," and his sharpest point is the one owners feel before they can articulate it.

The reason comprehension debt is so dangerous is that nothing in your current measurement system captures it.

Addy Osmani, director at Google, "Comprehension Debt," March 14, 2026.

Think about what that means on a Monday. Your reports show velocity climbing. Morale around shipping is high. Every visible signal says the AI investment is working, and every one of those signals is blind to the thing that will hurt you. This is the same trap I describe in why faster output does not always reach your bottom line: speed is easy to measure and easy to celebrate, and it is not the same as a result you can stand behind.

Osmani also names the mechanism, and it inverts how most owners assume review works. His framing: when code was expensive to produce, a senior person could review faster than a junior person could write, so quality control kept pace naturally. AI flips that. A junior person now generates output faster than a senior person can critically audit it. The reviewer becomes the bottleneck, and because nobody schedules the bottleneck, the review simply gets skipped. You did not decide to skip it. The math decided for you while you were looking at your velocity chart.

The data shows the bill arriving as outages, not savings

Faros AI, a company that sells engineering analytics, reported in an April 12, 2026 study called "The Acceleration Whiplash," built on telemetry from roughly 22,000 developers. I flag the vendor stake on purpose, because a company selling analytics has reasons to make a problem look urgent, and you should weight their numbers accordingly. Even discounted, the direction is hard to wave away. Median time spent in code review climbed 441.5%. In owner terms, the reading is now taking more than five times longer, which is exactly what you would expect when generation outruns comprehension and the unread pile keeps growing.

The same Faros AI report found pull requests merged with no review at all, human or automated, up 31.3%. That is roughly a third more changes going live with nobody checking them. Translate it to your shop: one in three new things in your business now ships without a single person confirming it does what it should. The same vendor reported production incidents per code change more than tripled, an incidents-to-change ratio up 242.7%, and bugs per developer up 54%, against 9% in their 2025 report. Each of those is a direct line to money: an incident is downtime, a refund, a support fire, an evening your best person spends fixing instead of building.

Hold the vendor caveat in one hand and the Anthropic finding in the other, and they tell one story. Anthropic showed understanding drops when AI assists. Faros showed defects climb and review backs up in the wild. The first explains the second. People understand less, so they catch less, so more breaks. None of this is an argument against using AI. It is an argument against using it faster than anyone can keep up with, which is the default setting nobody chose on purpose.

There is a human version of this that lands harder than any percentage. Researcher Margaret-Anne Storey documented a student team, cited in Osmani's piece, that hit a wall around week seven. They could no longer make simple changes without breaking something, because nobody could explain why the earlier design decisions had been made. That is a documented anecdote, not a statistic, and it is the whole problem in miniature. The work still existed. The understanding behind it had evaporated, and once it goes, even small changes turn dangerous.

What to actually do before the AI writes anything else

You do not fix this by banning the tools, and you do not fix it by reading every line yourself, because you are not a technician and you should not pretend to be. You fix it by forcing comprehension back into the process as a named, scheduled step. A non-technical owner can do, delegate, or demand all of this starting this week.

First, set a rule that nothing AI-generated ships until one human can explain it in plain language to another human who did not build it. For code, that is your developer walking a teammate through it. For an AI-written landing page or customer-service script, that is the person who generated it explaining to you, out loud, what every claim and rule does. If they cannot, it does not ship. The same logic that broke the roofer's quote form applies to your AI sales copy: output nobody can explain is output nobody can fix.

Second, ask your developer or agency one question and listen to how they answer it. "When AI writes our code, who reads it before it goes live, and how long does that take them?" A confident, specific answer, a name and a number, means review is happening. A vague answer means it is not, and you just found your next outage. This is the management muscle I argue is your real edge in why owning AI output beats knowing the tech yourself.

Third, slow the generation rate on purpose where the stakes are high. Anything that touches billing, customer data, pricing, or your public reputation gets generated at the speed your team can review it, not the speed the tool allows. A roofer does not need AI writing fifty proposal variants nobody checks. He needs three he can defend.

Fourth, require a plain-language record of why each significant decision was made, written by a person, at the moment it is made. The student team in Storey's account did not break because the code was bad. They broke because the reasoning was gone. A two-line note saying why a price rule works the way it does costs sixty seconds now and saves the panicked afternoon later when something breaks and nobody remembers the logic.

Fifth, separate the tasks where speed is genuinely safe from the tasks where it is not. AI drafting a first version of a blog-post intro you will rewrite anyway is low-risk speed. AI writing the refund logic in your checkout is not. Sort your AI use into those two buckets and apply review pressure only where a mistake costs real money. That keeps the tool useful without letting it run your business into the ground, and it is the realistic middle ground between the hype and the panic.

Measure understanding, and stop trusting the speed numbers

The metric that matters is not how much you produce. It is how much of what you produce a human can vouch for. Pick a number you can actually watch: the share of AI-generated work that passed a real human review before it shipped this month. If that share is falling while your output climbs, you are not getting more productive. You are getting deeper in debt, and the two look identical on every dashboard you currently own.

Watch the bug and incident trend over a quarter, not a week. Faros AI's bugs-per-developer figure jumping from 9% to 54% is the kind of slow climb that hides inside any single good week. If small things keep breaking and each fix takes longer because nobody remembers how the thing was built, that is comprehension debt showing up in your maintenance bill, even when this week looks fine. The damage is cumulative, so you have to measure it across time or you will not see it until it is large.

The vanity metric to distrust is raw velocity, the output count your tools are happiest to show you. "We shipped forty percent more this month" is the sentence that precedes the outage. Osmani's plainest line is worth keeping taped to your monitor: making code cheap to generate does not make understanding cheap to skip. The comprehension work is the job. The same holds for marketing copy and customer replies. The writing was never the hard part. Knowing it is right was. If you want the honest ceiling on what these tools give back, I laid it out in why realistic AI time savings land near five hours a week, not twenty, and review is exactly where the missing hours went.

Frequently Asked Questions

Does this mean I should stop using AI to write our code and content?

No. It means you should stop letting AI produce things faster than someone on your team can read and explain them. Use the tools for first drafts, low-stakes work, and anything you will review carefully anyway. The line to hold is simple: if no human can explain a piece of work in plain language, it does not go live, no matter how fast the AI made it.

I am not technical. How do I check whether my developer or agency is actually reviewing AI output?

Ask one question: when AI writes our code, who reads it before it ships, and how long does that take them? You are listening for a specific person and a specific amount of time. A clear answer means review is happening. A vague one, like "the tools handle it," usually means changes are going live unread, which the Faros AI data tied to a 242.7% jump in incidents per change.

How fast will comprehension debt actually hurt my business?

It depends on how much of your AI output touches money, customer data, or your reputation. Low-stakes work, like a blog draft you rewrite anyway, can pile up unread for a long time with little cost. High-stakes work, like billing or pricing logic, can break within weeks, the way a student team in documented research hit a wall at week seven and could no longer make safe changes. Sort your work by stakes and the timeline answers itself.

The uncomfortable part is that nothing here will show up as a crisis until it already is one. Your output looks healthy right up to the morning the quote form emails the wrong price and the only person who could fix it left the company in March. You have been measuring how much your business makes. Start measuring how much of it anyone can still explain, because the day no one can, you do not own a business anymore. You own a black box that happens to have your name on it.