Disposable Implementations: What Is Software Engineering For?

Disposable Implementations: What Is Software Engineering For? Christoph Treude

arXiv:2611.04383v1 [cs.SE] 3 Nov 2026

Singapore Management University Singapore

Abstract—Existing implementations are usually maintained for most of their life and replaced only as an exception. Coding agents may change that. If agents can produce new implementations from requirements, tests, architectural constraints, and operational records that survive replacement, changing a system may no longer require modifying its existing codebase. We call this process regeneration. An implementation is disposable when regeneration becomes a routine alternative to maintenance. Regenerating and verifying a clean implementation from current requirements and tests may be cheaper than having agents navigate (and potentially compound) existing technical debt, and could eliminate much of that debt. Yet existing code may contain knowledge absent from the preserved artifacts, including safeguards introduced after failures and assumptions that were never documented. A regenerated implementation may pass the available tests and still lose behavior that matters in production. This leaves open how to establish continuity across replacements and whether regeneration reduces maintenance effort or shifts it to the artifacts and processes that support it. We examine these questions through an exploratory review of practitioner literature. Published examples show that agents can replace existing implementations, but do not establish that repeated regeneration is safe or economical. If implementations become disposable, what should software engineering preserve? Index Terms—software maintenance, software evolution, coding agents, regenerative software, software knowledge

I. T HE I DEA Lehman’s first law of software evolution, continuing change, reads: “A program that is used and that as an implementation of its specification reflects some other reality, undergoes continual change or becomes progressively less useful. The change or decay process continues until it is judged more cost effective to replace the system with a recreated version” [12]. The cost of writing a replacement has fallen considerably since Lehman formulated his first law. Rather than modifying existing code, coding agents could produce new implementations from requirements, interface contracts, tests, architectural constraints, and operational records preserved across replacements. We call this process regeneration. An implementation is disposable when regeneration becomes a routine alternative to maintenance rather than a last resort at the end of a codebase’s life. The system persists; the implementation does not. An existing implementation embodies accumulated effort and knowledge, but it also carries technical debt. Coding agents reduce the effort needed to write a replacement, though not necessarily the cost of recovering the knowledge. As Chad Fowler puts it, “When code is cheap to generate, preserving it at all costs becomes irrational” [4]. Rather than having agents

navigate years of accumulated technical debt to make a change (and potentially compound that debt), it may be cheaper to regenerate and verify a clean implementation from current requirements and tests, potentially eliminating much of that debt in the process. Whether replacement makes sense depends on the software. Kanat-Alexander places software on a spectrum from disposable to durable according to four factors: the consequences of failure, the number of people and systems that depend on the software, the cost of rewriting it from scratch, and the cost of maintaining it [7]. At one end are applications that can be discarded and rewritten with little consequence; at the other are systems whose failure would be costly and on which other systems depend. He argues that rigorous software engineering remains necessary for durable systems, regardless of who writes the code. Coding agents primarily reduce one of his four factors: the cost of writing a replacement. They do not necessarily reduce the cost of verifying the replacement, integrating it with dependent systems, or migrating existing state. KanatAlexander also suggests making software more disposable by limiting the consequences of failure or the number of systems that depend on it, for example by restricting access to customer data. We instead ask whether an implementation can become disposable while the system it supports remains durable. Suppose AI agents maintain a service that other systems depend on. A new requirement changes how the service handles failed transactions. Rather than modify the code, the agents generate a replacement from the artifacts preserved across replacements. It passes the acceptance checks and is deployed, although its structure looks little like the previous version. The old code may be kept for reference, but it is no longer the starting point for the next change. Now suppose the old code contained a retry safeguard, added after a production incident. Nobody had documented or tested it. In Chad Fowler’s phrase, the implementation remembered what the organization had forgotten [2]. The agents leave out the safeguard because none of the preserved artifacts describes it, and the replacement loses a lesson learned in operation. What must carry over between implementations for us to regard them as versions of the same system? Software engineering may need to focus less on preserving an implementation and more on producing new implementations and establishing that they are acceptable. Three things that have usually been maintained together may come apart: the durability of the system, the continuity of its implementation,

