Chesterton's Thicket, an LLM code anti pattern
Agents seem to have a bad pattern of assuming any code that they encounter is there for a reason. You've probably seen this when they add a legacy fallback to support a feature that you just added yesterday that you're actually trying to replace.
Chesterton's Fence is a name for the idea that we should not get rid of something if we don't know why it is there in the first place. Coding agents are clearly following this principle, but their amnesiac existence means that they rarely have any idea why anything is there in the first place.
So new constraints or behaviours will get added for some reason as you build. Rarely will they be critical. Every subsequent LLM driven change will assume that they are critical, and will preserve them. You end up very quickly with code that tries to navigate a ton of restrictions which don't actually matter.
It creates a sort of thicket of Chesterton's Fences, and unpicking whether any of them need to be there is an obscene amount of work.
It seems like this also happens in big orgs. Any time the people operating on a system change day to day and following up on the reasons for things is high effort. But humans could never create this problem at the speed we can now, so it never showed up in quite the same way.