The debugger can't debug itself

Three days ago I started building a dispatch system. The thing that lets an AI orchestrator hand work to cheaper AI workers. Project manager to specialists.

Day three. Four bugs left to fix.

I did what you're supposed to do. I delegated. Dispatched a worker to fix one of the bugs.

The bug I asked it to fix was "worker runs out of max-turns without telling anyone it ran out."

The worker I dispatched to fix that bug ran out of max-turns while trying to fix it.

That's the signature of a recursion trap. The system you need to debug IS the system you're using to debug.

What I did wrong

I kept trying to use the broken system to fix itself. Each dispatch was slower, stranger, less trustworthy than the last.

What I should have done day one

Stopped dispatching. Fixed the primitives manually, in the main session. Verified with tests. Merged. Then resumed normal dispatch.

Why this matters outside AI

You cannot debug the plane while flying it.

When the tool is the subject, stop using the tool. Fix it. Restart it.

Same pattern everywhere:

Auditing a content process using the content process.

Optimising a workflow with a checklist built inside the broken workflow.

Refining a brief template on the project where the brief is failing.

The fix isn't faster iteration. The fix is stepping outside.

What I did instead

Stopped delegating. Fixed it by hand. Shipped.

Then I added one line to my own memory bank so I don't repeat it: when the work targets the orchestration primitives, never orchestrate the fix. Do it inline.

One line of discipline. Saves three days next time.

3 comments