AI Didn't Create These Problems. It Just Stopped Routing Around Them. | baweaver

baweaver

baweaver

Software Engineering

Simplicity is hard work. But there's a huge payoff. The person who has a genuinely simpler system is going to be able to affect the greatest change with the least work.<br>— Rich Hickey

ai<br>May 27, 2026

AI Didn't Create These Problems. It Just Stopped Routing Around Them.

I’ve spent the better part of the last few years using AI heavily at work, and there’s one very interesting thing that I have observed in all of this time:

Every single guardrail I’ve had to put in front of AI to keep it on track, make it more productive, more predictable, and less risky? They’re all things we should have been doing all along.

Testing, documentation, clear ownership, up to date documentation, deterministic validations? None of them are new, none of them are particularly controversial, and yet the moment that you let AI take the wheel you find out exactly how much of it was missing.

The Routing Problem

If there’s one thing AI is exceptionally good at it is finding the shortest path to achieve what it wants, often times right through the flower bed and over the vegetables.

Sure, to you it’s obvious, but to AI? Not at all.

As we become more experienced as developers a lot of problems become background noise we route around or ignore entirely. It happens so naturally that we don’t even notice when we do it, as much as we observe that there’s something which is a distraction, and an actual problem to be solved behind it.

Remember that callback hook from 3-5 years ago that validates a child model’s ordering? The one that starts slowing down if you happen to update more than say 30 records at a time? It was never documented, never really commented, no linter was going to catch it, and quite honestly you don’t even remember who wrote it. Maybe it was you? I’ve done that one a few times.

Point being that thing blows up in production once and you’re going to remember from that point on not to do that again. If you’re lucky you learned that lesson from someone else instead of running into it yourself, but either way it’s in your head and now you route around it every time you see it in the future.

That works great for humans, but AI doesn’t have that type of memory. It will walk straight into that hook or even write a new one, trigger a deadlock, and now you’re getting paged at 3AM trying to figure out what in the world went on.

If it were a human we would not blame them, we would (and should) ask how our existing systems failed them to allow an outage like that to make it to production. We don’t call them stupid or mock them or any such thing. We learn, we adapt, and we move on. Hopefully we also make sure there’s a “never again” guardrail in place as well, because “don’t do that again” is a hope and a prayer with a shelf life as long as that person and the people around stay at the company.

That’s the pattern. The stale documentation that only three people know how to update, and the other three left two years ago. The test suite full of stubs that tests a non-existent system that was refactored away three years ago. The implicit knowledge about which 3P services can and cannot handle above a certain amount of load and require aggressive caching. All of these were fine when experienced humans were the only ones navigating the codebase, but the moment that something without that institutional memory starts committing bets are off and every gap is now a live wire.

AI as Chaos Engineering

There’s a certain irony in all of this that I can’t help but find amusing. Years ago Netflix invented this novel concept called the Chaos Monkey, a tool that would randomly nuke a server from orbit. It wouldn’t tell you what, where, when, or even why as much as something would die and you had better hope that you designed things well enough to self-heal or it’s going to be a long day.

Why bring this up? Because AI is the best chaos engineer we’ve ever had. It finds gaps and holes that you would have never considers. It squeezes through cracks in the side of a building where the paint chipped at a certain angle at a particular hour of night when the moon hits it in a way that leaves everyone involved doubting their sanity and asking how in the world this happend.

AI is stress-testing our assumptions about how code should be written, what documentation needs to exist, and whether our systems are actually as robust as we think that are (they’re not.)

The important part is how we choose to respond to that. Do we behave like systems thinkers who consider how systems failed, or do we point fingers and blame? When production blows up a good engineer will ask what failed in this system that allowed this particular category of error to happen. We do not lecture about how a developer must not have been paying attention or how bad they are at their jobs. The same frame applies to AI: It’s going to make mistakes. We know...