Where does maintenance effort go? Lehman’s laws predict that complexity grows as software changes unless effort is spent controlling it [12]. Perry and Wolf describe a related decay, architectural drift, which they attribute to “insensitivity about II. W HY I T M ATTERS N OW the architecture” and which makes a system harder to adapt [11]. Planned replacement and generation from longer-lived arti- Regeneration from preserved architectural constraints might facts both predate coding agents. In 2014, Martin Fowler argued reduce such drift, but only if those constraints are complete that “often the best code you can write now is code you’ll and kept current. Agents may reduce the cost of writing code discard in a couple of years time” [1]; his sacrificial architecture without proportionally reducing the cost of making safe changes. allows an implementation that fits one stage of a system’s life With regular regeneration, does complexity disappear, return to be replaced at another. Model-driven engineering made in each new implementation, or shift into the artifacts and models the principal asset and used defined languages and procedures used to regenerate it? Servile warns that sufficiently transformations to generate implementations [3]. Coding agents precise specifications “start looking suspiciously like code” [13]. differ in that they can produce the replacement themselves from Maintaining such specifications could then cost as much as incomplete natural-language requirements, existing code and maintaining the code they replace. Well-structured code may documents, tool feedback, and executable checks. Böckeler also be cheaper for agents to modify: in an informal experiment, distinguishes spec-first, spec-anchored, and spec-as-source Edwards-Alexander found that refactoring a 17,000-line agentworkflows, and questions whether the latter two might inherit written Rust file reduced the input tokens needed for the same the inflexibility of model-driven development as well as the subsequent change by 83% [14]. non-determinism of language models [6]. IV. T HE Q UESTION W E W OULD P UT TO THE ROOM Chad Fowler describes regenerative software, arguing that Can a software system remain durable if its implementations the system, rather than its codebase, is the asset [4]. He asks what survives “when implementation becomes disposable” [17]. do not? If implementation continuity is no longer assumed, We ask when replacing an implementation benefits the system what does software engineering need to preserve, and how can we establish that the system continues to meet its obligations? it supports. In many systems, regeneration may remain limited to isolated III. W HAT W E D O N OT Y ET U NDERSTAND components, with most implementations still worth maintaining. What counts as continuity? A regenerated service is not In other systems, continuity may depend on continuously intended to be a copy of its predecessor: a new requirement is updated evidence or on the process that generates and validates what prompted the replacement. It may preserve its public API new implementations. Lulla et al. define loop engineering, and pass acceptance tests while changing performance, failure a term introduced in practitioner literature in June 2026, as behavior, security properties, or data migration guarantees. the practice of designing automated control structures that Should continuity be judged against observable behavior, repeatedly invoke coding agents [5]. For regeneration, such stakeholder intent, persistent data, contractual obligations, or loops would need to preserve knowledge across implementasome combination? Who makes that judgment if agents produce tions, verify each replacement against the system’s obligations both the implementation and its tests? independently of the agents that produced it, and control when What knowledge must persist? Requirements, tests, ar- replacements are deployed. Continuity might then depend as chitectural decisions, runbooks, and production observations much on the engineering process as on the artifacts it preserves. could all be preserved across regenerations. They will not V. W HY I T I S P LAUSIBLE necessarily capture the exceptions and compromises embedded in an existing implementation. Naur argued in 1985 that the Published examples include a large one-time replacement and theory needed to understand and extend a program resides the repeated regeneration of a small module. Timson reports in the people who developed it and cannot be fully conveyed a project that replaced 86 interdependent Go microservices, through code or documentation [8]. Piccoli extends this concern six years old and totaling roughly half a million lines of to coding agents: when an agent makes fine-grained design code, with a TypeScript monolith written by agents rather decisions without communicating them, software “becomes than humans [15]. The team ran an agent-written integration legacy immediately upon creation,” because neither the de- test suite against both versions. Passing the same tests, however, veloper nor the agent acquires the relevant understanding [9]. establishes agreement only for the cases covered, not behavioral Parnas identified two sources of software aging: neglecting to equivalence. The old code, including its bugs, served as the adapt software to changing needs, and making changes without specification, and the first generated test suite was discarded understanding the original design [10]. Regeneration can re- because it checked nothing. This was a one-time migration, move structural damage left by changes, but an implementation not repeated regeneration. Bartz-Beielstein reports an example generated without the original design concept can repeat the closer to regeneration as we define it: a 239-line module was same mistakes. What needs to survive replacement might be a deleted from a forecasting library and rebuilt three times by behavior, a constraint, a decision, a component boundary, or Claude Opus 5.5 using records of its intent, decisions, public an assurance claim rather than a file or repository. contract, and evaluations [18]. All three versions passed the and the knowledge required to change it safely. We develop this argument through an exploratory review of practitioner literature.

