Best Practices: Implementation Plan
Implementation plans make collaboration with AI coding agents easier to steer, understand, and review. Their structure, use, and distinction from plan mode are what matter.
Introduction
In my previous post, I introduced the bootstrap prompt as a central control instrument for giving AI coding agents the project context they need. The bootstrap answers the question, “What does the agent know?” It ensures that the agent understands the project’s architecture, conventions, documentation, and rules.
The implementation plan covered in this post addresses the implementation of a feature — the “how.” Even with a good bootstrap, there is no guarantee that the agent will implement the task at the desired quality and within the defined scope. Instead of letting agents start immediately, we first have them create an implementation plan that breaks the feature into sequential implementation steps. As developers, we remain human-in-the-loop (HITL) and are responsible for reviewing and approving the proposed steps.
Since the release of the latest frontier models, however, I have increasingly encountered the claim that implementation plans have become obsolete. As of July 2026, models such as Claude Fable 5 and GPT-5.6 Sol are indeed capable of implementing complex features without a plan. Whether that means we should abandon the plan as a control instrument deserves a more nuanced discussion.
What Is an Implementation Plan?
An implementation plan is a Markdown document or a dedicated artifact in the tool being used that breaks a feature into sequential tasks for an AI agent. The tasks describe the necessary implementation steps at a, well, “reasonable” level of detail. Finding the right level is not always easy in practice. Implementation plans are not written manually; they are created by agents. Depending on the model and reasoning effort, agents tend to produce implementation steps with varying amounts of detail. In my experience, an overly detailed plan is counterproductive. It can cause the AI to follow the plan too rigidly during implementation without understanding the bigger picture or considering sensible alternatives. The plan then resembles a poorly written ticket that specifies too much up front. Many details emerge only during implementation, when the AI anchors the feature in the codebase and discovers the relevant interfaces and patterns. An overly detailed plan can therefore restrict the AI’s creativity and lead to suboptimal solutions. In fact, I suspect that this problem is why parts of the community recommend letting frontier models work without a plan. A “bad” plan is worse than no plan at all.
A good plan structures a feature into the relevant implementation steps at an appropriate level of abstraction. In a layered backend application, for example, it defines which layer to start with (top-down or bottom-up), whether tests should be written first, and how interfaces should be approached. The plan does not contain concrete class or method names. Those details emerge during implementation. A good plan therefore describes the architecture of the implementation process, not the concrete implementation. The easiest way to achieve this is to document modeling rules for implementation plans and give them to the AI as a reference.
Elements of an Implementation Plan
As mentioned above, the plan must define the relevant implementation steps and their order. Each step should include:
- Goal: A one-line statement of what the implementation step should achieve
- Scope: A concrete list of which part of the feature specification will be implemented in this step (e.g. “Implement the API endpoints for survey management,” “Create unit tests for input validation”)
- Out of scope: An explicit boundary of what will not be implemented (e.g. “No changes to the database schema,” “No changes to existing interfaces”)
- Acceptance criteria: Measurable done-when conditions for the step (e.g. “All unit tests pass,” “The API returns the expected results x, y, and z”)
- Decisions: When initially creating an implementation plan, agents often ask for decisions they cannot make themselves. Our answers should be documented in the plan so they remain traceable during implementation and later reviews.
- Reference documents: Links to the feature specification, data model, architecture documentation, and related sources
An example implementation plan is available here: Implementation plan for the “Survey Management” feature.
Will We Still Need Plans in the Future?
As mentioned earlier, more practitioners now want to skip implementation plans when using the latest frontier models. Their argument is that the models are powerful enough to implement even complex features without a plan. I take a more nuanced view. Frontier models can implement complex features without a plan, but the quality of the result still depends heavily on the quality of the prompt and requirements (in our case, the feature file).
Without an implementation plan, we lose an early checkpoint for aligning on the requirements, scope, and implementation strategy. Misunderstandings may then surface only during code review. In practice, comparing a compact plan with the requirements is usually easier than comparing a large diff with them in full. A plan does not guarantee a good implementation, but it exposes questionable assumptions earlier.
Cost also matters. Creating and reviewing a plan initially consumes time and tokens. For complex or high-risk features, that investment can pay off by catching wrong turns before they produce a large amount of code and costly rework sessions. For small, clearly bounded changes, the planning overhead may exceed the benefit. An implementation plan is therefore not an automatic cost saver; it is a way to limit rework risk.
Six months ago, I recommended a plan for practically every implementation task. Today, I consider one necessary primarily for complex or architecturally significant changes. For simple tasks, a capable frontier model can start implementing directly. That boundary will probably continue to shift as models improve. It is quite possible that, in the foreseeable future, we will also be able to implement complex features without a plan.
Plan Mode vs. an Implementation Plan in Markdown
Another practical question concerns the form of the implementation plan. In recent months, several AI coding agent vendors have introduced native Plan Modes for creating, reviewing, and then implementing a plan directly in the tool. This makes the transition from planning to implementation more fluid.
Native Plan Modes and Markdown plans are not mutually exclusive. How persistent and shareable a plan is depends on the tool: some tools keep it primarily within the session, while others can save it to the workspace or create a file from the outset. Cursor, for example, can save plans to the workspace, Codex can combine Plan Mode with a PLANS.md workflow, and Amazon Kiro creates a versionable Tasks.md file as part of its spec workflow.
Tools such as Amazon Kiro and Google Antigravity also provide well-integrated review features for commenting on, approving, or rejecting individual implementation steps. As a result, working in Plan Mode is often smoother than a completely manual Markdown workflow.
A deliberately versioned Markdown plan stored in the project still remains independent of the tool being used. The team can review it together, agents can access it across multiple sessions, and it records decisions for later reviews or audits. For complex features, I therefore still prefer a versioned Markdown plan.
Conclusion
As of today, an implementation plan remains a valuable tool for steering collaboration with AI coding agents and exposing misunderstandings before implementation begins. Even when frontier models can implement complex features without a plan, a well-structured plan improves control, traceability, and team communication. Whether that effort is justified depends not only on model capability, but also on the complexity, uncertainty, and risk of the change.