AI Doesn’t Know When to Stop Digging
The Law of Holes
AI coding agents don’t understand the Law of Holes:
“If you’re in a hole, quit digging”
There’s an uncomfortable anti-pattern I’m starting to see with AI coding agents, even when using the best available models:
When the design is bad, they don’t fix it. They build on top of it.
AI Optimizes for Forward Progress
Modern LLMs are optimized for forward progress and eager to please. If you’re using them to generate code, it’s natural, then, that when you ask them to do something, what they’ll do is…generate more code.
When you ask an AI agent to fix a bug or improve a design, it usually adds more layers and abstractions. What it rarely asks is the question that actually matters:
“Why does this exist at all?”
The Dangerous Feedback Loop
At Google, it was common to cite an adage along the lines of:
Good developers might write code, but great developers delete it.
Because the real work in software engineering isn’t just cranking out code — it’s removing code that shouldn’t be there in the first place.
AI doesn’t have that instinct. It treats the current system as ground truth. It routes around problems instead of questioning them, or it papers over them by adding new abstractions.
So when an AI coding agent is in a hole, it keeps digging.
This could be a manageable limitation in practice. But the concerning failure mode is what happens when you combine that with how these tools are actually being used.
Because in a lot of teams, the people driving these systems are…junior developers, or not trained developers at all.
In other words, many teams now have junior developers supervising systems that behave like extremely fast junior developers. And that feedback loop is where things start to break down.
And often, no one in that loop has the experience, incentives, or authority to step back and say:
this abstraction is wrong
this layer shouldn’t exist
we should delete this entire mess and start over
Code Production vs. Engineering Judgment
Instead, both the AI and the person supervising it optimize for the same thing: keep going, make it work, don’t break what’s already there.
The result isn’t immediate chaos. Instead, it’s slow decay.
You get systems that “work”, but are unmaintainable and degrade over time. Every change adds a little more structure, a little more indirection, a little more accidental complexity. Nothing is obviously broken, but everything is getting worse.
And because AI accelerates the pace of change, it accelerates that decay too. This can happen shockingly fast on a large team or with a large codebase.
This is why I’m skeptical of a lot of the “AI will 10x engineering productivity” narrative. It might 10x code production. But if the decision-making layer doesn’t improve at the same rate, you’re just increasing the speed at which bad systems get built.
Which makes this, fundamentally, an education and leadership problem.
What Becomes Valuable Now
For years, we’ve optimized for people who can produce code. Now we have tools that can do that on demand.
The scarce skill is shifting to something else entirely: Engineering discipline and judgment.
Knowing when the model is wrong.
Knowing when the abstraction is wrong.
Knowing when to delete instead of extend.
Those are learned skills. They aren’t really taught in universities, and they certainly aren’t taught in AI bootcamps. They come from experience, from working with real, large, and critical systems, from seeing them fail, and from understanding that “forward progress” is not the same as continuous improvement.
And they’re exactly the skills that don’t get exercised in an AI agent workflow that looks like:
prompt, generate, patch, repeat. I’ve seen AI coding agent workflows devolve into:
“This doesn’t work. Fix it.”
Repeated over and over until something finally appears to work. At each step, the AI adds more code on top of whatever already exists, while the likelihood that any human still fully understands the system approaches zero.
The Real Bottleneck
None of this means AI coding tools are useless. They’re extremely effective force multipliers in the hands of experienced engineers.
But acceleration amplifies judgment -- good or bad.
The organizations that benefit most from AI won’t be the ones generating the most code or doing so the fastest. They’ll be the ones disciplined enough to simplify systems, reject unnecessary abstractions, and delete code instead of endlessly extending it.
Because once code generation becomes cheap, the bottleneck stops being implementation speed.
The bottleneck becomes judgment.
Until organizations understand that, we’re not leveraging AI to automate engineering. We’re automating coding entropy.
If your organization is navigating AI-assisted development and struggling with maintainability, engineering discipline, or long-term architecture concerns, that’s exactly the kind of problem I help teams work through. Feel free to reach out!
