[FEATURE] Ask the user earlier on long-running tasks: 4 of 5 wrong conclusions were caught only by external interrupts

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Scope: this concerns long-running development and research work, not short Q&A. For light usage the current behaviour is fine.

I use Claude Code for a months-long reverse-engineering project (an undocumented binary patch format for a guitar effects unit, plus designing audio measurement metrics). Sessions run for hours across many tool calls.

In one session Claude reached a wrong conclusion 5 times and caught only 1 by itself. The other 4 were overturned by my interruption or by the advisor model.

Three problems this exposes:

1. The gap is recall, not knowledge. Ask Claude "should you take a control group?" or "does your measurement method match the target?" and it answers correctly. It simply does not recall the principle while in the middle of the work. Every correction came from an external interrupt; nothing inside the working loop triggered self-correction.

1. Claude commits to its own approach for too long before admitting a limit. It kept refining a method instead of stopping to ask. In this project the decisive information — how the hardware actually behaves, what the sound is like by ear, which of two candidates is correct — exists only with me and is nowhere on the internet. No amount of further reasoning substitutes for it.

1. The errors were not visibly wrong. Most produced precise-looking numbers, which is exactly why they went unnoticed. An error that looks like an error gets caught; one that looks like a measurement result does not.

Proposed Solution

Make "I may be at the limit of what I can determine here — do you know X?" an early, natural move rather than a last resort, and surface self-checks at work boundaries rather than only when asked.

Concretely:

• At natural boundaries (before committing to an approach, after a measurement, before writing a conclusion), prompt the model to ask itself: "If this method were wrong, how would it look?" This single question would have caught most of my cases, because the failure mode was plausible-looking output rather than an error.

• When a task depends on information the user holds and the model does not (physical hardware behaviour, how something sounds, domain conventions), make asking the user an expected step early on — not something attempted only after several failed approaches.

• Treat the user as a participant in forming the hypothesis, not only as the approver of a finished conclusion. In my sessions, each of the 4 corrections came at a point where one sentence from me redirected the entire approach.

Alternative Solutions

I now maintain a file of "thinking patterns" that Claude reads before starting work (e.g. "is the measurement method appropriate to the target?", "are you at n=1?", "if this were wrong, how would it look?"). It helps.

But every user rediscovering and rewriting the same patterns is itself the larger waste — which is why I'm reporting it rather than just keeping the file.

The advisor model also works well as an external reviewer, and was what stopped the worst detour. But it is external to the working loop, so it only helps when invoked.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

Example scenario (one of the 5):

1. A delay effect did not sound at the time I had set. Claude measured it and found the actual time was 295 ms instead of 400 ms.
2. Claude formed two hypotheses about the hardware: a 0.74x linear scaling, or a clamp at 300 ms. Both looked reasonable and it was ready to apply a correction formula to existing presets.
3. I asked for a 5-point measurement first (100/200/300/400/600 ms) before applying anything.
4. All five came back at 294 ms — matching neither hypothesis. The real cause was that Claude had been writing the value to the wrong byte offset in the file it generates.
5. Had we applied either correction formula, it would have damaged presets I had already tuned by ear over weeks.

The general pattern: Claude questioned the behaviour of the thing being measured, but not whether its own configuration was written correctly. And the wrong answer looked like a plausible measurement, so nothing internal flagged it.

Additional Context

On speed: Claude Code is noticeably slower to respond than other AI tools. The depth of reasoning is real and valuable — but a wrong direction pursued deeply is expensive. Asking one question early is faster than reasoning correctly for ten more steps in the wrong direction. In this project, the two-person loop has been both more accurate and faster than Claude working alone.