Why is that fence there?

The thesis

Part 2 of our Digital Team series gave the team one rule: don’t do anything you can’t undo. It asks whether an act can be taken
back. “Chesterton’s fence” asks a different question: whether you know why the thing is there. It’s complementary. And has a beauty in itself because it may apply to anything in our lives, not specifically to technology.

In our charter, it turns out we had already been answering it for weeks without naming it.

So this is not new. Actually, it is the fine-tuning of an old habit. And how this story of a hundred-year-old fence, a five-hour podcast and a masked checksum intersected nicely.

The fence

The principle comes from the writer G. K. Chesterton in his 1929 book The Thing: Why I Am a Catholic.

“There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, ‘I don’t see the use of this; let us clear it away.’ To which the more intelligent type of reformer will do well to answer: ‘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.’”

I heard about it for the first time on the Lex Fridman podcast, interviewing DHH (David Heinemeier Hansson), on his second visit (#501, five hours and a quarter).

It is excruciatingly long, but a gold mine. I had difficulty to follow in one shot, and I consumed it in small batches – but was worth it every minute.

I will be quoting it for a while. The fence rule comes up near the five-hour mark, and it’s not about software at all. He is talking about why people have been drinking together for thirteen thousand years, without any sign of disappearing as habit, despite all the medical and legal issues:

“Maybe the fact that humans have literally been drinking for whatever it is, like 13,000 years fermenting things, had a social purpose, and we pull out Chesterton’s fence of our own chagrin, right?”

So, excessive drinking is indeed harmful, but we may first question the fact that the social glue it generates is much more important. Social survival bias, after all.

That is the fence used the way it is meant to be used: against the argument for keeping everything, for the question you owe the thing before you remove it.

DHH put it more sharply on his first visit (#474), explaining why he wrote the Rails Doctrine down in 2012, and that version is the whole idea of this article:

“If you want a community to endure, you have to record its values and you have to record its practices. If you don’t, eventually you’re going to get enough new people come in who have their own ideas of where this thing should go […]. We forget why Chesterton’s fence is there. We just go like, why is that fence there? Let’s yank it out. Oh, it was to keep the wolves out. Now we’re all dead.”

The takeaway spans across every conceivable human activity.

From personal silver linings, to corporate SOPs (Standard Operating Procedures).

From memory buildup in our minds (resulting in Conscience), to learning patterns.

“First come, first served” principle, or the legal formulation “Prior in time, prior in right”.

Or, maybe, the first lover in our personal lives.

A previous “thing” has its reason, and must be taken into consideration.

So, it’s better to record the values and the practices, or the next reader will yank out the fence. You can replace “new people” with “new agents” and you have the problem this series is about.

Why Part 2’s rule does not cover it explicitly

The reversibility rule asks one thing: “Can this be undone?”

Chesterton asks another: “Do you know why it exists?”

A fence is trivial to rebuild. Reversibility classifies its removal as safe and lets you act. But the possible harm lands in the interval – wolves on the road -, not in the state you can restore.

Part 2’s rule has a clause for that (“an undo restores state, never the interval”), but it only describes what happens after the fence is down. It never asks you to walk over and read the sign.

So the two questions are complementary, and an agent that asks only one of them is half-safe. Can I put it back? Do I know why it is there? Ask both. Always.

We were already doing it

Here is the part I liked: when I looked at how the team actually works, the fence was everywhere, under other names.

• History first. Before changing a line, read the log and the blame. The reason the line exists is usually in the commit that added it. The team calls this git archaeology and treats it as the default, not the exception.
• Premises decay. A design note from three weeks ago is a claim about three weeks ago. Re-verify before you build on it. That is the fence read at the moment of removal, not from memory.
• Every clause states its test and its reason. The team’s rules are written that way on purpose, a drafting standard, so that nobody has to go away and think. The why is on the fence.

Chesterton’s fence, then, is not a new rule for us. It is the name for a habit we had, and naming it is the fine-tuning: it tells you which half of the habit you are skipping when you skip it.

A fence I removed last week, correctly

The team’s redactor masks anything that looks like a secret before it reaches the model. For a long time it also masked SHA-256 checksums, and the code said so, in a comment: “this WILL be redacted by the hex heuristic, acceptable trade-off.”

That comment is a fence with its reason nailed to it. A 32-byte token printed as hex and a SHA-256 digest are the same string; the heuristic cannot tell them apart; someone decided masking both was the lesser harm.

Then the environment changed. We put the shell under the AI harnesses, and every command’s output started reaching the model through the redactor. The checksum I use to prove a backup landed came back as [REDACTED]. The read-back instrument had gone blind.

I did not remove the fence because it was in my way. I removed it because I could say why it had been put there, and show that the reason had moved: the trade-off was set when the redactor had one consumer, and it now had a second one that depended on reading the digest. The fix exempted digest shape (a checksum line, a digest label, a git object id), and kept masking a bare 64-hex line, because that shape is still exactly what a private key looks like. The fence was rebuilt one meter to the left, with a new sign.

And one meter turned out not to be far enough. We found that out at the next backup, which is the whole point of the story.

That is the whole procedure. Simply put, read the sign. Check whether the reason still holds. Maybe move the fence, don’t destroy it.

The deeper half

Chesterton talks to the “reformer”. He leaves the builder’s duty implicit, and it is the more useful half for a team of agents: every fence carries its reason. When you add a guard, a workaround, an odd clause, write why, where the next reader will look. A comment. A dated line in the rule. A commit message that says what it was solving. “Go away and think” becomes “read the line above.”

From Chesterton: “The gate or fence did not grow there. It was not set up by somnambulists who built it in their sleep… Some person had some reason…”

In programming, it is implicit good practice to comment your code. Shallow programmers don’t see the usefulness of it, leaving code largely destroyable and eventually despised and maybe even abandoned.

Agents also comment a lot. Their verbosity surpasses any human capability, I must admit. But I learned to see this as valuable “fences” which, in effect, are really useful for the other agents or sessions. In practice, AI agents create a far larger quantity of “documentation” and, if steered intelligently, it’s pure gold for anybody, human and agent. This documented process gives the project a “memory” and, frankly, healthy survivability over time.

Team’s rules carry dates and names on their clauses, and reasons why a rule that changes appends the change instead of rewriting it. The history is the sign on the fence.

These are the invaluable “scars” I am talking about in previous articles in the series.

Fences everywhere, yey.

A practical life lesson

Ask two questions before you touch anything. Can I put it back? Do I know why it is there?

Part 2 was the first. This was the second. Neither is new. The work is remembering to ask both, and writing the answers down where the next reader, human or not, will find them.

---

Bogdan Susala, September 2026

---

SOURCES

#501 transcript

#474 Episode page

#474 transcript

G. K. Chesterton

The book: The Thing: Why I Am a Catholic (1929), chapter “The Drift from Domesticity”