The AI-Assisted Development Lifecycle

The workflow I run with Cursor has a step that sounds wasteful: you build the whole feature, get it working, then throw it out and build it again. It isn’t, and the reason is structural. A generated diff is nearly free to produce, and reviewing one costs more the larger it gets, so once a model can write a feature’s worth of code in a session, the bottleneck shifts from producing code to trusting it. And the plan you reviewed so carefully is still a guess; the wrong parts don’t show until the code runs.

So you build twice on purpose. The first build is disposable: its job is to find out where the plan is wrong, which you fold back in before deleting the code. The second works from that sharpened plan one commit-sized task at a time, each diff small enough to review properly. The throwaway pass buys the knowledge cheaply so the real pass can spend it on quality.

What follows is the shape of the process, not a tool walkthrough, It assumes you already write code for a living and use Cursor day to day;

The shape of it

Seven moves, three phases.

• Plan
  • Write the spec.
  • Decompose it into commit-sized tasks.
• Explore
  • Let AI build the whole feature in one pass, then run it and review it over a few iterations: enhancing the code, finding requirements the spec missed, shifting implementation direction where the first approach was wrong.
  • Before discarding the build, migrate what it taught you back into the tasks.
• Build for keeps
  • Throw the exploratory code away, then rebuild one task at a time.
  • Review each task twice: you read it, then AI reviews the diff.
  • Open each task as its own PR for your teammates to review.

Each phase ends with a reviewable artifact before any later phase begins, and each move maps to a reusable Cursor skill so the steps run the same way every time.

Plan in cheap artifacts

Everything downstream inherits the quality of the spec, which is why most “AI coding” failures start before any code is generated. The standard pattern is to feed the model a ticket and let it improvise; this doesn’t transfer because the model defaults to plausible, not intended, and intent is the thing the spec carries.

The input to the spec step is a brain dump: the ticket, the related code, design notes, Slack threads, sketches. You add the intended approach and (the important part) the constraints: what must not change, what’s out of scope, what the solution has to respect. Constraints are information; they keep the model from confidently solving the wrong problem.

From that raw material the skill produces a structured spec covering problem, affected modules, key design decisions and their rationale, important flows, user-facing behavior, and explicit non-goals. Where the model had to guess, the guess shows up as an open question rather than buried as a silent assumption. You review the spec before going further. Fixing a misunderstanding here costs a sentence; fixing it after the code exists costs a day.

A reviewed spec still isn’t buildable. The next step decomposes it into a short ordered list of tasks, each roughly the size of a single commit, each one able to compile and pass tests on its own, in a sensible dependency order. If a task needs a paragraph to explain, it’s too big; if it’s a one-liner, fold it into its neighbor. You review the decomposition separately, because “is the feature right” is not the same question as “is this the right plan for building it.” Wrong slicing makes every later step quietly harder.

End of phase one: two reviewed artifacts, zero production code.

Why there’s an exploratory pass

A reviewed plan is still a set of predictions, and re-reading won’t show you where it’s wrong. The spec has a gap; a piece of functionality the plan took for granted turns out missing; an edge case surfaces only once you run the thing; the output doesn’t match what you pictured because the instructions were never precise enough to pin it down. The structural ones are worse, because the fix isn’t a single line: assumptions about the underlying code that turn everything into a mess, or the codebase changes surface a refactor that needs its own planning rather than getting shipped or sold as part of the feature.

So you let AI implement the whole feature in one pass, all the tasks at once, then run it, click through the behavior, and run AI code review over the result a few times. You read it yourself too, not line by line but for intent and the bigger picture, the structural reading a diff-level pass won’t give you. The build is disposable; its only purpose is to make the plan true.

Before discarding it, walk through it once more with the task list open and migrate everything it taught you back into the tasks: design decisions the spec didn’t anticipate, domain model refinements that emerged while implementing, features and requirements the spec missed. Once the tasks reflect what the build taught, the code can go.

Rebuild discipline

