Does Your AI Agent Need a Plan?

Source: Dev.to

Planning: A Spectrum, Not a Binary Choice

The real question isn’t whether to plan, but how to plan in a way that matches your current task and working style.

• Different developers, different approaches – some draft detailed pseudocode, others practice test‑driven development and let the architecture emerge organically.
• Team habits vary – some sketch complex diagrams on whiteboards, others spin up fast prototypes to “fail fast” and refactor later.

If planning is a spectrum when you code manually, why shouldn’t it be a spectrum when you use an AI coding agent?

The Debate on “Plan Mode” for AI Agents

There’s a healthy industry discussion about whether dedicated plan modes are essential or just overhead.

• You can always tell an agent to “make a plan first.”
• Some argue that a durable plan belongs in a file you can see, edit, and version alongside your code.

The truth is that a plan mode’s value isn’t just the plan itself—it’s the mental model and workflow it creates for the developer. Sometimes you want the agent to execute immediately; other times you want to see its thinking, give feedback, and collaborate before any code changes happen.

goose embraces both philosophies because different situations call for different methods.

Choose Your Strategy

For The Architect – /plan Mode

When you enter plan mode in the goose CLI, goose shifts into an interactive dialogue instead of executing right away. It asks clarifying questions about:

• Tech‑stack preferences
• Authentication requirements
• Deployment targets
• Error‑handling strategy

This back‑and‑forth continues until goose has enough context to generate a comprehensive, actionable plan.

• Custom planner configuration – set GOOSE_PLANNER_PROVIDER and GOOSE_PLANNER_MODEL via environment variables to use one model for strategic planning and another for execution.
• Checkpoint – after you approve the plan, goose can clear the message history and act on it, giving you a clean start before any code changes.

Example: I used this approach to migrate a static Vite/React project to Next.js. Goose produced an 11‑phase migration plan with checkboxes for each step (dependency updates, routing changes, component boundaries, etc.). After I said “yes start,” it executed methodically, committing after each phase.

Learn more about creating plans →

For The Director – Instruction Files

When you already know exactly what needs to happen, you can write the plan yourself and hand it to goose.

1. Create a Markdown file (e.g., plan.md) containing:

   • Context about the codebase
   • Specific files to modify
   • Expected outcomes and validation steps

2. Run it:

goose run -i plan.md

• Works well if you’ve already sketched the architecture, written a design doc, or simply know the codebase well enough that goose doesn’t need to ask clarifying questions.
• Instruction files can also be executed in headless mode for CI/CD pipelines or automation (see tutorial).

Core idea: You own the plan; goose owns the execution.

Learn more about running tasks →

For The Explorer – Conversational Context Building

This approach combines three goose features:

1. Conversational planning – treat goose as a pairing partner. Ask it to analyze, explain, and explore. Build a shared mental model before moving to execution.

2. Todo extension – the todo extension watches for complexity. When a task involves multiple steps, files, or uncertain scope, it automatically creates a checklist, updates progress, and checks off completed items.

3. Project rules – use files like goosehints or agents.md to encode persistent preferences, commit policies, testing requirements, and project conventions. These rules steer the agent without you having to repeat them each time.

Together, these features let you have a casual, exploratory conversation while maintaining structure underneath:

• Scope prompts deliberately – keep the dialogue focused.
• Todo extension creates organization when complexity appears.
• Project rules provide invisible scaffolding for better decisions.

No single philosophy is “right” for every situation. Choose the mode that best fits your current workflow, and let goose adapt to you.

# Your preferences are always in play

This is typically how I work. When I migrated a legacy LLM credit‑provisioning app to **Next.js**, many cringed at my approach. However, in context, I was returning to a codebase I'd built eight months earlier and didn't remember well. The app was split across two repositories and I didn't know which one handled what. Writing a `plan.md` file upfront would have been guessing.

So I asked **goose** to analyze both projects and explain how they communicated. I scoped my prompts deliberately: “just the frontend, no API calls.” I had the **todo** extension enabled, knowing it would create structure once the scope became clear. I also had project rules configured to handle commits automatically.

The approach took more back‑and‑forth than an upfront plan would have, but those prompts weren’t wasted effort. They built the context that made the actual migration possible. By the time goose created its checklist, we both understood what needed to happen.

- [Learn more about the todo extension →](https://block.github.io/goose/docs/mcp/todo-mcp)  
- [Configure your project rules with goosehints →](https://block.github.io/goose/docs/guides/context-engineering/using-goosehints)

What’s Your Style?

Goose supports multiple planning philosophies because developers don’t work in a single mode:

• The architect wants clarity before code.
• The director wants control.
• The explorer discovers the plan through the work.

None of these approaches is superior; each fits different situations. The same developer might use /plan mode for a well‑scoped migration on Monday and conversational context‑building for an unfamiliar codebase on Tuesday.

The question isn’t whether to plan—it’s which kind of planning fits your situation today.

Ready to try different planning approaches with Goose?
Start with our quickstart guide or explore the context engineering documentation to set up your scaffolding.