How It Was Built with AI: Spec, Plan, Subagents, Review

UnboundProse wasn't vibe-coded. The features in this deep dive — the editorial bots, the Workshop, the trust boundary — were built through a disciplined pipeline where AI did the work but never skipped the steps a good engineer wouldn't skip. The method matters as much as the product, because it's the part that generalizes.

Brainstorm before spec, spec before code

Every feature started as a conversation, not a code change. Before anything was written, the idea went through a structured brainstorm: one question at a time, narrowing purpose and constraints, surfacing the decisions the requester actually had to make. The Workshop, for example, started as "an open chat about a chapter" and the brainstorm pulled out the real forks — is it chapter- or manuscript-level, does context change per question, how many threads, is it allowed in creative territory. Those answers became a written spec.

The spec is the contract. It names what's in scope, what's deferred, the data model, the API surface, the UX, and — importantly — the open questions it's not solving. Writing it down first means the expensive disagreements happen in prose, where they're cheap to fix, instead of in code, where they're not.

A plan made of bite-sized, testable tasks

From the spec came an implementation plan: a sequence of small tasks, each one a self-contained change with the exact files to touch, the test to write first, and the commands to verify it. The Workshop's plan was fifteen tasks — schema, then pure helpers (token budget, prompt assembly, metadata formatting), then routes, then the web client and components, then the page, then the manual verification matrix. Each task produces working, committed software on its own.

Fan-out to fresh subagents

The plan was executed by dispatching each task to a fresh AI subagent with exactly the context it needed and nothing else. A clean context per task keeps the work focused and prevents the slow drift that happens when one long conversation tries to hold an entire project in its head. The orchestrator's job is to curate context, not to do the implementation — which also preserves its own attention for coordination.

A two-stage review gate on every task

This is the part that makes AI-built code trustworthy. After a subagent finished a task, it did not move on. Two independent reviews ran first:

1. Spec compliance — a separate agent read the actual code (not the implementer's summary) and checked it against the requirements: nothing missing, nothing extra, no misread requirement. 2. Code quality — only after spec compliance passed, another review checked correctness, decomposition, naming, and consistency with the codebase's existing patterns.

Findings went back to the implementer, which fixed them and was re-reviewed until clean. Real issues were caught this way — a security-posture change slipped into a route (auth quietly removed), shallow tests that asserted membership instead of structure, an accidental "ONE COLOR SCREEN PRINT" string rendered into output. The gate caught them before they compounded. A final whole-feature review confirmed the API and web contracts actually matched end to end.

Verification before "done"

"Done" meant evidence, not assertion. Tests were written before implementation and run to confirm they failed first, then passed. Type checks and the full suite ran on the merged result before merge. Where a feature needed a real browser — saving an API key, watching a reply stream in — that was called out as a human step rather than claimed as verified.

Debugging by root cause, not symptom

Two production issues showed the same discipline applied to failure. A page broke with "Failed to load chapter" after a session sat idle. The lazy fix would have been to retry on any error. Instead: trace it. An expired token hit an auth-optional endpoint, which treated the stale token as anonymous and returned 403 — and the client only refreshed on 401, so it never recovered. The fix was precise: refresh proactively when the token is locally known to be expired, so even auth-optional requests go out authenticated. A separate "it works locally but 500s in prod" turned out to be an unapplied database migration, found by checking the database state directly instead of guessing at the code.

The takeaway

The interesting claim isn't "AI wrote this." It's that AI can be held to an engineering process — spec, plan, isolation, independent review, evidence — and that the process is what produces software you'd actually ship. The orchestration is the skill. The model is the labor.