← Back to all posts

Hacker Laws for Agentic Software Engineering: Chesterton's Fence

Law 10 of 12. Chesterton's Fence says reforms should not be made until the reasoning behind the existing state of affairs is understood. The ASE key insight: the harness must make the agent find out why the code is there before letting it change — intent is a verification problem.

hacker-lawsagentic-software-engineeringserieschestertons-fencelegacyintentrefactoring

Law 10 of 12 in the Hacker Laws for Agentic Software Engineering series — read the index. Previous: Parkinson's Law · Next: The Bitter Lesson.

The Law

Reforms should not be made until the reasoning behind the existing state of affairs is understood. (hacker-laws)

The Key Insight for Agentic Software Engineering

Chesterton's Fence is the law every agent violates on its first pass: it comes across a fence — a function that looks redundant, a workaround that looks wrong, a test that looks pointless — and removes it, because the agent has no memory of why the fence was built and no patience to find out. The unrequested feature that cost Fowler's team three days of investigation is the mild form (Verification Is the Bottleneck); the removed workaround that was load-bearing is the severe form. "Each line of a program was originally written by someone for some reason" — and in an agentic system, the someone is often an earlier run of the same agent, which makes the fence rule both more important and harder: the reasoning may exist only in a session log.

The law is why legacy modernization is the clearest near-term value pool for agents, and why it is also the sharpest test of the harness: an agent told to "clean up this legacy code" is a fence-removal machine. The fix is not a better prompt ("understand before you change" is exactly the kind of instruction an agent will be told to ignore or will comply with shallowly); it is a harness rule — the verifier must check intent, not just correctness. Fowler's DSL idea is the constructive form: restrict the agent's change vocabulary until removing a fence requires explaining it first (Verification Is the Bottleneck).

The ASE reading of Chesterton's Fence: the harness must make the agent find out why the code is there before letting it change — intent is a verification problem. The fence rule cannot be a line in the system prompt; it has to be a gate in the pipeline: the agent must produce the fence's purpose as an artifact, and the verifier must check that artifact against the change. The mayor's answer to the man applies verbatim to the agent: "If you don't know its purpose, I certainly won't let you remove it. Go and find out the use of it, and then I may let you destroy it."

References