The exploratory build was written fast, all at once, with kinks patched in place rather than designed out; keeping it means inheriting that mess and trying to review your way out of it. Starting clean from sharpened tasks is faster, and the commit history tells a coherent story instead of a single “implement the feature” blob.

You implement the feature again, strictly one task at a time. Finish and commit one before starting the next; each task carries its own tests and has to pass the project’s gates (compile, lint, type-check, tests) before it counts as done. The reason for going one at a time is human, not technical: a small single-concern diff is something you can actually review. A thousand-line change is something you can only skim and approve on faith.

Each task in the rebuild gets reviewed twice before it goes out: you read it yourself, then AI reviews the diff. The order matters. Reading it yourself keeps you the author of your own codebase. The AI pass is a second independent reviewer over the same code, not a backstop for a read that is rushed. Then the task ships as its own pull request, where a teammate reviews a diff small enough to reason about. Three reviewers with different blind spots beat any one alone.

By the time the feature is merged, it has cleared a stack of independent gates, and none has to be perfect because none is load-bearing.

Encoding it as Cursor skills

The workflow holds together better when each move is a reusable skill rather than a prompt you retype. Each one has a narrow job and a few constraints that keep it honest:

• Spec: turns the brain dump into a structured spec, problem and affected modules and the decisions with their reasoning. Tell it to ask before it assumes, push back on an approach that doesn’t hold up and offer alternatives, and voice its guesses as open questions instead of making them implicit. Left alone it drifts from what and why into how.
• Decompose: turns the reviewed spec into a short ordered list of commit-sized tasks, each one able to compile and pass tests on its own. The constraint that makes it useful is reviewability: keep tasks small enough to read, write down the tasks dependency and order.Left alone it can produce tasks too big to review, or tasks that don’t compile in isolation.
• Build: turns a single task into code that clears the gates. Hold it to that task’s scope, and tell it the spec’s snippets are intent to adapt rather than gospel to paste; it doesn’t get to mark a task done while compile, lint, or tests are red.
• Review: reads the diff for what a second pass catches, the edge case and the missing test. Give it the surrounding context, let the linter own formatting so it doesn’t re-litigate it, and have it name what’s good alongside what’s wrong.
• PR: opens the task as its own pull request and describes what’s actually in the diff. Keep the body to the real changes; if left alone it tends to pad the body with filler or describes changes that aren’t in the diff.

The pattern: skills fail when they’re allowed to guess, or to do too much at once. Most of the constraints in a skill exist to prevent one of those.

Two supporting pieces matter in practice. Project rules (Cursor’s .cursor/rules/) keep the architecture, language standards, and quality gates as rules the AI reads on every task; the skills enforce the process and the rules enforce the standards. MCP servers give the model ways to check reality rather than predict it: task-tracking carries the decomposed tasks through implementation, a documentation server gives accurate current references, a browser-automation server lets it exercise the UI during the exploratory run.

Matching the model to the move

The seven moves don’t all need the same capability, and that difference is where the token bill comes down. Spec, decompose, and the reviews are judgment work: they decide what counts as correct and what counts as good, so they earn the strongest, most expensive model you have. Implementation is the other kind of work: once the tasks are sharp, turning one into code that compiles and clears the gates is mechanical enough for a cheaper model to handle, on both the exploratory build and the per-task rebuild.

The constraint hiding in “cheaper” is “still capable.” A model that can’t hold a well-scoped task produces diffs that cost more to review than they save in tokens, and the trade inverts. The gates are already there, though (the tests, your read, the AI review), so a capable mid-tier implementer’s mistakes get caught the same way any author’s would. Premium tokens go to the handful of decisions that set direction; cheap tokens cover the bulk of the typing. It trims the bill without moving the quality bar.

Where this still needs work

The exploratory pass is expensive in tokens even on a cheaper model, and on a feature small enough to fit in a single task it’s overkill; the rule of thumb is to skip it when the task list would be one or two items. The double review per task is also where the workflow demands the most discipline: it’s tempting, three tasks in, to wave an AI review pass through and merge. The version I actually run keeps both reviews mechanically required by tooling rather than willpower, and that’s a follow-up post.