The overengineering tax: when three tiers cost more than one Because that's a real failure mode, and it's the one nobody warns you about. Everyone warns you about doing too little. This is about doing too much, and calling it rigour.
The Complete AI Orchestration Journey: From Claude Web Chat to Production iOS App The reference notes I wrote in November 2025, before BowSmith shipped: four phases, the original 17-agent team, the prompt template that cut context drift, and the failures. Lightly updated, with pointers to where the thinking went next.
Reviewer design: catching what the architect tier misses A model's output is shaped by its assumptions, it brings the identical set of assumptions to the check. So it reads its own work and finds it sound, not because the work is sound, but because author and reviewer share a blind spot in exactly the same place.
Stop prompting, start delegating There's a mode most people never leave, and it has clear symptoms. You write one giant instruction and cram every requirement into it. When the output is wrong, you re-roll the same message with slightly different wording, like shaking a vending machine.
The Chapter, and the Company It Keeps Four weeks ago I put a claim on this blog: trust in software is produced, not felt. Last week I named the four ways AI-assisted delivery quietly stops producing it, and I promised that this post would do something different — walk through what is actually inside the chapter.
Routing rules: which tier gets which task Because here's the thing the token argument clears the ground for. Once you stop chasing the single best model, and stop pretending you can price the decision to three decimal places, the real skill comes into focus. It was never "which model is best." It's which task goes where.
Is the token even the right unit of account? The honest answer is: the token might not be a unit of account at all. That's a problem, because I've spent eleven posts denominating everything in it.