I've had an uncomfortable realization while working on several software projects recently.
The rule was already there.
Not implied. Not buried in some conversation six months ago. Not something I thought I had told the AI but hadn't.
It was there.
We had documented it. We had discussed it. In some cases, we had specifically transferred the rule from one project to another because we wanted to make sure the same mistake didn't happen again.
Then the AI did something else anyway.
That bothered me for a while because my first instinct was the obvious one.
How do we write the instruction better?
I'm starting to think that's the wrong question.
PageSnip became the model
PageSnip has been an interesting project because a lot of our ideas got worked out there first.
We developed the application shell. We worked through how dialogs should behave. We established presentation patterns. We built Markdown editing and preview behavior. We worked through images. We worked through the things that make an application feel like one coherent product instead of a collection of screens somebody happened to put together.
Once PageSnip had matured enough, it made sense to carry those ideas elsewhere.
ProHelp Viewer needed the same family resemblance.
The ProHelp Studio authoring application needed it.
ProSurface Core needed to make it possible for a Clarion developer to build an application with the same visual language.
The idea was pretty simple.
A developer should be able to use one of our products, then buy the developer tools and create something that feels like it belongs to the same family.
I still think that's exactly the right goal.
Our first approach to achieving it wasn't.
We transferred the knowledge
We didn't just tell another AI, "Make this look like PageSnip."
We got considerably more disciplined than that.
We created handoff prompts. We identified the patterns. We explained what PageSnip was doing. We told workers which implementation was authoritative. We described what should be carried over and what should remain product-specific.
We went through multiple iterations trying to line everything up.
For a while, that felt like exactly what good AI project management should look like.
Give the worker enough context. Identify the source of truth. State the boundaries. Explain the expected result. Let the AI do the work.
The problem was that the products still drifted.
Not all at once.
One little decision at a time.
A reasonable fix in the wrong place
This is the pattern I kept seeing.
Something breaks.
The AI searches for the code associated with the failure.
It finds a plausible location.
It reads enough surrounding code to understand what is happening.
Then it writes a fix.
The fix may actually be good code.
That's what makes this problem interesting.
It isn't necessarily some stupid hallucinated function that doesn't compile.
It may be a perfectly sensible solution to the problem the AI thinks it has been asked to solve.
But we've already solved that problem somewhere else.
Or that responsibility belongs to the shared layer.
Or another product already contains the canonical implementation.
So I find myself asking a question I've asked far too often lately:
Why are we solving this again?
The answer isn't that the AI deliberately decided to ignore the architecture.
I think the answer is usually simpler.
The local solution made sense from where it was standing.
Then there was the file that never existed
One experience recently drove the point home in a different way.
An AI worker insisted that a particular file was the source authority for the work it was doing.
There was just one problem.
The file had never existed.
This wasn't a case where the file had been deleted and the AI was remembering old repository history.
It wasn't an alternate name I had forgotten about.
It was imaginary.
Yet once the AI had incorporated that imaginary file into its understanding of the assignment, everything else it said about the situation was remarkably coherent.
That may be the more disturbing failure mode.
Bad reasoning is often easy to catch.
Good reasoning from a false premise can look excellent.
You can argue with it. You can point out that the premise is false.
But what interested me afterward was not the argument.
It was the engineering question.
Why did the workflow permit an imaginary authority to survive long enough to matter?
We had a rule about source authority.
What we didn't have at that particular point was a mechanism that made a false authority impossible to accept.
That's a different problem.
I started noticing the guards
Around the same time, I noticed something else happening in our projects.
Guard scripts were appearing everywhere.
A script verifies that this file exists. Another verifies that those files don't. Another checks a source manifest. Another protects an architectural boundary. Another confirms retained behavior. Another checks that generated output corresponds to the correct source. Another rejects a state the application should never be allowed to reach.
I don't remember seeing nearly as much of this in AI-generated projects even a short time ago.
I'm seeing it now in work done by multiple AI systems.
And I think I understand why.
We're gradually moving rules out of conversations and into the environment.
That's probably exactly where they belong.
We had been trying to make copies stay identical
The shared application work made this particularly obvious.
We had several products that needed the same behavior.
Our original answer was essentially to teach each project how to implement that behavior correctly.
That's a very human way to approach it.
Document the standard. Train everybody on the standard. Review the results. Correct the deviations. Repeat as necessary.
That works reasonably well when the programmers carry a durable mental model of the organization and its history.
An AI worker doesn't necessarily arrive with that.
It constructs the model it needs for the current assignment.
So we're changing the architecture.
If the MDX editor should exist once, it will exist once.
Products will consume it.
If image handling belongs in the shared implementation, products won't each receive instructions describing how to implement images.
They'll use the implementation.
That doesn't merely reduce duplicate code.
It eliminates opportunities for drift.
The conductor needs guards too
This has also changed what I think an AI project conductor needs to become.
We've already had good results separating the conductor from individual workers.
The conductor maintains the larger project. A worker gets a bounded task. The worker does the work and returns a package. The conductor evaluates what happened and decides what happens next.
That's much better than trying to keep one enormous AI conversation alive forever.
But I no longer think a conductor should merely be a very good keeper of instructions.
It also needs to become the enforcement point.
If this source artifact is authoritative, verify it.
If this build number is consumed, reject its reuse.
If these retained tests are mandatory, require them to pass.
If this package isn't allowed to depend on that package, test the dependency graph.
If implementation of a shared responsibility suddenly appears inside a product shell, fail the qualification.
Don't tell the worker to be more careful next time if a machine can prevent the mistake this time.
This isn't really about distrusting AI
I don't think the lesson is that AI is unreliable and therefore shouldn't be allowed to do important work.
My experience tells me almost exactly the opposite.
AI is becoming capable enough to do much larger amounts of important work.
That's why this matters.
When all you're asking an AI to do is write a 30-line function, an occasional bad decision is irritating.
When the AI is helping maintain a commercial product over months or years, local decisions accumulate.
A small architectural deviation today becomes the precedent the next AI discovers tomorrow.
Then another piece of code depends on it.
Then somebody documents it.
Eventually the mistake stops looking like a mistake.
It becomes the architecture.
That's what I want the guards to prevent.
The rule wasn't the solution
For a while, I thought we needed better project rules.
Then I thought we needed better structured context so the AI could find those rules.
Then we added conductors and bounded workers so one agent wouldn't have to carry the entire project in its head.
All of those things helped.
I'm not giving any of them up.
But I'm adding another question now.
When we write an important rule, I want to ask:
What happens if the AI ignores this?
If the answer is that a human eventually notices the damage, that's not much of a guard.
If the answer is that qualification fails immediately, that's considerably better.
And if the architecture makes the prohibited choice unavailable in the first place, that's better still.
The rule was already there.
What was missing was something strong enough to make the rule matter.
Related guide
For the broader argument about moving important AI programming rules out of prose and into enforceable architecture, read Mostly Guidelines.