bcherny

Hey, Boris from the team here. This is pretty surprising, given background subagents are the default. Could you confirm you’re running the latest, and run /bug and paste the id here? Happy to debug what’s happening

Interesting, I don’t see this very often with the latest models. Are you using Opus 5.5/Fable 5.1?

Either way, plan mode isn’t going away. You can always /plan or ask Claude to enter plan mode. We might re-map the shift+tab keyboard shortcut to something else by default for people that don’t use plan mode.

[I work on Claude Code] I broadly agree with the author’s point: plan mode was useful, and is no longer useful.

In Claude Code, all plan mode does is add a little reminder to every user message along the lines of “you’re in plan mode, please don’t code yet”. It’s something I came up with late on a Sunday night many months ago, when I got tired of asking Claude to plan with me first before coding in each new session. Something people might not realize is plan mode has always been a prompt — it has never changed the toolset because doing so would break the prompt cache, and so would be expensive for users.

This worked well for a while, until a few months ago, using early versions of Fable, I realized that I wasn’t using plan mode anymore because the model just got it, and because for the increasingly complex work I asked the model to do, planning had become interactive and iterative. With Opus 5.5, I feel Opus has gotten to that point too.

For codebase understanding, I sometimes ask Claude to generate an artifact that explains some aspect of its changes. For complex diffs to core parts of the system, I will often ask it to make diagrams or even interactive demos so I can better understand the change and alternatives considered. I don’t do this very often, but it’s a useful way to explain code when you need it. I ask Claude to attach these artifacts to its PRs also, so others can understand and future Claudes have the context.

I always use /focus mode, Tag, or Projects, so didn’t notice it personally. Either way, digging in.

Fairly often, yeah. Sometimes it is too easy to get excited about a solution without taking the time to specify a clear problem/goal.

Looking

Author here. This isn’t the one true framework, but it is the one I use. The goal of this post was to communicate to the team the way I think. There are many ways to think and there isn’t one that is more correct than others.

The word “feedback” might be overloaded here also — if you haven’t worked in a culture where feedback is an honest, no-blame part of the culture, then I can see how the idea of giving feedback can feel like a disingenuous corp-speak way to make a person fall in line or have their career impacted. There’s also an inherent power dynamic in giving feedback. However, if the work culture celebrates feedback as an honest way to have more direct conversations, and makes coworkers feel psychologically safe talking to one another directly in this way, it is something that makes culture better for everyone and gives better results in the end. I have given feedback to many people, and I have received it in turn many times.

Also, I am an IC, not a manager.

Author here. How can I repro what you’re seeing? Double check you don’t have /focus mode enabled.

Author here. These are unrelated, just happened to both be the same week.

(I work at Anthropic) I agree. I use an LLM to write my code, but I do all of my writing by hand, since it helps me think.

It reminds me of the transition over the last year from AI-assisted coding to AI doing all the coding. At first the code output wasn't good enough, and humans read and iterated on the code all day, so the details of the source code mattered. Now, the code is largely high quality and it meets a large set of guardrails we've set up over the years (linters, typecheckers, security checks, LLM-assisted code quality checkers), and it's just Claude working on the code, so the details matter less and engineers think a level or two up (machine code < assembly/bytecode < source code < conversation with agent < artifact with high level design).

I wonder if long form writing will go the way of code. You and the AI agree on an outline or other high level representation, then the LLM expands it into a document. But writing and coding are different enough in a number of ways that this is far from inevitable.

Boris from the team here -- I don't think this is right. If you are able to repro in the Desktop app, could you comment back? I cannot repro.

Boris from the team here. The classifier is free — we do not charge for safety features as a principle.

Boris from the team here — we’re looking into it.

For those using Claude Code, I recommend Learning mode to instruct Claude to walk you through implementing the solution yourself rather than doing it for you. It’s very helpful when diving into a new domain, and helps build lower level intuition.

To enable it, run /config > output styles > Learning

Yep! Set disableWorkflows:true in your settings.json

Looking

Typo! Edited

Yes!

Yes, it also helps! That's a place where raw model capability is the most helpful, but we do find that some dynamic workflow configurations can be helpful too.

There's two main differences:

1. Support for 1-2 OOMs more agents, to do more work in parallel

2. A phased, semi-structured approach where work happens in steps

JavaScript, running locally or in the cloud.

Yes, more docs + technical details coming soon.

We generally build features into the Claude Agent SDK, which is shared by CLI, Desktop, VSCode, and cloud.

Hey, yep. A few things I personally used dynamic workflows for over the last few weeks:

1. Autonomously landed 20+ optimizations to reduce Claude Code's token usage by ~15%

2. Ported tree-sitter, color-diff, yoga-layout, and a number of other WASM and Rust native modules to TypeScript, improving CPU and memory use by 2-10x in the process

3. Made our CI faster, and repeatedly found and fixed flaky tests (with /loop)

4. Migrated from regex-based bash static analysis to tree-sitter, reducing false positive permission prompts by 45%

5. Reduced Claude Agent SDK startup time by 61%, by repeatedly profiling and optimizing the startup path, putting up a number of PRs in the process

6. Shipped 69 code simplification PRs, deleting >10k lines of code

A few of us from the Claude Code team will be hanging around if anyone has questions! Very excited for this launch -- dynamic workflows have been a game changer for engineering here at Anthropic. Can't wait to hear what you think.

Totally. You can do that now, and Claude will know to use /code-review.

Yep, you can add free-form input. Will update /simplify to only check for code quality and not bugs (the way it used to work), that's a good suggestion.

/code-review has a specific prompt that we've found is a good balance of precision, recall, and cost. You could totally roll your own prompt also.

Hey, Boris from the CC team here. I agree, we're working on consolidating these. Going forward it will just be the built-in /code-review skill.

Here's how to use the skill on the latest version:

/code-review # do a balanced code review. checks for bugs and inconsistencies, poor code quality, duplication, band aids, etc.

/code-review --fix # same as above, but also fix the issues

# choose an explicit effort level (defaults to your current effort level). all of these also accept --fix:

/code-review low

/code-review medium

/code-review high

/code-review xhigh

/code-review max

# do an expensive and extremely thorough review (reliably catches >99% of bugs, costs $3-20 per review depending on complexity):

/code-review ultra

Open to feedback if anyone has feedback or ideas for how to make these even nicer to use.