The Bug That Kept Happening
A solo operator's coding agent shipped a button restyle that deformed checkout, cart, and subscription pages. The spec was simple: restyle the buy button on product detail pages. Nothing else. The agent implemented it, the developer skimmed the diff, and shipped. Within a day, three pages broke. The button lived in a shared component, so restyling it for one page affected all usages. This exact mistake happened twice, months apart, on different redesigns.
The developer runs a store with no other engineers. Every change goes through a coding agent treated like a contractor with commit access. The core job is to say with confidence: "this change is contained to what it claims to touch." For a long time, that wasn't possible—only a diff skim and a hope.
The naive approach: let the agent push straight to production for anything that looks small. For a production e-commerce site, that's expensive. A checkout bug costs money by the minute it's live. So the bar for "small enough to skip review" must be near zero.
The solution is a five-stage process that never gets skipped (except for actual typo fixes).
Stage 1: Spec What Must NOT Change
Before the agent touches anything, write the change in plain language. Include an explicit list of what must stay identical. For the button restyle, that would be: "Restyle the buy button on PDPs; checkout, cart, and subscription pages must be pixel-identical." That second sentence forces thinking about blast radius before writing code.
Stage 2: Grep Before Touching Shared Components
This rule came directly from two incidents. Before modifying any shared component, the agent must grep all usages and list them in the change summary, with a one-line impact note per usage. Most production incidents trace back to a shared component being restyled for one page and silently deforming others. The developer now asks "what else uses this file" as a reflex.
> Pitfall: The shared-component leak happened twice on completely different redesigns—a checkout re-theme and a product-page redesign. The second time, it was clear: a missing line in the checklist, not bad luck.
Stage 3: Review with a Fresh Agent Session
Early reviews failed because the same agent session that implemented the change also reviewed it. The agent "knew what it meant" and reviewed its own intentions, not the actual diff. The fix: spin up a genuinely fresh session with no memory of the implementation's reasoning. Hand it only the spec and the diff, and frame it as a skeptical reviewer. "Review this as a senior engineer looking for problems" produces different quality than "check if this diff matches the spec."
Here's how the implementer's view differs from a fresh reviewer's:
| Aspect | Implementer's view | Fresh reviewer's view |
|---|---|---|
| Context | Knows what it meant to change | Only knows the stated spec |
| Bias | Confirms its own intent | Hunts for contradictions to the spec |
| Blast radius | Assumes contained if it "felt" contained | Explicitly checks every file touched |
| Business rules | May not have been told them explicitly | Should be handed them as a checklist |
The reviewer's job: hunt for unintended file changes, shared-component blast radius, hardcoded values, and violations of business invariants (discount schedules, pricing logic). "Looks fine to me" is not a verdict. "Approve" or "request changes, with reasons" is.
Stage 4: Preview, Smoke Test, Then Production
Nothing goes straight from review to live. It goes to a preview deployment first. For anything touching money—checkout, cart, subscription flows—run a full mystery-shopper pass through the actual purchase flow on that preview URL. This catches bugs that code review can't: things syntactically fine but logically wrong, like a discount tier that computes correctly for four subscription cadences and silently wrong for the fifth.
Only after that does it go to production. Even then, the agent re-verifies the live site immediately after deploy, as an actual customer would experience it, with before-and-after screenshots. "Deployed successfully" and "deployed correctly" are different claims.
Stage 5: Every Incident Becomes a Permanent Checklist Line
The deploy checklist is nine lines long. Every line traces back to a specific incident that cost something. When something goes wrong despite the process, a short postmortem is written into the checklist immediately, while details are fresh.
The Impact
Agency-equivalent development for a store like this would cost low thousands of dollars a month. The tooling costs a fraction of that. The review process has caught revenue-touching bugs before production at least once a quarter—each one worth more than the month's entire tool bill.
What Review Actually Looks Like When You Can't Write the Code
You don't review code quality. You review containment and invariants. Does the file list match the stated scope? Does anything outside that scope change? Does the change respect business rules that were true before and need to stay true after—pricing, discount math, anything customer-facing numbers depend on? That's a review any operator can learn to do competently without being able to write the feature themselves.
Here's the prompt pair the developer actually runs, always as two separate sessions:
Change spec: [plain-language description]. Must-not-change: [list].
Implement on branch [name]. Requirements:
- Before touching any shared component, grep all usages and list them in your summary with an impact note each.
- Respect business invariants: [discount schedule, pricing rules].
- Output: diff summary by file, shared-component impact list, and preview URL.
Then STOP. A separate review pass and my approval happen before any production deploy.
[Reviewer session prompt:] Review this diff against the spec above as a skeptical senior engineer. Hunt specifically for: files changed beyond scope, shared-component side effects, and invariant violations. Verdict: approve / request changes, with reasons.
One more habit from a dumb loss: a working directory got deleted while it was still the active workspace for a session, wiping an in-progress redesign. Commit early, push often, and treat "delete this directory" with the same suspicion as a production deploy.
None of this makes shipping alone as safe as shipping with a team. It makes failure modes cheap and specific instead of expensive and vague—which, for a solo operator, is the bar worth clearing.
The full system includes 30 workflows that run a one-person company, with copy-paste prompts, failures, and impact ranges. The free sampler has no email gate.
