How I Work with Coding Agents
Rules files, plans, tiered models, review, evals and spend caps: how I direct coding agents, and what I still check myself.
Most of the code in my 2026 projects was written by coding agents. I’d rather say that up front than let you guess. What I do is set the design, write down the constraints, split the work, review the result and decide what ships. This post is what that looks like day to day, and where I think the real work is.
The tools are Claude Code, Codex and OpenCode. The case studies on this site are the evidence: Pricehound, the listing screening eval, the Meta MCP server and Paret were all built this way.
Every project has a rules file
Each repo carries a CLAUDE.md. It tells the agent where to start, which commands to run, and what it must never do. Pricehound’s says to read the task list and the last progress entry first, and has a list of nevers that includes “never present a recommendation without its sources”. Paret’s says never to commit real financial data.
Rules get added when something goes wrong. The Mission Control repo (more on that below) opens its command section with: always unset TMUX first, because a test once killed every tmux session on the host. That line exists because it happened.
Plans and decisions live in the repo
The agent doesn’t get a vague request. Larger changes start as a written plan in docs/, and the repos keep a task list, a progress log and a decisions log. At the end of each task the agent has to tick the task, add a dated progress entry saying what was verified, and record any new decision. When I come back a week later, or a fresh agent does, the reasoning is still there.
Cheap models do the typing, a stronger one reviews
My default model is Opus at a high reasoning effort. For a big change I split the work into pieces that own separate files, have Sonnet subagents implement them in parallel, and then have Opus review the combined result. I’ve asked for exactly that in sessions: implement with Sonnet subagents, review with Opus.
The same instinct applies to the models inside the apps I build. Pricehound, Paret and the listing screening all default to a small, cheap model, and use a larger one only where it earns it.
Checking, not trusting
An agent will tell you it’s done. I want something that isn’t the agent saying so.
- Tests and CI. I don’t call something deployed until the CI run for the push has passed. There’s a skill for that.
- Evals when the question is quality. The screening tool has a script that replays a saved day of data and counts how many known good items reach the shortlist. That’s how I know the cheaper reasoning setting missed a deal once, and why I didn’t take the saving.
- Checks in code. In Pricehound, a model’s quotes are verified against the page text, and in Paret every amount has to appear in the source file. The model proposes, code decides.
Skills and hooks
Skills are short instruction files the agent loads when a situation comes up. Several of mine are written around one specific failure: one fires when a port is busy or before a pkill, one covers a scratch Node script that can’t find its packages, one covers waiting for CI after a push. There are also ones for the Cloudflare CLI and for Coolify, so the agent uses the right tool instead of guessing at commands.
Hooks are fewer and plainer. One reminds the agent to load the UI design skill before it edits a UI file for the first time in a session. Another logs every web search and browser call so a router can pick providers and stay inside budgets.
Money has ceilings
My apps use separate model keys, and the monthly spend limits on the model provider’s workspaces are mirrored in Mission Control. Inside the apps, Pricehound stops at a daily cap (one dollar by default) and Paret has separate caps for daily use, statement imports and the weekly review. A bug in a loop then costs a capped amount, not a surprise.
Mission Control
I built a small web console for all this: Mission Control. It lists the agent sessions running on my server, restarts them with recovery, and shows projects, their AI keys and spend, scheduled jobs, disks and logs. It’s plain Node with no framework, one module per concern with a test file next to it. It sits behind a login, so there’s no link. Building it with the same method taught me what that method needs: small modules, a test per module, and a rules file that records every lesson.
What I don’t claim
The work is recent, and most of it has one user: me. I have no usage numbers. Only some of it has a proper eval, and where I have results I’ve put them next to their limits. The agents are fast and sometimes wrong in small ways, so the value I add is the part before they start and the part after they stop.