Beck: Two Commits, Never One
Kent Beck and Martin Fowler on why the cheapest discipline in software is the one that stopped happening.
Open a pull request from an agent and you will usually find two things tangled together. Somewhere in the diff is a change to what the system does. Everywhere else is a change to how the code is arranged: renamed variables, extracted helpers, a reordered import block, a nested condition flattened because the model preferred it that way. The reviewer now has to work out which lines are which, and there is no reliable way to do it except by reading all of them.
That is a solved problem. It was solved before the agents arrived, by two people who have been arguing for thirty years that the arrangement of code and the behaviour of code are different kinds of thing and should never travel together. Kent Beck states the rule; Martin Fowler wrote the catalogue that makes it operable. The last article left the uses relation degrading one reasonable edge at a time, and asked what keeps a graph clean while cleaning is still cheap. This is the answer, and it is startlingly mundane.
1. The word doing all the work
Fowler’s Refactoring appeared in 1999 and in a second edition in 2018, and its definition contains a phrase that carries the entire discipline: a refactoring is a change to the internal structure of software that does not alter its observable behaviour.
Not “should not”. Does not. If you cannot demonstrate that behaviour was preserved, you did not refactor. You edited, and you now have two uncertainties where you had one: whether the new arrangement is better, and whether the system still does what it did on Friday. The catalogue of named transformations exists because each one is small enough to be verified, and the discipline is the sequence of small verified steps rather than the ambition behind them.
Which makes the guarantee the whole asset. Everything else in the practice is arguably scaffolding around a claim about sameness.
2. Beck’s rule: separate the two, always
Tidy First? runs to under a hundred pages, and its central instruction takes one line: a structural change and a behavioural change never belong in the same commit.
That is a claim about the cost of review rather than about neatness. A structural change can be checked largely by inspection: names moved, shape improved, nothing new asserted. A behavioural change has to be reasoned about, because somebody is claiming the system will now do something it did not do before. Put them in one diff and the reviewer cannot do either job properly, because every structural line has to be examined in case it is smuggling behaviour. Review cost becomes the product of the two rather than the sum.
There is a second reason, and it is usually the one that bites at three in the morning. Mixed commits cannot be reverted in halves. If the behaviour turns out to be wrong you either keep the bad behaviour or throw away good structure, and in practice the team keeps everything and adds a patch on top.
Beck calls the smallest of these structural moves tidyings: extract a variable, delete dead code, add a guard clause, make two things that look different actually look the same. A tidying is a refactoring nobody could reasonably argue about. The question mark in his title is real, and he gives four honest answers to when: first, after, later, never. Tidy first when it makes the next change easier. Tidy after, when finishing taught you something you did not know at the start. Later or never when you are not coming back, and that is a legitimate answer rather than a moral failure.
3. The chain that makes it a business argument
The part of Beck’s book most worth carrying into a leadership meeting is a chain he takes from Larry Constantine, and it is four terms long.
The cost of software is approximately the cost of changing it. Changing it is dominated by the big changes. And the big changes are priced by the coupling. So the cost of your software is your coupling, and almost nothing else you measure touches it.
Nothing in that chain mentions volume, headcount, story points or lines shipped, which is why the numbers on your delivery dashboard have such a weak relationship to what your systems actually cost you. And notice what it implies about generated code. Volume is not the liability. Coupling is the liability, and generation raises coupling by default because each addition attaches wherever attachment was easiest.
Beck is careful not to turn this into a crusade. Decoupling is not free, it has diminishing returns, and reducing coupling in one place tends to make it reappear in another. The aim was never zero.
4. The option went deep in the money, and nobody exercised it
Here is where Beck’s economics become uncomfortable to read.
He treats a tidying as an investment: you pay now, you collect later, and whether it is worth it depends on how soon you will be back and how uncertain the future is. Design creates options, and options are worth more when uncertainty is higher. Structural changes are also far more reversible than behavioural ones, which makes them cheap bets in the technical sense as well as the ordinary one.
Now put free generation into that model. The cost of performing a tidying has collapsed, because an agent will do it in seconds. The value of having tidied has risen, because there is far more code to carry and far more uncertainty about what next quarter’s tooling will make possible. Both sides of the trade moved in the same direction at once, which on Beck’s own reasoning makes structural investment more obviously correct than it has ever been.
And GitClear’s measurements show refactoring falling by around 70 per cent against 2022 levels while duplication rises. The single practice that got cheaper is the practice that stopped. Call that a tooling failure if you like. It looks to me more like an organisation optimising for the thing it can see.
5. What actually broke
The discipline did not lapse through laziness, and the diagnosis matters here, because the wrong one leads to the wrong intervention.
Refactoring requires the behaviour-preservation guarantee, and the guarantee has always come from tests you trust. When the same agent writes the code and the tests, the tests do not check the code; they restate it. Both come from one understanding of what the system should do, so a shared misunderstanding passes green. The suite still runs. It has quietly stopped being evidence.
Fowler’s answer to the analogous problem in security is the one to borrow: move from probabilistic prompting to deterministic enforcement. Do not ask the model nicely to preserve behaviour. Constrain the pipeline so that a commit touching both structure and behaviour cannot merge, and so that the characterisation tests protecting a module were written by somebody who was not generating changes to it. Constraints hold. Instructions in a prompt are mostly a hope with good grammar.
At the Thoughtworks retreat in Utah last February, fifty or so practitioners spent a day and a half on the future of the profession. One of the eight themes they landed on was the question of where the rigour goes now. Good question. This pair give the most concrete available answer to it. It goes into the shape of the commit, and into whatever the pipeline refuses to let through.
The next article goes to the practitioners writing about this in public.
Placement: Building, the third of four phases; Learning, Deciding, Building, Transforming. Small batches belong to the Information lever, which asks what a build must carry and how clearly it can be read. Building enters the cycle at Structure and runs it fast, which is what makes a commit a hypothesis rather than a delivery. The Build Is the Test opens this stretch of the argument.
(An Organisational Prompt is something you can do now....)
Organisational Prompt
Split one pull request in half.
Take the next substantial change your team ships, and require it to arrive as two pull requests: one that changes structure and changes nothing else, and one that changes behaviour and touches structure not at all. Do not announce a policy. Do it once, with one team, and watch what happens.
Three things usually happen. Somebody will discover that the split is harder than expected, which tells you the module is more coupled than anyone believed. The structural half will review in a fraction of the time, and that difference is what mixed diffs have been costing you all year. And somebody will probably ask whether the tests actually prove that behaviour was preserved.
If the answer to the third is that the tests were generated alongside the code, you do not have a behaviour-preservation guarantee. You have a suite that agrees with itself. Fix that before you scale anything.
Further Reading
Kent Beck asks the question in his title, Tidy First? A Personal Exercise in Empirical Software Design (O’Reilly, 2023). It runs to under a hundred pages, and the last third, on coupling, cohesion and optionality, is what to read if you decide where the money goes. He develops the rest of the series in public at tidyfirst.substack.com.
Martin Fowler: the refactoring catalogue is free online and remains the reference. The book around it is worth owning; the catalogue alone is enough to change how a team talks.
Martin Fowler and Unmesh Joshi: LLMs and Building Abstractions (2025), a published email exchange rather than an essay, which is why it is more honest than most of what has been written on the subject. Fowler’s fragments from the February 2026 retreat are the shortest route to what serious practitioners are currently unsure about.
I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.