The one Tidy First? habit that makes AI changes reviewable

Kent Beck, in Tidy First? (O’Reilly, 2023), a short book with a question in the title, offers an idea worth taking away. Every time we change code, we change either its structure or its behavior. Beck says these two kinds of changes belong in separate commits or separate pull requests. He designs around that line: “Software design is preparation for change; change of behavior.”

Beck’s argument for splitting is economic: behavior change makes you money now; structure change buys options on the next change. Most software cost is the cost of changing it, and coupling makes that cost go up. A structure-only change is small and easy to reverse. He suggests structure-only changes (“tidyings”) merit lighter review, since review is a fixed cost that deters tidying at all.

I think this idea of a split is the most useful idea in this book for people who are under change control. I’ve spent 10 years working with large financial institutions and Fortune 500 companies, now as a principal cloud architect. In regulated shops, change boards and approvers want to know what you’re doing and why. A big-bang refactor rarely makes it through the approval process. A mixed diff can’t be confidently signed off. A diff that provably makes no behavior change is the easiest to approve. Getting in the habit of shipping such small changes is how modernization continues to happen between big programs.

AI makes this split even more important. DORA’s research links more AI adoption to a 7.2% drop in delivery stability, likely because of larger batch sizes. GitClear found that for the first time in the latest year measured, copy/pasted code exceeded moved code, suggesting skipped tidying. I’d argue this rule applies to agents too: ask for two diffs.. structure first, behavior second. Verifying the first changes nothing is much faster than untangling mixed change. If an agent can tidy for nearly free, is “tidy first?” even worth asking anymore?