In 1985, Peter Naur published "Programming as Theory Building" after observing a recurring failure: when a completed program, along with its source code and comprehensive documentation, was transferred to another team, the receiving team often made incremental changes which seemed reasonable but led to gradual program deterioration. Despite having all appropriate documentation, the new team lacked insight to the underlying rationale for the code's structure.

Naur contended that the primary product of programming is the theory internalized by the founding developers. This theory enables explanation of the code, its relationship to the addressed problem, and anticipation of modification consequences. Documentation and source code are only partial, inherently incomplete representations of this theory. Once the original theory is lost, the program becomes effectively defunct, regardless of documentation quality. Subsequent changes become speculative.

Naur challenged the assumption that programmers are interchangeable if sufficient documentation is available. This argument remains highly relevant, as most new code is now generated by coding agents that begin each session with limited understanding of the underlying theory.

Empirical studies have quantified the effects of coding agent adoption. Among 22,000 developers, task completion per developer increased by 34%, while bugs per developer rose by 54%. Incidents per merged change more than tripled. Median review time increased approximately fivefold (Faros AI, 2026). While some of these effects are attributable to increased code volume, others are not. A causal difference-in-differences study of 806 repositories adopting Cursor found a significant but temporary increase in development velocity, accompanied by a persistent rise in static-analysis warnings and code complexity, resulting in decreased per-project quality (He et al., 2026). In 20,574 agent sessions, misalignment between agent and developer persisted across adjacent sessions within the same repository. The proportion of constraint violations and inaccurate self-reporting increased over time, even as the overall rate declined (Tang et al., 2026).

Three missing things

When agents generate code, three critical elements are lost: the developer's understanding of the module, mutual agreement between teams on shared interfaces, and the rationale underlying completed work.

The first issue concerns the loss of understanding. Developers who address defects acquire valuable knowledge about the module, improving the quality of later contributions. Delegating these tasks to agents reduces opportunities for such knowledge acquisition. In a randomized experiment, developers using AI assistance to learn a new library scored 17% lower on comprehension tests than those who wrote code manually, with full delegation resulting in the greatest deficit (Shen and Tamkin, 2026). As a result, subsequent fixes are performed by individuals lacking sufficient background knowledge, leading to repeated failures in the same modules. Modules with the fastest code integration rates show the highest frequency of such failures, indicating diminished developer understanding.

The second issue concerns interfaces. Conway (1968) observed that a system's structure mirrors the communication patterns of its developers. An interface between two components represents an agreement between groups and requires mutual awareness. If one group changes its expectations without notifying the other, both may pass their respective tests, yet the feature may fail. Agent sessions operate on only one side of this agreement and lack communication with the other group, resulting in a lack of ownership over the interface. This creates a coordination problem that cannot be resolved solely by addressing the loss of understanding.

The third issue concerns the agent's self-reporting of its work. When direct observation is not feasible, reliance on self-reporting or objective measurement becomes necessary. Human contractors are incentivized to provide accurate accounts through reputation and liability, but agents lack these mechanisms. In a study of 11,755 agent runs, agents that reported completion were incorrect in approximately three-quarters of failures where no independent check was available. Alternative models reviewing these claims could not reliably detect inaccuracies. When an independent verifier could confirm the actual state, false completion rates dropped to 3% (Advani, 2026).

Improving model alignment does not resolve this issue. In the same study, models that included reasoning traces were among the least reliable, as their reasoning mainly justified completion claims rather than verified them. Over a year of real-world sessions, inaccurate self-reports increased as a proportion of agent failures, even as model performance improved (Tang et al., 2026). Most inaccurate completion reports are not intentional misrepresentations but result from agents' incomplete contextual awareness. Enhancing agent honesty does not address this problem. Objective verification mechanisms, such as test executions, type checks, or deployment readbacks, provide effective and low-cost solutions regardless of the underlying model.

All three issues existed prior to the adoption of coding agents. Agents alter not only the speed of delivery but also the process itself. They generate working code without requiring a person to write or read it. Previously, writing and reading code facilitated the development of understanding, interfaces, and accurate self-reporting. Manual coding, though slow, ensured that these elements were established as a byproduct. When this step is removed, code is delivered more quickly, but the accompanying theory is absent. Agents accelerate delivery while bypassing the activities that previously addressed these gaps; without intentional efforts to close them by other means, faster agents may worsen outcomes rather than improve them.

Rules don't apply themselves

A typical response is to improve how knowledge is documented. However, empirical evidence indicates that this approach has consistently failed to address the underlying issues, even when applied at scale.

