The difference between a debugging session that takes ten minutes and one that takes an hour usually isn't the bug itself — it's whether Claude Code had the real error in front of it from the start, or was working from a description of it.
"It's throwing a type error somewhere in the checkout flow" forces it to go looking for the same information you already have on your screen. Paste the actual stack trace instead — the exact file, line number, and error message. That's the difference between starting from a hypothesis and starting from a fact.
Claude Code can execute commands directly, which means it doesn't have to take your word for what a failure looks like — it can run the failing test, read the real output, make a change, and run it again. That loop, done by the agent itself, is faster than the version where you run the test and paste the result back manually each time.
For a bug whose cause isn't obvious from the stack trace alone, targeted logging at a few suspect points is often faster than guessing — have it add temporary logging, re-run, and read what actually happened at runtime. This works well specifically because the logging is scoped and temporary; review it in the diff the same way you'd review any other change, and remove it once the real cause is found.
If the same category of fix gets tried two or three times without new information surfacing, that's not a sign to keep waiting — it's a sign it's missing something you already know. An undocumented assumption about how a third-party API behaves, a config value that isn't in the codebase, a business rule that lives only in someone's head — hand that over explicitly instead of letting the loop repeat.
Paste the actual error — the full stack trace, not a paraphrase. A summary loses the exact line numbers and error type that would otherwise let it jump straight to the likely cause instead of re-deriving what you already have in front of you.
Yes, when a test already reproduces the bug — let it run the test, read the real failure, make a change, and re-run, rather than you relaying results back and forth manually. That loop is faster and it catches its own mistakes before handing control back to you.
If the same fix attempt repeats without new information after two or three tries, that's the signal — it's missing context you have and it doesn't, like an undocumented assumption about how a system behaves. Add that context directly rather than letting it keep guessing.
Yes for temporary, scoped logging used to isolate a bug — it's easy to review and remove afterward. Treat it the same as any other change: read the diff before approving it, especially in code that runs in production.