37 evaluations. Those records occupied 805 lines, including 453 lines of evaluation code—3.4 times the size of the module. The experiment involved only one module. Neither example establishes that regeneration is reliably safe or more economical than maintenance. Böckeler argues that code still matters when defects are difficult to detect and their consequences are serious [16]. Regeneration can become routine only if an engineering process can identify which behavior and constraints must survive, check that each replacement preserves them, and establish when regeneration is preferable to maintaining the existing implementation. VI. W HAT W OULD A DVANCE I T Laurie Voss argues that “if you can build something that proves you got the answer, AI can get the answer much faster than you can” [20]. Verifying a newly generated implementation is not enough: regeneration also requires evidence that the system continues to meet its obligations across replacements. Testing and dependability researchers could examine the risk of using the same tests to guide regeneration and approve its output. Software evolution and mining researchers could investigate how regeneration affects the interpretation of commit histories and measures of change, technical debt, and code churn. Architecture researchers might use Chad Fowler’s observation that cheap code “separates accidental irreversibility from intentional durability” [19] to distinguish constraints worth preserving from those introduced to make a codebase easier to modify. Requirements researchers could investigate how to record and update intent so that it survives replacement, particularly when specifications are incomplete. Human–AI systems researchers could study how engineers acquire the understanding needed to supervise systems that agents repeatedly replace, and where responsibility for the result lies. Possible evidence includes case studies of replacement projects, traces of agent-driven development, and experiments that systematically vary which artifacts are available during regeneration to determine what behavior or knowledge is lost. Repository histories alone are not enough: Lulla et al. found that repositories running agent loops rarely commit the loops’ state files [5], so studying disposability also means tracing agent executions and deployed behavior across repeated regenerations. The longer-term goal would be an empirical characterization of implementation disposability: which systems can evolve through regeneration, when it is a better option than incremental maintenance, what knowledge must survive replacement to make it viable, and where its costs and risks fall. Such a characterization needs a vocabulary for degrees of disposability and counterexamples where regeneration is unsafe or uneconomical. Regeneration may demand greater rigor in preserving knowledge and verifying behavior across replacements, since the existing implementation can no longer be relied on to carry that knowledge forward. We need to determine which artifacts, practices, and forms of evidence are worth preserving when implementations are routinely replaced.

