After watching Anthropic's recent postmortem (anthropic.com/engineering/april-23-postmortem), I've been thinking about the way I approach Claude Code differently. They lowered default reasoning effort to fix latency, called it the wrong tradeoff, and reverted under public scrutiny. The reverts are good but they don't change the underlying equation I'd been ignoring.

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.