RPI → RPIQ: the method that made AI build production software

Part 4 of "From Vision to Production." Publishes Tue Jul 14, 2026.

For the first stretch of this project I didn't have a method. I had a chat window, a vague plan, and a lot of optimism. It got me surprisingly far and then it fell over — not because the model wasn't capable, but because I wasn't giving it a system to be capable inside of. The turning point wasn't a better model. It was a repeatable loop.

That loop is the single most useful thing I built in eighteen months, and it's what the rest of this series hangs on. I call it RPIQ.

From RPI to RPIQ

The starting shape was borrowed and obvious: Research → Plan → Implement. Understand the problem, decide the approach, write the code. It's how any careful engineer already works, and pushing the model through those stages instead of jumping straight to "write me a screen" immediately raised the quality of what came back.

But RPI had a quiet failure mode. Quality lived inside Implement — a thing you hoped happened while the code was being written. At machine speed, hope is not a plan. Bugs, dead code, and confident-but-wrong changes slipped through because nothing owned catching them. So I promoted Quality out of Implement and made it a stage in its own right. Research, Plan, Implement, Quality — each with its own inputs, its own outputs, and its own standard of "done." RPI became RPIQ, and the whole thing stopped leaking.

The important shift isn't the extra letter. It's that Quality became something the loop is designed to produce, not something you inspect for afterward.

Context engineering: killing the drift

The second thing that changed everything was realizing that my real job wasn't writing prompts. It was engineering context.

Long sessions rot. The model starts sharp, then slowly loses the thread — it forgets a constraint we agreed on twenty messages ago, contradicts an earlier decision, re-solves a solved problem. I used to blame the model. It was my fault: I was feeding it an ever-growing, ever-mushier pile of conversation and expecting it to stay precise.

The fix was to stop improvising and start using reusable prompt templates that pin the context down every single time. Same structure, same slots, filled fresh for each task. Measured across the project, that one discipline cut my context drift by roughly 80%.

The anatomy of a template

A good template isn't clever wording. It's four boring, load-bearing parts, in the same order, every time.

Role sets who the model is acting as and the standard it's held to. Context pins the facts that matter — the relevant code, the constraints of the codebase, the decisions we've already made — so nothing has to be remembered, only read. Constraints say what it must not do: scope limits, style rules, the boundaries it keeps wandering across. And Evidence request is the one most people skip: I require the model to hand back proof — the tests it ran, the diff it produced, the reasoning behind a choice — so I'm reviewing evidence, not vibes.

Fill those four in and the model has almost nowhere to drift to.

The four surfaces I actually manage

Once the loop and the templates were in place, I noticed my day had reorganized itself around four surfaces of control — the places where I'm actually steering the work:

• Work routing — deciding which task goes where, and in what order.
• Context engineering — the templates above, keeping every task grounded.
• Evidence production — insisting the work returns proof of itself.
• Gate design — building the checks that decide what's allowed through.

Those four overlay the RPIQ loop rather than sitting outside it. Manage them well and the loop runs; neglect any one and quality quietly slips back inside Implement where you can't see it.

See it live at CAST26

This method is the spine of everything I'm presenting on stage — the loop, the templates, and the four surfaces, running against a real production codebase rather than a demo. If you want to watch RPIQ work in practice, come find the talk at CAST 2026 (CAST26), August 3–5, in Cocoa Beach, FL.

Next week: what happens at the Quality stage when there are seven thousand tests and no human fast enough to read them all.