A few weeks ago I wrote about context engineering and RPI after watching Dex Horthy’s talk. My colleague Pierre-Luc Godin (PL) read it and wanted to dig into one point. What followed was a classic “someone is wrong on the internet” moment - PL couldn’t let it go, and the conversation was worth sharing.

The point he dug into: I described each phase of Research-Plan-Implement as “a compression step.” That’s true. But there’s more to why the workflow actually works.

The Original Framing

In my previous post, I described RPI like this:

Research compresses the codebase into understanding. Plan compresses understanding into intent. Implement compresses intent into code. Each phase is a compression step.

The mental model was: you have this massive codebase, way too big for any context window. RPI lets you progressively distill it down until you have something small enough to execute reliably in the “smart zone.”

This framing is true. Context management matters. The dumb zone is real. Compaction at the right moments keeps you out of trouble.

But if compression were the whole story, something wouldn’t add up.

PL’s Killer Point

Here’s what PL said that got me thinking:

“If it was just compaction, Haiku could do the research and plan.”

If the only value of the research phase were producing a smaller artifact, you wouldn’t need Claude Sonnet burning expensive reasoning tokens on it. A cheaper, faster model could read files and summarize them just fine. Compression is compression.

But that’s not what happens in practice. You need the reasoning capability at each step. Not because the output needs to be smaller - but because something is being produced at each step that didn’t exist before.

PL again: “You need those reasoning tokens at the right steps. Even if you could fit all the relevant source files inside the ‘smart’ zone, you wouldn’t get good results if you skipped the research and plan phases. The process matters.”

This isn’t about context window size. It’s about where thinking happens.

Three Insights That Refine The Model

After going back and forth with PL (and re-watching parts of Dex’s talk), three things clicked that sharpen the mental model.

1. Optimal Compaction Points Emerge From The Workflow

PL’s point reminded me of something from poetry, of all places. Cavafy’s “Ithaka” captures it:

Keep Ithaka always in your mind. Arriving there is what you’re destined for. But don’t hurry the journey at all. Better if it lasts for years…

Ithaka gave you the marvelous journey. Without her you wouldn’t have set out. She has nothing left to give you now.

And if you find her poor, Ithaka won’t have fooled you. Wise as you will have become, so full of experience, you’ll have understood by then what these Ithakas mean.

Compression for the sake of compression - without the thinking, without the process - gets you Ithaka without meaning. A smaller artifact, sure. But hollow. You skipped the voyage that would have given it value.

Compacting mid-research yields worse results because you haven’t learned what’s safe to discard yet. You’re still figuring out which files matter, which patterns exist, which assumptions hold.

But after research completes? Now you know. The journey has taught you what matters. That’s a natural point to compress - not because someone prescribed a waypoint, but because you’ve finally arrived somewhere worth pausing.

As PL put it: “When you’re done researching, you can discard more accurately: it’s the optimal point to compact.”

We’re not arbitrarily stopping to compress. We’re compressing at the moments when compression is safe - because the journey has reached a point where we finally understand what matters.

2. The Plan Step Produces Something New

Here’s something interesting about RPI artifacts. A research document is typically around 200 lines. An implementation plan is also around 200 lines. Similar size.

The LLM can generate the plan from the research document with no new external information. It doesn’t need to read more files. It doesn’t need to search anything. Everything it needs is already in the research doc.

Yet the plan is a fundamentally different artifact. You can’t implement directly from research notes - they describe what is, not what to do. The transformation from “here’s how the system works” to “here’s the exact sequence of changes” requires reasoning that creates something new.

The value gets created in the transformation, not at either end.

Dex makes this point in his talk when he describes what a good plan looks like: “A good plan has actual code snippets of what’s going to change. When you read it, you should be able to see very easily how even a dumb model isn’t going to screw this up.”

That clarity doesn’t exist in the research doc. It’s produced by the planning step. The reasoning tokens spent on planning aren’t compressing information - they’re transforming it into a different shape. A shape that makes execution mechanical instead of creative.

If compression were all that mattered, you’d expect the plan to just be a shorter version of the research. But it’s not shorter. It’s different. The output is different from the input in kind, not just size.

3. The Process Dictates Quality

This is PL’s conclusion, and I think it’s the key insight:

“If your flow is A → B → C, you may very well find optimal compaction points between steps, but defining A, B, and C is just as important. You’re not just funneling context from your entire codebase into a code diff - you’re working through a very specific process.”

The compaction points matter. But which points you stop at matters more.

Research → Plan → Implement works because those three phases match how developers actually think through problems. It’s not arbitrary. A different decomposition - say, Research → Implement directly, or Plan → Research → Implement - would produce different results even with perfect compaction at each boundary.

PL again: “A → X → C will yield different results. The process is the fundamental thing that dictates your results’ quality. It may be bottlenecked by inefficient compaction or context exhaustion, but the process is fundamental.”

We’re not optimizing context management for its own sake. We’re following a cognitive workflow that happens to have good compaction properties. It’s the other way around: good workflows create good compaction points, not the reverse.

The Refined Mental Model

So how should we think about RPI?

Compression is the mechanism. The workflow is the architecture.

The “dumb zone” is real - you do need to manage context. But context management is a constraint, not the goal. The goal is following the right cognitive process. Compaction is just how you sustain that process across the limits of current models.

The HumanLayer team has a useful framing for this. They talk about “leverage” at each phase: errors compound upstream. A wrong turn in research costs more than a wrong turn in code.

That’s why human review leverage is highest at the research and plan phases - that’s where the direction gets set.

But notice: this leverage model isn’t about context size. It’s about where thinking happens. The expensive reasoning tokens matter most at research and planning because that’s where the shape of the solution gets determined. Implementation is just following the path you’ve already charted.

This also explains why you can’t skip phases even with infinite context. The value isn’t in making things smaller. The value is in transforming understanding into intent into action. Each transformation requires reasoning. The journey is the point.

The Journey Is The Point

Let me connect this back to Dex’s original insight: “AI cannot replace thinking. It can only amplify the thinking you’ve done - or the lack of thinking you’ve done.”

But now we can be more precise about where that thinking needs to happen.

It’s not enough to “stay in the smart zone.” You have to work through the right cognitive steps. Research produces understanding that didn’t exist before. Planning produces intent that didn’t exist before. Each step generates something - it doesn’t just compress something.

The compression framing isn’t wrong. It’s just incomplete. Yes, you’re taking large things and distilling them smaller. But along the way, you’re transforming them into different kinds of artifacts. That’s where the value gets created.

PL dug into something worth exploring, and now the picture is sharper. Compression matters. Context management is real. The dumb zone will bite you. And the steps between compressions are where the actual thinking happens.

Thanks for not letting it go, PL.