Don’t hesitate to build your own tool or even a whole program for a single operation. For a woodworker this is a fairly common situation. When there is no tool at hand that fits the job exactly, they make one. A one-off tool improves the precision and elegance of the solution. With an agent, it takes minutes.

For inspiration, here is the “Playground” skill: https://github.com/anthropics/claude-plugins-official/tree/main/plugins/playground and an elegant demonstration of building a one-off tool (the author is a designer, not a developer): https://www.youtube.com/watch?v=lkKGQVHrXzE&t=2172s

Before the agent writes a plan or a spec, let it interview you. Matt Pocock calls this grilling. The AI will happily ask you 30 questions, to the point where it gets a bit uncomfortable. But that is the point, fill in all the gaps and replace the agent’s hidden decisions with your own.

For me this works better than reading through a lengthy spec the agent generated from a thin brief. A side product is a shared vocabulary for more efficient communication, and a record of the important decisions.

Details and a concrete skill here: https://www.aihero.dev/skills-grill-me

Out of the box Claude Code can do more than I need day to day, and every tool and feature costs tokens right at startup. In settings.json I limited what I rarely use and dropped about a third of the system prompt and built-in tools. The difference between models is even bigger. With optimized Opus 5.5 I start a session at 8k tokens, with unoptimized Sonnet 5 at 25k. Comparison: https://html.lukastrumm.com/claude-context-compare/

The saved context lets you stay in the “smart zone” longer, making better use of the model’s own intelligence. Any feature can be turned back on for a single session when needed. Here is each setting I limited and why: https://github.com/lttr/dotfiles/blob/master/claude/README.md

You still need to review code, but these days it often makes more sense to look at it from a higher level. And when you spot something, you want to give the agent targeted feedback right in the context of that code.

You can get the higher-level view by grouping the changes into distinct areas. Try it on any GitHub PR with a tool by Anthony Fu: https://pulls.review

The feedback part is a review tool you start right from an interactive session with the agent, which then hands your comments back to it. Matteo Collina built such a tool: https://githuman.dev I tried to build my own that combines both ideas and adds a bit more. It turned out not to be that hard: https://github.com/lttr/git-history-viewer

If some simplification is welcome, or necessary because of the amount of changes you have to take in, it can help to have an HTML overview generated. Simon Willison described the approach: https://simonwillison.net/guides/agentic-engineering-patterns/linear-walkthroughs/