Chesterton's fence
Deleting has become nearly free. Understanding what you are deleting has not, and that gap is widening.
There is a fence across a road. Nobody is around who remembers building it, and standing there looking at it, you cannot think of a single reason it should exist.
G.K. Chesterton put the case in The Thing in 1929. The modern reformer, he wrote, goes up to the fence and says "I don't see the use of this; let us clear it away." And the more intelligent reformer answers: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
Most people remember this as an argument for caution, which is a shame, because it is something much more precise than that. It is a claim about where the burden of proof sits. Chesterton is not saying the fence is probably useful. He is saying that your inability to see its purpose is a fact about you before it is a fact about the fence. It is evidence of something, but far weaker evidence than people act on, because the reasons fences exist are exactly the kind that do not announce themselves to a passerby.
The third option is the whole point
Notice what the answer is not. It is not "leave the fence alone," which would make you a cargo cult, preserving everything anyone ever built because you are afraid of it. It is also not "clear it away," which is the confident version of the same ignorance.
The answer is go find out. There are three moves available and almost everyone argues about two of them. Keep, remove, or understand, and then decide. Chesterton's reformer is allowed to destroy the fence. He just has to earn it first, and what earns it is being able to state the reason the fence exists and why that reason no longer holds.
Which sets up the uncomfortable corollary. If you go and find out, and the answer is genuinely unrecoverable, that is not a green light. It is a bill arriving. Somebody built a thing for a reason and never wrote the reason down, and you are now paying for it in the only currency available: you either keep something you do not understand, or you remove something and find out the hard way.
The economics just changed
Here is why this old parable is suddenly load bearing rather than merely wise.
For most of software's history, removing a fence was expensive. You had to find the code, understand the blast radius, make the change carefully, test it, ship it. That cost was itself a speed bump, and the speed bump did some of the thinking for you. It was often easier to leave a mysterious thing alone than to remove it, so mysterious things survived by default.
That is over. Removing a fence is now close to free. An agent will delete the retry wrapper, collapse the special case, simplify the odd conditional and hand you a clean green diff in seconds, and the diff will look like an unambiguous improvement, because on every dimension visible in the repository it is one. The code is shorter, the tests pass, the complexity went down.
But understanding the fence has not gotten cheaper at all. It still costs the same forty-five minutes of asking around, or the same trawl through four years of pull requests, or it is simply impossible because the person who knew has left. Deletion got radically cheaper; archaeology barely moved. So the ratio between "how easy is it to remove this" and "how easy is it to learn why it is here" has quietly inverted, and everything Chesterton warned about now happens at machine speed and at a scale where nobody is watching any individual fence go down.
Green tests are not an explanation
The obvious objection is that we have a safety net now. If the tests pass, the fence was not load bearing.
That confuses two different things. A test encodes a behavior somebody thought to write down. The reason a fence exists frequently lives nowhere near the code: it is a clause in a contract with your largest customer, a compliance requirement in one market, a lesson from an incident three years ago that produced a retry policy and no comment explaining it. None of that is expressible in a test suite unless somebody already knew it and chose to encode it, and if they had known and cared enough to encode it, the fence would not be mysterious in the first place.
Passing tests tell you the code still does what the code said it did. They cannot tell you that you have not just removed the only thing standing between you and a contractual obligation nobody in the room has heard of.
The sign on the fence
The fix is not to slow down deletion. Slowing down is the cargo cult again, and the whole value of cheap removal is real; most fences genuinely are obsolete and clearing them is how a system stays alive.
The fix is to make the finding out as cheap as the removing. A decision, recorded at the moment it is made, with the reason attached, is a sign on the fence. It turns Chesterton's expensive archaeology into a two second lookup, and in doing so it converts the whole dilemma into something ordinary: you read why the fence is there, you see that the customer who needed it churned in 2024, and you take it down with confidence. The record is not what stops you from deleting. It is what lets you delete safely and fast.
This is the work Brief does, and I will put it plainly. Brief is a product navigator: it holds the decisions and the reasons behind them, and puts them in front of the person or the agent standing at the fence with a shovel. For enterprises this is the sharper problem, because they are the ones who have accreted the most fences and lost the most of the people who built them; the visible symptom is not usually a broken system, it is paralysis, an organization that cannot safely remove anything and therefore carries every constraint it has ever created, forever.
None of this says every fence deserves to stand. Most do not. Chesterton's rule is not conservative; it is procedural, and it is satisfied the moment you can say why the thing exists. The only position it forbids is the one that has become the cheapest and most common: removing something because you personally cannot see the point of it.
So the next time a diff deletes something odd and the tests go green, the question is not whether it still works. Ask the older one. Do you know why it was there?
Frequently asked questions
What is Chesterton's fence? It is a principle from G.K. Chesterton's 1929 book The Thing: if you come across a fence across a road and cannot see why it is there, you should not remove it until you can explain why it was built. The point is about burden of proof, not caution. Your inability to see a purpose is a fact about your knowledge before it is a fact about the fence, so it is far weaker evidence than it feels, and certainly not proof that no purpose exists.
Does Chesterton's fence mean you should never remove old code or constraints? No, and that is the most common misreading. The principle explicitly allows removal; it just requires you to understand the original reason first and be able to say why it no longer applies. Keeping everything you do not understand is its own failure mode, a cargo cult. The rule creates a third option between keep and remove: go find out, then decide.
If the tests pass after deleting something, was it safe to delete? Not necessarily. Tests encode behaviors somebody thought to write down, while the reason a constraint exists often lives outside the code entirely, in a customer contract, a regulation, or a lesson from an old incident. Green tests confirm the code still does what the code described; they cannot confirm you have not removed something load bearing for a reason that was never encoded.
Why is Chesterton's fence more relevant with AI coding agents? Because the two halves of the problem changed at different rates. Removing a constraint has become nearly free and instant, while learning why it exists still costs the same conversation or archive dig, or is impossible if the person who knew has left. That widening gap means the cheapest available action is now exactly the one the principle warns against, executed faster and across more of the system than before.
← Back to Blog