Research, Plan, Implement!

Research, plan, implement (RPI) is my favorite way to approach building with generative AI when I am maximizing for quality. It was also how I built prior to generative AI, as you probably did as well. In it's most basic sense, it means to do research before making a plan to implement your feature. Sounds like the core loop of software development...and it is! Maybe always will be. Let's look at what this means in the world of generative AI.

Why should I care?

Natural language in inherently ambiguous. No matter how clear you think you are, you likely are leaving ambiguity on the table when working with a human language like english to give instruction and define the behavior of software. Second, we have the model context window as a hard limitation. There is ultimately only so much context you can use in any single session with AI. And even with a 1 million token window, you start to get higher surcharges at 150k+ tokens, and using much less of the window will tend to give you better results by staying in the "smart zone" and avoiding compaction which produces a less detailed view of the context through summarization. This leads me to 2 conclusions:

1. I should decompose the work into chunks that fit the context window for best quality results.
2. I need to know how the model interprets my instruction

Both of these are mitigated through planning. The plan is the AI telling us what it will do based on our instructions. This gives us the ability to stop, read, reflect, and make sure we want what the AI is telling us as well as helping us to see unknowns which we might have missed before being confronted with a concrete plan. It also can serve as a reviewable artifact that can be used to align with other people on the team. In both cases, other people and the AI itself can help us to see what we do not yet. Which brings me to the last reason why I plan:

I want to make the decisions. I am not looking to give decisions up to the LLM for technical or product questions. And doing research gives me the basis for knowledge to make those decisions while the plan is a forcing function to surface those points to make an informed decision.

What is RPI exactly?

Research, plan, implement, is a mindset moreso than a specific tool. It is a workflow that can scale up or down based on the task size at hand. Your specific goals in each in terms of what specific kind of artifact you are producing can vary greatly base on the task, but the goal in each phase is the same, no matter the size of the task:

• Research: The goal here is for you to learn. Make sure you understand the task you are working on as well as the context of it (architecture, codebase, product requirement docs, etc). Use this time to learn and surface questions you do not have the answer for and to either talk to the right stakeholder or learn with the internet, internal docs, etc.
• Plan: The goal here is to align with others and to continue to surface your ambiguities with regard to the task. Others means your teammates in engineering, QA, Product, Design, leadership, but also the AI model. This varies based on the size of the task. For instance, an architecture review for a new service has totally different concerns than the already broken down story to add a new widget to the dashboard. In the latter, we care more about what the AI is going to do than what the leadership thinks of this feature, but if we are adding a new piece of expensive infrastructure to our service, leadership might care. We are aligning with others and leaving the correct decision maker to make the decisions that are consequential to the product or engineering concerns.
• Implement: The goal here is to actually do the task. For a user story, this might mean writing the code to do the thing: writing tests, fixing bugs, and raising a PR. In contrast, at the start of a new project, this "implement" might really be to create the Jira backlogs so you can start delegating the work to others.

Because of this, I like to view RPI more as a mindset since it can scale up and down depending on what you need at that moment rather than a rigid set of rules, given the loop that is the software development lifecycle (SDLC) is fluid. In many cases you might collapse the research and planning to one session because you have the handoff artifacts from your product team (those also being the implementation of the product RPI flow of figuring out user requirements using a variety of data sources and methods and ultimately documenting them for engineers to build). Other cases, you might spend days or weeks learning and prototyping (research, primarily) in order to find the right plan for your team to execute on.

Spec driven development

You might have come across this concept before through the name spec driven development (SDD). This term was given to ways of working that focus around "specs". Now this is not referring to real specifications, but rather referring to md files holding guidance on architecture, product decisions, user flows, designs, etc. There are a lot of frameworks for SDD ranging from tools like speckit, prompt frameworks like bmad, or whole IDEs like Kiro. This is just a more opinionated way to doing the basic functions of research and planning with specific types of documents that each of those approaches use with specific forms to capture all the information needed to later implement those tasks. As well as with ways to manage the work (many times also focused around checking off boxes in a md file). But, you do not need a heavy and opinionated framework to do this. Full disclosure, I use none of the above tools in any serious capacity, though there are parts I like conceptually of each and this is neither a criticism nor endorsement of any specific tooling

