When Code Outpaces Understanding

The essay argues that generative AI decouples code from the program's "theory" in the developer's head (Naur's Programming as Theory Building): the model produces a correct-looking artifact faster than a person can build up an understanding of it. The author grounds the hypothesis in a triangulation of data — declining refactoring (GitClear), a slowdown despite the opposite feeling (METR), impaired learning (Anthropic), security vulnerabilities (Veracode), and declining delivery stability (Faros, DORA) — and fairly acknowledges the counterarguments, as well as the fact that this is directional rather than peer-reviewed data.

In 1985 the Danish computer scientist Peter Naur described a case that today reads like a warning written four decades before anyone was ready to listen. One team wrote a compiler for a programming language. A second team was to extend it, and was given everything one could wish for: complete documentation, commented source code, written design notes, and personal consultations with the original authors. And yet it kept proposing one modification after another that failed to exploit the compiler's internal structure and instead pasted onto it patches that broke its original simplicity. The first team saw this at a glance and each time offered a solution guided by the existing structure. The second team ultimately succeeded, but only thanks to that personal help. When the compiler was later taken over by further programmers without it, things turned out differently: after ten years the original elegant construction was still recognizable, only buried under formless accretions and effectively useless.

From this Naur drew the thesis that gave his paper Programming as Theory Building its lasting value. The real product of programming is not the code. It is the theory in the programmers' heads: the knowledge of how the program maps onto the world, why each of its parts is the way it is, and what would be a sensible and what a ruinous change. The code is only a lossy projection of this theory. When the team that holds the theory disappears, the program is, according to Naur, dead; reviving it from the text alone is impossible, because the text does not carry the theory. It did not carry it even in that compiler, where there was a surfeit of it.

This is where my reflection begins: generative artificial intelligence does to programming something that was never possible before: it decouples two things that always grew bound together — the code itself and the theory in the head of the one who writes it. Before the era of language models a program grew roughly at the pace at which the author's theory grew, because writing the code was at the same time building that theory; one was impossible without the other. An assistant based on a large language model severs this bond. It produces a correct-looking artifact without a corresponding theory having formed in a human head, and it produces it orders of magnitude faster than a person could build the theory themselves.

It is a difference in kind, not in degree. Fred Brooks, in his 1987 essay No Silver Bullet, distinguished the essential and the accidental complexity of software. Historical leaps in productivity, whether higher-level programming languages or better tools, attacked the accidental kind, the labor of representation; the essential complexity, that is, the design of the conceptual construct itself, remained untouched. Model-generated code accelerates precisely the representation, the easier half of the problem, and leaves the conceptual construct alone — and on top of that decoupled from the human. It attacks the wrong half.

A good hypothesis should state what could refute it. Naur's framework yields a concrete prediction: if models produce code without theory, refactoring must decline. Of all programming activities it is the one most dependent on theory — it is precisely the capability Naur describes: seeing the similarity between a new requirement and the existing construction and consolidating the code into reusable units. Without the theory of the system it cannot be done. If refactoring did not decline as the volume of machine-generated code grew, my thesis would be substantially weakened.

The analytics firm GitClear went through 211 million lines of changed code from 2020 to 2024. The share of moved, that is refactored, lines fell from 24.1% in 2020 to 9.5% in 2024, while the share of copied lines rose from 8.3% to 12.3%. 2024 was the first year in which copying overtook moving. The incidence of duplicate blocks of five or more lines increased eightfold in the same year. Meanwhile the volume of code grew. The prediction thus came out in the expected direction. This is a correlation, not a proven cause: the firm infers model adoption from timing, not from direct measurement at each commit. Even so, it is the hardest single finding in the whole reflection.

A second line of evidence aims at the human being. A controlled 2025 METR experiment followed sixteen experienced open-source developers across 246 real tasks in repositories they themselves know intimately over the long term. Before they began, they expected models to speed up their work by 24%. After the experiment ended, they estimated a 20% speedup. In reality they were 19% slower with the model's assistance. That discrepancy between feeling and measurement is more important than the number itself. It comes with a caveat: these were experts on code they know intimately, that is, exactly the situation where the model's marginal benefit is lowest; it does not follow that it never helps.

A third line shows what happens to learning. In January 2026 researchers at Anthropic had fifty-two developers solve tasks in an asynchronous library they did not know. The group with model assistance scored 17 percentage points worse on the subsequent comprehension test, 50% versus 67%, and the largest drop was in debugging. The manner of use mattered: those who asked the model about principles and connections retained their understanding; those who fully delegated the task lost the most. The same pattern shows up not only in programming — a survey of more than three hundred knowledge workers conducted by Microsoft Research and Carnegie Mellon found that the greater the trust in the model, the less of one's own critical thinking a person expends. And it is worth noting who published the study on skill loss: a firm whose business interest points in the opposite direction.

The fourth and fifth lines shift the view to the level of entire systems and teams. The security firm Veracode found in 2025 that in 45% of the tested cases the model introduced into the code a vulnerability from the OWASP Top 10; for Java it was over 70%, and the result did not improve with newer models. Telemetry from the firm Faros AI, covering twenty-two thousand developers, showed that as model adoption rose the ratio of incidents per pull request increased by 242.7%, the share of changes merged without any review by 31.3%, and the number of bugs per developer by 54%. The Google DORA report for 2024 attributed to every 25-percent increase in adoption an estimated 7.2% decline in delivery stability; at the same time, however, it also measured improvements in code quality, review speed, and documentation, so the picture is not one-sided. All of these are data from vendors and from telemetry, directional rather than peer-reviewed evidence. They converge strikingly nonetheless.

Against this, a defense suggests itself: surely the tests will catch it. But test coverage verifies that the code does what it does — it does not verify why it does it. It verifies behavior, not theory. Michael Feathers once defined legacy code simply as code without tests; the decoupling I am speaking of here begets its successor — code without theory, which passes tests just fine. The green light then gives false reassurance: it is on, and yet the theory of the system in the human head lags behind the code. It is a debt that is booked nowhere — until someone has to repay it.

The strongest counterargument runs that artificial intelligence is simply another layer of abstraction. We do not understand the compiler, the processor, or the libraries in depth either, and yet we build working software; the model is just another story above assembler, the C language, and Python. The objection is serious, but it fails in one place. Stable abstractions are deterministic, specified, and contractual — I rely on the compiler precisely because I do not need to know its theory; its behavior is guaranteed. Model-generated code is nondeterministic, unspecified, and sits at the level where the theory decides; it is load-bearing business logic, not solid ground underfoot. So it is no further layer of abstraction at all — it is a decoupling.

A second objection is brought by the data itself. The continuation of the DORA report from 2025, built on roughly ninety-percent model adoption, shows that artificial intelligence behaves more like an amplifier than a uniform destroyer: it speeds up mature teams and multiplies the dysfunction of immature ones. Here I must give ground and narrow the thesis — it does the most harm where the foundations are weak or where the human fully delegates the work. A conditional claim bears more weight than an absolute one. It must be added, however, that even this relief is contestable: the Faros telemetry cited above found no hint that mature organizations were protected from the quality decline — the degradation came regardless of initial maturity. Between an amplifier and a flat tax on everyone, the data has not yet decided.

A third objection is plain: millions of people ship working software with the help of models every day, so the thesis must be false. But shipping is not the same as understanding. My thesis predicts hidden rot — and that is exactly the observed signature of the five lines above: swelling duplication, declining delivery stability, incidents multiplying faster than reviews. "It works today" and "it is rotting from within" do not contradict each other in any way.

The fourth objection is the most serious of all: models will improve and will, in the end, be able to hold the theory, whether thanks to large context or to agentic loops. In the work logs of today's agents one can see them forming hypotheses about the system and verifying them. That models are improving fast was, after all, shown by METR itself: when it repeated its experiment in February 2026 with tools from the end of 2025, the slowdown for newly recruited developers was only 4% against the original 19%; for some of the original ones, however, it stayed close to 18%. Here my thesis is at its most vulnerable, and it is fair to admit it. So far, though, agents build a local and fleeting theory, bound to the context window; they do not hold a lasting theory of a particular system, mapped onto a particular reality of the world, across many sessions. And even among the people who use them, the Anthropic study showed that they build less theory. The day it is proven that agent users remember the system and can later modify it themselves, without help, as well as those who wrote it by hand, will be the day this reflection needs rewriting.

The unpleasant part remains. In 1983 the engineering psychologist Lisanne Bainbridge described the ironies of automation. Automation takes from a person the routine that was building their skill, and leaves them precisely the hardest tasks, the ones it has meanwhile deskilled them out of. The developer who did not write the system and does not fully understand it is exactly that operator: the person the task has deskilled and whom we nonetheless ask, at three in the morning during a production outage, to take over the controls of a machine whose theory they never built. Edsger Dijkstra named it as early as 1972: the programmer runs up against the strictly limited size of their own skull. The decoupling does not move that limit anywhere — it merely accelerates the inflow of code that is supposed to fit behind it. The fatigue from working with models is therefore not the fatigue of supervision at a single moment. It is the fatigue of responsibility without understanding, held continuously and against a target that grows faster than we can manage to encompass it.

The question, then, is not whether artificial intelligence writes good code. It is who will hold the theory at the moment the program needs saving — and whether we will even recognize that it is dead before it stops running.

The data and sources were verified as of 3 June 2026. The figures from corporate reports and telemetry (GitClear, Veracode, Faros AI, DORA) are directional, not peer-reviewed evidence; the core thesis about understanding growing more slowly than code has no direct study and is the author's hypothesis supported by triangulation of independent sources. Before using it for decision-making, I recommend updating the data and independently verifying the key findings.

Creation transparency:

The conception, structure, and editorial line of the article are the work of the author, who drew up the content sketch, established the key theses, and directed the entire creative process. Generative AI (Claude, Anthropic) was used as a tool for research, locating primary sources, and the formulational elaboration of the author's content sketch.

The author edited the outputs continuously, verified the key findings, and approved the final wording. No part of the text was published without human review. All factual data were verified against the publicly available sources cited in the text.

The procedure complies with the requirements of Article 50 of EU Regulation 2024/1689 (the AI Act) on the transparency of AI-generated content. #poweredByAI