That Ugly Code Is Load-Bearing
That ugly code you're about to delete? It might be load-bearing. AI agents love to tear down fences they don't understand — a "simplify this file" prompt will happily strip the retry loop that guards a flaky vendor API, or the timezone special-case that took someone three production incidents to get right. Accumulated complexity sometimes has a reason, and sometimes doesn't. Your job is to find out which — before the diff lands.
The rule: Chesterton's Fence
In 1929, G.K. Chesterton described a reformer who finds a fence across a road and wants it gone. His answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think." Only when you can explain why the fence was put up have you earned the right to remove it.
The principle maps one-to-one onto code review of AI-generated deletions. The agent didn't build the fence, has no memory of the incident that motivated it, and optimizes for "cleaner" — the exact profile of Chesterton's careless reformer. The fix isn't to ban deletions; it's to demand the archaeology first.
The 3 questions before any deletion
Before removing anything weird, answer these — and make your agent answer them too:
| Question | Command that answers it |
|---|---|
| Why was it written? | git blame -w -C <file>, then git show <commit> for the message and linked issue |
| How did it evolve? | git log -L <start>,<end>:<file> (or -L :<funcname>:<file>) — every commit that touched those lines |
| What depends on it? | git grep <symbol> across tracked files, plus your editor's find-references |
If any answer is "no idea," you're not ready to simplify. Read more context first, then cut with confidence.
Reading the blame like a detective
-wignores whitespace so a reformat commit doesn't hide the real author.-Cfollows moved and copied lines across files — pass it up to three times to chase code through refactors. Without it, blame stops at the last "move files around" commit.--ignore-revs-fileskips known noise commits (mass reformats, lint sweeps) listed in a file — many repos keep a.git-blame-ignore-revsfor exactly this, wired in withblame.ignoreRevsFile.- The commit message matters more than the commit diff. A one-line diff with "fix: handle DST transition for AU/Lord Howe" tells you the fence is load-bearing.
Power-user: make the agent do the archaeology
- Bake it into your agent instructions (CLAUDE.md, AGENTS.md, or your review prompt): "Before deleting or simplifying existing logic, run
git blameon the affected lines and quote the original commit message in your explanation." - Demand a justification per deletion. Ask the agent to output a table: lines removed → original commit → why it's safe now. If it can't fill the third column, reject the hunk.
- Use
git log -L :<funcname>:<file>as the agent's first tool call — the function-scoped history is usually 3–10 commits and fits in context easily. - Turn hard-won fences into tests. If a weird branch guards an edge case, write the failing test that proves it, then delete. Now the fence is documented and enforceable, and the next agent can't quietly remove it.
Resources
- git blame — official documentation (
-w,-C,--ignore-revs-file) - git log — the
-Lline-range history option - git grep — search tracked files
- G.K. Chesterton, "The Drift from Domesticity" (The Thing, 1929) — the original fence passage
- Chesterton's Fence: A Lesson in Thinking — Farnam Street
Building an AI feature? Yeda AI designs, audits, and ships production LLM systems.