Regenerative Software — Chad Fowler (Category #Books)
The book is still being written, and I already want to recommend it. Chad Fowler’s "Regenerative Software" is available through O’Reilly Early Release. In my view, the current chapters explain very well where software development is heading and why. The publisher currently plans the final release for April 2027, but there is already plenty to discuss.
Fowler starts with economics. For decades, working code was expensive to produce, so an entire development culture grew around preserving it. Meanwhile, knowledge of the system accumulated inside that code: odd exceptions, lessons from incidents, peculiarities of particular customers. When all of this exists only inside the implementation, a rewrite becomes archaeological work. You can write a new version. Recovering everything that was encoded in the old version is much harder—and no one did that without an urgent need. Incidentally, this echoes the reasoning in the whitepaper "What Happens When Technical Debt Vanishes?", which I discussed earlier.
In the author’s argument, AI sharply reduces the cost of producing a plausible implementation. “Plausible” is doing a lot of work here. Verifying that the implementation actually keeps the system’s promises does not automatically become cheaper. Value therefore shifts toward understanding behavior, defining component boundaries, and being able to justify that a replacement is safe to ship.
This leads to regenerative software: designing a system so that its parts can be recreated while preserving accumulated knowledge. The implementation may change, but contracts, constraints, evaluations, and decision rationale must survive it. Fowler draws a useful analogy with infrastructure: we have already moved from pets to cattle and learned to recreate servers from YAML files. Now he asks what it would take to make the software itself equally replaceable—apparently with a lot of Markdown files.
A small service does not guarantee any of this. If neighboring components read its tables or rely on an undocumented ordering of events, replacing it will affect them too. The author proposes assessing architecture through a concrete question: can we replace this component without changing the others, and how will we verify that its promises still hold?
The chapter on evaluations is especially revealing. Fowler describes participating in a rewrite of a system for schools: a modern architecture, TDD, and one hundred percent unit-test coverage. Users rejected the new system, and the team had to roll it back. The behavior they needed lived in habits and unspoken working rules that the team had not captured in its requirements. All the tests were green. They simply did not check everything that mattered.
In his model, behavioral evaluations must outlive any particular implementation: preserving invariants, contracts, latency requirements, and cases drawn from real incidents. Those evaluations themselves also need continual reassessment. Automating code replacement against the wrong success criterion can reproduce the same mistake with impressive efficiency.
Another important layer is provenance, or the history behind decisions. Why is the retry count capped here? Why is this validation duplicated? Which alternatives have already been tried and rejected? The next engineer or agent needs access to those reasons and the evidence supporting them. Otherwise, the next “simplification” can easily remove a defense against an old failure.
To me, this is where the book explains the shift particularly well: cheaper code increases the value of engineering judgment. You need to understand what the system must preserve, how to check it, and which evidence deserves trust. Fowler also acknowledges the cost of the approach: good evaluations are expensive to build, and making every part of a stable internal tool replaceable may be pointless. That caveat belongs alongside the idea of regeneration.
I recommend it to architects, tech leads, and developers who already work with agents and are trying to understand how engineering practice should evolve alongside the tools. I do not think that conversation needs to wait for the final chapter.
#Books #AI4SDLC #Architecture #Engineering #Software