I Built This With the Method It Teaches

This is the last essay in the series, and it's the one I've been most looking forward to, because it's the one where I get to show my work instead of just describing it.

Everything in the first four essays, the memory you own, the guaranteed delivery, the rules that bind, the verification loop that catches drift, I didn't just design it and write it up. I used it. The product that implements this method was built by this method. A frontier model did the planning. A cheaper model did the building. A verification loop sat between them catching mistakes, including the planner's, including mine. And I kept the receipts, because the whole point of this series is that receipts are what make AI work trustworthy, and it would be pretty hollow to make that argument without any.

Let me tell you how it actually went, warts included. The warts are the good part.

Two models, one job each

The setup was simple. One model, the expensive, capable kind, acted as the planner. Its job was to look at the whole codebase, decide what needed to change, and write instructions detailed enough that a less expensive model could execute them without having to make big judgment calls. Precise file paths. Exact acceptance criteria. The instructions were written so that "done" meant something you could check, not something you had to take on faith.

Then a second model, cheaper and faster, acted as the executor. It took those instructions one phase at a time and built. When it finished a task, it didn't get to declare victory. It had to show that the task's acceptance criteria actually passed. The criteria were the judge, not the model's confidence.

If that sounds familiar, it's the same shape as the whole method. Delivery: the planner hands the executor a precise spec. Adherence: the executor's work is checked against criteria it can't talk its way around. The plan was the memory. The acceptance criteria were the gates.

And the interesting part, the part that convinced me this was more than a clever way to save on model costs, was what happened when the two models disagreed.

The time the executor caught the planner

Partway through the build, the plan told the executor to delete a piece of code. Straightforward instruction. Remove this endpoint, it's being replaced.

The executor didn't just do it. It went and checked what depended on that endpoint first, and found that three live features were still calling it. Deleting it would have broken all three. So instead of blindly following the instruction, and instead of quietly deciding on its own what to do instead, it stopped and escalated. It said, in effect: the plan tells me to delete this, but here's the evidence that deleting it breaks working features. How do you want me to proceed?

That's the moment the whole thing earned its keep. Because a single model, working alone, does one of two bad things there. Either it follows the instruction literally and breaks your product, or it improvises a fix and now you've got an unrequested change you didn't know about. The escalation, the stopping to ask when reality contradicts the plan, is what you actually want, and it only happened because there were two models with different jobs and a rule that said reality wins over the plan.

We resolved it. The plan was wrong; it got corrected; the correction got written down so it couldn't happen again. And here's the part that's almost too on-the-nose: the reason the plan was wrong in the first place is that the planner was working from a slightly out-of-date picture of the codebase. Its memory of the project had drifted from the project's reality.

Which is the exact disease this entire product exists to cure. The planner got bitten, mid-build, by the precise problem the thing we were building is designed to prevent. I couldn't have staged a better demonstration if I'd tried, and I promise you I didn't try. It just happened, and I wrote it down, because that's the rule.

The fossil in the plan

There was another one like it, smaller but just as telling. Early on, the planning was based partly on a document the system had generated about itself, a spec describing what the product was and did. And that document was wrong in a specific way: it described a business model I'd abandoned months earlier. It confidently laid out a pricing scheme that no longer existed anywhere in the actual code.

Why? Because the document had been generated from old information and never reconciled against what the code actually did now. It was a fossil. A confident, professional-looking fossil, describing a version of the company that was no longer true.

I want you to sit with how ordinary that is, because it's the whole problem in miniature. The information existed. It was even well-organized. It was just stale, and nothing had forced it to reconcile with reality, so it drifted, and then a model read the stale version and planned around it as if it were true. That is what happens to AI memory without a mechanism that keeps it honest. It doesn't get dramatically wrong. It gets quietly, plausibly, expensively out of date.

Fixing that, teaching the system to regenerate its self-description from the actual current state of the code rather than from its own memory, is one of the pieces of this product. I needed it because I watched its absence cause a real problem in my own build.

What the receipts are worth

I logged all of this. The escalations, the corrections, the moments the executor pushed back on the planner and was right to, the moments I had to make a call the models couldn't. There's a running record of every place the plan met reality and reality won.

That record is the thing I keep coming back to, because it's the answer to the question this whole series has been circling. How do you trust AI to do real work? Not by believing it's smart. Not by hoping it stays on track. You trust it the way you trust any system built from imperfect parts: you build the checks in, you make the failures visible, and you keep the receipts. The AI that I trust isn't the one that claims it never errs. It's the one that shows me every place it might have, and what caught it.

I'll be honest about what this cost and what it saved. The planning, the expensive part, the deep thinking about architecture and tradeoffs, that was a small slice of the total. The bulk of the work, the actual building, ran on the cheaper model, checked against criteria, escalating to me or to the smarter model only when it hit something genuinely hard. That's not just an economy. It's the right shape. The scarce, expensive resource is judgment, so you spend it on judgment and let the cheaper resource do the volume, with checks in between so the cheap volume stays honest.

Which, now that I write it out, is the same argument as the rest of the method one more time. Deliver the knowledge. Bind it with checks. Escalate what the checks can't resolve. Keep the record. It works for a project's conventions and it works for building a whole product, because it's not really about code. It's about how you get trustworthy work out of a capable, fallible thing that will occasionally, confidently, reach for the wrong tool.

That's the series

Five essays. Memory you own, delivery you can guarantee, rules that bind, a clear map of who sees what, and now the proof that I built the thing using the thing. If you've read this far, you've got the whole method. You could go build it yourself, and some of you will, and that's fine, that was the point of writing it down instead of keeping it secret.

For the rest of you who'd rather have it built and installed and taught, that's what I do now, and there's a link below. Either way, here's the one line I'd want you to keep: the future of working with AI isn't smarter models that never make mistakes. It's better scaffolding around models that sometimes do. Build the jig. Keep the receipts.

I'm Kevin Rodenhofer. Thirty years making technology behave, now building and teaching AI infrastructure under my company OuterData Corporation. This was the last of five, get in touch for the course, or reach out if you want the method installed for your team. Thanks for reading. It means more than you'd think.