When Code Becomes Disposible...

Would you delete a working module today?
For decades, software engineering has been built around one assumption: code is expensive to write, so we must preserve, maintain, and carefully evolve it. But AI is changing the economics of software development. Writing code is becoming cheaper than understanding it, and trusting it is becoming even harder.
What happens when code becomes disposable?
This talk challenges some of our deepest beliefs about software engineering. From clean code and refactoring to testing, code reviews, and ownership, many practices we consider essential were designed for a world where humans write and maintain code.
We’ll explore the emerging idea of regenerative software, where implementations can be deleted and rebuilt while the system's behavior, contracts, and guarantees survive. We'll examine why evaluations, architectural decisions, provenance, and institutional knowledge may become more valuable than the code itself.
This isn't about the death of programming. It's about rethinking what software engineering means when code is no longer the most valuable asset.
We spent decades learning how to write code worth keeping. Now we must learn how to build systems where code is safe to delete.

Transcript

1. WHEN CODE BECOMES DISPOSABLE... LEMi ORHAN ERGiN CO-FOUNDER, CRAFTGATE
2. Would you delete a working module today?
3. Sprints Design by TDD Automated testing Reusable components Pair programming Code review Write documents Develop in iterations Open PRs and approve Do not delete please. Let's maintain it, whatever it takes. and refactor relentlessly to make it clean by using good engineering practices
4. Good engineering was an answer to scarcity by keeping what we have Time, Attention, Expertise, Cognitive Capacity
5. The break came quietly Till the end of 2025, AI-generated code was considered slop. Then Opus 4.5 arrived, and agentic harnesses became viable. COBOL was supposed to make programmers obsolete. It didn't. Neural networks were supposed to work magic. They didn't. No-code made the same promise. It didn't deliver. Back then, skeptical engineers were right. This time, they were wrong.
6. AI-assisted development is from the Earth assuming AI is a second brain We construct AI assisted flows as if the way of developing software of today is the best way of doing it
7. We’ve entered a brand-new universe. At first glance, it looks a lot like the world we know. The same languages, the same IDEs, the same PRs. But the gravity, the atmosphere, even the laws of physics are not the same there.
8. AI is a brain of its own, does not belong to anybody We have to unlearn everything we know today and design systems with the new development dynamics
9. PRINCIPLES MAY SURVIVE BUT PRACTICES MAY NOT DRY · KISS · YAGNI · SOLID · Clean Code · Mob Programming · Pull Requests · Technical Debt · Modularity · Abstraction · Encapsulation · Reusability · Maintainability · Design Patterns · TDD · Unit Testing · Test Coverage · Code Review · Regression Testing · Documentation · ADRs · Agile · Sprints · Daily Stand-ups · Sprint Planning · Software Craftsmanship · Retrospectives · Refactoring · Story Points · Planning Poker · Backlog Refinement · Definition of Done · Estimation · CI/CD · DevOps · Software Architecture · Code Ownership · Observability · Feedback Loops · Continuous Integration · Version Control · Domain-Driven Design · Separation of Concerns · Team Autonomy · Pair Programming · Knowledge Sharing · Code Review · Engineering Productivity · SDLC · Developer Experience · Technical Leadership
10. The death of a program happens when the programmer team possessing its theory is dissolved - Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming 15(5), s. 253–261, DOI 10.1016/0165-6074(85)90032-8
11. Everything we know about software development assumes humans write the code. That assumption has changed.
12. n e t rit I A by w s i ode c l l A Now AI writes the code. That triggers a inevitable economical pressure. It exposes the dynamics that were always there.
13. Cheap to write. Expensive to know. Too expensive to trust. For decades, writing from scratch cost far more than editing what already existed, and our engineering culture was built on that gap. The gap is closing, sometimes reversing. code is neither free nor flawless. It has simply become cheaper to regenerate than to understand.
14. Legacy is expensive to understand, not to own. The real problem is lost trust.
15. We lose trust to code by each modification Code and people's minds hold every decision ever made Refactoring is an attempt to regain it Refactoring can never be lossless
16. The point of trust has shifted from code to ...
17. The point of trust has shifted from code to ... Code review Test coverage Code quality Business outcomes Runtime behavior Testing Metrics
18. When the point of trust shifts from code, maintenance loses its importance and regeneratibility becomes the new trust point What's dying is a specific form of programming: one that equates value with authored code, longevity of code with quality, and maintenance with virtue. — Chad Fowler, The Death and Rebirth of Programming, Dec 2025
19. Let's burn our disk packs! No biological organism can live in its own waste products — Alan Kay Xerox PARC, 1976
20. Phoenix Principle Burning something down and rebuilding it so that its behavior remains the same, without human intervention or organizational memory.
21. g n i g n a i a h v c e k li s in prod ssh file necting con Editing is a mutation and the mutation speeds up every day A system becomes legacy when understanding it requires historical knowledge (initial design decisions) that isn't encoded anywhere except the code itself
22. Code always took the spotlight, leaving everything else overlooked and undervalued. But when code becomes disposable & regenerable, the real heroes finally emerge data.
24. What the How How we components system communicate promises verify those promises How we see what actually happens What must survive when code changes
25. Don't patch or upgrade it Regenerate it if possible* Wasteful? We'll lose optimizations? Institutional knowledge? Not for large systems? Big bang? What will this break? Mutation is the waste, it hides the actual costs If it matters, write it as a constraint or invariant If it lives only in the implementation, it is risk The hard part is decomposition, not replacement Rewriting a whole product in one go is not Phoenix Does this pass the eval?
26. Instead of building re-usable software, we should try to build disposable software. — tef, Write code that is easy to delete tef, Easy to delete, 2016
27. The most durable systems of the AI era will be built from code that is meant to die — Chad Fowler Regenerative Software Dec 2025
28. parts of the body die all the time COMPONENTS DIE but the body goes on THE SYSTEM LIVES
29. Implementation is a cache, a materialized view of what we understand A system is its behavior, interfaces, data and invariants. Code is one way to express them.
30. The truth is the log. The database is a cache of a subset of the log. — Pat Helland, Immutability Changes Everything, Jan 2015 Helland, CIDR 2015
31. e r e h t o g e d l i p d o e e p w s p e r O o v f De ng be lo CHAOS MONKEY The best way to avoid failure is to fail constantly. If we aren't constantly testing our ability to succeed despite failure, then it isn't likely to work when it matters most. — John Ciancutti, Netflix Tech Blog, Dec 2010 Netflix Tech Blog, 2010
32. The Deletion Test needs an oracle. A way to mechanically tell correct from incorrect without referring to history. — Chad Fowler
33. Human brains are not good at validation. … We are never going to beat the machine when it comes to validation — we are literally the weakest link! — Charity Majors AI demands more engineering discipline. Not less, Jun 2026
34. We write tests to verify the implementation, not validate the behavior.
35. A simple check for you to apply: if reimplementing your service in a different language would invalidate your test suite, your tests are specified at the wrong boundary. — Chad Fowler, Evaluations Are the Real Codebase, Dec 2025
36. Three layers of tests, three lifetimes. 1 Ephemeral unit tests · structural assertions · mock-heavy integration tests 2 Durable property tests · contract tests · invariants · end-to-end checks 3 Live monitoring · drift detection · anomaly alerts
37. For a model that can change the eval, the eval is no longer a judge.
38. Repeat after me AI doesn't write bad code. You built the wrong system.
39. A DIFF TELLS YOU WHAT. NEVER WHY.
40. 2 a.m., an eight-month-old commit CG-1234 refactor auth logic 2 approvals Slack thread: in an archived Slack channel Author: left the company 2 months ago What is the reason for this changeset and its design? The reason should have been in the commit message :(
41. The conversation is the commit.
42. Editing code by hand is editing a compiled binary: an escape hatch, not a method. Every manual edit leaves provenance debt: code with no way to ask why it's there.
43. Provenance you can query.
44. What is worth keeping? Intent & requirements Generation context Constraints & invariants Durable evals Specs · goals and expected behavior run records · prompts · models · tools · inputs Specs & policies · what must never break eval suites · executable correctness checks Contracts & boundaries Production learnings API & event schemas · stable interfaces PR analysis · incidents · lessons learned Decisions & rationale Data & state Plans & alternatives Provenance System Knowledge Agent conversations ADRs · decisions · reasons · trade-offs agent plans · chosen and rejected approaches LLM-Wiki · architecture · components · flows what must survive regeneration how everything connects, and why it changed transcripts · discussions behind the code
45. THE CRAFT MOVED. IT DID NOT DISAPPEAR. Programming hasn’t disappeared. But its center of gravity has shifted. — Chad Fowler, The Death and Rebirth of Programming, Dec 2025
46. n=1 is a design test, not a headcount model. FOWLER'S CONSTRAINT If one competent engineer cannot understand, modify and regenerate your system from its specification, it is already too complex.
47. From ownership to stewardship.
48. We called maintenance a virtue. The real virtue is deleting without fear. Programming is not dead. But it has been reborn, and it expects us to change with it. — Chad Fowler, The Death and Rebirth of Programming, Dec 2025
49. Evolution of Code to Modularity
50. Evolution of Code to Modularity lemi orhan ergin co-founder, craftgate speakerdeck.com/lemiorhan