How Claude Code Best Practices Are Shifting From Supervision to Systems

Lydia Hallie introduced herself as a member of the Claude Code team at Anthropic and opened with the observation that "the models have gotten really good lately." She named Opus 5.5 as her favorite daily driver and said that Fable 5.2 had launched earlier that same week. According to her, these models are very good at long-running tasks and at understanding a codebase, and Fable in particular is good at verifying its own output.

She added that as these models improve, the way people work with them in Claude Code also changes, which set up the rest of the talk.

Hallie described how sessions looked earlier in the year. Opus 4.5 was, in her words, really good for its time, and she said she enjoyed working with it. Compared with today's models, however, it stopped much earlier and ran for shorter periods, so developers kept correcting it and reminding it to do things. Some added words such as "important" and exclamation marks to their CLAUDE.md file. Auto mode did not yet exist, so users either approved every action manually or took the riskier route of using the dangerously-skip-permissions option. In her words, people were still very much in the loop as humans.

As the models became better at bigger tasks, she said, sessions changed. At Anthropic, she said, sessions now look different: dozens of sessions run at the same time for hours, they verify their own results along the way, and some sessions orchestrate other sessions. She described the developer's role as having moved from being in the loop for almost every step, running one or a couple of sessions at a time, to acting more like a manager of dozens of sessions.

She also cited an October blog post by Anthropic in which the company said it went from about 2,500 changes a day in May to more than 30,000 a day in September. She framed this as a sign that developers have to rethink what they focus on.

Hallie said that developers now have to rethink what they focus on. Earlier best practices were mainly about steering sessions, approving commands, saying no to certain actions or restricting what Claude could do, checking the output, and starting sessions. Each place where developers step out of that loop, she said, something else has to take over, and that something is either the model, the harness, or the environment it runs in.

She posed two questions that follow from this. If people are not in the loop to approve every command while running many sessions at once, how can they ensure the code is still high quality? And if sessions run for hours without supervision, how can they ensure those sessions run safely? She said the rest of the talk would address these by taking an older session and showing what needs to change.

Hallie started with the defaults that new sessions use now, which she said developers should not need to think about much. She updated the model from Opus 4.5 to Opus 5.5 and changed the permission setting from manual approval to auto mode. She said Opus 5.5 is much better at understanding the user's intent and the codebase, so developers do not need to steer it as much mid-session. Because auto mode has been the default permission mode since August, developers no longer have to approve every command.

Because newer models understand intent better, Hallie said the instructions in a codebase also need to be reconsidered. Developers who followed earlier best practices may still have lines such as "important," "never do this," or exclamation marks in their CLAUDE.md. She said that with today's models these are unnecessary and can make the model go off track, leading to more tool calls and overall worse results.

Under her current guidance, CLAUDE.md should include only what Claude cannot see from the code. Her example was a service that still uses a legacy source somewhere but is not directly referenced in the code; that should stay. Information such as which stack the project uses or where to look is no longer needed. She mentioned a command called doctor prompt audit, which checks CLAUDE.md and skills for what a new model no longer needs, and said it makes it easy to optimize an environment for a specific model.

Hallie explained that auto mode is a permission mode that runs a separate classifier on nearly every action except reading or editing files within the project. It automatically allows commands it knows are safe, such as running tests or installing dependencies, and blocks commands where it is unsure whether they are safe. She said this is usually the right behavior.

Hallie gave an example in which she asks Claude to ship something to staging. A push to the deploy repo would otherwise have been approved, but by default auto mode trusts only the current folder and repository, so it blocks that command and the developer is back in the loop. If developers still have to approve many commands even in auto mode, she said, the first thing to check is the settings, where auto mode can be configured in plain English. That text is sent to the classifier, which decides whether to reject or allow certain commands. Developers can list the repositories, buckets, and domains they trust and state what should always be allowed or never done.

She summarized that by just using today's defaults, most of the in-the-loop work had already been removed: the model took over the steering and auto mode took over the approving. The harder question, she said, was how to make sure it is acceptable not to be present for each step, which led to the topics of safety and verification.

Hallie said that in most cases auto mode does what the user tells it, but that is not a guarantee. She cited a study Anthropic published in August that tested auto mode against real people in the loop. In that study, only about 14% of people caught a clearly dangerous command, while auto mode blocked 89% of them. She said auto mode is therefore much better than humans at this, but about one in ten of those commands still went through.

Her conclusion was that a real guarantee can only be enforced in the harness.

Hallie said that older best practices around permissions still matter for this reason. If a project has a deny rule for a specific tool call, Claude Code checks that rule before the auto mode classifier even looks at the call. If a tool call matches a deny rule, the classifier never sees it at all. She said deny rules are therefore still the best way to ensure Claude never does something.

That raised the question of which items should become rules and which the model can be trusted with. Her test was whether, if Claude gets something wrong once, the mistake can be taken back. Wrong code can be reverted, so that can stay with the model. Discarding uncommitted changes or reading a key that then ends up in the transcript cannot be undone, so those should be rules. As an example, she said she never wants Claude reading a specific .env file. By default auto mode would approve reading it, so she would add a deny rule, which also stops commands like cat from opening the file.

Hallie said permissions are not always straightforward because some commands have side effects. Running npm test is a normal command that auto mode will run, but the script executes code the developer did not write, such as dependencies, or a quick script Claude wrote to check something. If one of those were compromised, it could open the .env file or SSH keys and send them to a server the developer has never heard of.

She added that even if humans were still approving everything, they would probably have clicked allow, since nothing about the command looks suspicious. Her point was that permissions only decide whether a tool call runs; they cannot limit what it can reach once it is running. Because running tests is part of how Claude checks its own work, she said, the answer is not to block npm test but to limit the environment it runs in.

