AI-Orchestrated Debugging — What "Baby-Sit the AI" Actually Looks Like

When I tell clients I use AI heavily in my debugging workflow, the reaction usually splits two ways. The first is "great, that's cheap and fast." The second is "isn't AI hallucinating constantly — how do I trust it on my codebase?"

Both reactions assume AI is doing the thinking. It isn't. I'm doing the thinking. AI is doing the typing, the searching, and the boilerplate. That distinction matters for how the workflow actually runs.

The Mental Model: I Orchestrate, AI Executes

Think of it like a senior dev pair-programming with a fast, infinitely available, but inconsistent junior dev. The senior dev:

• Decides what to investigate
• Reads the AI's output critically and pushes back when it's wrong
• Makes the architectural decisions
• Tests every change before accepting it

The junior dev (AI):

• Searches the codebase in seconds
• Generates the boilerplate for unit tests, debug logging, regex patterns
• Suggests hypotheses for what might be wrong
• Drafts the fix once we agree on the cause

If the AI starts driving — making architectural decisions, accepting its own suggestions, deploying without review — the wheels come off fast. So they don't get to drive.

The Concrete Workflow

Here's what an AI-orchestrated debugging session actually looks like, end to end:

1. Reproducing — AI helps find the entry point

I describe the symptom. AI greps the codebase for the relevant function or component. In seconds I have the file and line where the bug almost certainly originates. That's 10 minutes of manual searching saved.

2. Instrumenting — AI writes the debug logs

I tell AI which boundaries to log and what variables to capture. It generates the logging code in seconds, formatted to match the existing logging style in the codebase. I review and apply.

3. Forming hypotheses — AI suggests, I judge

This is where AI is most useful and most dangerous. I ask: "Given these debug logs, what's the most likely cause?" AI gives me three or four hypotheses. Some are good. Some are wrong. My job is to know which is which.

For wrong hypotheses, I tell AI why and have it generate a better one. That back-and-forth narrows the cause faster than I could alone.

4. Writing the fix — AI drafts, I review

Once we've agreed on the cause, AI drafts the fix. I read every line. I push back on anything I don't understand. I test the fix locally before I commit.

If AI's fix uses a pattern that's inconsistent with the rest of the codebase, I rewrite it. If it uses a library I don't trust, I swap it.

5. Writing tests — AI generates, I verify behavior

AI writes the test scaffold. I write the assertions — because asserting the *correct* behavior is the part that requires judgment about what the code should do, which AI can't always know.

6. Hardening — AI flags related risks

I ask: "Now that we've fixed X, are there similar patterns elsewhere in the codebase that might have the same bug?" AI greps and surfaces them. I review and decide which to fix in this engagement vs. flag for later.

What "Baby-Sit the AI" Actually Means

This phrase is intentional. The AI is doing real work, but it needs continuous supervision:

• It hallucinates — sometimes confidently. It'll claim a function exists when it doesn't, or that a library has a method it doesn't. I verify by reading the actual code, not by trusting AI.
• It loses context — on long sessions it'll forget constraints we established earlier. I re-anchor it regularly.
• It pattern-matches superficially — if a piece of code looks like a common pattern, AI will assume it behaves like that pattern even if the actual implementation differs. I catch this by reading.
• It overcommits — given a small fix, AI will sometimes suggest a sweeping refactor. I push back and keep scope tight.

If you've used AI just for autocomplete, this might sound like more work than just writing the code yourself. It is more work than autocomplete. But the speed of the *combined* workflow — me thinking, AI executing in seconds — is genuinely 5-10x faster than me alone for most tasks.

Where AI-Orchestrated Workflow Pays Off Most

• Unfamiliar codebases — AI can read and summarize faster than I can
• Test generation — boilerplate test setup is a perfect AI task
• Regex, SQL queries, log parsing — fast wins where the cost of error is low (you can verify the output)
• Cross-cutting refactors — "rename this thing in 47 files consistently" is what AI is best at

Where it pays off least:

• Critical security code (auth, payment, crypto) — too high stakes for AI to draft
• Performance-critical paths where the right answer requires deep system knowledge
• Anything requiring real business judgment about user behavior

What This Means for Clients

For bug-fix engagements, AI orchestration means:

• Faster turnaround (most bugs fixed in days, not weeks)
• More tests written (because the boilerplate is cheap)
• Better documentation (AI writes the PR descriptions)
• Same level of senior judgment (because I'm still the one deciding)

You get the speed of a junior dev with the judgment of a senior. That's the actual value.

---

Want to see this workflow on your codebase? I take on AI-orchestrated bug-fix engagements at all sizes. A $1,500 Quick Win for one defined bug + tests, or a $500 Discovery to audit your codebase and lay out a roadmap. Send me the symptom and I'll tell you what's realistic.