A few months back, Addy Osmani — a senior engineering lead at Google — wrote about something he'd started seeing across teams: engineers who couldn't fully explain the code their AI tools had generated for them. Not junior engineers. Senior ones. They could read it. They could ship it. They just couldn't always walk you through why it worked, what assumptions it was making, or what it would do under edge conditions they hadn't thought to test yet.
That detail stuck with me, because I've been watching the same thing happen to myself.
The boring parts were the learning layer
Before AI pair-programming was a thing, writing a REST endpoint meant you probably read through the Express docs. Or you banged your head against a CORS error for forty-five minutes. Or you wrote the same middleware three times across three projects until it finally clicked. None of that felt like learning. It felt like overhead. It was boilerplate, error messages, documentation you half-understood and then closed.
But that overhead was doing something. Every error message you stared at was forcing you to build a mental model of the system. Every time you wrote the same db connection logic again, you got a little faster at spotting the edge case. Every time you read docs instead of copying a snippet, you came away with a rough map of what the library actually did versus what you assumed it did.
You weren't just producing an endpoint. You were incrementally building a representation of how this part of the stack behaved. That mental model is what lets you read an unfamiliar error six months later and know in three seconds where to look. It's what makes a senior engineer fast — not that they type more accurately, but that they've already seen a version of this problem before.
AI took those parts. They felt boring. So nobody noticed.
The parts AI is best at are exactly the parts that felt the most tedious: scaffolding, boilerplate, repetitive CRUD, the first draft of any standard pattern. Hand me a data model and I can give you a working API in ten minutes. Three months ago that would have taken an afternoon.
Nobody is mourning the boilerplate. That's the point. But the boilerplate was the tax that paid for comprehension. Now we're not paying the tax. And we're moving fast enough that we don't feel the gap — until something breaks in a way we can't quickly explain.
Comprehension debt
Addy Osmani coined the term for this: comprehension debt. Like technical debt, but for understanding. Your codebase grows. Your mental model of it doesn't keep up. The gap between what exists in the repo and what any human on the team can actually reason about gets wider every sprint.
METR's July 2025 study (arxiv.org/abs/2507.09089) found that experienced developers using AI tools on real-world tasks were actually 19% slower than without them. The finding gets misread as "AI is useless" — that's not what it says. AI is excellent at the planning layer. It's excellent at generating plausible-looking code. What it doesn't do is build your mental model of what it generated. That part is still on you. And if you skip it — which the speed of the workflow makes very tempting — you're accumulating a gap between what's in your codebase and what you can actually debug when it breaks.
The comprehension debt doesn't show up in your velocity metrics. It shows up three months later when something subtle breaks at 2am and nobody on the team can explain why that component was built that way.
If you're hitting this gap right now
If you're in that place — where you've built something, it mostly works, but you'd struggle to walk a senior engineer through exactly how it holds together — a 30-minute conversation is often the fastest way through it. Not to explain it to someone else. To explain it out loud at all, which is a different thing.
That's what the MVP Builder Unstuck Call is for: mvpbuilder.io/unstuck-call. $29. You bring the thing you built. We talk through it. You leave with a cleaner map of what you actually have.
What you can actually do about it
The simplest forcing function I've found: write down what you built today in your own words. Not the code. Not the commit message. Two sentences about what the component does, what assumptions it makes, and what would break it.
If you can't write those two sentences, you didn't understand what you built — the AI did. The writing isn't the point. The writing forces processing. It's the same reason rubber duck debugging works: articulation requires comprehension. You can paste AI-generated code without understanding it. You cannot explain it without understanding it.
This is what daily check-ins in MVP Builder are actually doing under the hood. Not accountability theater. Processing pressure. Every day you write what you built, you're forcing yourself to understand it well enough to describe it to someone who'll read it. Over 30 days, that compounds into a mental model you actually own. It's slower than vibe-coding everything in a weekend. It's also the difference between a project you can maintain and one you're afraid to touch.
The structural observation
AI didn't take your ability to learn. It removed the situations that forced you to. The boilerplate you skipped writing — the docs you didn't read — these weren't obstacles between you and the real work. For a lot of us, they were the real work, disguised as friction.
The engineers who'll be fast in three years aren't the ones who generated the most code with the least friction. They're the ones who stayed curious about why it worked, even when the AI made it very easy not to.
Part 13 in a series about what's actually hard about building a side project with a full-time job.
Part 11: Solo devs have one structural advantage in a post-labor world. Most of them aren't using it. [link]
Part 12: AI sprint planners are solving the wrong problem. [link]
Top comments (0)