What I changed in how I use Claude Code after Anthropic's postmortem
9 comments
You have good approaches.
I created a slash commands that I run, and explicitly wrote to be executed with Sonnet. I also compact manually, and try to keep the session short.
But let's look at the big picture. When using a tool, it must make our lives easier and more convenient. To stop troubling our minds with redundant things. Our focus must be on the product and its quality, and features, and don't waste energy on things outside the scope. What's the point of using a product that pushes us to think about redundant things.
The whole point of using Claude Code just disappeared. I am thinking more on tokens, limits, and optimizations, making compromises on the tasks, rather than product vision and requirements.
And this is a pity. Total waste of time and energy
But let's look at the big picture. When using a tool, it must make our lives easier and more convenient. To stop troubling our minds with redundant things. Our focus must be on the product and its quality, and features, and don't waste energy on things outside the scope. What's the point of using a product that pushes us to think about redundant things.
The whole point of using Claude Code just disappeared. I am thinking more on tokens, limits, and optimizations, making compromises on the tasks, rather than product vision and requirements.
And this is a pity. Total waste of time and energy
but if you put into perspective what it would cost you a month for a graduate's salary - and you compare that to the max plan - the value for money is still astronomically incomparable
Do “moats” still matter in modern tech?
[deleted]
The fact is we potentially have a team of engineers at our disposal now. Token cost is a real cost, but I couldn't hire my own engineer for any of the personal work I'm doing. Apply that lens to token usage and the approach shifts. It stops being about the cost ceiling and becomes a cost/output/quality view, the same way I'd think about hiring decisions on a real team.
Four places I now think about: model, configuration, prompting, agents.
On model. Opus is still the strongest for critical decisions and architectural reasoning. Sonnet is usually good enough for coding and simple repetitive tasks. I use the right model for the work. If I cheap out, I can't expect quality.
On configuration. /effort runs from low to max. Opus 4.7's default is xhigh. I set the level to fit the work. A quick edit doesn't need max, an architectural decision does. The cheapest move and the one I'd been skipping.
On prompting: three patterns I find most effective.
1. "Ask questions if unsure." Without this I'm not giving the model an out, which closes off solutions even when there's no clean answer and tradeoffs need to be surfaced.
2. "Time and cost are not factors here. Prefer robust, sustainable, scalable solutions, do not leave tech debt." This inverts the implicit optimisation pressure for the duration of the task.
3. "Reflect on this session and encode via claude.md or skills what you learned, so the next iteration doesn't repeat the same mistakes." Worth capturing as a skill and iterating for myself. Without this every session starts from zero, repeating mistakes I've already corrected.
On agents. Without going into detail as this is a whole post in itself, the pattern that works for me is using agents to separate concerns. One agent does spec review against the code (code is source of truth). A separate agent does code review after implementation.
Engineering and product teams have always balanced speed to market with cost and quality. AI is no different. The difference is which levers I choose. Spend the budget on effort deliberately, and the work comes back at the level I want.