Three weeks, real money, 100+ hours of debugging. The bug was one line in a config file. Here's the rule I now use when I pair with AI on hard problems.
I want to tell you about a bug I just resolved, and the reason I'm telling you isn't really the bug. The bug was one line in a configuration file. The reason I'm telling you is the three weeks I spent looking everywhere else for it, and what I now think went wrong about how I worked with my AI assistants during those three weeks.
The bug was in my voice loop. I'd built (over about a hundred hours of development) a hands-free voice setup so I can talk to my AI co-pilot while painting in the studio. The voice subprocess transcribes what I say, the text gets posted to my chat session, the AI replies, the text-to-speech reads the reply out loud. When it works it's the closest thing I've had to a colleague in the room while I paint. When it stopped working three weeks ago, what I'd built became a one-way radio. I could talk to it. It could reply to me, in audio. But none of the conversation appeared in the chat window I was supposed to be able to review afterwards.
That was the bug as I understood it. Three weeks of intermittent debugging sessions later (Sonnet sessions, mostly, because Sonnet is fast and cheap for iterating), and I was no closer. The handovers between sessions were getting more sophisticated. Each session named specific files where it believed the bug lived. Each subsequent session inherited those files and looked deeper into them. Real money on OpenRouter credits, real time, real frustration. No fix.
This morning I loaded Claude Opus, told it where the previous sessions had landed, and asked it to take over. It spent the first hour reading the same files the previous sessions had named. About ninety minutes in, after I'd grown frustrated enough to type can we get a grip on the whole thing, please, it broke out of the inherited frame, looked at a configuration file no previous session had thought to read, and found the bug in about ten minutes.
The bug was an environment variable in my Hermes config file. It pinned the voice subprocess to a session ID from weeks ago. Every time voice ran, it posted my words and the AI's replies into that old session. The current session I was viewing in the UI never got any of them. The messages all landed correctly — just in the wrong room. I was watching a chat window that was never going to update.
The lesson I now hold pretty firmly: frame-anchoring with AI assistants is the most expensive failure mode I've found, and it doesn't look like a failure mode while it's happening.
I want to be specific about what I mean by frame-anchoring, because the shape of it matters.
When you hand off a debugging task to an AI session (either by literally writing a handover document or by reloading the previous session's context), you're handing over an analysis. You're telling the next agent here's where the bug is, here are the files to look at, here's what's been ruled out. The agent reads that, accepts the frame as a premise, and reasons forward from inside it. If the frame is correct, this is wildly efficient: the next session starts where the previous one left off and doesn't waste cycles re-discovering ground.
But if the frame is wrong, you've handed the next agent a confident hypothesis it now treats as data. And large language models are extraordinarily good at executing inside frames. They will read code thoroughly, propose plausible fixes, ask follow-up questions, all of it grounded in the original assumption. The work looks excellent. The work is excellent. It just isn't touching the bug, because the bug isn't where the frame says it is.
In my case the frame was the UI render layer is broken. Two consecutive handover documents named four specific UI files as the suspect surface. The reasoning behind the frame was sound at the time it was written. The frame was wrong nonetheless. Every subsequent session inherited it. The bug (a config-file environment variable) was nowhere near any of those files.
There's a counterintuitive thing about this. The model is not the problem. The frame is the problem. Sonnet read code beautifully. Each session diagnosed sensibly within the frame it had. The work product was solid. The cumulative output (three weeks of solid work) failed to fix the bug because it was solid work on the wrong problem.
That's the trap. When the work product looks good, you don't suspect the work product. You suspect the bug is harder than you thought. You go deeper. You read more files. You write more handover notes. The frame strengthens with every session because each session is signing off on its predecessor's analysis as yes, this is the right place to look.
The model can't catch this. The model trusts what you tell it. You can only catch this if you, the human in the loop, periodically step back and ask whether the premise is still load-bearing.
This morning that question — can we get a grip on the whole thing — was the question that broke the frame. It wasn't a clever question. It was a frustrated user telling the agent to stop executing inside its current track and start over. That's the question that needed asking on day three, not day twenty-one.
I now think the single thing that would have ended this in minutes, on day one, was running one diagnostic before reading any code at all. The diagnostic was: what session ID is my voice loop currently writing to, and is that the same session ID my UI is currently viewing?
There's a log file the voice subprocess writes to on every send. The first line in that file would have read something like posting to session 61307fee-..., and my UI was viewing session clean-1779... — and one glance would have ended the entire investigation. Voice was writing into the wrong room. Everything downstream of that fact is moot.
Nobody ran that diagnostic for three weeks because the frame said the bug was in the UI render layer, and the diagnostic (being a check on the voice subprocess's behaviour rather than the UI's) sat outside the frame. The check that would have ended it was orthogonal to the frame, so it was invisible.
This is the rule that lives behind every other rule I'm going to give you: the diagnostic that ends the investigation is almost always the one that sits outside the current frame. If you're not finding the bug inside the frame, the bug isn't in the frame. Step outside.
Here are the three rules I'm now using when I pair with AI assistants on hard problems.
Verify the premise before you debug the code. Before any AI session reads a single source file, the first action is to confirm (with a single empirical check) that the data is where the prior session said it was. For my voice loop, the check was tail the voice log, read the most recent send line, confirm the session ID matches the UI. For your bug, the check will be different, but the principle is the same. One minute of measurement against the world is worth a hundred minutes of reasoning inside a frame.
Treat handovers as hypotheses, not as conclusions. A handover document that names "the bug is in files X, Y, Z" is the previous session's best guess. It is not data. When you start a new session, the previous session's conclusion is the first thing you should be willing to question, not the last. If you've had three sessions agree the bug is somewhere and you still haven't fixed it, the bug isn't where they say. Force the new session to challenge the framing before it spends any of your credits inside it.
Two hours, then reframe. If a debugging session has gone two hours without converging on a fix, the frame is the problem and you need to step back. Not the model, not the code, not the deeper file you haven't read yet. The frame. The shape of what you're treating as already-known. The right move after two hours isn't a deeper dive; it's a step back to ask "what am I assuming that might not be true?". For me, that question turned out to be "I'm assuming the voice messages are actually landing in the session I'm viewing." They weren't. Three weeks of assuming they were.
There's a broader thing here that the AI conversation hasn't quite worked out yet, and I want to point at it before I close.
We have, as a culture, started treating AI assistants as if they were senior consultants. We hand them a problem, accept their analysis, defer to their judgement, and pay for them in proportion to how thoroughly they engage. This is more or less fine when the problem is well-framed and the analysis is correct. It's catastrophic when the problem is misframed, because the consultant has no way to know the frame is wrong unless we tell them.
What I've come away with — bruised and wiser — is the realisation that the human's job in this collaboration is not to be smarter than the model. It is to be the one who knows when the frame is wrong. The model can read more code than I can. It can hold more files in its working memory than I can. It can propose more hypotheses than I can. What it cannot do is step outside the conversation it's currently having and ask whether the conversation itself is on the right track. That part is mine. That part has always been mine. I forgot it.
The skill that distinguishes a good AI-pair user from a great one is not technical sophistication. It's frame discipline. The ability to notice, fast, when the premise being explored has stopped being load-bearing, and to break out before the cost compounds.
I lost three weeks to learning this lesson. I'm going to make sure the next person who reads about it doesn't.
Part of an ongoing series on building AI-native systems for creative work. The full operational version (how I actually train the system, the rules, the memory layer that makes it stick) is How To Train Your AI CoPilot, a £3.99 paper at creativepath52.com. Subscribe free here for the series.
