Skip to content

I Built an AI System Smart Enough to Catch Its Own Bugs. On One Call, It Handed the Wheel Back to Me.

July 20, 2026

Everyone's complained about a boss who won't delegate: it's a tiny thing, why does it need to land on your desk?

Hold the complaint for a second. There's a kind of decision where he isn't doubting you — it's that the thing has no right answer. Every option holds up, and in the end one person has to stand up and say, if this goes wrong, it's on me. That sentence can't be handed off.

I built an AI system smart enough to catch its own bugs, fix its own code, even point to the one guard of its own that was just for show. And it locked up at exactly that kind of moment, and handed the wheel back to me. The moment where two calls are both right, crash into each other, and the only thing left to break the tie is who takes the fall.

This is about the instant it froze, and why I had to be the one to catch it.


Start with how smart it is.

There are 11 content IDs sitting in my system, and every one of them genuinely got filed. Each has two to five finished platform packages hanging off it — proof the pipeline ran end to end.

But open the ledger, and all 11 are marked not done yet.

The work was finished and filed; the ledger said none of it had happened. Every light green, the registry lying in unison. And nothing in the system had noticed — until I drew a table and forced it out.

Every light green, the ledger says nothing was ever done: the two sides don't match, and no one caught it


That table is almost embarrassingly plain.

I listed every part of the system across the top, then listed the same parts down the side, and made a grid. Wherever one part needs another to do its job, I put a checkmark in the cell. That's it — a who-depends-on-whom chart.

Spread it out and three things jump out. First: if this one breaks, who goes down with it. Second: which two parts are stuck waiting on each other, neither able to move — a dead loop. Third: which whole row, which whole column, is completely empty — that's a patch of ground nobody owns.

The table has a proper name. It's called a design structure matrix — an engineer named Steward came up with it in the 1960s, and MIT later used it to build aircraft for decades. The name is intimidating; underneath, it's just a who-depends-on-whom chart. I borrowed it to audit my own AI system.

A who-depends-on-whom chart: list the parts across and down, and any row or column left empty is ground nobody owns

It caught two patches of no-man's-land on the spot: one that hands out IDs, one that keeps the approval records. Whole rows, whole columns, empty — not a single role watching either. Take the one holding the approval records: whether a piece gets cleared to publish rides entirely on what it logs, and yet not one person in the whole system was responsible for checking that it logged right. Follow that empty line down, and I reached the 11 lying IDs.

You think you're running an organization; really you've only got a grip on the org chart — the who-reports-to-whom roster. Line the roster up perfectly, and you still haven't seen a single case of who's clenched onto whom underneath, who takes down whom when they fall.


Catching it was only the start. Almost everything that came next, the machine did on its own.

It found the root cause itself: one line of code, written wrong. After a piece got filed, the ledger was supposed to flip from holding the ID to done — but that step got shoved permanently out the door by an upstream line that said, this ID already exists, just wave it through. The line that would have updated the ledger got tucked onto a branch the flow can never reach. All 11 IDs, every last one, stuck there.

Then it designed the fix itself, guard layered on guard. Before touching anything, snapshot the scene. When it actually made the change, do it under a single lock, counting as it went — the number of rows changed had to come out to exactly 11, not one off, or the whole thing rolled itself back automatically. A lock, and another lock on top.

The sharpest move: I had a second AI reviewer deliberately break one of its guards, to see whether the alarm would sound. That flushed out a fake green light. The code was fixed correctly — but one guard, the one meant to stop the same mistake from happening again, looked green while never actually being wired in. Like a fire drill where the bell looks installed, until a real fire shows it was never connected to anything. Patched on the spot.

Those 11 rows in production flipped back to correct, carried by the snapshot and the lock, not one off. A second reviewer independently checked 8 items, all green. Then I checked them again myself.

It was smart enough to force out the guards in my own system that were only for show — smart enough to deliberately break the one guard of its own it knew was fake, and hand me the pieces.


