This Fence Has No Farmer

A developer reflects on the concept of Chesterton's Fence in web development, warning against removing unexplained code without understanding its purpose. The post highlights how AI-generated code, often pasted into production without review, can create new 'fences' with no human origin, making it harder to determine why certain code exists.

Every web developer inherits fences. Not literal ones though some days you get why people fantasise about selling up and buying an actual farm instead . I mean the weirdly named function hooked into WordPress's wp head that nobody can explain, the plugin that looks like dead weight until you deactivate it and the checkout breaks, the API call that looks redundant but is actually keeping some cron alive, the CSS override that's the only thing stopping the mega menu from crashing into a client's oddly tall logo. You didn't build any of it. Somebody, at some point, presumably had a reason, even if that reason's long since evaporated. Before ripping anything out, it's worth finding out why it's there. There's a name for this, and it's turned up in more places than you'd expect: Chesterton's Fence, after a bit of reasoning popularised by the 20th-century writer. Find a fence in a field, can't work out why it's there? Don't tear it down out of frustration. Go find out why it was built, then decide. It's a nice little rule, and it shows up in philosophy, in policy debates, in pretty much any conversation about not messing with systems you don't fully understand, which is probably why some developers have latched onto it too. The obvious way this goes wrong is that you rip it out. It looks pointless, nobody documented it, nobody on the client's side remembers it going in, so you delete it in the spirit of tidying up. A week later the client mentions their sidebar widget stopped displaying properly. Turns out that "pointless" snippet was filtering the widget output for a specific post type, and nobody realised it was doing that until they started getting complaints. The other way is the opposite: you leave it alone, out of fear this time rather than confidence. You don't understand it, you suspect it might be important, so you work around it instead of actually dealing with it. Do that enough times, across enough developers, and you end up with a codebase that's mostly archaeological sediment, layer after layer nobody's brave enough to touch. It doesn't get any better this way. It just gets harder to work in. Both come down to the same thing really. You haven't found out why the fence is there. Sometimes that's because there's genuinely no documentation and nobody left to ask, since the original developer's long gone and the client's changed hands twice since. Sometimes it's time pressure, the client wants it live today and nobody really wants to spend an afternoon investigating a twelve-line function that might turn out to do nothing. Sometimes you've just inherited enough WordPress sites to convince yourself you've seen this particular thing before. Increasingly, there's another possibility: nobody actually knows why it was there in the first place. The old version of this problem assumes a person built the fence. Somewhere, at some point, a developer made a decision, and if you dug hard enough, through commit history, an old comment, an email thread, or just the client's memory, you could usually piece together why. Even bad reasoning is still something you can weigh up and argue with. That assumption feels a little less reliable now. A client pastes a snippet an AI assistant handed them straight in. A no-code AI builder spits out a page template full of inline styles nobody's ever going to read closely. Someone asks a chatbot to fix the mobile menu and drops the result straight into production without a second glance. Now you're the one staring at the fence, except this time there might not be a farmer left to ask, because nobody knows why the code does what it does. They accepted something that sounded plausible and got on with their day. There's often no paper trail at all. No commit message, no comment, sometimes not even a particularly good sense of when it was added, because it never went through anything resembling a normal development process. The code can also look more confident than it deserves to. It's well formatted, uses sensible variable names, follows familiar patterns, all of which makes it easy to assume someone thought it through carefully. Except sometimes it's calling a deprecated WordPress function, or relying on a hook that doesn't behave the way the code assumes it does, or solving a problem that didn't really exist https://adamgreenough.net/blog/the-xy-problem/ I should revisit the XY problem blog https://adamgreenough.net/blog/the-xy-problem/ , it's getting worse; AI's eagerness to agree with practically any premise can make the wrong angle sound very convincing. To be fair to the machines, none of this makes all AI-written code inherently worse than the human kind. Developers have been committing baffling, undocumented nonsense since long before any of this existed. But there's a subtle difference when you can't even assume there was a person who understood the thing at the time. Here's the bit I find genuinely interesting: the same tools multiplying the number of unexplained fences are also pretty good at helping you investigate them. If I come across a mystery function these days, I'll quite happily paste it into an AI assistant and ask what it does. Not because I necessarily trust the answer, but because it's a remarkably quick way of getting a rough map of unfamiliar territory. It can point out a hook I hadn't noticed, explain what a WordPress function is actually affecting, or suggest why a particular bit of code might have been written that way. That's useful. It's particularly useful when you're looking at somebody else's code and don't really know where to start. You can ask it what would happen if the function wasn't there, what else in WordPress might depend on it, or what you'd want to test before removing it. Sometimes that gets you to the answer much faster than working through everything manually. The important bit is that it's giving you somewhere to look, rather than giving you permission to delete the fence. AI is pretty good at explaining what code appears to do. It's much shakier at explaining why somebody intended it to exist, especially when the somebody might have been an AI itself. If I ask it why a mysterious function was added in 2019, there's a fairly obvious limit to what it can tell me. It can infer. It can spot patterns. It can give me plausible explanations. It can't magically recover an intention that nobody recorded. So I'm increasingly quite happy to use AI for code archaeology , but more as a particularly fast colleague who has seen a lot of code than as the final authority on whether something should stay. If it tells me the fence is unnecessary, that's interesting. I'm still going to look behind the fence before I knock it down. The core of Chesterton's Fence is still what it always was: understand before you remove. What's different is that the assumption sitting underneath it is getting a bit weaker. Fences are going up faster than they used to, and a growing number of them were suggested by a tool rather than reasoned through by a person. That doesn't necessarily make them bad. It just means there's often less real intent behind them to begin with. And maybe that's where AI ends up being oddly useful. We're creating more unexplained code at the same time as we're creating better tools for explaining code. The same thing that's making the archaeological layer thicker is giving us a pretty good shovel. That doesn't mean we need to panic every time we spot AI's fingerprints in a codebase. It just means the old assumption that somebody, somewhere, knew exactly why this thing existed isn't quite as safe as it used to be. Which ties back nicely to something I wrote a while back, Our Clients Are Using AI Now https://adamgreenough.net/blog/our-clients-are-using-ai-now/ : clients were never going to wait around for developers to bring AI into the workflow, and plenty of them are already in there themselves. This is just what that looks like a few months on, showing up as actual code in actual production sites, WordPress or otherwise. The bit of the job that still matters most was never writing the code in the first place. It's knowing what you're looking at, working out what it does, deciding whether that fence still needs to be there and increasingly, accepting that there may not have been a farmer at all.