Everything We Got Wrong About Research-Plan-Implement - Dexter Horthy

The Research-Plan-Implement (RPI) methodology, once a promising approach for AI-driven development, has shown significant flaws in practice. While it was adopted by thousands of engineers, its effectiveness was inconsistent. Experts could achieve great results, but when the methodology was given to broader teams, the outcomes were often poor. This led to a critical re-evaluation of the process.

The core issues stemmed from engineers outsourcing the thinking process to the AI. This manifested in several ways: generating research artifacts tainted with opinions by telling the model the goal upfront, and relying on “magic words” like “work back and forth with me” to coax the desired interactive behavior from the agent. The year 2026 must be the year of “no more slop,” emphasizing craft over rushed, low-quality output.

The Failure of Monolithic Prompts and the “Instruction Budget”

A key reason for RPI’s unreliability was its reliance on a single, monolithic prompt with over 85 instructions. LLMs have a finite “instruction budget”—frontier models can only consistently follow about 150-200 instructions before their adherence degrades. When a single prompt contains too many steps for control flow (e.g., present design options, get feedback, then write the plan), the model often skips critical alignment steps, leading to suboptimal results.

The solution is to stop using prompts for control flow and instead use control flow for control flow. By breaking the monolithic process into a series of smaller, more focused prompts, each with a much smaller instruction count (under 40), the system becomes more reliable and predictable. This approach is a practical application of “Context Engineering,” focusing on simpler tasks and better instructions rather than just stuffing more information into the context window.

From RPI to CRISPR: A More Structured Workflow

A new, more robust methodology has been developed to address the shortcomings of RPI. This process, nicknamed CRISPR, breaks down the development process into more granular, manageable stages:

1. Questions: Generate questions to guide research.
2. Research: Create an objective, fact-based document about the current state of the codebase, deliberately hiding the implementation goal from this context window to avoid introducing opinions.
3. Design: A collaborative design discussion to align human and agent.
4. Structure: An outline of the implementation phases.
5. Plan: The detailed, tactical plan for the agent.
6. Implement: The actual code generation.

This structured approach ensures human ownership and provides multiple opportunities to steer the agent before code is written.

High-Leverage Artifacts for Human-Agent Alignment

The new process introduces key artifacts that create leverage and facilitate alignment, moving away from reviewing long, thousand-line plan files.

• The Design Discussion: This is a concise (e.g., 200-line) Markdown document that acts as the “shared understanding” between the engineer and the agent. It forces the agent to externalize its findings on the current state, desired end state, relevant patterns to follow, and open questions. This allows the engineer to perform “brain surgery” on the agent’s understanding early, correcting bad assumptions (like following a deprecated pattern) before they derail the project.

• The Structure Outline: This document outlines how the work will be done, serving as a high-level blueprint of the implementation phases. It’s analogous to a C header file, showing the signatures and types without the full implementation. Its primary benefit is enforcing a vertical plan, where features are built in testable, end-to-end slices (e.g., API endpoint -> service layer -> database). This contrasts with the AI’s natural tendency toward horizontal plans (e.g., all database work, then all service work), which are difficult to debug when they inevitably fail.

The Importance of Reading the Code

The initial advice to “not read the code” and trust the plan was wrong. Experience over the last six months has shown this leads to significant rework. While projects like openclaw may not have every line read by a human, the stakes are different for production SaaS code in regulated industries. Engineers must own and read the code they ship.

The goal is not a 10x speedup that produces unmaintainable “slop,” but a sustainable 2-3x improvement that maintains a near-human level of quality. The structured CRISPR process facilitates this by front-loading alignment. When a 200-line design document is reviewed by the team, course corrections are cheap. By the time the code is written, the formal code review is often a simple confirmation, drastically reducing rework and improving team velocity.

• Tags:
• Software Engineering
• Prompt Engineering
• LLM
• Context Engineering
• Developer Productivity
• Coding Agents
• RPI
• CRISPR