One of the things I like about working with AI is that sometimes the mistake is more useful than the successful result.
That doesn't mean I particularly enjoy the mistake when it happens.
Usually my first reaction is something closer to:
Why in the world did you do that?
But every once in a while, the answer to that question matters more than the bug we were trying to fix.
That happened recently while we were working across PageSnip and several related products.
An AI worker fixed something.
The fix was wrong.
And the reason it was wrong bothered me.
Because we'd already solved the problem before.
We had an established pattern
PageSnip had become the proving ground for quite a few things.
That wasn't really planned at the beginning.
It just happened naturally.
We'd build something.
We'd discover where the rough edges were.
We'd fix them.
We'd live with the result long enough to find the next problem.
Eventually some of those patterns became good enough that we wanted them in other products.
So we started carrying them across.
ProHelp Viewer needed to feel like part of the same family.
The temporary authoring application needed the same foundation.
ProSurface Core needed to expose the same kind of behavior to Clarion developers who wanted to build applications with that look and feel.
We weren't guessing anymore.
In many cases, PageSnip had already shown us what worked.
So why were we solving the same problem again?
That's what stopped me.
One of the other projects needed a fix.
The AI found the problem and implemented a solution.
The solution wasn't absurd.
It wasn't broken code.
It wasn't one of those AI moments where you look at the result and wonder what planet the model thought it was programming on.
It was a reasonable fix.
It was also different from the way we had already solved the same kind of problem in PageSnip.
That was the part that bothered me.
We had already established the pattern.
We had already transferred patterns between these products.
We had already spent time trying to make sure they behaved consistently.
Why was an AI worker looking at this problem and deciding to invent another solution?
My first thought was that the worker had failed.
That's true.
But it wasn't the interesting part.
I started asking why the wrong fix looked right
The more I looked at it, the more I realized that from the worker's point of view, the local fix made sense.
It entered the project through the bug.
It searched for the relevant code.
It found something nearby that could solve the problem.
It changed it.
That is exactly what we'd expect a programmer to do if they didn't know the history of the system.
I knew the history.
I knew we'd already solved this elsewhere.
I knew which product had the mature implementation.
I knew which direction we wanted the architecture to move.
The worker knew what was in front of it.
That's when the question changed.
Instead of:
Why didn't the AI remember the rule?
I started asking:
Why does the code allow somebody who doesn't know the history to arrive at the wrong answer so easily?
That was a much more interesting question.
We'd built a system that required memory
This is one of those things that's easy not to notice while you're building software.
You make a decision.
Everybody involved understands the decision.
You make another decision based on the first one.
A few months later, the code contains assumptions that make perfect sense to the people who were there.
Then somebody new arrives.
Or an AI worker arrives.
They don't have the history.
They have the repository.
Those aren't the same thing.
We had been relying more than I realized on historical knowledge.
This is the implementation we trust.
That one is older.
This behavior belongs over here.
That file looks important, but it isn't the authority anymore.
This product was where the pattern was proven.
We're eventually going to move this responsibility into the shared layer.
All of that made sense to me.
How much of it was obvious from the code itself?
Not enough.
The AI had found a fault line
That's the way I think about it now.
The worker hadn't created the fault line.
It had found it.
There were two ways to think about the responsibility.
The architecture wanted one.
The local code made another look reasonable.
The AI stepped on the crack.
We could blame the AI for stepping there.
Or we could mark the crack.
Better yet, we could fix it.
This is part of why we're building the shared platform
The lesson tied directly into the work we were already beginning on the shared platform.
Instead of maintaining several implementations that are all supposed to behave the same way, move the real implementation into one shared place.
Then PageSnip uses it.
ProHelp uses it.
Future products use it.
The products don't each need to know how the implementation works.
They need to know how to consume it.
That changes things dramatically.
If there's only one markdown editor, an AI worker doesn't have to remember which of four implementations is authoritative.
There aren't four implementations.
That's much stronger than telling every worker:
Make sure you follow the PageSnip pattern.
I don't think AI caused that problem
We could have gone on for years with humans maintaining those products.
Maybe the drift would have happened more slowly.
Maybe the programmers involved would have remembered enough history to keep the copies aligned.
Maybe not.
But the architectural weakness would still have existed.
We would still have been maintaining duplicated knowledge.
We would still have been depending on programmers to know which implementation was canonical.
We would still have been relying on discipline to keep related products from wandering apart.
AI just accelerated the process enough that the problem became impossible to ignore.
That may be one of AI's underrated benefits
Everybody talks about how much faster AI can write code.
That's obvious.
I think there's another benefit that gets less attention.
AI can stress an architecture in ways that expose assumptions.
Give the same system to several independent workers and see where they go.
What do they keep duplicating?
What do they misunderstand?
Which files do they keep treating as authoritative?
Where do they repeatedly put fixes?
Which responsibilities do they interpret differently?
That isn't a formal architecture test.
But it can be surprisingly informative.
The workers are approaching the system without all of the tribal knowledge we use to fill in the blanks.
Sometimes what looks like an AI mistake is actually a blank we forgot was there.
The right response isn't another paragraph every time
My old instinct would have been to fix the worker prompt.
Add a line saying:
Before implementing this, inspect how PageSnip handles it.
Then maybe add the same warning to the project rules.
Then mention it in the handoff.
Then mention it again in the qualification checklist.
There are times when that's exactly what we should do.
But there's a limit.
If I keep having to explain the same architectural fact to every new worker, eventually I need to ask why the software doesn't express that fact itself.
That thought leads directly into what we wrote about last week in Mostly Guidelines.
Important rules eventually need guards.
But this experience added something to that lesson.
Before you guard the rule, understand why the wrong path exists.
Sometimes the mistake points farther upstream
The bug may appear in the product.
The worker may patch the product.
The rule may say the behavior belongs in the shared component.
But perhaps the real architectural problem is that the shared component isn't actually authoritative enough yet.
Maybe the product can still override too much.
Maybe the old implementation still exists.
Maybe there isn't a clean API for the shared behavior.
Maybe responsibility is divided between two layers.
Maybe the product-local code contains enough of the implementation that a local fix looks natural.
In that case, telling the AI not to touch the code is useful.
Removing the reason that code needs to exist may be better.
The wrong fix became a design review
That is essentially what happened for me.
The moment I realized the AI had independently solved something that we'd already solved elsewhere, I stopped looking only at the patch.
I started looking at the relationship between the projects.
Why were we copying patterns?
Why were we maintaining similar implementations?
Why were we depending on transfer prompts to keep them synchronized?
Why should a worker on one project need to know what another project's worker did six months ago?
Those questions helped push us toward a more serious shared-platform architecture.
The wrong fix didn't create that idea.
But it made the need for it much harder to ignore.
I've started watching for this now
When an AI does something wrong, I still correct it.
But I'm paying more attention to the shape of the mistake.
Was it random?
Did it ignore something obvious?
Was the requirement unclear?
Or did it arrive at a solution that makes perfect sense from one part of the code while violating something I only know from the larger history of the project?
That last one gets my attention.
Because if I have to know the history to see why the fix is wrong, we may have an architectural problem worth examining.
The warning was more valuable than the patch
The particular fix that started this train of thought didn't survive.
It shouldn't have.
But the mistake did something more useful.
It exposed a place where our architecture depended too heavily on memory and too little on structure.
It showed us that transferring rules between projects wasn't going to be enough.
It reinforced why shared responsibilities need shared implementations.
And it reminded me that an AI worker can be wrong about the fix and still be right about where the architecture is weak.
Sometimes the wrong fix is the right warning.
Related guide
For the broader lesson about using AI mistakes as evidence about the software itself, read AI Didn’t Create the Architectural Problem. It Exposed It..