Light weight RPI

The lightest weight version of RPI is to simply use plan mode in your coding harness of choice and then when you are happy with the plan, "implement". In the majority of coding harnesses like Claude code or Cursor, plan mode enables deeper research, firing off an "Explore" subagent to read through your local files. This is preferred to simply asking the AI for a plan since it if does not do that deeper exploration, you will miss out on important context. In both cases, you are aligning with the AI, but without the enablement of that research beforehand, you can miss out on finding the right solution. Try this yourself and see the difference between a plan made with and without plan mode on.

Now, for breaking down the larger session work into more digestible chunks, is going to require more up front planning work. For this, project management software is very nice to use given something like a Jira story has a defined lifecycle and lives within a structure (like the epic it is a substory of) and can be related to other tasks that have to happen in parallel or before. When planning the big work, I try to push some ambiguities and decisions to later in the dev cycle as long as I can research enough information to make the good large decisions first. Thinking about things like technology choice as well as the order of operations of the work to make the feature slice or epic happen. I am also trying to surface unknowns to me from product or design for those stakeholders to decide on. This way, when I plan out the rest of the work, all the large decisions are made and we are free to deliver the code.

Minutes in planning prevents hours of rework

I don't recall the first time I heard a quote like this, but it was early in my software career. As we started our half day of planning on my first team as a full time employee at Amazon, and we groaned (because half day or more is a LOT of discussion around stories for a 2 week sprint), someone said this quote "hours planning saves days of execution". Well even if execution of a story that would take 3 days can now be done in an afternoon, we still need to make sure we are doing the right work in the first place and that all our standards are still met. Both of which require that alignment across other stakeholders as well as the AI itself.

The more you can understand through your research and the more you align with others in the planning stage, the less rework you need to do later. This compounds of course, too. A wrong assumption in your research will lead you to make bad decisions in the plan which could result in unusable work or unmaintainable software. Or missed assumptions can lead to the wrong feature being built. Those produce much more work in the end compared to figuring it out before tens of thousands of lines of code is written. Or even before you create a dozen Jira stories, it's a good idea to make sure your team understands the need for them.

I have taken to truly nitpicking the plan to make sure that my requirements are being met and that I am in full alignment with every word in the plan when it comes down to code-level plans. Even if you do not go quite this in depth with your review, just know that the more you do up front, the better your output will be long term. It's a lot less to review the plan in depth than reviewing the changes after your agent did a bunch of stuff.

My toolchain

So my personal toolchain has changed a bit over the past few months, but currently, it is the following:

• harness: pi.dev
• plugin: Plannotator.ai for plan mode and local review tools. This is vital to me and works great in other harnesses, also like Claude code. In all cases, it uses a harness hook so that when the plan file is written, it opens it in localhost website and allows you to annotate line by line and then pass that feedback in a structured way back to the agent loop. 10/10
• agents: Pi extension to allow for subagent definitions and managing work in secondary sessions (including adding an Explore-like agent definition for that deep exploration of the codebase). This happens by default in most harnesses I have used.
• skills: orchestration skill for executing a plan. Skill for managing backlog items according to your team process.
• Cloud environment: I am using a self-hosted Coder with docker-based snapshots for sandboxing and environmental level separation. Prior to this, I was using Cursor Cloud environments. Both are primarily for implementation so you can replicate the environment to do parallel work in addition to having good separation of concerns between repos or projects.
• Some other subagent and skill definitions along with custom extensions not super important for sake of this discussion.

Part of my flow also is to denote which parts of the plan can be broken down and parallelized. For larger projects where I work with other engineers, I also use Linear.app or other project management software to help manage the larger work with more people involved. Otherwise, I tend to just keep my md plans, research files, and "backlogs" in files in a docs folder in the repo. If you hold these in code, make sure to have a process to clean them up from time to time because the drift between real life and old plans will cause problems longer term. I do not prefer to commit these types of files, but it is sometimes necessary without another place like project software to manage the plan in order to make use of cloud environments.

Matt Pocock Skills

