Regenerative Software

Chapter 6. Provenance as the New Version Control

A Note for Early Release Readers

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

This will be the 6th chapter of the final book.

If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at [e-mail].

Most engineers have removed something that looked unnecessary and later discovered that it was there for a reason.

Picture a retry limit, hard-capped at two, sitting in a payment service with no comment explaining why. To a human or an autonomous agent tasked with simplifying the platform, raising the limit seems like an obvious low-risk improvement. The code still compiles, the evaluations still pass, the diff looks clean. But a few weeks later, a network blip triggers a wave of duplicate wire transfers — the exact failure the cap was put there to stop.

The cap was never just code. It was a lesson, and removing it didn’t add a new bug so much as undo the fix for an old one.

That is the vulnerability of modern software systems: an implementation records the decisions a team made, but not the reasons behind them. A mature system encodes hundreds of hard-won lessons as constraints and workarounds nobody wrote down, and a naive rewrite reproduces the same outputs and passes the same tests while quietly discarding ...