I’ve been doing a fair bit of coding lately with Claude. Mainly automating investment analyst work, the kind of repetitive, structured analysis that eats hours and where consistency matters more than creativity.
That shift from “using AI to get answers” to “using AI to build tools that do the work” is what agentic engineering means in practice. Getting the setup right changes everything about how productive that loop actually is.
Here’s what works.
Switch to Claude Code First — Everything Else Is Secondary
If you’re building anything with continuity on a codebase — returning to it, iterating on it, extending it — Claude Code gives you a step-change in capability over the standard chat interface. It maintains context across a session in a way that makes agentic work feel like working with a capable junior engineer rather than resetting a conversation every twenty minutes.
Everything else in this post assumes you’re working in Claude Code.
The Vanilla Loop Is Good Enough More Often Than You Think
Since Opus 4.6 dropped, I’ve actually pulled back on many of the MCP servers and additional skills I’d accumulated. The basic loop of plan → execute → review has been sufficient for most work. There’s a tendency when you get into this space to over-engineer the setup before you’ve found where the real friction is. Start with the vanilla loop, identify where it breaks down, then add tooling to solve that specific problem.
The Skills and Resources Worth Adding
When the vanilla loop isn’t enough, there are two main sources worth knowing.
Superpowers is a well-regarded open-source collection of .md files that improve Claude’s behaviour across the full development lifecycle. Requirements, architecture, coding, testing. If you want an all-in-one starting point, begin here.
Skills.sh lets you go more specific. I sprinkle in targeted skills depending on the project’s tech stack. The ones worth adding:
- Writing plans — for chunkier product requirements documents:
skills.sh/obra/superpowers/writing-plans - Architecture patterns — useful on greenfields projects, less so when retrofitting patterns onto an existing codebase:
skills.sh/wshobson/agents/architecture-patterns - Systematic debugging:
skills.sh/obra/superpowers/systematic-debugging - Test-driven development:
skills.sh/obra/superpowers/test-driven-development
Give Claude the Ability to Self-Verify
Set up a browser MCP server, either Playwright or Chrome, so Claude can navigate to the running application, take a screenshot, analyse the UI, and make code adjustments based on what it actually sees. The model is no longer working blind. It can verify its own output against reality.
The principle generalises: wherever you can give Claude a feedback loop. A way for it to check that what it produced actually works, when done the output quality improves materially.
Four Operational Habits That Make the Difference
Contextualise the codebase upfront. Maintain a claude.md file that references a product.md, which gives Claude the context it needs to understand what it’s working in. Do this once and it saves significant re-prompting across every session. Great care should be taken in building and maintaining this file. It is loaded every session. If it gets long that is a hidden token cost.
Review on-disk, not in-session. When asking Claude to review something, you get better results if it reviews a file on disk rather than content within the active session. A subtle distinction that turns out to matter. On disk, claude can run a verification, carring out a tool driven test.
Use hooks for anything that must happen. If there’s an action you want Claude to reliably take — running tests, linting — use hooks rather than relying on prompt instructions. Instructions get treated as suggestions. Hooks get treated as requirements.
Run /compact at 50–70% context usage. Claude pays better attention to goals and manages token usage more efficiently when you compact before the context window fills. Don’t wait until you’re at the limit.
Model Selection Matters for the Type of Work
Opus at high or maximum effort for planning. The cost is worth it at this stage, the quality of the plan shapes everything downstream.
Sonnet for execution, with the caveat that this depends on the complexity of the plan. If the plan is intricate, execution warrants a more capable model.
Haiku limited use. It’s blazingly fast, but Sonnet’s accuracy advantage is worth the marginal time cost in most practical cases. Reserve Haiku for high-volume, low-stakes tasks where speed is the primary constraint.
The underlying logic: don’t optimise for cost at the planning stage. Optimise for getting the plan right.
Where to Start
If you’re new to agentic engineering and want a working setup without over-investing
upfront:
- Switch to Claude Code
- Set up a
claude.mdfile that describes the project and codebase - Add the Superpowers collection as a baseline
- Set up self-verification, add browser automation and alter
claude.mdor hooks to trigger verification - Work the vanilla plan → execute → review loop, and identify your actual friction points before adding more
The tendency in this space is to build an elaborate setup before you understand what you actually need. Resist that. Start with what works and add specificity where the loop breaks down. And when it breaks, don’t solve the problem directly, but improve the loop.
I’m actively building internal tooling using this setup, primarily to automate investment analyst work at Terem Capital. If you’re working on something similar, or building AI-native tooling into a B2B SaaS product, I’d be interested to compare
notes. Get in touch.