Every 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 oddly specific conditional buried in a function nobody remembers writing, the dependency that looks completely unused until you remove it and something three pages away breaks, the API call that looks redundant but is actually keeping some mission-critical process alive, or 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, you don't really know why it's there, but you also know better than to assume that means it doesn't need to be.
That's more or less Chesterton's Fence, named after a bit of reasoning popularised by the 20th-century writer. Find a fence in a field and can't work out why it's there? Don't tear it down just yet. Find out why it was built, then decide whether it still needs to be there. 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 two ways this goes wrong
Knowing you shouldn't blindly tear down the fence is the easy bit. What you actually do when you find one is where things get a little messier.
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 tests are perfectly happy, naturally; nobody had written one for the thing nobody remembered existed.
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. Maybe there's no documentation or nobody left to ask. Maybe the client wants it live today and nobody wants to spend an afternoon investigating a twelve-line function that might turn out to do nothing. Maybe you've just inherited enough WordPress sites to convince yourself you've seen this particular thing before.
But increasingly, there's another possibility: maybe there was never much of a reason to find.
The fence that nobody built
There's an assumption buried in Chesterton's Fence: somebody built the fence. It didn't grow there by itself, so whoever put it there presumably had a reason. Code has traditionally worked much the same way. Even if the reasoning was bad, there was at least some reasoning to uncover.
That assumption feels less reliable now. A CMS user pastes in a snippet an AI assistant handed them. 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. Six months later, you're the one staring at the fence. Nobody really knows why the code looks the way it does; somebody accepted something that sounded plausible and got on with their day.
There's often not much of a paper trail either. No commit message, no comment, and almost certainly no record of whatever conversation with an AI produced it. The code itself can look more considered than it really was too. It's well formatted, uses sensible variable names and 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, relying on a hook that doesn't behave the way the code assumes it does, or confidently solving the wrong problem because that's the problem it was asked to solve.1
To be fair to the machines, developers have been committing baffling, undocumented nonsense since long before any of this existed. AI-written code isn't inherently worse. What's different is that the reasoning you're looking for might never have existed in the first place, even if something has come to depend on the code since.
The fence inspector
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. The slightly dangerous part is that those explanations can be plausible enough to sound like intent, when really you've just asked one AI to come up with a reason for something another AI might have generated without much reasoning in the first place. It can't magically recover an intention that nobody recorded, or that might never have existed at all.
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 fence is still a fence
The core of Chesterton's Fence is still what it always was: understand before you remove. What's changed is how much we can assume about why the thing we're looking at exists in the first place.
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 may be less real intent behind them to uncover.
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.
Which ties back nicely to something I wrote a while back, Our Clients Are Using AI Now: users 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.