- Book: Observability for LLM Applications
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
You type the task, press Enter and switch to another tab. The agent has the repo, a permission mode that rarely asks, and a goal. Twenty minutes later you come back to a finished turn and a diff that touches files you never mentioned, built on a reading of the task you would have rejected in one sentence.
That habit feels like the whole point of an agent. Anthropic's own Claude Code best-practices guide says close to the opposite. Its section on managing a session is titled "Course-correct early and often", and the advice is to "Correct Claude as soon as you notice it going off track." It adds: "Though Claude occasionally solves problems perfectly on the first attempt, correcting it quickly generally produces better solutions faster."
Here is my take, and it is an opinion. The most valuable moment in an agent run is the first couple of minutes, when it reads files, states a plan and makes its first edit. A "fully autonomous" run with no spec and no check behind it mostly postpones that correction to the point where it costs the most.
What the vendors tell you to do
The guide is specific about the keys. Esc stops Claude mid-action, and "Context is preserved, so you can redirect." Pressing Esc twice, or running /rewind, opens a menu to "restore previous conversation and code state." It also sets a limit on nudging: "If you've corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches. Run /clear and start fresh with a more specific prompt that incorporates what you learned."
The other half is asking for a plan before any code. The guide recommends four phases (explore, plan, implement, commit) and uses plan mode for the first two, where Claude "reads files and answers questions without making changes." You can open the plan in your editor and change it before a line is written.
# Claude Code
claude --permission-mode plan # read and plan, no edits
Shift+Tab # cycle into plan mode
Ctrl+G # edit the plan in your editor
Esc # stop mid-action, keep context
Esc Esc or /rewind # restore conversation and code
/clear # after two failed corrections
Codex CLI has its own set. /plan asks Codex to "propose an execution plan before implementation work starts." While it works, pressing Enter will "inject new instructions into the current turn", and Tab queues a prompt for the next turn. Pressing Escape twice on an empty composer lets you "edit the previous user message and fork the chat from that point."
# Codex CLI
/plan <prompt> # plan before implementation
Enter (while working) # steer the current turn
Tab (while working) # queue for the next turn
Esc Esc (empty input) # edit last message, fork from it
Two vendors both shipped keys for redirecting a run that is still going. They expect you to use them.
Why a wrong turn costs more with every turn
Three things grow while you are in the other tab.
The context grows. The guide says "LLM performance degrades as context fills," and that a full window can leave Claude "forgetting" earlier instructions. A run that spent fifteen minutes on the wrong approach has filled its context with that approach. Your correction lands on top of it, which is the "cluttered with failed approaches" state the guide tells you to escape with /clear. Correct it in minute two and there is little to clear.
The diff grows. A short run hands you a small change you can read. A long one hands you a big one, and big diffs are where review falls apart. Atlassian, summarising a Cisco code-review study, writes that reviewing more than 400 lines "can have an adverse impact on your ability to find bugs" and that "most are found in the first 200 lines." That study looked at human-written code. Your attention span doesn't change because a model wrote the lines.
The cost of undoing grows. Rewinding is cheap only for some changes. The guide warns that checkpoints "only track changes made through Claude's file editing tools. Changes made through Bash commands or external processes are not captured." Twenty minutes in, the agent may have installed packages, generated files or run a migration, and a rewind restores none of that.
Anthropic made the general point in December 2024. Its Building effective agents post warns that "The autonomous nature of agents means higher costs, and the potential for compounding errors," and describes agents that "pause for human feedback at checkpoints or when encountering blockers."
The fair case for walking away
The same guide also says when you can leave, and it is worth taking seriously. "Give Claude a check it can run: tests, a build, a screenshot to compare. It's the difference between a session you watch and one you walk away from." On specs it goes further: "Time spent making the spec precise pays off more than time spent watching the implementation."
I agree with both. A precise spec and a check that returns pass or fail are what make an unattended run safe. The check closes the loop that you would otherwise close by reading.
Most quick prompts have neither. "Clean up the auth module" comes with no spec and no test that knows what clean means. Defaults are also moving toward fewer interruptions. With Claude Code v2.1.283 or later, the guide says auto mode is the built-in starting permission mode for interactive terminal and VS Code sessions, with a classifier reviewing most actions instead of you. That is good for flow. It also means the agent stops to ask you less often, so looking at it is now something you have to decide to do.
Walking away is earned by a spec and a check. Without them, an autonomous run is a review you have postponed.
The two-minute habit
In practice, with the keys above:
- For anything that touches several files, start in plan mode and read the plan. The guide's own rule of thumb: "If you could describe the diff in one sentence, skip the plan."
- Edit the plan before you approve it. A wrong assumption in a plan costs a sentence to fix.
- Watch the first few tool calls. Which files does it open? Is it searching where the bug actually lives?
- Press
Escon the first wrong file, not the fifth. In Codex, type the correction and press Enter to steer the turn. - If you've corrected the same thing twice, run
/clearand rewrite the prompt with what you learned. - Once the direction is right and a check exists, switch tabs.
The keys already ship in both CLIs. The habit is counting the start of a run as part of the work.
Where Hermes IDE fits
I build Hermes IDE, so weigh this section with that in mind. The habit above is easy with one agent. With three running in parallel, you can't watch three starts while also checking whether the other two are stuck on a prompt.
Hermes IDE runs each agent (Claude Code, Codex or another CLI agent) in its own real terminal, so Esc, /rewind and Codex's Enter-to-steer work exactly as they do anywhere else. Around those terminals, every session shows one status: working, needs approval, asked you, done, error or idle, and it says when that status is a guess.
The attention inbox counts the agents blocked on you, and ⌘I (Ctrl+Shift+I on Windows and Linux) jumps to the one that has waited longest. That is how you catch an agent waiting on you in its second minute instead of its twentieth. Notifications fire when an agent is blocked or done but skip the session you are already looking at, and Hermes never answers a permission prompt for you or types into a terminal on its own.
Codex and Claude Code side by side, each in its own hermes/ worktree, with the sidebar showing each session's status, context use, cost and branch.
Since 2.3.4, the bar above each session keeps Model, Plan and Review in the same place for every agent, and a command you click only runs when the agent is waiting.
Under the session, an "Agent replies" strip shows each reply with the lines it added and removed, so a first reply that already rewrote half a module stands out. Click a reply to see its changes or restore your files to that point.
The bar above a Claude Code session: Prompts, Context, Model, Plan and Review, with the Commands list open.
Hermes can't tell you that a working agent is heading the wrong way. "Working" looks the same whether the agent is right or wrong, and only you can judge the direction. What the status and the inbox buy you is attention: you stop polling the agents that are fine and spend your two minutes on the one that just started.
Hermes is free to download, source-available under BSL 1.1, and runs on macOS, Windows and Linux. It isn't affiliated with Anthropic, OpenAI or any agent vendor. Download it or read the code on GitHub.
So when do you press Esc? On the first wrong file, or do you let the run finish and review the whole thing? Tell me in the comments.
If this was useful
Watching the first turns of an agent is the same discipline as reading traces when an LLM feature runs in production: catch the drift early, then let an eval or a check decide when you can stop looking. Observability for LLM Applications is my book on that side of the work, covering tracing, evals, cost and quality regressions once your LLM features ship.
Top comments (0)