4,182 karma · joined July 11, 2010
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.
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.
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.
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.
To enable it, run /config > output styles > Learning
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
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
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.