Claude Code bijsturen tijdens het werk: Esc, de wachtrij en /btw

Wil je Claude Code bijsturen terwijl hij bezig is, dan heb je drie mogelijkheden. Met Esc stop je het lopende antwoord of de lopende tool call: Claude houdt het werk dat al gedaan is en wacht tot je hem een nieuwe richting geeft. Typ je een bericht en druk je op Enter, dan komt het in de wachtrij: Claude Code geeft het door zodra de lopende tool calls klaar zijn, nog binnen dezelfde turn. En met /btw stel je een zijvraag die nooit in het gesprek belandt.

Alle drie werken. Ik liet dezelfde taak veertig keer draaien, in twee groottes, om te zien wat de timing kost, en elke run haalde alle checks. Het verschil zat in de rekening. Bij de grotere taak kostte corrigeren nadat de agent klaar was 56% meer dan alles meteen in de opdracht te zetten, in de mediaan van vijf runs. Hem met Esc stoppen bij zijn eerste edit kostte daar niets extra.

Het experiment ​

Een klein Node-project met drie CLI's die dezelfde CSV met verkoopcijfers lezen. De opdracht: voeg aan alle drie de datumopties --since en --until toe. Daarna de correctie waar je altijd net te laat aan denkt: zet het filteren in één pure functie in lib/filter.js met eigen unit tests, weiger onmogelijke datums zoals 2026-02-30 met exit code 2, en documenteer beide flags in de README.

Vier routes, elk vijf keer, met steeds exact dezelfde tekst:

• Opdracht: taak en correctie samen in het eerste bericht.
• Esc: alleen de taak, onderbroken bij de eerste edit van de agent, daarna de correctie.
• Wachtrij: alleen de taak, correctie in de wachtrij gezet bij de eerste edit, zonder onderbreking.
• Achteraf: alleen de taak, correctie nadat de agent meldt dat hij klaar is.

Claude Code 2.1.293 op Opus 5.5, headless, zonder gebruikersinstellingen, hooks of CLAUDE.md. Een script beoordeelde elk resultaat op twaalf checks. Eerst draaide ik een versie met één CLI, beoordeeld op zeven checks. Daar had de agent weinig ruimte om af te dwalen, en daarom bestaat de versie met drie.

Medianen. Alle veertig runs haalden elke check. De agent kwam er altijd. Hij deed onderweg alleen meer werk, en hoe later de correctie, hoe meer hij moest terugdraaien. Tegen de tijd dat hij in de route achteraf de echte eisen hoorde, had hij al zes tot acht edits gedaan die hij door de correctie moest overdoen.

Het gaat om centen bij een taak van een minuut. Juist daarom staat de tweede kolom erbij: van één CLI naar drie werden de meerkosten van de route achteraf ruim twee keer zo groot, terwijl die van Esc naar nul zakten. Je echte taken zijn langer dan de mijne.

Voordat hij begint: geef de context die je hebt ​

De goedkoopste correctie is de correctie die je nooit hoeft te sturen. Bijna alles uit mijn correctie wist ik al vóór de eerste prompt, en bij de taak over drie bestanden deed elke route die zonder die informatie begon, meer edits.

Twee dingen maken je opdracht beter zonder hem langer te maken:

• Verwijs met @ naar een bestand en de volledige inhoud komt in het gesprek. @src/lib/filter.ts werkt altijd beter dan "die filterhelper". Bij een map krijg je alleen een lijst met bestanden.
• Plak een screenshot met Ctrl+V (Alt+V op Windows en WSL, Cmd+V in iTerm2), sleep hem erin of geef het pad. Een layoutbug die je in woorden beschrijft, kost een extra rondje dat het plaatje je bespaart.

Het onderzoek komt vanaf de andere kant op hetzelfde uit. In Ambig-SWE presteerden agents die bij een onvolledige opdracht eerst vragen stelden tot 74% beter dan agents die meteen begonnen. Plan mode is de ingebouwde versie daarvan: de agent laat zijn aanpak zien voordat hij iets schrijft, en dat is het goedkoopste moment om bezwaar te maken.

Esc: stoppen, het werk houden, bijsturen ​

De docs over de interactieve modus beschrijven Esc precies: "Stop the current response or tool call mid-turn so you can redirect. Claude keeps the work done so far."