Acknowledgments. The author thanks the organizers and participants of the Thoughtworks Future of Software Development Retreat Europe (Engelberg, Switzerland, June 2026) for discussions that informed this paper. Use of generative AI. ChatGPT and Claude helped refine the question, draft and critique text, verify references, and find practitioner literature. The author is responsible for the argument, citations, and final text. R EFERENCES [1] M. Fowler, “Sacrificial Architecture,” MartinFowler.com, Oct. 20, 2014. [Online]. Available: https://martinfowler.com/bliki/SacrificialArchitectur e.html [2] C. Fowler, “The Implementation Remembers,” The Phoenix Architecture, Jun. 14, 2026. [Online]. Available: https://chadfowler.com/regenerative-s oftware/3mobohx4fq22x/ [3] D. C. Schmidt, “Model-driven engineering,” IEEE Computer, vol. 39, no. 2, pp. 25–31, 2006. [4] C. Fowler, “Regenerative Software,” The Phoenix Architecture, Dec. 21, 2025. [Online]. Available: https://aicoding.leaflet.pub/3majnyfydzs2y [5] J. L. Lulla, V. Nersesyan, S. Mohsenimofidi, C. Treude, and S. Baltes, “Loop Engineering: Building Blocks, Adoption, and Impact,” presented at the 2nd Journal Ahead Workshop (JAWs@ASE 2026), arXiv:2608.21884. [6] B. Böckeler, “Understanding Spec-Driven-Development,” Oct. 2025, updated Sep. 2026. [Online]. Available: https://birgitta.info/posts/spec-d riven.html [7] M. Kanat-Alexander, “Does code quality still matter? It depends on this,” talk at AI Engineer NYC, Oct. 13, 2026. [Online]. Available: https://www.youtube.com/watch?v=bU5gDVyu_28; essay: https://www. codesimplicity.com/post/does-code-quality-even-matter-anymore/ [8] P. Naur, “Programming as theory building,” Microprocessing and Microprogramming, vol. 15, no. 5, pp. 253–261, 1985. [9] R. Piccoli, “Why generative AI won’t create 10x developers,” Thoughtworks Insights, Sep. 3, 2026. [Online]. Available: https://www.thoughtw orks.com/insights/blog/generative-ai/why-generative-ai-wont-create-ten -x-developers [10] D. L. Parnas, “Software aging,” in Proc. 16th Int. Conf. Software Engineering (ICSE), 1994, pp. 279–287. [11] D. E. Perry and A. L. Wolf, “Foundations for the study of software architecture,” ACM SIGSOFT Software Engineering Notes, vol. 17, no. 4, pp. 40–52, 1992. [12] M. M. Lehman, “Programs, life cycles, and laws of software evolution,” Proc. IEEE, vol. 68, no. 9, pp. 1060–1076, 1980. [13] V. Servile, “Should we still design code for humans?” Thoughtworks Insights, Jul. 23, 2026. [Online]. Available: https://www.thoughtworks.c om/insights/blog/programming-languages/should-still-design-code-hum ans [14] G. Edwards-Alexander, “The Economic Benefit of Refactoring,” MartinFowler.com, Jul. 30, 2026. [Online]. Available: https://www.martinfowler .com/articles/exploring-gen-ai/refactoring-economic-benefit.html [15] P. Timson, “Can You Trust Code No Human Wrote?” Mindstone Blog, Jul. 6, 2026. [Online]. Available: https://blog.mindstone.com/p/can-you-t rust-code-no-human-wrote [16] B. Böckeler, “I still care about the code,” MartinFowler.com, Jul. 9, 2025. [Online]. Available: https://martinfowler.com/articles/exploring-gen-ai/ i-still-care-about-the-code.html [17] C. Fowler, “The Phoenix Primitives,” The Phoenix Architecture, Apr. 13, 2026. [Online]. Available: https://chadfowler.com/regenerative-software/ 3mjfruwwuck2d/ [18] T. Bartz-Beielstein, “Deleting Code Without Losing Knowledge: Regenerative Software for Python Libraries,” arXiv:2610.17197, Oct. 12, 2026. [Online]. Available: https://arxiv.org/abs/2610.17197 [19] C. Fowler, “Most of Your Architecture Was Just Expensive Code,” The Phoenix Architecture, Aug. 21, 2026. [Online]. Available: https://chadfo wler.com/regenerative-software/3mtmk6ot6oc2i/ [20] L. Voss, “Apollo says AI hasn’t paid off outside tech. That’s because it’s 1997,” LinkedIn, Oct. 25, 2026. [Online]. Available: https://www.li nkedin.com/pulse/apollo-says-ai-hasnt-paid-off-outside-tech-thats-bec ause-laurie-voss-pkotc/

Related documents

• Software and Systems Reuse, Product Lines, and Configuration : First International Conference, VARIABILITY 2026, Limassol, Cyprus, September 29–October 2, 2026, Proceedings / edited by Gilles Perrouin, Thorsten Berger, George A. Papadopoulos, Ina Schaefer, Sophie Fortz#1353774
• The state of software maintenance#1436383
• Stabilization Without Simplification: A Two-Dimensional Model of Software Evolution#2705
• Software Engineering of Emerging Technologies : Second International Conference on Software Engineering of Emerging Technologies, SEET 2026, Behrend, PA, USA, August 10–11, 2026, Proceedings, Part I / edited by Shahid Hussain, Muhammad Abdul Basit Ur Rahim, Arif Ali Khan, Saif Ur Rehman Khan, Timothy Kurzweg, Naseem Ibrahim, Mansoor Ahmad#1202778
• Software Engineering of Emerging Technologies : Second International Conference on Software Engineering of Emerging Technologies, SEET 2026, Behrend, PA, USA, August 10–11, 2026, Proceedings, Part II / edited by Shahid Hussain, Muhammad Abdul Basit Ur Rahim, Arif Ali Khan, Saif Ur Rehman Khan, Timothy Kurzweg, Naseem Ibrahim, Mansoor Ahmad#1089405