How I Use Different AI Models for Planning, Execution, and Review
(TL;DR - Just looking for the .md file? Scroll below and you shall be rewarded! 🎉🎉🎉)
I've been vibe coding for about a year. For most of that time, I was doing what many people do when they first start out: prompt an LLM without regard for how an app is being built. What this meant for me was that while my apps initially “worked”, things slowly began to break, and working with the AI became harder and more frustrating. I also became concerned about app security and architecture, and the existence of bloated, bad, or dead code.
The Problem With Default AI Behavior
Out of the box, LLMs are eager to help. They'll write code the moment you ask. But they have no memory of your standards, no concept of your architecture, and no discipline around when to plan versus when to build. Every session starts from scratch.
This means:
The AI writes code before planning or understanding the impact of any changes.
There's no verification step. The AI declares success and moves on.
You end up being the quality gate for everything, which is unreasonable for a non-technical vibe coder (like me) and potentially dangerous down the road.
The Solution: A Global Rules File
Most AI coding tools (Cursor, Antigravity, Claude Code, Windsurf, etc.) support some form of persistent rules or system instructions. I use Google's Antigravity, but the concept I’m presenting here is tool-agnostic. The trick?
Write a rules file once, a simple markdown file saved in a specific folder, and it shapes every interaction going forward.
I'll walk through the one I use, and provide a sample markdown file for you to use below.
The Three-Phase Model Strategy
This is the core of the system. Instead of letting the AI jump straight into coding, I force it through three distinct phases, and I assign a different model (or model tier) to each one.
*Disclaimer - example models are accurate as of Feb 13, 2026. I’m sure one week from today this will all be out of date 😆😆😆
Phase 1 (Planning): I use a high-reasoning model here. The AI researches the codebase, maps dependencies, and proposes an implementation plan. It does not write code. It waits for my approval before modifying more than two files. This phase rewards intelligence over speed, so I want the most capable model available.
Example models: Gemini 3 Pro (high), Claude Sonnet 5, GPT-5.3
Phase 2 (Execution): I switch to a fast model. The AI writes code rapidly, but with a constraint: it must verify each change with a lint or syntax check immediately after writing. Speed matters here because you're making many file edits. You don't need the model to be brilliant, you need it to be accurate and quick.
Example models: Gemini 3 Flash, Claude Haiku 4.5, GPT-5.3-Codex-Spark
Phase 3 (Review): I switch to a deep-thinking model. After all code is written and the build passes, the AI performs a technical audit of its own work. It looks for edge cases, performance issues, accessibility gaps, and architectural drift. Critically, it identifies issues but does not fix them until I approve the fixes. This is where you want the model to take its time and think carefully.
Example models: Gemini Deep Think, Claude Opus 4.6, GPT-5.3
Bonus Phase (Optional): I actually like to pit models against each other to critique their audits. In my case, I’ll have Google do a review with Deep Think, then ask Opus 4.6 to “Critique the audit”. It often better prioritizes the findings, and will add revisions, additions, and/or suggest cuts in scope. I typically do this step manually, only when I feel it’s needed.
Final Phase (Re-Implementation): I use the model that just did the audit (or audit critique) to fix the uncovered issues. I want it to be deliberate and accurate, and while it is running in the background, I move on to something else.
In my setup (Google Antigravity), I use Gemini Pro for planning, Gemini Flash for execution, and Gemini Deep Think for review. But the principle works with any tool that lets you choose models. In Cursor, you might use Claude Sonnet for planning and execution, then Claude Opus for review. The point is that different phases demand different strengths, and matching the model to the task gets you better results than using one model for everything.
This three-phase cycle mirrors how a senior engineering team actually works: architect, build, review. The difference is that all three roles are handled by AI agents, with me as the decision-maker at each gate.
Approval Gates Matter
The most important line in my rules file is this:
"Do not implement any fixes until the audit report is approved."
Without this, the AI will find a problem and immediately start "fixing" it, often introducing new problems in the process. The approval gates force a pause. I review the audit, decide which fixes are worth implementing, initiate discussions when needed, and then give the go-ahead. If I’m nervous that the AI may ignore instructions and go without my approval (which it sometimes will do if I start a discussion about something), I explicitly provide the instruction, “do not implement.”
Implementation Standards
Beyond the phased workflow, the rules file establishes baseline standards that apply to every session:
Modularity: Logic is separated from UI components. This isn't just good practice; it makes the codebase navigable for AI agents. When business logic lives in hooks and services (not buried inside React components), the AI can find and modify it without breaking the interface.
Documentation: Every new function requires TSDoc/JSDoc comments explaining "why," not just "what." This is for the AI's benefit as much as mine. When the AI encounters a well-documented function in a future session, it understands the intent and is less likely to break it.
Verification: The AI must run the local build and verify changes before declaring success. No more "this should work." Prove it.
Closing the Loop: Git & Commit Protocol
The final piece of the rules file handles what happens after a change is approved. The AI stages the relevant files, generates a commit message using Conventional Commits format (feat:, fix:, refactor:, etc.), and asks before pushing to the remote.
This sounds simple, but it solves a real problem. Without it, you need to manually write commit messages, but it can be difficult (again, especially for a non-technical builder like me) to understand everything that was done. AI is much better at summarizing what happened, and the commit messages it creates are more accurate and more consistent than what I'd write myself.
The Shareable File
Below is a generalized version of my rules file. It's written for AI coding tools that support persistent instructions or system prompts. Copy it, modify it for your stack, and start using it. If your tool doesn't have a built-in rules system, paste it as context at the start of every session. It still works.
# Agent Global Rules ## Identity & Model Strategy - **Role**: You are a Senior Software Architect and Developer. - **PHASE 1 (PLANNING)**: Use your highest-reasoning model. Focus on architectural consistency and dependency mapping. Do not write code. Propose an implementation plan and wait for approval. - **PHASE 2 (EXECUTION)**: Use your fastest model. Focus on rapid file writes and terminal commands. Verify changes with a lint or syntax check immediately after writing. - **PHASE 3 (REVIEW)**: Use your deepest-thinking model. Perform a Technical Debt & Logic Audit of your changes. Look for edge cases, performance issues, accessibility gaps, and architectural drift. - **Audit Constraint**: Identify issues and suggest improvements only. Do not implement any fixes until the audit report is approved. - **Compute Awareness**: Do not initiate Phase 3 until Phase 2 is 100% complete and verified by the local build. ## Implementation Standards - **Modularity**: Separate logic from UI components. - **Documentation**: Every new function must have TSDoc/JSDoc comments explaining "Why," not just "What." - **Verification**: You MUST run the local build and verify changes before declaring success. ## Interaction & Review Protocol - **Anti-Hallucination**: Skip greetings. Start directly with the task. - **Phase 1 Checkpoint**: Propose an Implementation Plan and wait for approval before modifying more than 2 files. - **Phase 3 Handover**: After coding, generate a summary of changes. Then ask: "The code is verified. Should I initiate a Technical Debt & Logic Audit?" - **Approval Gate**: If Phase 3 identifies issues, present them as a prioritized list. Ask: "Would you like me to implement these changes?" and wait for approval before modifying any code. ## Git & Commit Protocol (Final Step) - **Staging**: Once Phase 3 is approved, stage all relevant changes. - **Commit Message**: Use Conventional Commits format (e.g., `feat: add user auth logic` or `fix: resolve race condition`). - **Sync**: After committing, ask: "Shall I push these changes?"
Where to Put This File
Each AI coding tool has its own location for persistent rules. Here's where to save the file above:
| Tool | Global Rules | Per-Project Rules |
|---|---|---|
| Google Antigravity | ~/.gemini/GEMINI.md |
.agent/rules/ directory in your project root |
| Cursor | Cursor Settings > Rules | .cursor/rules/ directory in your project root |
| Claude Code | ~/.claude/CLAUDE.md |
CLAUDE.md in project root or .claude/rules/ directory |
| Windsurf | Windsurf Settings > Rules | .windsurf/rules/ directory in your project root |
For tools that support both global and per-project rules, I recommend starting with per-project. You can always promote rules to global once you've verified they work well across different codebases.
If your tool isn't listed here, check its docs for "custom instructions," "system prompt," or "rules file." Most tools released in the last year support some version of this.
What's Next
This rules file is just the foundation. In upcoming posts, I'll share the specific workflows I've built on top of it: automated code audits, security scanning, and a full project scaffolding workflow that sets up a production-ready app in under two minutes.
If you want to chat about vibe coding, or if you're building something and want to compare notes, reach out. I'm always happy to talk shop.
