Claude Code needs less steering, but unattended work needs stronger checks

Lydia Hallie, who works on Claude Code at Anthropic, says stronger models have changed how her team works: they can take on longer tasks, understand a codebase and verify more of their own output. Practices built around frequent intervention should be reconsidered as capabilities change.

Earlier sessions needed more steering: people repeatedly corrected the model, emphasized instructions in CLAUDE.md and approved commands individually, or used the riskier option of skipping permissions. Hallie contrasts that with Anthropic sessions that run for hours, sometimes in dozens of parallel threads, including sessions that orchestrate others.

Hallie says Anthropic reported growth from about 2,500 changes a day in May to more than 30,000 in September. As people step out of individual steps, she argues, the model, its execution harness or the environment must take over steering, approval and verification.

Her example updates an older model and manual-approval setup to Opus 5.5 and auto mode. She says the newer model needs less mid-session steering and recommends revisiting emphatic instructions such as repeated warnings in CLAUDE.md, which she says can cause extra tool calls or worse results.

Hallie recommends retaining information Claude cannot infer from the code, such as a legacy dependency that is not directly referenced. She describes a doctor prompt-audit command that checks project instructions and skills for material a newer model may no longer need.

Hallie describes auto mode as using a separate classifier for most actions beyond reading or editing project files. It can allow routine commands and block uncertain ones. In her example, a push to a separate staging deployment repository is blocked because the default trust scope covers only the current folder and repository.

If auto mode prompts too often, Hallie says its settings can state trusted repositories, buckets and domains in plain language, including actions to always allow or never permit. Those instructions inform the classifier; she distinguishes this configuration from stronger enforcement later in the talk.

A classifier is not a guarantee. Hallie cites an Anthropic study in which about 14% of people caught a clearly dangerous command and auto mode blocked 89%; about one in ten such commands still passed. She presents harness-level restrictions as the place to enforce rules that must hold.

A deny rule is checked before the auto-mode classifier, she says; a matching tool call never reaches that classifier. Her test for what deserves a rule is whether a single mistake can be reversed: an ordinary code change may be reverted, while loss of uncommitted work or exposure of a secret can be harder to undo.

For instance, she suggests denying reads of an environment file when its contents must not enter the session. But a permitted command can have indirect effects: an ordinary npm test may execute dependencies or scripts that read private files and contact an external server. Tool-call permission alone does not constrain everything that runs afterward.

A sandbox limits what shell commands and their child processes can read, write and reach, with the operating system enforcing the boundary. Hallie says the relevant deny rule can be passed to the sandbox so that even a dependency cannot open the protected environment file. She notes that most of the machine remains readable by default, so other sensitive paths need their own restrictions.

The sandbox described covers shell commands and their children, not Claude's own file operations, MCP servers or hooks. Hallie therefore recommends considering a cloud session with a fresh repository copy on its own machine: local environment files, SSH keys and tokens are absent if they are not in the repository.

If a cloud session needs an API key, Hallie describes using a network secret so the session can use it without exposing it to the model. She says network access is restricted by default to approved services such as package registries and GitHub, with other domains explicitly configured.

A disposable machine does not undo actions that leave it: a pushed commit or message sent through a connector persists. Hallie therefore still uses auto mode and committed deny rules in cloud sessions, for example to guard against force pushes or secrets entering commits.

Long unattended sessions also need verification. Hallie gives an authentication API migration as an example: a model might leave the old API in place, migrate only new logins or log everyone out. Each can appear plausible unless the desired outcomes are checked.

She suggests explicit pass-or-fail checkpoints such as tests and builds, as well as screenshots, and reviewing those results rather than relying on a final impression. The prompt can define what done means, ask for subtasks with tests and request actual output, but prompting alone does not guarantee the checks will run.

For checks that must run, Hallie recommends hooks: scripts invoked at specified points. Her examples run a linter after an edit, relevant tests before a task is marked complete and the full suite before the session finishes. If a check fails, the agent can try another fix.

Hallie cautions that, in her described hook setup, an exit code of 1 does not prevent the task from being marked complete, while exit code 2 sends Claude back to address the issue. She advises designing hook scripts accordingly.

Separate cloud machines allow several sessions to run without sharing the same working folder. Starting and reviewing each session manually can still be a useful level of control; Hallie does not suggest that every team must immediately automate those decisions.

CI provides consistent checks for every pull request regardless of how its originating session ran. Hallie describes an autofix capability that lets Claude respond to failed checks and says merge-when-ready can be enabled for suitable changes; she emphasizes that automatic merging is not the default and depends on risk.

Her team uses a separate Claude review with fresh context rather than the writing session, plus other agents to double-check identified bugs. She says their human review varies by risk: small documentation or copy changes may need no person, ordinary product changes one reviewer and riskier changes two.

Hallie describes an orchestrator session that breaks a larger request into tasks, starts separate sessions, tracks results and sends incomplete work back. She points to Claude Code projects, described as beta, as an example: a user communicates with one coordinating session instead of managing each worker individually.

The coordinating session can use a model chosen for planning and judging results, while worker sessions use a model suited to implementation. Hallie says the project setup also manages context automatically, reducing the need to decide when to compact or clear it.

Her conclusion is that earlier responsibilities have moved rather than disappeared: the model steers work, auto mode handles approvals, deny rules and environments restrict actions, and tests, hooks and CI check results. She recommends trying a larger task after configuring CI, network access, secrets and setup scripts, then observing where the session still needs intervention.