Hallie said that when running locally or on one's own machine, commands can run in a sandbox. The sandbox gives control over which files a command can read, which folders it can write to, and which hosts it can reach, and the operating system enforces these limits. The limits also apply to everything the command starts, including child processes. The deny rule is checked by Claude before the command runs, but Claude only sees "npm test" and not which files the script ends up opening. With the sandbox on, the rule is passed down to the operating system, so when a dependency tries to open the .env file, the OS does not allow it.

She noted that by default the sandbox can still read most of the machine, so a separate rule is needed for SSH keys if the developer cares about them. It also cannot reach hosts that were not approved. However, the sandbox covers only the shell commands Claude runs and whatever those start. Claude's own files, MCP servers, and all hooks still run outside it, so the rest of the session still runs on the developer's machine. Her ideal was to run the whole thing somewhere none of that exists in the first place, which she identified as a cloud session.

Hallie described a cloud session as one that gets its own machine with a fresh copy of the repository, and that keeps running when the laptop is closed, which she said is important for longer sessions running for hours. In this setup the .env file problem goes away, because the file is not in git. SSH keys and GitHub tokens are also not on the machine. If the session still needs an API key, it can be added as a network secret; the session will flag mid-session that an API key is missing, and it can use the key without the key ever being sent to the model.

By default, network access in a cloud session is limited to things like package registries and GitHub. Other hosts must be explicitly added to the environment.

Hallie said that with a cloud session, long-running sessions can keep going with the laptop closed and remain safe because they run in their own environment. She cautioned, however, that the machine is disposable but the things that leave it are not. Examples are a commit that is pushed or a message sent through a connector. She said she still runs the session in auto mode with deny rules, and that commits go into the repository so they carry over, which means checks can catch things like a force push or a secret included in a commit.

Hallie said that beyond safety, developers also need to make sure Claude is working on the right thing. In the loop, people knew the work was good because they had already seen every change and approved it. Now Claude works for hours in the background, and developers are not going to read every file at the end either.

She illustrated with a task of moving code to a new API. Claude is good at understanding what is wanted, but it still makes many small decisions. With the exact same prompt, one run might move the code and leave the old API in place, another might move it only for new logins, and another might move it but log everyone out. All of these look reasonable, which is why she said it helps to set verification points along the way. Anything that returns a pass or fail counts, such as tests, a build, or a screenshot. Reviewing those checkpoints is much shorter than reviewing the whole change at the end. In her example, the version that logs everyone out fails the first check and has to find another way.

Hallie said the easiest way to set up verification is in the prompt: state what done looks like, ask Claude to split the work into tasks with their own tests, and ask it to show the actual output, since the developer was not there to see it. She stressed, however, that prompting is not a guarantee a model will do it. For checks that must run, she recommended hooks, which are scripts Claude Code runs at a specific point. Hooks give control because the developer decides when they run, what they run, and what they check.

Her example: every time Claude edits a file, run the linter; every time it marks a task complete, run the tests for what it changed, so if it touched auth code it has to pass the auth tests; and when the whole session is finished, run the entire test suite. If a check fails, Claude goes back and fixes the problem until it passes. She added a caveat: when a test fails, most tools exit with exit code one, but Claude Code marks the task completed anyway with exit code one. Scripts therefore need to exit with code two so that Claude is actually sent back to fix the problem.

Hallie said that once she is comfortable leaving one session alone, she can start a few more, because each now has its own machine. They are not all working in the same folder, and developers no longer have to think much about git worktrees themselves. She still starts every session herself and reviews every one. She described that as already a pretty good place: people remain fully in control of what starts and when a task is called done, but they are still the ones kicking off each session and remain in the loop for all of them.

Hallie said that the most important thing to have in place now is CI, because every session eventually opens a pull request, and CI runs the same checks on each one regardless of how the session was set up or what Claude decided along the way. If CI autofix is turned on, Claude can also see when one of those checks fails and go back to fix it, so developers are not spending review time on things a check could already have caught.

For some changes, she said, merge-when-ready can be enabled, so GitHub merges a pull request once all checks pass and no one has to review it. She noted this is not the default and depends on how risky the change is. On her team, every pull request is first reviewed by Claude, and not by the session that wrote it. That review comes with a fresh context and a separate group of agents that double-check each bug it finds. How much people review on top depends on risk: small changes such as documentation copy do not need a person once automated checks are green, ordinary product changes may need one reviewer, and risky changes might need two.

Hallie said that where things are going, and what Anthropic is already doing more of, is that developers do not start all the sessions themselves. She admitted that she is terrible at keeping track of many threads. Instead, one main session acts as the orchestrator: the developer tells it what needs doing, it splits the work, starts another session for each task, and keeps track of what comes back. If something returns that is not actually done, it sends it back until the work is done and passes everything. The orchestrator needs a model good at deciding and judging results, such as Fable, while the worker threads need a model good at doing the work, such as Opus 5.5, and the two can be set separately. She added that with code projects, context management is now automatic, so there is no need to think about when to compact or clear.

Her summary was that the old best practices are all still there but have moved: the model now steers, auto mode approves within the deny rules, and the environment restricts what is possible; tests, hooks, and CI check the work; and Claude can start the sessions too. People are now mostly there to start the first one and review what comes out. Her suggested first step was to pick one task much bigger than usual, make sure CI catches what matters, configure the environment's network access, secrets, and setup scripts, start it in the cloud, and see where sessions still get stuck and where the developer is still in the loop, since that is the next thing to hand over to Claude. She also recommended the best-practices documentation.