Naur's argument that not all relevant theory can be externalized is supported by Polanyi (1966), who wrote that we know more than we are able to articulate. A senior engineer often understands the implications of a code change without being able to fully explain why. Ryle (1949) made a related distinction between knowing that, which you can state, and knowing how, which you can do but not fully explain, like riding a bike. An engineer with a comprehensive theory can predict outcomes, but cannot fully reason about their intuition.

Furthermore, Wittgenstein (1953) argued that rules do not contain the criteria for their own application. Faced with a concrete case, someone has to decide which rules apply, or whether it's an exception. Those decisions require knowledge external to any given rule. Similarly, Badea and Artus (2021) argue that any rule in symbolic form is open to interpretation, whose guiding values cannot themselves be written as rules.

The study of law has long grappled with similar issues and is informative to this discussion. Hart's (1961) called the phenomenon the "open texture of law" and identified two causes. The first is language. Every general term has a core of settled meaning and a penumbra of doubt. A rule saying "no vehicles in the park" clearly bans cars, but does it ban bicycles, or an ambulance? The second is foresight. Rule-makers cannot anticipate every future case, so even a perfectly worded rule meets situations its authors never imagined. Hart's conclusion was that every legal system is a compromise between two needs: rules must be definite enough that people can apply them to themselves without asking an official, and open enough to be administrable and adjustable to real-life conditions. Trained professionals (judges, lawyers, prosecutors, etc) are required to help administer and navigate this system.

There have been different attempts to make law fully algorithmic. Frederick the Great's Prussian code of 1794 ran to some 19,000 provisions in an attempt to decide every civil law case in advance. Judges were prohibited from interpreting the laws; disputed questions were to be referred to a royal commission. Revolutionary France tried the same device, the référé législatif, sending interpretive questions back to the legislature. Both attempts were unsustainable and reversed within a decade. Today the civil and common law traditions differ mainly in how they weigh precedent, not in whether interpreters are needed (Merryman, 1969). Two independent legal cultures, starting from opposite theories of written rules, converged on the same optimum.

Providing rules and context to coding agents is the latest version of the same experiment. AI agents are often provided with rule sets that include specific instructions, but lack generalizable guidance on how to apply them. Three studies found that context files make agents cheaper to run, but fail to improve the quality of the work (Gloaguen et al.; Khatri; Lulla et al., 2026). Agents continue to struggle when rules require interpretation or when no rules apply.

These findings apply only to rules that require interpretation. Machine-executable rules are different. This is why compiling the same instructions from prose into executable checks that intercept an agent's actions raised constraint compliance from 67% to 88% (Sharma, 2026). Specifications written as tests rather than prose offer a useful alternative and a path forward for addressing the theory gap.

Operating model implications

Goldratt's (1984) theory of constraints holds that a production system is governed by one binding constraint at a time, and that improving anything else changes little until that constraint is relieved. Operating models in software can be read the same way. Each method, Scrum, XP, Kanban, and the rest, is partial, built around the relevant constraining factor at the time. For agent-written code, the constraint has moved to the supply of good judgment. No existing method was built around that.

The named methods sort into families by the constraint each was built against. Ohno (1988) built the Toyota system in capital-scarce postwar manufacturing, where inventory was the binding constraint. Scrum and XP emerged in the 1990s, when market cycles shortened and the reliability of plans and the cost of late changes became the binding constraints on software delivery (Schwaber and Sutherland, 2020; Beck, 2004). Continuous integration and DevOps formed when merging and releasing code became slow and error-prone as teams and codebases grew. Team Topologies emerged in the 2010s, when systems had grown too large for a single team to understand (Skelton and Pais, 2019). SAFe and LeSS operate one level up. Coordinating many teams is a different problem from limiting how much one team must understand. Coordination needs grow with the number of teams involved. Galbraith (1974) treats that growth as a separate design problem from any single unit's capacity.

Classified by the constraint each was built against, the methods sort into five families.

The table supports two key observations. First, two of the families make assumptions about how engineers acquire knowledge of the code. The discipline family's collective ownership, exemplified by the "you build it, you run it" approach, assumes that engineers learn the code by writing and operating it. However, the delegation experiment proves that this assumption is no longer valid. The cognitive-load family assumes that understanding is maintained by a bounded team with a designated owner, which remains true. Second, the cognitive-load family is the only one whose constraint is a property of human understanding rather than of the work itself. Its constraint is the closest to judgment among the five.

