Most teams think the fastest path through an MVP is to open their AI coding tool of choice, dump a feature description into the chat, and start iterating. You get code fast. You also get something you'll spend the next two weeks untangling.
The teams shipping better MVPs — cleaner code, fewer surprises in production, faster PR reviews — are doing something that feels counterintuitive: they're making the AI slow down before it writes anything. They're letting the AI ask the questions first.
This post is about a workflow we built and battle-tested at Coginitics. Not a prompt engineering trick. A structured protocol with seven discrete commands, each running in a fresh AI context, each producing a concrete artifact. If you're a tech lead trying to figure out how to get consistent, reviewable output from AI on real features — this is the pattern worth understanding.
The "Just Prompt It" Trap
There's a version of AI-assisted development that feels productive but isn't. You describe a feature, the AI generates a reasonable-looking implementation, you start integrating. An edge case breaks. You ask the AI to fix it. The fix introduces another problem. You ask again. Each correction makes the context longer, the AI's model of your system fuzzier, and the output a little less coherent.
By the time the feature is "done," you've run 15 prompts in a single session. The code is a patchwork of iterative corrections. The PR is harder to review than if you'd written it yourself — because nobody, including you, has a clear mental model of what the intent was at the start.
The root cause isn't the AI. It's the session structure.
Here's what actually happens in a long AI session: the model tries to maintain coherence across an increasingly long context window. The longer the context, the more the model falls back on patterns and plausible-sounding completions rather than precise reasoning about your actual codebase. It starts hallucinating — not dramatically, but quietly. Methods that don't quite exist. Assumptions about your schema that are almost right. Confident suggestions that fit the general shape of your system but miss the specific constraint you mentioned eight messages ago.
A short context with a clear brief outperforms a long context with an accumulating history of half-formed requests, every time.
The Mechanism Most Developers Skip
Here's the move that changes everything: before asking the AI to write any code, ask it to interview you.
In the spec and plan phases of our workflow, the AI's job isn't to generate anything. It's to ask questions. It takes a short ticket description — one or two sentences — and then works through clarifying rounds. What's the input shape? What are the hard constraints? What happens in the edge cases? What does "done" actually mean?
Crucially, it doesn't fire all of these questions at once. It asks in rounds. It processes your answers, cross-references the codebase to understand what already exists and what's missing, and decides whether it has enough context to proceed — or whether it needs another round of questions. By the time it produces a spec or a plan, it has built a genuinely detailed understanding of the problem, not a plausible approximation of it.
This is where most developers short-circuit the process. They describe the feature in the first prompt and immediately get code. But the AI's first interpretation of a vague description is always a guess. The interview loop is what replaces the guess with actual clarity.
The impact on output quality isn't incremental. It's categorical. The code that comes out of a well-interviewed spec is qualitatively different from the code that comes out of a vague opening prompt — not because the model is smarter, but because it had better input.
The 7-Command Workflow
Here's how the full workflow is structured. Each command is a discrete step with a clear input, a clear output, and a fresh AI context.
spec
The developer provides a short ticket description. The AI begins interviewing: asking clarifying questions in multiple rounds, pulling in context from the codebase, surfacing constraints and edge cases the developer may not have explicitly thought through. Output: a spec file in the ticket's folder. No code is written during this step.
plan
Takes the spec as input and builds the execution plan. The AI interviews the developer again, this time focused on sequencing, risk, and acceptance criteria. Should this roll out in phases? What's the QA checklist? Are there design decisions worth deferring rather than locking in now? Output: a plan file and optionally a follow-up file. Still no code.
implement
The coding phase. The agent reads the spec and plan, then implements. Because the brief is precise and the acceptance criteria are written down, the implementation prompt is focused. The agent isn't guessing at constraints — they're in the spec. Phased work produces stacked PRs, one per phase. Reviewers get a diff and a plan file to check it against.
qa
Works through the acceptance criteria checklist produced during planning. For each criterion, the agent either runs an automated test or prompts the developer with the specific manual test steps, then waits for a pass/fail response. Results are recorded back into the plan file. QA isn't a separate effort bolted on at the end — it was designed during planning and executed here.
follow-up
Goes through the deferred items list from the plan, one by one. For each item the developer decides: integrate now, defer to a future ticket, or drop. This step keeps the backlog honest. Nothing gets silently forgotten because it wasn't in the original PR scope.
investigate
Used for R&D spikes — when you need to understand a library, evaluate an approach, or map an unfamiliar part of the codebase before committing to a plan. It's a legitimate phase, not a workaround, and keeping it separate prevents exploratory work from bleeding into implementation sessions.
bug-fix
Takes an issue description, traces the problem through the code, validates that the behavior is genuinely a bug (rather than expected behavior), and makes a targeted fix. If the trace doesn't confirm a bug, it flags that and stops — it doesn't make unnecessary changes to satisfy the ticket description.
Why Fresh Context Is a Feature, Not a Limitation
Every command clears the AI context. When you run spec, it starts fresh. When you finish and run plan, that's a new agent — it reads the spec file you just produced, but it has no memory of the conversation that created it.
This feels like a workflow constraint. It's the single most important design decision in the whole system.
A fresh agent reading a spec it didn't write is functionally a second set of eyes. It approaches the document without the assumptions and shortcuts the first agent built up during the interview rounds. If there's an ambiguity the spec agent glossed over, the plan agent often surfaces it. If the spec missed an edge case, the implement agent may notice the gap when it reads the codebase with fresh context.
The alternative — one long session that spans spec, plan, and implementation — means a single model with an ever-growing context window, accumulating shortcuts and gradually losing precision. The drift is subtle at first and obvious too late.
Fresh context isn't a workaround. It's a quality mechanism.
A Real Project: Billing Module Migration
We applied this workflow to a billing module migration for a client — moving their subscription infrastructure from one payment provider to another. The scope was substantial: subscription management, invoicing, webhook handling, proration logic, and a transition plan for existing customers already mid-cycle.
The spec phase ran through several interview rounds. The AI asked about the existing subscription data model, what customer-visible behavior needed to stay identical during the transition, how webhook failures should be handled mid-migration, and what the rollback path looked like if something broke for a live customer. Several of those questions surfaced requirements the developer had assumed were obvious but hadn't written down anywhere.
The plan phase broke the work into four phases: read-only integration (new provider active for new subscriptions only), parallel running (both providers live, old subscriptions untouched), migration (move existing subscriptions across), and cutover (disable the old provider). Each phase got its own acceptance criteria checklist.
Implementation ran as four stacked PRs. Because each PR was implementing a documented phase against a written checklist, reviews were fast — reviewers were checking the implementation against a plan, not trying to infer intent from the diff.
QA caught two issues the automated tests missed: a proration edge case on annual plans upgraded mid-cycle, and a webhook ordering assumption that only surfaced under specific timing conditions. Both had been written into the QA checklist during planning, because the spec interview had raised them as risks.
Four phases, four PRs, zero rollbacks to production.
What Changes for the Team
When you adopt this workflow, the distribution of developer effort shifts noticeably.
Before the workflow: most mental energy goes into iterating prompts, reviewing AI output for subtle errors, debugging unexpected edge case behavior, and explaining to reviewers what the code was trying to do.
After: the energy front-loads into spec and plan. Developers think harder before the AI writes anything. Reviewers check implementation against a written plan rather than reconstructing intent from the diff. The AI's output is less surprising — not because the model is smarter, but because it had a better brief.
A few outcomes become measurably better:
PR review speed. When the plan file sits alongside the diff, the "what was this supposed to do?" question has a written answer. Review time drops, and so does the back-and-forth.
Hallucination rate. Fresh contexts with tight briefs produce significantly fewer hallucinated methods, incorrect schema assumptions, and misread constraints than long sessions with accumulating history. The spec isn't just good documentation — it's the primary defense against drift.
Developer onboarding. New team members can read a spec and plan alongside the code and understand not just what was built but why it was built that way. It's useful documentation written at the moment of lowest cost — before implementation, when the decisions are fresh.
Backlog hygiene. The follow-up command forces explicit decisions on deferred items. Nothing gets silently dropped because it wasn't in the original PR scope.
Junior developer growth. Writing the spec means writing edge cases before prompting. That process teaches systematic problem decomposition — the kind of thinking that used to come only from years of experience. The workflow makes it explicit.
Actionable Takeaways
If you want to start applying this, here's the minimum viable version:
-
Start with the interview pattern on your next feature. Give the AI a one-sentence ticket description and tell it to ask you clarifying questions in rounds — referencing your codebase each time — before it writes a spec or any code. Do this before you open an implementation chat. Notice how the brief you end up with differs from what you would have typed as your first prompt.
-
Build your own workflow commands. You don't need to adopt our exact setup to benefit from the principle. Start a conversation with an AI and describe the workflow you want — spec, plan, implement, QA. Ask it to help you design the command definitions step by step. The design conversation itself is a useful exercise; you'll surface requirements about your own workflow you hadn't articulated.
-
Treat context isolation as a feature. When you move between phases, start a new session. Feed it the artifact from the previous phase. Let the fresh context catch what the previous context assumed. Resist the temptation to keep one long session running — the accumulated context is working against you.
-
Write the acceptance criteria before implementation starts. If you don't have a QA checklist at the end of the plan phase, the plan isn't finished. The checklist is what makes QA a verification step rather than an open-ended exploration.
What's Coming Next
This post covers the structure and the reasoning behind it. We're working on a more detailed follow-up that goes deep on each command — the exact prompt design, how the AI interview loop works in practice, and the decisions behind how we handle stacked PRs and phase boundaries.
We're also publishing the full command set as a public GitHub repository so you can adapt the workflow to your own setup without starting from scratch.
If you want to talk through how this maps to your team's current process before then, get in touch — that conversation tends to be useful regardless of whether you adopt any of this wholesale.
The tools are good. The workflow is what makes them consistent.
