Core Development Methodologies

Two developers get the same AI assistant and the same ticket: “add team invitations to the dashboard.” One pastes the ticket, accepts a 400-line diff, and spends the afternoon debugging why invites silently fail for existing users. The other ships it in an hour with passing tests and a clean diff. Same model, same task. The difference is methodology, not prompting.

The process those methodologies sit inside is the AI-native SDLC: six stages in a loop, each committing an artifact the next stage can read. This section is the set of plays you run inside those stages — not a rival framework. They are not theoretical: they are patterns extracted from teams shipping production code with Cursor, Claude Code, and Codex, across startups and enterprises alike.

Why methodology matters with AI

AI coding assistants are probabilistic. They generate plausible code, not provably correct code. Without a structured approach, you end up in a loop: generate, spot a bug, regenerate, introduce a new bug, regenerate again. Each cycle burns tokens, time, and trust.

A good methodology gives you three things:

• Predictability. You know what the AI will do next because you told it what to do next.
• Verification checkpoints. You can catch problems at each stage instead of debugging a tangled mess at the end.
• Context efficiency. Structured workflows keep your prompts focused, which means the AI performs better within its context window.

Context is the biggest lever on output quality

Before any methodology helps, the AI needs the right inputs. Two of them do most of the work.

Precise @-mentions. Reference the exact files and symbols the task touches rather than letting the AI guess. For the invitations feature above: @src/db/schema.ts @app/api/teams/route.ts. Pointing at the schema and the route is worth more than ten sentences of description.

