AI action plans only work when the developer owns them. IDE-generated checklists from tools like Cursor and Windsurf track what the model is doing right now, but they do not carry the project-level view that keeps a large codebase coherent. This article breaks down four plan types and shows who is responsible for each.
Why your IDE's built-in plan is not your project plan
Your IDE's built-in plan tracks what an AI model is doing right now, not what your project needs overall. Tools such as Cursor, Windsurf, and Claude Code generate useful in-session checklists, but as of 2025 none of them can replace a project plan you write yourself.
AI action plans written by your editor track the model's own work, while the plans that actually control a project must come from you. Tools such as Cursor, an AI-first code editor built on VS Code, and Windsurf, an agentic IDE, now generate checklists as they work: they list steps, mark items done, and keep a running record of what they changed. Claude Code, Anthropic terminal-based agentic coding tool, behaves the same way.
These built-in checklists are useful because they give the model a line of reasoning across a long session. The model can program for extended stretches because it keeps tracking what it has done and what remains. Windsurf, for example, can generate a plan as it develops and update its notes as you interact with it.
| Tool | Plan scope | Plan owner |
|---|---|---|
| Cursor | In-session task steps | The model |
| Windsurf | Running notes updated as it develops | The model |
| Claude Code | Checklist of its own terminal actions | The model |
| Your project plan | Whole application across sessions | You |
The problem is scope. The model has no sense of your project's overall dimension. Ask it for a login screen and it will decide on its own whether to build a password reset flow, create a database, or pick a CSS framework. Those decisions often make no sense in your project, because the AI works task by task on very specific things. In a July 2025 video on the Full Cycle channel, presenter Wesley Willians argued that many of these built-in plans are a trap: developers assume the tool's checklist removes the need to plan, and then lose track of the application entirely when a session ends and a new chat starts from zero.
The global action plan: your high-level map
The global action plan is a high-level view of how the whole project or sprint will be developed, and its ownership sits with the developer. It defines the stages and the order of development, so both you and the AI know where in the process you are at any moment.
In the transcript's example, a global plan for an MCP (Model Context Protocol) server project included items like: set up the development environment, bootstrap an MCP server over streamable HTTP, implement user tools, add notification streams, build a multi-step resumable workflow, manage sessions, and expose everything through a web server. None of these items say how to implement anything. They say what exists and in what order.
You can use AI to help draft this plan, but refining and guaranteeing it is explicitly your responsibility. If the AI ends a session and starts a fresh chat, this document is what tells the next session where the project stands. Without it, the model does not know where it stopped, and it starts to fill the gaps with invented decisions.
The topic-based action plan: what each stage contains
A topic-based action plan is one level lower: it lists what will be developed inside each stage or feature. The developer also owns this document. Where the global plan says 'user tools', the topic plan breaks that into concrete items: user tools built with Better-Auth, a users module with its own Claude-oriented configuration, a user listing, an in-memory event store for resumability, middleware and routes on the web server, and the entry point.
The distinction matters because a topic plan is already granular enough to guide a sprint. Comparing it against the global plan shows the shift: the same features now appear as named modules, data stores, and middleware rather than abstract stages. It answers 'what will be built in this feature' while still leaving 'how it will be implemented technically' to the next level.
The prompt-based plan: making the AI plan inside your rules
A prompt-based action plan is embedded in the prompt itself: you tell the model how to behave and require it to produce a plan under your criteria. This is the level that changes how sessions run, because you move from describing the project to controlling the model's reasoning process.
In the example prompt, the developer defines the model's role and then a workflow: adopt a high-level development strategy, break it into sub-strategies, create a clear action plan based on them, and sketch a sequence of specific, simple, verifiable steps. The same workflow specifies checkpoints. When the model finishes a stage, it either asks permission to continue or hands control back to the developer, or it runs to completion with review afterwards. You choose which behavior applies.
This is where a quality prompt stops being optional. As the video puts it, a decent prompt is not something that is merely 'worth it'; it is something you must have. Editor rules files complement it, but a well-built prompt that fixes recurring workflow failures is the single highest-leverage artifact in this stack. GitHub Copilot and VS Code extensions support similar instruction files, so the pattern transfers across GitHub Copilot and VS Code based setups.
The AI-controlled plan: useful, but it is the model's tool
The AI-controlled action plan is the internal checklist the model generates and tracks itself: it notes tasks, marks them complete, and updates annotations as it codes. This is the first plan type most people see, because the editor displays it on screen.
Its purpose is the model's own session control, not your project control. You can edit those files to help the tool, but the entity maintaining them is the AI. Treating this checklist as a substitute for the other three levels is the mistake. When the session ends and a new chat begins, the model's own plan does not carry the project forward reliably; it does not know where things stopped or how decisions connect, which is when hallucinated changes start to appear.
Action plan versus task: the level that defines implementation
An action plan and a task operate at different levels of detail: the plan gives a general view of what will be done, while the task defines, in technical detail, how one specific item is implemented. Since around 2023, as AI-generated code became common in real projects, keeping these two levels separate has been what stops implementation from drifting. The plan says what; the task says how.
A plan says 'session manager with in-memory store'. A task says: create the SessionData interface, define the basic types for transport, server, and creation, implement the in-memory event store with StoreEvent and ReplayAfterEvents methods, and build automatic cleanup with the basic lifecycle methods.
The three levels can be compared like this:
| Level | Scope | Typical content |
|---|---|---|
| Action plan | Whole feature or project | Ordered list of items, e.g. 'session manager with in-memory store' |
| Task | One plan item | Interfaces, methods, lifecycle steps, sometimes example code |
| Subtask | One complex task | A single focused implementation step |
Tasks carry low-level implementation details and can include example code as a base, so the model has a concrete pattern to follow instead of inventing one. A complex task can expand into subtasks. This is also where the line between a developer who knows what they are doing and pure vibe coding appears: without tasks, nothing defines how the implementation should happen, and the output quality is left to chance.
Scale determines how much of this structure you need. For a throwaway project of half a dozen files, the full layered setup is overkill. As a project grows in complexity and lines of code, these documents, along with automated tests, are what keep it from becoming software you have to rewrite a week later because the AI made uncontrolled changes. By 2025, this layered discipline was widely treated as the practical baseline for working with coding assistants. In every case, AI can help generate and expand the lists, produce examples, and speed up the writing, but the responsibility stays with the developer.
FAQ
- Do I still need my own action plans if Cursor or Windsurf already generate one? Yes. The plan your IDE generates tracks the model's own steps within a session. It does not carry the macro view of your project, the sprint order, or the technical constraints, and it does not survive a new chat reliably.
- Who is responsible for creating the global action plan? The developer. You can ask AI to help draft or expand it, but refining it and keeping it accurate is explicitly your job, because you are the only one with the full picture of the project.
- What is the difference between an action plan and a task? An action plan gives the general view of what will be done and in what order. A task defines technically how one item gets implemented, with enough detail and examples that the model does not invent its own approach.
- Do these plan types work with any AI coding tool? The layered approach is tool-independent. The video's workflow applies whether you use Cursor, Windsurf, Claude Code, or GitHub Copilot, because the plans live in your files and prompts rather than inside one product.
- Is all this structure worth it for a small project? Usually not. For a small project with a handful of files that you can discard, a lightweight plan or none at all is reasonable. The full structure pays off as the codebase, timeline, and complexity grow.
Turn your own workflow explanations into written guides
This article started as a 19-minute video about keeping AI coding sessions organized, and the same move works for your content. If you explain workflows, architecture decisions, or lessons learned on YouTube, that knowledge is locked inside a format that is hard to search and reference later.
Skala Blog turns a YouTube video into a structured written article: paste the URL, transcribe the video, and generate a draft you review before publishing. Brazilian training programs such as Crazystack teach developers to document what they build; Skala Blog handles the transcription-to-article step itself. If your best explanations currently exist only as recordings, converting them into retrievable, citable text is the natural next step.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits