My current AI coding workflow

I’ve been coding with Cursor for nearly a year, and I’ve found that clear planning consistently leads to better results. At first, my workflow was unstructured, I mixed planning and execution in the same AI interaction. This often led to overly complex changes, causing the model to make mistakes and making it difficult to track progress.

AI coding usually fails when language models (LLMs) are asked to plan and code at the same time. The rule #1 of using LLMs effectively is straightforward: give them one clearly defined task at a time. Vague or broad instructions typically produce poor results.

Plan & Act modes in Cline

The solution is very simple. Don’t let them do both at once. This is why Cline has Plan & Act modes and Windsurf just came out with their planning mode, which disables editing and creates an explicit plan to implement. I realized I could build a similar workflow in Cursor.

My Workflow

Plan & Act mode in Cline

Inspired by Cline, I replicated separate planning and execution steps in Cursor using custom modes. These custom modes allow me to use specific prompts and control the tools available to the agent when the mode is active.

I created distinct planner and executor modes, each with prompts tailored to precisely guide the model’s actions. For planning, I chose Gemini 2.5 Pro because it offers a long context window, strong intelligence, and supports multi-turn conversations for clarifying requirements. For execution, I opted for Claude Sonnet 4 due to its speed, reliability with tools, and strength in iterative debugging.

Here’s how it works in practice:

The Planning Phase

I switch to Planner mode and add relevant files and folders to the context. Then I describe what I want to build or change. The planner asks clarifying questions, one at a time, building on previous answers. This iterative Q&A continues until we have a complete understanding of the requirements. This approach was inspired by Harper Reed’s AI codegen workflow, where he uses a similar one-question-at-a-time method to develop thorough specs.

The output is a plan.md file with numbered tasks, each with a checkbox for tracking progress.

The Execution Phase

I switch to Executor mode, add the plan.md file to the context, and simply type “go”.

The executor then:

• Reads the plan and identifies the first unchecked task
• Implements the specific changes required by the task
• Runs tests to verify that the implementation works correctly
• Commits the changes with a clear, descriptive message
• Marks the task as completed in the plan

By repeatedly typing “go”, the executor moves sequentially through the remaining tasks until the entire plan is complete.

Instead of one massive, difficult-to-review change, this workflow gives me:

• A clean git history with atomic, easy-to-follow commits
• Each change thoroughly tested and verified individually
• Clear explanations of what was implemented with each commit
• Easy rollback capability for any specific change if necessary

Two-mode system

Planner Mode

Modes dropdown in Cursor

I configured Planner mode with Gemini 2.5 Pro Max to leverage its massive 1M token context window. This means I can drop entire project folders into the conversation and the model understands the full codebase context.

Planner mode configuration:

• Model: Gemini 2.5 Pro Max
• Edit tools disabled: Crucial to enforce planning without outputting code
• Keybinding: ⌘⇧W for quick access

Planner mode prompt

The planner prompt evolved significantly, focusing on:

• Strict guardrails to prevent premature code generation
• Iterative Q&A to build detailed, clear specifications
• Explicit approval before finalizing the plan
• Progress tracking with checkboxes
• Atomic tasks with clear scope boundaries

Plan format

Example plan.md file

The structured output of planner (plan.md) uses hierarchical numbering for grouped tasks, and includes a “Rules & Tips” section accumulating learnings across tasks.

With a well-structured plan in hand, the executor can work autonomously and reliably.

Executor Mode

Executor mode in action

I chose Claude Sonnet 4 for execution due to its speed and effective debugging capabilities.

Executor mode configuration:

• Model: Claude Sonnet 4
• All tools enabled: For reading files, writing code, running tests, and committing changes
• Auto-settings: Auto-apply edits, auto-run, and auto-fix errors enabled
• Keybinding: ⌘⇧E for quick access

When I switch to executor mode and type “go”, it springs into action. It reads the plan.md file, finds the first unchecked task, and gets to work. The screenshot above shows it identifying task #18 and diving into the code.

Executor mode prompt

Each section in the prompt serves a specific purpose in creating reliable, autonomous execution.

What makes the executor effective:

• Learning from past tasks — It maintains a “Rules & Tips” section that grows with each task
• Finding the next task — It reads plan.md and automatically identifies unchecked items
• Commit discipline — Every task ends with a git commit, creating natural checkpoints
• Circuit breaker — If something fails repeatedly, it stops and asks for help rather than spiraling out of control and creating a mess

When tests fail and Sonnet 4 can’t fix it at first go, it sometimes does something I have not seen other models do, it creates temporary .js files to test specific functions in isolation. This makes it much more capable of figuring out issues on its own, without me intervening.

Two modes working together

These modes are designed to complement each other effectively:

• Planner understands requirements and code without modifying it
• Executor precisely follows plans without second-guessing

The prompts themselves are living documents. Every once in a while I see the models doing something I don’t like, which needs addition or correction in the prompt to avoid it.

Parallel Agents

I wanted to push this workflow further. Claude Code can run multiple agents in parallel using git worktrees. Would it be possible to replicate this in Cursor? It would allow more powerful workflow: while I work on complex features, autonomous agents could handle simpler tasks in parallel.

It turned out to be possible, but not without challenges. Cursor’s edit tool has a limitation — it only works in the current worktree. This meant the agents couldn’t use Cursor’s built-in editing. The solution was to give a text edit MCP server access to the agent in order to modify files in their own worktrees.

Here’s how parallel execution works:

• Assign each agent a different task from plan.md
• Agents work independently in isolated branches
• Changes auto-merged upon completion

This approach allows me to focus on more complex issues while 2–3 agents concurrently handle simpler tasks.

Parallel agent executor prompt

Conclusion

Over the past few weeks, I’ve used this workflow to ship PRs with thousands of lines changed. The AI handles the bulk of the work. It implements features, writes tests, and refactors across multiple files. I step in when things get tricky. Debugging subtle issues, making judgment calls where there’s no clear right answer, or tweaking naming and code style to match our conventions.

This workflow continues evolving, particularly with the releases of new tools and models. New patterns are emerging that help us work more effectively with AI agents. Separating planning from execution works. Giving AI clear, atomic tasks works. Building in feedback loops works.

I’ve put the prompts on GitHub if you want to experiment with this approach. They’ll keep changing as we figure out better ways to work with these tools. If you find improvements or build something interesting with them, I’d love to hear about it.