{"schemaVersion":"1.0","type":"Article","types":["Article"],"slug":"ai-wrote-the-code-now-nobody-understands-it-q374p","url":"https://zyvop.com/ai-wrote-the-code-now-nobody-understands-it-q374p","title":"AI Wrote the Code. Now Nobody Understands It.","subtitle":"Naur said in 1985 that the real product is the theory in the team's heads. AI can write the code, but it can't hold that theory for you.","tldr":"Code that works and passes tests can still be code nobody understands. Here is what a 1985 essay, a controlled study and a 2026 interview study say about that gap, and what teams can do about it.","keywords":["comprehension debt","AI coding","maintainability","Software Engineering","code-review"],"entities":["Anshu Pathak","comprehension debt","AI coding","maintainability","Software Engineering","code-review","ZyVOP"],"keyTakeaways":["I keep hearing the same worry about AI-written code: it's sloppy, it's bloated, it'll rot the codebase.","But when I look at where teams actually get stuck, it's rarely the code itself.","It's that nobody can say why the code looks the way it does."],"headings":["Naur said it forty years ago","Review is the job now, and review is what slips","Nobody is being lazy","\"But nobody reads assembly\"","What I'd actually do","The part that's easy to miss","Further reads"],"outboundLinks":["https://pages.cs.wisc.edu/~remzi/Naur.pdf","https://www.fastcompany.com/91531519/google-ceo-says-75-of-the-companys-code-is-ai-generated","https://infoq.com/news/2026/02/ai-coding-skill-formation/","https://arxiv.org/html/2607.10856v2","https://www.infoq.com/news/2025/09/dora-state-of-ai-in-dev-2025","https://www.ssp.sh/brain/the-problem-is-not-the-ai-code-but-nobody-knows-anything-anymore/"],"contentText":"I keep hearing the same worry about AI-written code: it's sloppy, it's bloated, it'll rot the codebase. Sometimes that's true. But when I look at where teams actually get stuck, it's rarely the code itself. It's that nobody can say why the code looks the way it does. The code works. The tests pass. Ask why it retries three times, or why that column exists, and you get a shrug. That shrug is what I want to dig into. Naur said it forty years ago In 1985, Peter Naur wrote Programming as Theory Building. His argument: the valuable part of a program isn't the source or the documents. It's the theory in the heads of the people who work on it. That theory covers what the program is for, how it maps to the real problem, and why it was built this way and not another way. Naur used the idea to explain why programs decay. When people change a program without a real grasp of the theory, each change makes the text a bit worse. And if the team that holds the theory goes away, what's left is code nobody can properly extend. You can read it. You just can't ask it why. Now think about who is changing programs today. A model that usually starts each session from whatever context you hand it. It can write a huge amount of text, but it doesn't carry a theory from one session to the next. If the humans stop building one too, then nobody has it. Review is the job now, and review is what slips At Cloud Next this spring, Sundar Pichai said that 75% of new code at Google is AI-generated and approved by engineers, up from 50% the previous fall. Believe the number or don't. Look at the verb, though. For a growing share of code, the human contribution is the sign-off. A sign-off is only worth something if the person can tell when the code is wrong. That's the skill that took the biggest hit in a randomized trial by Anthropic researchers. Fifty-two mostly junior engineers learned an unfamiliar Python library, half of them with an AI assistant. On a quiz taken afterward without AI, the assistant group averaged 50% and the hand-coding group 67%. The widest gap was on debugging questions. The assistant group also wasn't meaningfully faster: about two minutes, and that difference wasn't statistically significant. The limits are real. One library, one sitting, mostly juniors, an immediate quiz. It doesn't show that a senior engineer in a familiar codebase will lose skills. What it does show is a loop worth worrying about. You need judgment to supervise AI, and leaning on AI while you learn weakens that judgment. The detail I like most is that how people used the tool mattered more than whether they used it. People who asked conceptual questions scored 65% or higher. People who handed over the writing scored below 40%. Same tool, very different outcome. Nobody is being lazy The uncomfortable part is that people see this coming. A July 2026 study interviewed 20 practitioners across 12 organizations, and surveyed 80 more, about how they build software-engineering agents. The researchers describe what they call comprehension debt: teams accepted code they couldn't fully explain because it worked and the deadline didn't move. One participant compared it to a landmine in the codebase that they knew might go off, but they couldn't afford to stop. The practices meant to pay this debt down also got weaker support in the survey than the study's other recommendations, so the authors treat it as unsolved. The sample leans toward big tech and toward people who build these tools, so don't stretch it too far. It matches how developers say they feel. In Stack Overflow's 2025 survey, only 3% said they highly trust AI output, and usage kept climbing anyway. So this isn't a discipline problem you fix with a stern memo. Nobody gets promoted for slowing down to understand something that already works. The bill does arrive. Google's 2025 DORA report found that AI adoption now correlates with higher delivery throughput, but it still correlates with more instability: more failed changes, more rework, slower recovery. DORA's own summary is that AI amplifies whatever an organization already is. \"But nobody reads assembly\" The best objection I know: we stopped reading compiler output decades ago and nothing bad happened. Maybe code is heading the same way, and worrying about it is nostalgia. I don't think that holds yet, for a boring reason. A compiler turns the same source into the same output, following a spec. A prompt doesn't. Ask a model twice and you can get two different programs, and neither is derived from your prompt in any way you can check. So the code is still the thing that gets deployed, debugged and changed. It's source, not output. That could change. The July study notes teams moving toward specifications that are versioned and read by both humans and agents. If that matures, the spec becomes the thing you have to understand, and Naur's theory moves up one level. It still has to live in somebody's head. What I'd actually do Nothing here means using AI less. It means using it the way the high scorers did, and leaving traces the chat window won't. Ask the model why before you ask it how, and make it explain a design back to you before you accept the code. Keep the reasoning in the repo. Five lines in the pull request saying what was chosen, what was rejected and why will outlast any chat session. Make sure a named person can answer questions about each area, and check by asking \"why\" in review, not just \"does it pass\". Save the slow, line-by-line review for changes that are hard to undo, like data models, auth and payments. Let the rest move fast. The part that's easy to miss Naur's warning is usually read as a story about turnover: lose the people, lose the program. With AI you can lose the theory without anyone leaving. Everyone's still there, the commits keep landing, and the understanding has quietly stopped forming. That's why it's so easy to miss until the first incident that needs it. Further reads Programming as Theory Building, Peter Naur (1985) Anthropic study: AI coding assistance and skill mastery, InfoQ's summary How Do Practitioners Build SE Agents?, the July 2026 interview study DORA 2025 report on AI-assisted development, InfoQ's summary The Problem is not the AI Code, but Nobody Knows Anything Anymore, Simon Späti","contentHash":"sha256:834696642e0b5b8ae272ea6bc237c2c6f545e2fa27fc681f4385018cc454f45f","authorName":"Anshu Pathak","authorUrl":"https://zyvop.com/author/anshu","authorSameAs":[],"category":null,"tags":["comprehension debt","AI coding","maintainability","Software Engineering","code-review"],"audience":"Readers and engineers researching comprehension debt","tone":"Practical and evidence-based engineering guidance","readingTimeMinutes":5,"wordCount":1096,"faqs":null,"primaryTopic":"comprehension debt","publishedAt":"2026-09-30T02:41:04.181Z","updatedAt":"2026-09-30T02:41:04.181Z","canonicalUrl":"https://zyvop.com/ai-wrote-the-code-now-nobody-understands-it-q374p"}