When Code Begins to Write Itself

This blog post is machine-translated from the original Chinese version. Link: https://mp.weixin.qq.com/s/BBg8rxH9EwfmFkKkZYJVhA

In early 2025 Andrej Karpathy coined a term: vibe coding. You tell the AI in natural language what you want, the AI generates code, and you do not read it carefully — if it looks about right, you accept it. Give in to the vibes. The phrase caught on to the point that Collins Dictionary named it word of the year for 2025. A year later, it is already obsolete.

What has replaced it is loop coding, or more precisely loop engineering. Where is the difference? In vibe coding the human is still inside the loop: he has stopped writing code, but he is still looking, still feeling, still nodding and shaking his head. In loop coding the human factor withdraws from the loop itself. You first design an autonomous loop; the AI agent takes the task and runs on its own — writes code, runs tests, reads the errors, edits the code, runs the tests again, and continues until a preset termination condition is met. The human role retreats from judging inside the loop whether this is right to designing the loop’s structure and its stopping condition. Claude Code, Devin, OpenAI Codex Agent — the core working mode of every mainstream AI coding tool now is this.

Discussing ChatGPT 5.5 Pro on mathematics problems, Gowers remarked that very good coders are better at vibe coding than not such good coders. Placed in the context of loop coding, the observation needs updating. In vibe coding a good programmer’s advantage is intuition: he can feel where the generated code is wrong. In loop coding his advantage is architecture: he can design a loop framework the AI will find it hard to wander out of. The first is a wine taster; the second is the food engineer at the winery. But the two share something: if you do not understand the thing yourself, you can neither sense the problem nor design the loop well.

Loop coding is genuinely fast. A good framework can generate, test and repair dozens of files in minutes. A feature module that traditionally took a junior engineer a week, a loop agent will deliver in an afternoon — along with a great many burned tokens — in a version that runs. This speed is itself changing the economics of the software industry.

But the first consequence of that speed is not a decline in code quality. It is a break in comprehension. Addy Osmani at Google gave the phenomenon a name, comprehension debt — he credits the term to Jeremy Twei. When code is produced faster than humans can read it, you are borrowing from the future, and what you are borrowing is your own future capacity to maintain the system. Traditional technical debt is knowing the code is bad and having no time to fix it. Comprehension debt is not knowing whether the code is good, because no one has read it. This is not a metaphor. GitClear’s 2026 data shows that on teams making heavy use of AI coding, code churn — the proportion of code that must be revised or deleted after being written — rose by 39%. Seventy-five percent of engineering leads expect to accumulate moderate to severe technical debt from AI-assisted development within twelve months. There is more code and less understanding.

This leads to a deeper problem. When people cannot finish reading what the AI has written, they naturally fall back on proxy indicators: did the tests pass? Is CI green? Did lint stay quiet? These tools worked well at the speed a human writes code, because human output rate was itself a form of implicit quality control. But once a loop agent raises output by an order of magnitude, those proxies are forced to carry far more weight than they were designed for. Tests passed does not mean the code is correct; it means only the code satisfies the conditions the tests happen to cover. The difference lies in what the tests do not cover — and AI-written tests and AI-written code tend to share the same blind spots.

This is where things start to get strange. When a loop agent meets, inside the loop, something it does not know how to resolve — an API returning a format it has not seen, a library behaving differently from the version in its training data — it does not stop and say I don’t know. We have now observed, in many settings, that it will sometimes invent a solution that looks entirely reasonable: assume an API endpoint that does not exist, define a data format that does not conform to the specification, or write a comment saying according to the documentation, the default value of this parameter is X when the documentation contains no such sentence. This is not a bug in the traditional sense. A bug is code that fails to work as expected; here the code works perfectly against an expectation the AI invented for itself. The loop framework becomes a closed, self-validating system of fiction, wholly consistent on the inside. The problem surfaces only on contact with the real world: a user sees data that should not appear, a third-party service returns a format that should not exist. And by that point what we face is not a bug but a virtual building raised on a fictional foundation, with virtual light showing through one of its virtual windows.

In medical imaging we have found that mainstream vision-language models will still produce a fluent, confident diagnosis when the evidence does not support one. We call this silent failure. What happens in loop coding is the code version of the same failure mode: the model does not know that it does not know, and its confidence disables every verification mechanism downstream. In imaging the consequence is a potentially absurd misdiagnosis. In code it is a system that looks entirely normal, passes every test, and then breaks three months after launch under some particular condition — and once repaired, breaks under another.

The process also accelerates itself, because every round of a loop agent’s output becomes the input to the next round. If a false assumption enters at round three, round four will not correct it; round four will treat it as established fact and build new code on top. By round ten, that small original fiction has been buried under layer upon layer of logic. The heap of terrible code a human programmer leaves behind at least has a human being’s thinking buried inside it: you can curse him, follow his logic, and roughly reconstruct what he was thinking and how he went wrong. The heap an AI leaves behind has no thinking in it at all. It is a stack of locally optimal solutions, each layer solving a problem created by the layer beneath it.

I wrote recently about artificial intelligence in The Infinite Game and The Last Instruction, breaking learning into three motions: the problem raiser (what to learn from), the problem solver (how to learn), and the problem judger (whether the learning objective has any value at all). Loop coding is a nearly perfect instance of a raiser–solver loop: the agent continually discovers problems (a test failed) and solves them (edit the code), the loop drives itself, and no human intervention is required. It can even run with no explicit judger, using the test cases as referee — passing means right, failing means keep editing.

But I also wrote this in that piece: as the raiser–solver becomes more autonomous, the inherited lossy proxies are forced to bear far more normative weight than they were ever designed to carry, and capability that has not been examined is what people call danger. What loop coding is staging now is the concrete version of that abstract argument. A test case is a lossy proxy. It can judge whether code satisfies some set of preset conditions. It cannot judge whether that set of conditions is complete, and still less whether this code should have been written at all.

Code has begun to write itself. It writes quickly, it writes confidently, and all the tests pass. But the question of whether it should be written still has to be answered by a person — assuming there is still a person watching.