There are other notable tools that I do not use on the daily, relevant to this RPI workflow, but also are not full SDD frameworks. The biggest repo of skills that I recommend to others and use for my own inspiration is the Matt Pocock skills repo. In particular, Wayfinder and grill-me are the skills that most help with the hard problems of planning large work. Wayfinder helps you to break the work down and grill me helps you to surface ALL ambiguities that you and/or the model might have over your plan before going forward to implement it. These can take a lot of time to go through the grilling session, so please keep that in mind you are doing a hard thing when using these skills! You can use his repo as more of a framework, but the individual skills tend to work as standalone tools, as well.

Downsides?

Like all things, there are downsides to planning. For one, it's hard and you don't always know what you want right away. Planning, especially if you are really doing due diligence on research and understanding everything about the problem space, is a slow process and it will slow you down to something functional. So if you are making something that is somewhat disposable software or are straight up vibe-coding and don't care about long term maintenance, stability, scalability, etc, writing detailed plans is probably overkill to get where you want to be. And I do vibe code disposable software for myself from time to time, though I do use plans, I don't do so as rigorously as a I might for a more serious project. Though I do often think about the saying "there is nothing more permanent than temporary software" which has been true more times than I want to admit in my career...

For anything serious, you will want to make a rigorous plan, but you can still gain the rapid prototyping benefits of vibe coding as a part of the research and stakeholder alignment process which is perfectly fine and still fits the RPI methodology! A prototype is a fantastic way to align with other stakeholders including your customers and GenAI gives the perfect affordance to make something good enough for a prototype with little effort. I encourage you to consider this as a part of Research and Planning stages of a project and not to be afraid to throw away the prototype, especially if it is fully vibe-coded. Many times, it is more work to fix the problems in a not thought through vibe-coded piece of software than it is to use it as input to a better plan. Especially true if this is outside your core system.

Try this: Plan Maximalism

To really get started and see how often planning can be helpful, I encourage you to try using plan mode in new ways. Here are 3 different things to try:

1. Use plan mode to do a well-defined medium sized piece of work. Even if you think it's all written perfectly, try with and without plan mode in the same codebase and same prompt and observe the differences and see which you prefer after you implement.
2. Try to use plan mode for everything for a few days. Don't do a single task without creating a plan first to do that task. For instance, make a plan to address feedback from a PR, or make a plan based on a plan to create backlogs in Jira. You will likely find that it's extra steps, but you are much less likely to be surprised at the model doing something strange if you do this. Give it a try and see what new types of plans end up being helpful to your workflow.
3. Do some high level planning with AI including generating some intermediate files including a high level plan, maybe architectural decision records or other mechanism to capture needed information, and maybe some research files for summaries of how key services work. Spend time to understand the problem space and then capture the work in a way that it can be acted on in smaller chunks that roll up to a large feature. And if you do this already in your daily work, try really thinking about where your data comes from that you need to do this planning and making sure you can fill in the gaps you see on your next large task. Breaking down a large and complex set of features is likely to span multiple AI sessions, so think about what types of artifacts you need to create in order to not lose necessary context.

I have used plans before allowing AI to write scripts, run scripts, create backlog items in Linear or Jira, modify skills, and of course before modifying runtime or infra code. That alignment with the AI, alone, and knowing what it will do at least at the high level before it happens is invaluable to reducing the rework and code-level nitpicks I would otherwise have. Give this way of working a try for a few days and see the benefits of model alignment! Track how many times you change your instruction to AI based on what it tells you in the plan.

RPI, All Day, Every Day

RPI workflow and mindset is the biggest lever you have over quality outcomes when working with generative AI. By using genAI in different ways depending on the phase you are on: as a brainstorming and idea backboard, to surface ambiguities, and to align with others, we end up with far better thought in our plans than just telling the AI what to do and giving a loose goal, no matter how large and detailed our prompt is. By using this workflow, we give ourselves many opportunities to align across stakeholders, check our own knowledge, and ultimately do less rework when it comes down to writing the code or doing whatever task AI is helping us with. We can produce intermediate files that serve as a compression of what the AI will do for easier review with ourselves and others and to work around those context window limitations for larger work. And we can scale this approach up and down depending on what we need to achieve.