Don’t Lick the Glass: What AI Taught Me About Governance, Part 2

Part 1 of this series was about authority.

An AI can see something, understand it correctly, and have the technical capability to change it without having the authority to do so.

Capability is not authority.

Round 23 taught me about a different failure mode.

Sometimes the AI has authority. Sometimes the evidence is good. Sometimes the defect is real.

And continuing to fix it is still the wrong move.

That is harder to catch because nothing looks obviously broken. A reviewer finds a bug. You verify it. You authorize a repair. The repair gets tested. Another reviewer finds another legitimate problem.

That sounds like a healthy engineering workflow.

For a while, it is.

Eventually, repetition becomes information of its own.

It Started With Ten Broken Logos

The original problem was almost embarrassingly ordinary.

A previous change had season-qualified the logo filenames in Gridiron Gazette, but the league configuration was still pointing at the old names. All ten logo_url values referenced files that no longer existed.

Worse, nothing checked them.

The Week 1 build could have completed successfully and published a Gazette with ten broken team logos.

So PR #37 began with a straightforward job: fix the paths and make the build refuse to publish when a configured logo doesn’t exist.

That should not require twenty-five corrective rounds.

It did.

Because fixing the paths exposed a larger question:

When Gridiron says this is the logo, what exactly does “this” mean?

A filename? A team name? Whatever bytes happen to be sitting under that filename when somebody reads it? The exact artwork the Commissioner previewed and approved?

Every time we strengthened that answer, another part of the application revealed that it was operating under an older one.

Explicit paths had to survive localization and publication. Installation had to be atomic. Preview needed to stop installing artwork. Previewed artwork needed a digest binding it to the exact reviewed bytes. Publication had to prove those were still the bytes being installed. The published record needed to carry that identity, and readers needed to enforce it instead of quietly deriving a new one later.

None of those findings was imaginary.

That was the problem.

When Diagnosable Isn’t Enough

In an earlier article, The Architecture of “No,” I wrote that good governance doesn’t mean a system never fails. It means failure is “bounded, observable, and diagnosable.”

I still believe that.

Round 23 taught me there is another question that comes after diagnosis:

What if you keep diagnosing legitimate failures in the same place?

PR #37 had bounded work. Reviews were finding real problems. We had evidence. Repairs were authorized, implemented, tested, and reviewed again.

The governance system was doing what I designed it to do.

And we still ended up at Round 23.

Every round gave us a rational reason to authorize the next one. From inside a single round, nothing looked particularly ridiculous.

There was a defect. Here was the evidence. Here was the bounded repair. Here were the tests and receipts.

Review it again.

The absurdity only became visible when we stopped looking at the current round and looked at the sequence.

We could follow the process correctly and still ask the wrong question twenty-three times.

MIRROR and SCOUT Ask Different Questions

I didn’t invent MIRROR or SCOUT. I first encountered those frameworks through Jules White of Vanderbilt University in one of his Coursera courses, and I adapted them into the way I work with AI systems.

They gave me names for two very different questions.

MIRROR asks: Does this repair hold?

SCOUT asks: Why does this wall keep cracking?

Most of PR #37 had been living in MIRROR territory.

A correction was made. Another reviewer attacked it. If the reviewer found a legitimate weakness, we repaired it and tested again.

That is useful. I still use it.

But MIRROR assumes continuing to examine the repair is the right level of inquiry.

Eventually that assumption itself needs review.

SCOUT moves outward.

What assumptions are we carrying? Who owns this state? Where is identity established? Where does it get re-derived? What counts as the transaction boundary? Who else reads or writes the same thing?

Those questions changed PR #37.

The Problem Was Older Than the Bug

SCOUT went back to the legacy system rather than starting with the latest patch.

Historically, team name effectively acted as logo identity. Consumers could resolve artwork again when they needed it rather than carrying a verified identity forward.

The served-logo directory had behaved like a regenerable cache keyed by filename. PR #37 was trying to make those assets behave like immutable, identity-bound objects without fully changing the older model underneath them.

Rendering in place had been safe enough under an assumption of one sequential operator. Publication had also developed two different commit shapes with different ordering, filesystem operations, rollback behavior, and error handling.

Most importantly, the system repeatedly verified artwork identity at individual moments without necessarily carrying and enforcing that identity through the entire transaction.

We had gotten very good at asking:

Are these still the right bytes right now?

Then checking again later.

But verification at an instant is not the same thing as preserving identity across a transaction.