Die tweede zin verklaart waarom het in mijn runs zo weinig kostte. De agent begint niet opnieuw. Hij heeft de code gelezen, kent de CLI's en heeft één edit die hij opnieuw moet bekijken. Je verliest alleen de richting die hij insloeg, en die was toch al fout.

Maak er een gewoonte van om bij het eerste signaal te drukken, niet bij het derde. De best practices van Anthropic zeggen het zo: "Correct Claude as soon as you notice it going off track". Waarom dat klopt, zie je in onderzoek naar hoe agents vastlopen. Failure as a Process volgde mislukte runs van coding agents op de command line in Terminal-Bench, zonder dat er een mens meekeek, en vond dat "half of all failed trajectories have already committed their decisive error by step 7, but do not become unrecoverable until around step 12, and do not produce externally observable evidence until around step 16."

Tussen stap 7 en stap 16 werkt de agent gewoon door, en het lijkt goed te gaan. In dat gat verdient Esc zich terug.

Zet een bericht in de wachtrij als het bijna goed is ​

Je hoeft de agent niet te stoppen om iets tegen hem te zeggen. Typ terwijl hij werkt en druk op Enter. De docs: "Claude Code passes it to Claude as soon as those tool calls finish, within the same turn."

Dat is milder dan Esc, en in mijn runs kostte het bij beide taken 15% meer dan de volledige opdracht. De agent maakt eerst de reeks tool calls af waar hij mee bezig is, en leest jouw bericht pas daarna. Prima als je correctie een detail is. Zit de richting fout, dan betaal je voor elke tool call die hij eerst nog afmaakt, en daarna nog een keer om die terug te draaien.

Twee toetsen maken de wachtrij handiger dan hij lijkt. Ctrl+Enter verstuurt berichten uit de wachtrij meteen. En met Up vanaf de eerste regel van het invoerveld haal je ze terug, zodat je ze kunt aanpassen voordat ze verstuurd worden.

Eén kanttekening: een bericht dat midden in een turn uit de wachtrij komt, krijgt geen eigen checkpoint. Wil je terugdraaien wat Claude daarna deed, dan ga je terug naar de prompt waarmee de turn begon.

/btw voor de vraag die geen correctie is ​

Halverwege een taak vraag je je af waarom hij voor een bepaalde library koos, of welk bestand de authenticatie regelt. Stel je die vraag in het gesprek zelf, dan staan vraag en antwoord de rest van de sessie in de context.

Daar is /btw voor. De docs: "Use /btw to ask a question about your current work without adding to the conversation history." Een /btw-vraag ziet alles wat er tot dan toe gebeurd is, heeft geen tools en draait terwijl Claude doorwerkt. Heeft het antwoord toch tools nodig, druk dan op f om de vraag af te splitsen naar een subagent op de achtergrond.

Wanneer je stopt met corrigeren en opnieuw begint ​

Bijsturen heeft een grens. Elke correctie laat de mislukte poging in de context staan, en modellen maken vaker fouten als hun eigen eerdere fouten nog in beeld zijn. De best practices van Anthropic trekken die grens zo: "If you've corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches."

Dan heb je twee uitwegen. Met Esc Esc open je het rewind-menu, ga je terug naar de prompt van voor de omweg en stuur je hem opnieuw met wat je nu weet. Of je maakt de sessie leeg en begint met een opdracht waar de correctie al in staat. Dat was in mijn experiment de goedkoopste route, of gedeeld de goedkoopste.

Bijsturen is het vak ​

Anthropic onderzocht zo'n 400.000 Claude Code-sessies voor het rapport van juni over expertise en agentic coding. Een van de conclusies: "Part of the value of expertise appears to be the ability to steer the agent in the right direction." Bij gebruikers die Anthropic als beginner inschatte, werd 19% van de sessies opgegeven, tegen 5 tot 7% bij alle anderen.

Ervaren gebruikers onderbreken ook vaker. Een eerdere studie van Anthropic zag nieuwe gebruikers in 5% van de turns ingrijpen en ervaren gebruikers in ongeveer 9%. Ze zien wanneer een turn duur dreigt te worden, en zeggen het terwijl het nog goedkoop is.

Meer is bijsturen niet. De agent komt er hoe dan ook. Jij bepaalt hoeveel van de route je twee keer betaalt.