A persistent rules file. Encode your stack and conventions once so you don’t repeat them every prompt. A short CLAUDE.md (also read by Codex) or .cursor/rules/*.mdc file like:

- DB access goes through Drizzle in src/db; never write raw SQL in route handlers.
- API routes return typed JSON via the `apiResponse()` helper in lib/api.ts.
- All new tables need a migration in drizzle/ and a matching zod schema.

Caution

More context is not always better. Flooding the model with dozens of irrelevant files dilutes attention and invites confident wrong answers. Curate a tight set of the files that actually matter for the task at hand.

Plan, execute, verify: the loop every methodology runs on

The reliable pattern is three phases with a human checkpoint between each. Here it is applied to adding team invitations to a Next.js + Drizzle app.

1. Plan first (read-only). Work in a read-only mode so the AI proposes without editing. Have it produce a TODO plan that names the files each step touches.

   Copy-paste prompt: a plan that names affected files

   In read-only/plan mode, using `@src/db/schema.ts` and `@app/api/teams/route.ts`: propose a plan to add team invitations (invite by email, pending/accepted states, accept endpoint). Output a numbered TODO where each item names the exact files it changes and the Drizzle migration it needs. List your assumptions about existing-user vs. new-user invites as CONFIRMED or GUESS. Do not write code yet.

2. Execute incrementally. Switch to an execution mode and do one TODO item at a time, reviewing each diff. Working in small steps keeps every change reviewable.

   Copy-paste prompt: execution scoped to one TODO item

   Execute TODO item 1 only: add the `invitations` table to `src/db/schema.ts` with a matching zod schema and a Drizzle migration. Do not touch the API routes yet. Show me the migration and stop for review before item 2.

3. Verify continuously (TDD). Use automated feedback loops. Test-Driven Development is especially powerful here: have the AI write failing tests first, confirm they fail, then implement until green.

   Copy-paste prompt: a TDD check that resists cheating

   Write failing tests first for the invitation acceptance rules: an invite can be accepted once, expired invites are rejected, and an already-member user gets a 409. Show me the failing test output. Only then implement until the tests pass — do not modify the tests to make them pass, and tell me if a rule is ambiguous.

How each phase maps to Cursor, Claude Code, and Codex

The Plan-Execute-Verify spine maps onto distinct mechanics in each tool. The discipline is identical; the controls differ.

Cursor

Plan in the Ask mode (mode dropdown, read-only). Execute by switching to Agent, accepting diffs per hunk; Cursor writes a checkpoint before each edit so you can roll back a bad step. Verify by having Agent run your test command and fix failures, reviewing each change before accepting.

Claude Code

Plan in plan mode (claude --permission-mode plan, or Shift+Tab to cycle into it). Execute in default mode (approve commands) or accept-edits mode for auto-applied edits. Verify with a PostToolUse hook that runs your test suite after each edit, so a failing change can’t accumulate unnoticed.

Codex

Plan with codex --sandbox read-only -c approval_policy=on-request. Execute with codex --sandbox workspace-write -c approval_policy=on-request; the sandbox and approval policy are separate controls. Use a dedicated git worktree when you want checkout isolation. Verify by letting Codex run tests and then opening a GitHub PR, so your normal CI and reviewers gate the merge.

Note

Editor and CLI commands aside, the three tools share the same backbone: read-only planning, small reviewable execution steps, and an automated verification loop. Pick the tool whose gate fits your workflow.

Treat the agent as a first-pass implementer

The agent is a very fast implementer that still lacks your domain judgment. That is not the same as “review every line like a junior’s PR.”

• Give clear instructions: Be specific. Break complex tasks into steps that match plan.md.
• Review at the gates: Read intent.md, spec.md, plan.md, and the PR summary plus agent findings. Go line-by-line only when the change is critical or the agent flagged it.
• Iterate and provide feedback: If the first output isn’t right, correct the plan or the instruction file so the next session does not repeat the mistake. A precise “the 409 case is unhandled; add it and rerun the tests” beats rewriting the prompt from scratch.

The methodologies

Superpowers Package design, worktrees, executable plans, TDD, subagents, review, and verification into one cross-harness agent workflow.

PRD to Plan to Todo The foundational workflow for feature development. Transform requirements into a detailed engineering plan, then break the plan into executable tasks the AI can implement one by one.

Test-Driven Development Write the tests first, then let the AI write the code to pass them. TDD gives the AI an unambiguous definition of success and a built-in verification loop.

Error-Driven Development Use failures as your primary feedback signal. Instead of trying to prevent all errors, lean into them as the fastest path to correct implementations.

Continuous Delivery Ship small, verified changes continuously. AI accelerates the cycle from idea to production when you pair it with automated pipelines and incremental delivery.

Human in the Loop The patterns that keep you in control. Know when to intervene, when to let the AI run, and how to review AI-generated code without becoming a bottleneck.

Agent vs Ask Mode Every tool offers modes that range from autonomous execution to read-only analysis. Knowing when to use each mode is the difference between productive sessions and wasted context.

How these methodologies connect

These are not competing approaches. In practice, you combine them. A typical feature build might look like this:

1. PRD to Plan to Todo to produce and commit intent.md / spec.md / plan.md.
2. TDD to write failing tests for the first task (the session-owned feedback loop).
3. Agent mode to let the AI implement the code after the plan is accepted.
4. Human in the loop at the gates: intent, plan, PR, production — not every generated line.
5. Error-driven development when the tests reveal edge cases you did not anticipate.
6. Continuous delivery to ship the verified change through branch protection; the agent does not pass the production gate.

Where these practices break down

• Context overload. Twenty @-mentioned files produce worse answers than three. Trim to what the task touches.
• Plan drift. Long sessions wander from the approved plan. Re-paste the numbered TODO and ask which step you’re on before continuing.
• Rubber-stamped reviews. After several correct diffs you stop reading; that’s when the bug ships. Keep diffs small and lean on automated gates (hooks, CI) that don’t fatigue.
• Tautological tests. AI-written tests can pass against broken code. Confirm a test actually fails when you break the implementation.

Where to go next with the method section

Read the AI-native SDLC first for the six-stage loop these methodologies run inside, then PRD to Plan to Todo for the conversation that produces the early artifacts. The principles index holds the full set. Beyond that:

Managing Large Codebases Keep the AI grounded when the repo is too big to fit in context.

Prompting Techniques The prompt patterns that get production-quality output.

Privacy and Security Keep secrets and sensitive code out of the wrong contexts.

Team Collaboration Share rules, prompts, and workflows across your team.