I steer. The agents do the typing.
I guide, Claude learns and understands, and we iterate on a written plan together. That is where most of the work happens. Then it implements, and we validate the result together.
LearnClaude
It reads the repo, the docs and the current state, and comes back with facts and where each one came from. No edits, no guessing.
UnderstandClaude + me
It tells me how it read the request and asks what the code cannot answer: scope, trade-offs, what “done” means. I answer. Nothing moves on while a question is open.
Plan, togetherwhere the bulk of the work is
We iterate on a plan written in plain language: the batches, the decisions, and the scenarios that will prove it works. I read it, push back, change it. Nothing gets built until I approve that exact version.
ImplementClaude
Now it builds, with cheaper models taking the mechanical steps. If reality does not match the plan, it stops and says so instead of improvising a design.
Validate, togetherindependent agent + me
A separate agent runs the scenarios from the plan, unchanged, and shows evidence. I look at it and decide whether it is right.
Show, don’t describe.
Before I approve a plan, I want to see the thing. Claude turns an idea into a clickable prototype in minutes, I react to it, and we go again. Looking at a rough version teaches us more than a page of requirements, and changing it costs almost nothing.
BDD is how we agree, and how I check.
Every acceptance criterion becomes a scenario in plain language, in the Given / When / Then style of BDD, before a line of code exists. It is the contract between me and the agents: what the thing must do, described from the outside, in words I can read.
Scenarios do not replace tests. The agents still write unit, integration and end-to-end tests, because those catch what a sentence cannot. BDD is the layer I own: I read the scenarios, and I watch them pass alongside the rest of the suite.
The scenarios say what the system does, not how it is built. So the same way of working holds whether the answer is C#, Go, TypeScript or something I have never touched. I do not need to know the idiom to know the result is right, because I validate the behaviour, not the syntax.
Judgement stays mine
I decide what gets built and when it is done. The agents never decide either.
Mistakes are cheap early
Most of the effort goes into the plan, where a wrong turn costs a sentence, not a rewrite.
Proof, not promises
“Done” is a scenario that passes. A separate agent checks it, and I see the evidence.
Stronger models (Opus) do the thinking and planning. Smaller and cheaper ones do the repetitive work, and a failed check is what escalates a step. Work happens in isolated git worktrees, lands through pull requests, and merging is my call. Secrets never go into prompts.
This site was built this way.
The redesign you are looking at went through the same loop: every question asked and answered, a plan iterated until I approved it, scenarios written before the code, and a design gate where I approved the look before the rest got built.
Curious how it works for your team?
Happy to talk about it.