You need to understand your code before you ship it. Really.

In my last post I wrote about how AI changed my development workflow — I barely write code by hand anymore. This post is the uncomfortable sequel: what happens to understanding when writing goes away.

My claim is simple: a team that understands its code has fewer bugs, and that understanding is an asset — as real as your test suite, just invisible in every dashboard you have.

Coding was never the job

Here's a stat that should be printed on every engineering manager's wall. Studies measuring how developers actually spend their time found that on average 58–70% goes to comprehending existing code, and only about 5% to editing it.

Read that again. Five percent writing. The rest is reading, navigating, building a mental model, figuring out why the thing does what it does.

So when AI "writes the code for you," it automated the 5%. The 70% — understanding — is still on you. That's why "the AI did the work" never felt quite true to me, even as a heavy AI user. The typing was never the work. The understanding was.

Understanding = fewer bugs. This is not a vibe, it's data.

Microsoft ran one of my favorite studies on this, on Windows Vista and Windows 7 — codebases with thousands of developers. The finding: components touched by many low-expertise developers, and components without a strong single owner, had measurably more faults before release and more failures after release.

In plain language: when people who don't deeply understand a piece of code change it, bugs go up. When someone owns it in their head, bugs go down.

This matches everything I've seen in ten years of building software. The scariest bugs I've dealt with never came from bad code. They came from orphaned code — code that worked fine until the one person who understood it left, or forgot, or never existed in the first place.

Team knowledge is a bug-prevention system. It just doesn't show up in Jira.

Then AI showed up and broke the feedback loop

Before AI, there was a natural (and annoying) safety mechanism: code was slow to produce. A senior could review faster than a junior could write. PR review was a bottleneck, but a productive one — reading the diff forced comprehension, and that comprehension spread across the team, one review at a time.

That loop is broken now. Researchers are calling the result comprehension debt — Addy Osmani has a great piece on it, and O'Reilly republished it with extra data. Earlier this year, several independent research groups converged on the same number: AI generates code roughly 5–7x faster than humans can actually read it. The debt doesn't show up in your velocity charts. It shows up 6–18 months later, when nobody on the team can confidently modify or debug what was shipped.

And it's not just the codebase — it's the developers. Anthropic ran a randomized trial with 52 engineers learning a new library. The AI-assisted group finished in about the same time as the control group, but scored 17% worse on a comprehension quiz afterwards — with the biggest drop in debugging ability. Same speed, less understanding. That's the trade nobody puts in their AI productivity slides.

One more finding from that research thread that I can't stop thinking about: developers who use AI in delegation mode ("just make it work") score below 40% on comprehension tests. Developers who use it in inquiry mode — asking questions, exploring trade-offs — score above 65%. The tool doesn't destroy understanding. How you use it does.

The obligatory balanced take

Now, before someone puts me in the "AI skeptic" box: no. I still think AI-assisted development is the biggest upgrade of my career, and I said so in the last post.

And honestly — not all code deserves to be understood. The one-off migration script? The internal admin page? The landing page animation? Let the AI write it, skim it, ship it, forget it. Treating every line as sacred is how you end up slower than your competition for zero benefit.

But there's a category of code where comprehension is non-negotiable: your core domain logic, the paths where money moves, the code you'll be debugging at 2 AM during an incident. For that code, "tests are green" is not the bar. Tests measure the code. They don't measure the team. You can have 100% coverage and 0% comprehension — and that combination is a time bomb with a very quiet clock.

What I actually do about it

Not theory — things that work for me and teams I've worked with:

1. Review for architecture, not syntax. AI doesn't make typos. It makes design decisions that conflict with how your system was built six months ago. That's what your review time should go to.
2. Use AI in inquiry mode. Ask it why, ask for alternatives, ask what breaks. The 40% vs 65% comprehension gap above is entirely about this habit.
3. Verify comprehension instead of assuming it. This one is literally why I built Reviewsaur — it generates a short quiz from the PR diff, so "I reviewed it" means "I understood it," not "I scrolled it." I built it because I caught myself approving code I couldn't explain.

The bar was never "it works"

We're all still figuring out how to build software in this new world, me included. But I keep coming back to this: "it works" was never the bar for professional software. "We understand why it works" was. AI changed who types the code. It didn't change whose head the system has to live in.

How is your team handling this? Do you actually read AI-generated PRs, or do you scroll and pray? I genuinely want to know.