By then, treating every finding as an independent bug no longer described what we were seeing. Old architectural assumptions were producing families of bugs.

SCOUT Did Not Magically End the Work

This is where neat engineering stories usually cheat.

You find the architectural problem, redesign the system, triumphant music plays, everybody goes home.

That isn’t what happened.

SCOUT did not make the remaining work disappear. We still had Rounds 24 and 25.

What changed was the level at which we were working.

We were no longer treating each finding as an isolated defect. We had a map of the legacy assumptions producing the defect family, and the remaining corrections were made against that map.

By Round 25, the circuit breaker was written directly into the review instructions. If another substantive finding appeared on the same seam, implementation would stop and we would SCOUT again before authorizing another correction.

The final exact-head review came back without another major issue.

PR #37 merged.

SCOUT isn’t the thing you run when you want the bugs to go away.

It’s the thing you run when you need to know whether fixing another bug is still the right job.

The Round-5 Circuit Breaker

I am not interested in repeating Round 23 to prove that Round 23 taught me something.

So the lesson became a rule.

After roughly three consecutive corrective rounds on the same conceptual seam, repetition becomes an architectural warning.

No later than Round 5, stop patching and SCOUT:

• Reconstruct the assumptions.
• Externalize the state model.
• Look at ownership and identity.
• Examine transaction boundaries.
• Look for competing definitions of the same concept.
• Identify the adjacent readers and writers.

Then decide whether another local repair is actually the smallest correct move.

Five isn’t magic. It is a circuit breaker.

If Round 3 gives you strong evidence that the architecture is fighting you, there is no prize for completing two more patches first.

That rule earned its plaque on my Wall of Shame:

If you’re fighting Round 23, you missed the exit at Round 5.

AI Makes Another Round Cheap

AI changes the economics of iteration.

Code can be generated faster. Tests can be written faster. Another model can inspect the repair almost immediately.

That is genuinely useful.

It also means you can travel in the wrong direction at extraordinary speed.

When producing another patch becomes cheap, the natural friction that might once have forced a team to reconsider the architecture drops with it.

There is always another model available to review the latest repair.

There is always another fix available.

There is always another round.

And if each model is doing good work inside the frame it was given, nobody necessarily questions the frame.

Greater capability does not automatically produce greater perspective.

Sometimes it just lets you drive farther down the wrong road before you run out of gas.

AI-assisted development therefore needs stopping rules for modes of reasoning, not just authority over actions.

At some point the question has to change from:

Did we fix it?

to:

Why are we still fixing this?

I Use the Same Distinction in Content

I eventually started using the same MIRROR and SCOUT distinction outside code.

I use it when I write.

For content, MIRROR asks whether the piece answers the questions a reader is likely to have.

Did I introduce something and fail to explain it? Did I make a leap that makes perfect sense to me because I’ve been living inside the subject for six months, but the reader hasn’t?

SCOUT asks what assumptions I’m making that could be incorrect.

Am I treating my experience as universal? Am I assuming background I haven’t established? Am I repeatedly repairing paragraphs because the article is organized around the wrong thesis?

You can polish the same section fifteen times and eventually produce an extremely elegant paragraph that should not be in the article.

Software doesn’t have a monopoly on Round 23.

The medium changes.

The pattern doesn’t.

Repetition Is Evidence

The lesson from PR #37 isn’t that we should have predicted every architectural problem before writing the first fix.

That standard would be useless.

We build with imperfect knowledge. Reality gives us more information as we go.

The mistake is treating each new failure as though it exists independently of the failures that came before it.

At some point, recurrence becomes evidence.

Three failures along the same seam might still be coincidence.

Five should make you suspicious.

Twenty-three is the system standing on the table waving both arms.

The skill isn’t becoming so good at debugging that you can repair an infinite number of local failures.

It is recognizing when another successful repair would only make you better at maintaining the wrong architecture.

MIRROR still gets its question:

Does the repair hold?

But eventually SCOUT gets one too:

Why does this wall keep cracking?

And if you’re fighting Round 23, you missed the exit at Round 5.

This is Part 2 of Don’t Lick the Glass, a series about real-world AI governance from the operator’s side of the desk.

Melanie Brown is the founder of Bluedobie Developing, a rural Kentucky-based SaaS and web development company, and the creator of DobieCore — an AI content platform engineered to give small business owners professional results without the prompt engineering learning curve. She writes the Bluedobie Dialogues series about systems thinking, sustainable business architecture, and what durability actually looks like in practice.