— Insights
How far to let AI drive — designing the workflow for a new product
Neither hand it all to the AI nor do it all yourself. Split a product launch into four stages, decide who owns which judgment at each one, and switch models as you go.
Every time I start a new product, the same question comes up: how much of this should the AI do? You’ll find posts claiming a full product got built overnight with no human in the loop, and you’ll find engineers saying they end up rewriting everything in review anyway so they may as well have written it themselves. Having launched a few of our own products this way, I’ve come to think the binary is the wrong frame entirely.
The useful question isn’t “delegate or don’t.” It’s “which judgment, at which stage, belongs to whom?” Business-model exploration, technical selection, implementation, and mechanical bulk work differ enormously in what the model is good at and in what it costs you when it’s wrong. Treating them with the same posture is exactly how you end up either shipping something broken or grinding through work a model would have finished in minutes.
This post lays out the four-stage flow I actually run, where the human/AI line sits at each stage, and how model selection maps onto it. Implementation guardrails are covered in Making AI actually follow the rules with Claude Code hooks, and review design in Layered AI code review — this one is the layer above both: the shape of the process itself.
Four stages, one gradient
Here’s the whole thing at a glance.
| Stage | Work | The model’s role | The judgment you keep |
|---|---|---|---|
| 1. Business model | Problem framing, revenue, competition, kill criteria | Sparring partner, coverage of angles | Whether to build it at all |
| 2. Technical selection & design | Stack, architecture, schema | Enumerate options, lay out trade-offs | Fixing the constraints |
| 3. Implementation | Scaffolding, features, tests | The workhorse — most of the code | Acceptance criteria and review |
| 4. Bulk & mechanical work | Copy, i18n, data transforms, boilerplate | Nearly everything | Sampling checks |
The important property is the gradient: the closer you are to stage 1, the higher the share of human judgment; the closer to stage 4, the higher the share of AI. Apply a uniform posture across all four and you get one of two failure modes — an upstream mistake that compounds, or a downstream slog that never needed you.
Stage 1: Business model — spar with it, don’t let it decide
At the concept stage, the value the model provides is coverage of angles. It’s a tireless counterpart for “will anyone actually pay for this,” “has someone tried this and folded,” “under what conditions does the revenue assumption break.” You can ask the same question twenty different ways without exhausting anyone’s patience.
The prompts I reach for here are fairly fixed:
- Is this a “nice to have” or a “can’t operate without it”? On what evidence?
- Where exactly does money change hands? Is there a path where someone uses it forever for free?
- Have comparable services shut down? What killed them?
- If I had to name three conditions that would make me kill this, what are they?
But the decision never goes to the model. The reason is structural: an LLM is poor at saying “don’t build this” and meaning it. Prompt it to be harsh and you’ll get critical angles — but that’s the model playing a requested role, not making a business call. Setting kill criteria, and actually stopping when you hit one, is human work.
The output of this stage isn’t code, it’s a record of decisions. I keep “why this problem” and “what would make me stop” in an Obsidian vault. It doubles as context I hand the model at later stages, and as the thing I read six months later when I’ve forgotten why I started.
Stage 2: Technical selection & design — get the trade-offs, fix the constraints yourself
This is where the stack and the architecture get decided. The model’s job here is narrow: enumerate the options and lay out the trade-offs so you have material to decide on.
I use a workflow with an explicit design phase for this — codebase exploration, clarifying questions, and architecture design as separate passes rather than one blended prompt. The critical part is that you give the model your constraints before it designs anything. Design against vague constraints and you get proposals that are technically sound and operationally wrong for you.
The constraints I always pin down first:
- Headcount — am I running this solo, or will a team touch it?
- Cost ceiling — what’s the monthly infrastructure budget?
- Exit likelihood — if the odds of shutting this down are high, favor low-lock-in choices
- Regulatory surface — advertising claims, medical-device rules, personal data, whatever the sector imposes
- Existing assets — internal libraries or repos worth reusing
Regulatory judgment in particular has to stay human. The model knows the law in general terms, but “is this specific phrasing acceptable for this sector in this context” is a question the operator answers and is liable for. Decisions like “this feature touches regulated claims, so build the human-approval step into the flow now rather than bolting it on later” go into the requirements because you put them there — not because the model surfaced them.
The output here is again a record before it’s code. Keeping an ADR that documents why the alternatives lost — not just what won — pays off in the implementation stage: when the model proposes a rejected approach, you can dismiss it in seconds instead of relitigating it.
Stage 3: Implementation — the workhorse, gated by criteria you wrote first
From here the model carries the load. Scaffolding, features, tests, refactors — by volume, most of the code.
What stays with you is the acceptance criteria. Run this stage on “does it work?” and you accumulate code that runs but drifts from the design intent. Before handing off implementation, write down:
- The behavior the feature must satisfy (ideally as tests)
- What must not be touched — existing contracts, public APIs, schemas
- The definition of done: tests pass, types pass, lint passes, verified on a real device
Then push the mechanical parts into deterministic gates. The commit-time typecheck/lint/secret-scan setup is covered in the hooks piece, and this stage’s throughput depends heavily on how good those gates are. A process where the only check is “a human reviews what the AI wrote” does not survive contact with volume. Anything a machine can decide goes to the machine; only the classes of problem that need an LLM or a human get routed there.
One more habit that pays here: commit at stage boundaries. Long sessions get compacted, and early context thins out. Committing per phase means that even across a context reset, git history tells you exactly how far the work got — the blast radius of losing context stays small.
Stage 4: Bulk & mechanical work — delegate essentially all of it
Sweeping copy changes, i18n string pairs, data format conversions, boilerplate files. Almost no judgment is involved, so hand it over and do sampling checks.
The thing to inspect here is the distribution, not every row. Rather than reading all 100 converted records, read five at random plus three that look like edges — longest, shortest, one with unusual characters. Clean? Ship it. Broken? Fix the prompt and rerun the whole batch. Correcting items one at a time is not stage-4 work.
Model selection — switch it by stage
This is where it hits the invoice. Claude’s models are tiered by capability and price; as of July 2026 the lineup looks like this:
| Model | Input / output (per million tokens) | Position |
|---|---|---|
| Claude Fable 5 | $10 / $50 | Hardest reasoning, long-horizon autonomous work |
| Claude Opus 5 | $5 / $25 | Complex agentic coding, enterprise work |
| Claude Sonnet 5 | $2 / $10 * | Speed/intelligence balance; near-Opus on coding |
| Claude Haiku 4.5 | $1 / $5 | Fastest, cheapest. Mechanical tasks |
* Sonnet 5 is on introductory pricing: $2 / $10 through August 31 2026, $3 / $15 from September 1.
Map that onto the stages:
- Stages 1 and 2 (concept and design): top tier. The quality of the material you decide on propagates into everything downstream, so economizing here is a bad trade. Token volume at these stages is low anyway — a high unit price on a small number of tokens is a rounding error.
- Stage 3 (implementation): mid tier. Sonnet 5 lands close to the top tier on coding and agentic work, which makes it the right default for the stage where volume actually accumulates. Escalate only the genuinely hard parts.
- Stage 4 (bulk work): smallest tier. There is no argument for running judgment-free work on an expensive model.
On input pricing, the spread from top to bottom is 10x — and the effective gap is wider than that. Fable 5 and the Opus line use a newer tokenizer that produces roughly 30% more tokens for the same text than the Haiku generation, so processing identical input costs closer to 13x, not 10x. Running stage 4 on the top tier means paying that multiple for output you’d have gotten either way. Conversely, running stage 1 on the cheapest tier means founding a business on shallow analysis — which costs far more than the token savings.
A practical note: change models at stage boundaries, not mid-session. Prompt caches are per-model, so switching mid-conversation means the new model’s cache starts cold and the prefix has to be written from scratch. Cache reads run about a tenth of normal input pricing; cache writes run 1.25x or more. Downgrading to a cheaper model mid-session can therefore end up costing more than staying put. Ending the session when the stage ends keeps this simple.
For finer-grained control, route sub-tasks to a cheaper model via subagents. The main conversation stays on the higher tier while exploration and mechanical passes get delegated to child tasks running something smaller. You lower cost without disturbing the main session’s cache — useful in stage 3 whenever the “go read things” share of the work is high.
Separate where you think from where you build
One last thing, unglamorous but load-bearing: I keep thinking and building in physically separate places.
- Where I think: an Obsidian vault — problem framing, kill criteria, ADRs, operating rules, tasks
- Where I build: git repositories — code, tests, configuration
Two reasons. First, the context you hand the model stays clean. Decision notes living inside the repo become noise during implementation sessions; code living in the vault gets in the way when you’re tracing a decision.
Second, the reasoning survives. Git preserves the history of the code, but “why we chose this design” evaporates unless you write it down deliberately. Conversation logs are effectively gone once a session ends, and get trimmed by compaction before that. Anything you want to keep has to live outside the conversation.
With that separation in place, starting an implementation session is just “read this ADR from the vault, then begin” — and you start with the right context loaded. The longer a project runs, the more this compounds.
Wrap-up
What makes an AI-assisted product launch work isn’t the tooling or the prompts — it’s deciding who owns what, stage by stage. Humans decide more upstream, the model does more downstream. Holding that gradient in mind is most of what separates “shipped something broken” from “ground through work I didn’t need to do.”
Three judgments stay human, always: kill criteria, regulatory calls, and cost structure. Each is either unrecoverable when you get it wrong or carries operator liability. Exploration, comparison, implementation, and cleanup can all lean heavily on the model.
Model selection follows the same gradient. Top tier where you’re producing the material you’ll decide on, mid tier where volume accumulates, smallest tier where there’s no judgment at all. With a 10x spread across the range, running every stage on the same model is a decision you’ll see on the bill.
Start with whatever project you’re on right now: name which stage each piece of work belongs to, and who should own each judgment. That alone makes the line between what you delegate and what you keep much easier to draw.