About here you're probably asking: so what's left for a person to do?

That's the turn. In the whole fight, the one place the machine locked up and couldn't move was that patch of ground holding the approval records — whether it, too, should get a role assigned to watch it.

I didn't call that one myself. I threw it back to the AI first.

One proposal said: watch it. This ground has zero monitoring, it's a blind spot, it needs a health check built for it. Another proposal said: don't. This ground belongs to the publishing step and to human approval; jamming it into an automated health check is overreach.

Same patch of ground, two AI proposals, opposite conclusions.

I stared at the two of them for a long time. Neither had done its math wrong. The one that said watch it was stating a fact — this ground really has no one on it. The one that said don't was stating a fact too — this ground really does belong to someone else. Both chains of reasoning stood on their own, and the conclusions crashed dead into each other.

Why does this happen? Because the question has no answer you can compute.

Is this risk worth the cost of watching? Watch it, and you spend a person, you need a role carrying that responsibility. Don't, and you save the trouble — but if the approval step ever slips, there's genuinely no one holding the net. Which way is heavier? That isn't a compute problem. It's a question of how much responsibility you're willing to shoulder for that risk.

It's like that boss who won't let go. Two proposals on his desk, one saying do it, one saying don't, and you can't fault either. What he finally rules on was never about who calculated more precisely — it's that if this goes wrong, it's on me is a sentence only he can say.

My AI system hit the exact same wall.

Both proposals did the math right, and still crashed into each other — because the question has no computable answer

Where AI locks up is never that it isn't smart enough. It's that the question has no right answer, only "who is accountable" — and those four words, AI can't say for you.


I stepped in.

I overturned the "don't watch it" proposal and ruled: add the watch. Not because I calculated it better than those two proposals — they calculated it far better than I did. It's because the question came down, in the end, to who is accountable, and that AI can't take. It can lay out the ledger on both sides for me, clean. But if this goes wrong, it's on me — that sentence can only come out of someone who can actually be called to account.

So "human in the loop" — the phrase everywhere right now — nine times out of ten gets used as a liability disclaimer. Something goes wrong, and hey, at least there was a person in the flow to take the fall.

My system is the counter-sample. What a person in the loop is actually there to do is not to stamp approvals. It's to settle the one judgment that even two AI proposals couldn't settle between them. Once AI has computed everything it can compute, it takes the class of thing with no computable answer and hands it back to the only one who can answer for it.

A ruler to keep. Does this thing have a single right answer? If yes, give it to the AI. If no, you carry it. Drawing the table, catching the bug, fixing the code, running the checks — anything with a right and a wrong, anything you can verify — hand all of it over. Whether to watch this risk, whether those 11 IDs get flipped or reset — anything that can only be weighed, that needs someone to answer for it — you have to stand in the loop yourself.

Does this thing have a single right answer: right-or-wrong goes to the AI, only-a-judgment-call you carry

The stronger AI gets, the harder you have to think this through: which class of judgment must never go to it. Not because it isn't smart enough. Because the core of that judgment is accountability, and accountability can't be handed off.


I'm Uncle J. Eighteen years in HR — and the thing worth the most isn't the résumé, it's the judgment: reading people, breaking down the work, dividing authority. Then I took that judgment and, alone, wrote it into an AI system.

It's smart enough to catch its own bugs, fix its own code, even hand me the pieces of a guard of its own that was just for show. And it locked up in front of one judgment I've been making every day for eighteen years — whether to watch that risk or not. It couldn't call it. That one still came back to me.

Other people talk AI specs. I work out one thing only: what it actually changed, and what it can never replace.

Uncle J · theunclej.com


OG Image (1200×630)

Want to turn this into an operating system? Send Uncle J the context →

J叔

Subscribe to Uncle J's Insider

Notes on AI organization, AI HR, agentic engineering, and content systems when they are worth sending.