Do you need to understand the code your AI writes?

The short answer

No, you don’t need to be able to write the code your AI agent produces. Pretending otherwise is how people talk themselves out of building anything at all. What you do need is the ability to read it: follow what changed in plain terms, ask why when something looks off, and catch a problem before it ships instead of after. That’s a real, learnable skill, and it sits well below “learn to code” on the difficulty scale. The people who get hurt by this stuff are the ones who never look at what the agent just did, not the ones who can’t write a for-loop.

What a controlled study actually found

Most of what circulates about AI and skill loss is opinion. Anthropic ran an actual experiment worth knowing about. Fifty-two junior software engineers, all comfortable with Python and already coding alongside AI, were split into two groups and given the same job: learn Trio, a Python library neither group had used before, well enough to build with it. One group learned it with AI assistance. The other learned it unassisted. Everyone then sat the same quiz, covering four skills: debugging, reading code, writing code, and explaining the underlying concepts.

The AI-assisted group averaged 50%. The unassisted group averaged 67%, close to two full letter grades higher, a gap too large to put down to chance (the researchers reported it as statistically significant). The single widest gap between the two groups, across all four categories, was on debugging: exactly the skill you need the moment something breaks and the agent can’t fix it either. For what it’s worth, the AI-assisted group did finish about two minutes faster, though that edge wasn’t statistically meaningful. The honest read is narrower than “AI makes you slower”: AI can quietly trade comprehension for speed if you let it, without buying you much time in return.

The detail that matters most for how you actually use these tools: researchers also tracked how each person in the AI group used their assistance, and it wasn’t uniform. The people who scored best weren’t the ones who leaned on AI less. They were the ones who used it differently, asking it to explain choices, posing follow-up questions, treating it like a tutor mid-task rather than a vending machine for finished code. Passive delegation, the “just make it work and don’t bother me” mode, produced worse retention than active, curious use of the exact same tool. How each person chose to use it decided the outcome, not the AI itself.

Comprehension debt: the bill that shows up later

There’s a name for what happens when nobody on a project, including the person who “built” it, can actually explain how it works anymore: comprehension debt. The engineer and writer Addy Osmani coined the term for the widening gap between how much code exists in a project and how much of it anyone involved understands. It sits close to a related idea from Margaret-Anne Storey, a computer science professor who studies how people, not just code, hold software together. She calls it cognitive debt: the growing distance between a system’s real structure and the team’s shared understanding of why it’s built that way.

Storey’s go-to example is a student team building fast with AI help that hit a wall around week seven. The code ran. The tests passed. But nobody on the team could explain why a particular design decision had been made, or how two parts of the system were even meant to talk to each other. That’s the shape of the problem: unlike a slow build or a tangled dependency, something you’d feel every time you touch the code, this kind of debt doesn’t announce itself. It hides. It feels like progress right up until the day you need to change something, and the person who’d normally explain it is you, and you can’t.

That gap is exactly where AI slop comes from more often than not. It’s rarely code that’s obviously broken since agents usually get the syntax right. More often it’s code that looks complete, runs fine today, and rests on choices nobody in the room could defend if you asked them to.

Even the person who coined “vibe coding” walked back the purest version

If anyone had standing to say “don’t bother reading it, just vibe,” it was Andrej Karpathy, the AI researcher known for his work at Tesla and OpenAI. In February 2025, he posted the tweet that put a name on this whole way of building: giving in to the momentum, accepting whatever the agent suggests, letting the project grow past the point you could explain it yourself. He was upfront that it was fine for weekend throwaway projects and not much more, and later described it as a tweet he had fired off casually, without expecting it to name a movement.

Over the course of 2026, Karpathy himself moved past that purest version of the idea. In interviews he described AI-generated code as bloated and brittle without human judgment, called agents interns who need supervision on taste, and shifted his vocabulary toward agentic engineering: engineers who direct and oversee agents rather than hand over the keys and look away. That’s a more disciplined cousin of what this dictionary already calls agentic coding. The person who normalized not reading your own code spent the following year, in public, describing what happens once you try to ship something real that way, and adjusting his own advice accordingly. That carries more weight than any argument we could make ourselves.

What “reading the code” means in practice

None of this requires a computer science degree. “Reading the code” is a specific, buildable habit, not a euphemism for “go learn to program first.” In practice:

1. Before you accept a change, get your agent to state it back in one or two plain sentences: which file, what behavior, why this approach. If the explanation doesn’t make sense to you, that’s information about the change, not a verdict on you.
2. Know which parts of your app are load-bearing: anything touching a login, a payment, a database write, or an environment variable. Slow down there. Move fast everywhere else.
3. When a bug survives two or three fixes in a row, that’s the moment researchers and forums both describe as the 70 percent wall. Stop prompting variations on the same fix and go find out what’s actually happening first.
4. Treat repeated, directionless back-and-forth with the agent as a signal rather than an annoyance. That pattern has a name, prompt fatigue, and it usually means you’re patching a symptom you never understood.
5. If your agent invents a function, an API, or a library that doesn’t exist, catch it by reading the actual line, not by watching the app seem to work. That’s AI hallucination, and it hides in code that compiles just fine.

None of this asks you to write a single line yourself. It asks you to look, every time, at what just changed and ask whether you could explain it to someone else. That’s the actual skill, smaller than “learn to code,” and it’s the thing that consistently separates people who ship software that holds up from people rebuilding the same feature for the fourth time.

What Glim would tell you

This is close to the whole reason Glim exists. Glimfly builds Glim, a small companion that narrates what your agent is actually doing while it’s doing it: which file it touched, what that change means, why it reached for one approach over another. It doesn’t read the code for you. It builds the vocabulary you’re missing, one real change at a time, until you can do the reading yourself. If a term in this guide didn’t land, the dictionary has the rest of it, explained the same plain way.