On this account, the current shift deserves an operating model built around (human) judgment as the main constraint, following the same pattern that produced every earlier family. An operating model can address a binding constraint in two ways: reduce demand or increase supply (Galbraith, 1974). Galbraith also names the mechanisms available for each. Demand for a scarce decision resource is reduced through rules and programs, decisions made once and applied mechanically to every routine case, and through self-contained units that need little coordination between them. Supply is increased by referring the exceptions the rules cannot decide to those able to decide them. It is protected by slack, capacity deliberately held below full load. A well-designed operating model therefore minimizes the instances where judgment is required and allocates the remainder deliberately. This gives the operating model three tasks, each borrowing its practices from the family that already solves a version of it.

1. Reduce the need for judgment.
2. Increase the supply of judgment.
3. Protect that supply from being overrun by demand.

The first task applies Galbraith's "rules and programs" through the discipline family: a rule that can be executed should be written as an executable artifact instead of prose. This was recognized already before agents, with modest quality gains from test-first work (Rafique and Misic, 2013). Furthermore, it becomes more important once code is agent-written, because a test is verifiable and provides the agent with a clear signal to act. Compiling instructions into executable checks raised agent compliance from 67% to 88% (Sharma, 2026). Anthropic's own guidance for agentic software delivery applies the same rule across a full lifecycle. Each stage commits a checked artifact, intent, spec, plan, and tests that the next stage reads and verifies against, rather than reinterpreting what was meant from memory (Claxton, 2026). The same rule applies to interfaces and to the merge decision. Both should be established by execution, rather than diff analysis. Where the environment offered no independent check, agent completion reports were wrong in about three-quarters of failures, compared with 3% when an independent verifier could confirm the state (Advani, 2026).

The second task applies Galbraith's "self-contained unit": the owned module. Examining Windows components, Bird, Nagappan, Murphy, Gall and Devanbu (2011) found that failure rates rose with the share of changes made by minor contributors, engineers with little ongoing stake in the module. An agent session has no ongoing stake in any module either. In that sense, a codebase written mostly by agents is a codebase written mostly by minor contributors, which Bird found to be failure-prone. A named owner is the module's self-contained unit.

Ownership removes the need for a separate code review. Review developed to put a reader other than the author in front of each change. Bacchelli and Bird (2013) identify that independence as its principal benefit. Where the agent is the author and the owner the reader, that independence is already present in the ownership arrangement. The two functions coincide. One benefit of the original practice does not transfer. The exchange of understanding between author and reviewer requires two people. Only the owner remains. AI review does not substitute for it, since it focuses on defects and contributes little of the knowledge that passes between the human author and the reviewer (Zhong et al., 2026).

Ownership only supplies judgment if the owner understands the module. How the owner works with the agent determines whether that understanding is retained. In a controlled experiment, developers who directed the work in conversation retained a measurable degree of comprehension, while those who delegated it lost it (Shen and Tamkin, 2026). Delegated code is code the owner has not reasoned through, which reproduces the loss of understanding that Bird associated with minor contribution.

The third task applies Galbraith's "slack" through the flow family: cap work in progress at the stage that is actually saturated, so that the people who exercise judgment are never loaded to capacity. Waiting time grows non-linearly as a system nears capacity (Kingman, 1961). The adoption data fits the curve, throughput up by a third while median review time rose roughly fivefold (Faros AI, 2026). Verification, not coding, is now the saturated stage, so that is where the cap belongs. The same rule bounds demand at intake. Shape Up already does this, subject to one correction. It sizes a cycle by what can be built. The cycle should instead be sized by what the owning team can verify.

Taken together, small teams own modules and accumulate precedent. Work begins with a specification and tests and is sized by verification capacity. In modules with repeated fixes, a person directs the agent. Changes are merged through tests that execute the changed lines, then through the owner's reading of what the agent produced. A passing suite that never runs the changed lines proves nothing. Most Python agent pull requests have no changed line covered by any existing test (Dipongkor et al., 2026). Interfaces are owned and contract-tested. Demand is capped. Overruns are canceled rather than carried forward. The principle behind every practice is the same. Execute what can be executed, and retain an interpreter for what cannot.

Where this could be wrong

The argument depends on Naur's assumption that the relevant theory of a system is not fully externalizable. This is a weaker proposition than a claim that such practice cannot be recorded. It is the one the evidence supports. Documentation is abbreviated, written under time pressure, or omitted. Some knowledge may resist articulation entirely. The cause is secondary. In each case, the agent operates on an incomplete account of what the team understands.

Whether the unrecorded theory can be supplied to an agent after the fact is an empirical question. Research on giving agents a persistent representation of a codebase and its history speaks to it. Should a complete decision record allow an agent to produce correct changes where sparse context files did not, the missing information was largely unrecorded rather than unrecordable. In such a case, the human role contracts to final verification. Should richer records reach a limit, some portion of practice cannot be captured. Module owners remain necessary. The second result appears more likely, though the confidence attached to it is moderate.

