Start With a Spec, Not a Prompt
The instinct with a capable agent is to describe the feature and let it go. We start earlier and smaller: with a short, explicit specification of the change. Not a novel—a page. What are we building, why, what are the constraints, and what does "done" look like in terms someone else could check?
This matters more with agents, not less, because a spec is the only thing standing between "build a checkout flow" and an agent's private theory of what a checkout flow is. The spec is where product judgment lives, and product judgment is precisely the part that does not come out of a model. When the change touches more than one surface—an API and a UI, a schema and a worker—we make the spec a first-class artifact and treat it as the contract the rest of the workflow verifies against.
A useful test: if you cannot state the acceptance criteria before building, you are not ready to build. You are ready to prototype, which is a fine thing to do, but it is a different gate with different exit rules.
Plan Before You Build
With a spec in hand, we plan the implementation before touching code—and increasingly, we let a planner model draft that plan against the real repository. The plan names the approach, the files likely in scope, and the risks. It is deliberately reviewable: a human or a second model can read it and object before any code exists, which is the cheapest possible moment to catch a bad approach.
Planning is also where we make the simplicity decision. Left alone, an agent will often reach for a more elaborate design than the problem warrants, because elaborate designs are well-represented in its training data. The plan is where we insist on the smallest change that satisfies the spec, reuse what already exists, and add abstraction only when a concrete second use case demands it. Cheap to write, cheap to argue about, expensive to skip.
Build in Isolation
When building starts, it happens against the plan and in an isolated workspace—its own branch, and for anything substantial, its own worktree. Isolation is not ceremony. It is what lets a builder—human or agent—work without stepping on a shared, dirty tree, and it is what makes a change safe to throw away if the approach turns out wrong.
This is where coding agents earn their reputation. Cursor's Agent mode and Claude Code are genuinely strong at producing a focused change against a clear plan. The discipline we add is that the builder's job ends at "here is the change and here is how I tested it"—a self-test report, not a merge. Building produces a candidate. It does not produce a decision.
Verify Independently
Then the candidate meets a verifier that did not build it. This is the gate most teams under-invest in, and it is the one that pays. The verifier runs the acceptance checks from the spec against the actual result—not against the builder's summary of the result. Where possible we run it in a fresh context, and for higher-risk work on a different model provider, so that a shared blind spot does not get politely confirmed.
Verification is also where evaluation discipline shows up. The same instinct behind structured agent evaluations—define the standard, run against it, judge repeatably—applies to a single feature. For anything with an observable runtime effect, we verify against the running system, not the diff. A change that "looks right" and a change that behaves right are different claims, and only one of them belongs in production.
Review, Then Ship With Receipts
Human review comes last, not first, and it is deliberately narrow by the time it arrives. Because the spec framed intent, the plan caught approach errors, and the verifier confirmed behavior, the reviewer is no longer re-deriving whether the thing works. They are exercising the judgment machines do not have: is this the right change for the product, does it fit the architecture, does it carry risk we are not pricing.
When it ships, it ships with a trail: the spec it satisfies, the tested commit, the verification result, and the sign-off. That trail is what lets you move fast without the usual penalty, because when something does break later, you are debugging a documented decision instead of a mystery.
What This Looks Like in Practice
A client wanted a new customer-facing report added "by Friday." The old reflex would have been to hand it to the fastest engineer and hope. Instead we spent the first hour on a one-page spec: the exact metrics, the empty and error states, and a concrete acceptance check ("given this fixture, the report shows these three numbers"). A planner model drafted the approach against the repo; a senior engineer trimmed it from a clever generalized reporting engine down to the specific report actually requested.
The build ran in an isolated worktree and produced a change plus a self-test note in about two hours. An independent verification pass—separate session, different model—ran the acceptance check against a local deploy and bounced it once for a wrong empty-state message. The fix and re-verify took twenty minutes. Human review was ten minutes, because there was nothing left to prove except product fit. It shipped Thursday, with a receipt trail, and it has not needed a hotfix. The workflow did not slow them down; the spec and the verifier are what let them commit to Friday at all.
Common Mistakes
- Prompting instead of specifying. Skipping the spec outsources product judgment to a model that does not have any.
- Building before planning. The cheapest place to fix a bad approach is a plan nobody has written code against yet.
- Verifying the summary, not the system. An agent's "tests pass" is a claim; a run against the live system is evidence.
- Front-loading human review. Reviewers who re-derive correctness burn the exact senior time the workflow is meant to protect.
- Shipping without a trail. No receipts means every future bug is an archaeology project.
- One giant change. Large, unscoped diffs defeat verification and review alike; keep changes small enough to judge.
This workflow assumes your tools cooperate with it. In practice, coding agents will follow your gates only if your repository and your agent configuration make the gates the path of least resistance. Next we get concrete about that—how we use Cursor and AI coding agents without quietly abandoning engineering discipline.
