My Agent Built the Wrong Thing Perfectly

A Tuesday disappears into polished wrongness

Last month a founder asked an agent for "coupon support at checkout." What came back was genuinely beautiful — a coupon model, an admin UI for creating codes, usage analytics, even expiry emails. Admired for ten minutes before the cold realization: the checkout flow has no cart page. Coupons had nowhere to live. The agent had built an entire feature for an architecture that doesn't exist.

Forty-five minutes of prompting, two hours of review and testing, one full afternoon — all producing deleted code. The worst part? Every line was clean. Lint green, tests green, preview gorgeous. Wrong the way a perfect stranger's house key is wrong: exquisite, useless.

Agent built wrong thing isn't a quality failure. It's a mind-reading failure — the founder's, for assuming "coupon support" meant anything specific to anyone but them.

Clean-wrong vs messy-right

Three things the incident teaches about why agents miss:

1. Vague prompts are design lotteries. "Coupon support" contains roughly fifteen decisions (where applied, who creates, stacking, expiry, refunds) — the agent guessed all fifteen confidently. Any founder would have answered twelve of them in seconds if asked. The tragedy: the prompt never required it to.
2. Confidence scales with detail, not correctness. The admin UI and analytics made the wrongness feel earned — sunk-cost admiration keeps founders testing 30 minutes past knowing. Polish is camouflage for misalignment; the prettier the output, the longer you delay the verdict. Ugly-wrong dies fast. Beautiful-wrong bills hours.
3. A founder's head is not documentation. "You know what I mean" works with cofounders (shared history) and fails with models (no history). Every unspecified decision is a coin flip the agent calls confidently. Count unspecified decisions before prompting — more than three means stop and write.

The opencode post blamed missing conventions.

The 20-minute spec that ends it

My ritual now, every feature, no exceptions — born from that deleted Tuesday.

Step 1 — Write the one-paragraph contract before prompting.

GOAL: percentage coupons applied on the single-page checkout, pre-payment.
NON-GOALS: no admin UI (seed codes via script), no stacking, no gift cards.
DATA: coupon_pct column on orders + coupons table (code unique, pct, expiresAt).
ACCEPT: POST /api/order with code → total reduced; invalid → 400 + message;
        uses existing checkout UI only. DONE when: curled happy + unhappy.

Goal, non-goals, data, acceptance — four headings that force the fifteen decisions out of the founder's head. Non-goals matter most (they kill the admin UI before it's built). Twenty minutes feels slow until one deleted Tuesday is priced against fifty spec sessions: the ritual pays 100-to-1 for founders who never skip it.

Step 2 — Require questions before code.

Prompt footer, every feature task (copy-paste, non-negotiable):
"Before writing code: list every decision you had to guess, numbered.
 Wait for answers. Then build exactly the spec, nothing beyond it."

The first run returns questions instead of code — which feels slower and is dramatically faster.

BoringPush sessions require the questions-first footer on every feature task.

Step 3 — Verify against the spec sentence by sentence.

# acceptance lines become curl commands, one per line:
curl -X POST /api/order -d '{"coupon":"WELCOME10",...}'  # total reduced? ✓
curl -X POST /api/order -d '{"coupon":"NOPE",...}'       # 400 + message? ✓
# plus: git diff --stat (files beyond spec scope = reject and re-prompt)

Spec-to-curl is mechanical: each acceptance line converts to one command, run and pasted.

That's the machine — specs from anywhere, surprises nowhere.

Two months compared, before and after the ritual

The downside, owned: twenty minutes of writing before every feature feels bureaucratic to founders who "just want to prompt." The feeling passes once the ledger shows spec months shipping more working features than prompt months, with zero deleted Tuesdays. Writing is thinking; prompting without writing is wishing with API access.

BoringPush reviews start from the spec, not the diff.

FAQ

How is agent built wrong thing different from normal miscommunication?

Degree and polish: humans ask clarifying questions mid-work and show rough drafts early; agents work silently for an hour and present finished artifacts. The silence removes every correction point except the end — where sunk cost peaks. Same miscommunication, ten times the momentum behind it. Process (questions-first, small slices) reinserts the correction points agents skip.

What if I don't know what I want yet — isn't exploration valid?

Yes, labeled as such: "spike: explore three coupon UXes, no production code, report tradeoffs." Exploration prompts produce learning; building prompts produce code. The disaster is exploration accidentally wearing a building prompt — an afternoon of prototypes committed as architecture. Name the mode upfront: spike or ship, never both, never neither.

Should the spec live in git or in chat?

Git (docs/specs/), always: chat scrolls away, specs compound. Next month's "coupon stacking" prompt reads last month's coupon spec first — continuity no context window provides. Specs in git become the product's memory; specs in chat become archaeology. Write where future-you (and future-agents) will actually look.

How detailed should acceptance criteria be?

Curlable: every line converts to one command with expected output. "Handles invalid codes" is a wish; "invalid code → 400 + {error} message" is a test. If a line can't become a curl, it's not done being written. Precision at spec time is precision at verify time — vague acceptance produces vague verification produces Tuesday deletions.

Do small tasks need the full ritual?

Scaled, never skipped: one-liners get one paragraph (goal + accept line, two minutes), features get the full page. The ritual scales down to a breath and still catches the "no cart page" class — two sentences would have saved that Tuesday. Skipping is how Tuesdays happen; scaling is how rituals survive contact with Mondays.

What if the agent's questions reveal MY spec is wrong?

Then the ritual paid double: better questions surfaced a better design before code existed. Revise the spec (ten minutes) instead of the codebase (ten hours). Wrong specs caught at question-time are the cheapest possible design iterations — this is the process working exactly as designed, not failing. Celebrate the catch, update the paragraph, proceed.

Keep reading

• Antigravity + Next.js: Tame Its 40-File Weekends — fences for long autonomous missions
• Build Features With AI That Don't Need Rewrites — the pipeline specs feed
• Mobile AI Guardrails: Couch Fixes That Can't Break Prod — specs that survive small screens