Recurrent defects have causes unrelated to agents. High personnel turnover produces the same pattern. A team that adopts agents while hiring rapidly cannot readily distinguish the two. The claim is that agent authorship is one route to the pattern, not that the pattern establishes agent authorship as its cause. The diagnosis can be examined by assigning clear ownership and executable specifications to the modules that fail repeatedly. If agent authorship is the operative cause, the rate of repeat fixes in those modules should decline within a project cycle. If it does not, the cause lies outside the account given here.

References

Advani, L. (2026). From confident closing to silent failure: Characterizing false success in LLM agents. arXiv:2606.09863.

Bacchelli, A. and Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. ICSE 2013, 712-721.

Badea, C. and Artus, G. (2021). Morality, machines and the interpretation problem: A value-based, Wittgensteinian approach to building moral agents. arXiv:2103.02728.

Beck, K. (2004). Extreme Programming Explained: Embrace Change, 2nd ed. Addison-Wesley.

Bird, C., Nagappan, N., Murphy, B., Gall, H. and Devanbu, P. (2011). Don't touch my code! Examining the effects of ownership on software quality. ESEC/FSE 2011, 4-14.

Claxton, L. (2026). The AI-native SDLC playbook. Anthropic. https://claude.com/blog/the-ai-native-sdlc-playbook

Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28-31.

Dipongkor, A. K., Baral, T., Lam, W. and Moran, K. (2026). Test coverage analysis of agentic pull requests. arXiv:2607.18057.

Faros AI (2026). AI Engineering Report 2026: The acceleration whiplash. https://www.faros.ai/research/ai-acceleration-whiplash

Galbraith, J. R. (1974). Organization design: An information processing view. Interfaces, 4(3), 28-36.

Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. North River Press.

Gloaguen, T., Mündler, N., Müller, M., Raychev, V. and Vechev, M. (2026). Evaluating AGENTS.md: Are repository-level context files helpful for coding agents? arXiv:2602.11988.

Hart, H. L. A. (1961). The Concept of Law. Oxford: Clarendon Press.

He, H., Miller, C., Agarwal, S., Kästner, C. and Vasilescu, B. (2026). Speed at the cost of quality: How Cursor AI increases short-term velocity and long-term complexity in open-source projects. MSR 2026. https://doi.org/10.1145/3793302.3793349

Sharma, R. K. (2026). ContextCov: deriving and enforcing executable constraints from agent instruction files. arXiv:2603.00822.

Khatri, P. (2026). Do context files help coding agents? A two-agent ablation study on real repositories. arXiv:2607.27250.

Kingman, J. F. C. (1961). The single server queue in heavy traffic. Mathematical Proceedings of the Cambridge Philosophical Society, 57(4), 902-904.

Lulla, J. L., Mohsenimofidi, S., Galster, M., Zhang, J. M., Baltes, S. and Treude, C. (2026). On the impact of AGENTS.md files on the efficiency of AI coding agents. ICSE JAWs 2026. arXiv:2601.20404.

Merryman, J. H. (1969). The Civil Law Tradition: An Introduction to the Legal Systems of Western Europe and Latin America. Stanford: Stanford University Press.

Naur, P. (1985). Programming as theory building. Microprocessing and Microprogramming, 15(5), 253-261. https://doi.org/10.1016/0165-6074(85)90032-8

Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.

Polanyi, M. (1966). The Tacit Dimension. Chicago: University of Chicago Press.

Rafique, Y. and Misic, V. B. (2013). The effects of test-driven development on external quality and productivity: A meta-analysis. IEEE Transactions on Software Engineering, 39(6), 835-856.

Ryle, G. (1949). The Concept of Mind. London: Hutchinson.

Schwaber, K. and Sutherland, J. (2020). The Scrum Guide. scrumguides.org.

Shen, J. H. and Tamkin, A. (2026). How AI impacts skill formation. Anthropic. arXiv:2601.20245.

Skelton, M. and Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution.

Tang, N., Chen, C., Xu, G., Shi, Y., Huang, Y., McMillan, C., Dong, T. and Li, T. J.-J. (2026). How coding agents fail their users: A large-scale analysis of developer-agent misalignment in 20,574 real-world sessions. arXiv:2605.29442.

Wittgenstein, L. (1953). Philosophical Investigations. Oxford: Blackwell.

Zhong, S., Noei, S., Zou, Y. and Adams, B. (2026). Human-AI synergy in agentic code review. arXiv:2603.15911.