Vibe engineering with Opus 5.5? route by the feedback

There are two camps right now. One uses "serious" AI for real work and treats everything else as a toy. The other just vibes: one chat, one model, whatever it says goes. I think both have the split wrong.

Vibing is fine when the feedback is cheap. If the model writes a function and a test tells you in two seconds whether it works, let it rip. The trouble starts when the same model, at the same setting, gets pointed at a race condition, a migration you cannot undo, or a failure that only shows up when the frontend, the API and the database disagree.

So I stopped asking "which model is best" and started asking one question before every handoff: what comes back when this thing acts?

The rule: the feedback shape picks the model

I run several AI coding sessions at once, across Claude Code, Codex and Cursor. My rule gives every piece of work one of four roles. The role decides the model and how hard it thinks. The importance of the project does not.

Role	What the work looks like	What I run
Navigator	Talking about code: plans, briefs, reviews, docs	Opus 5.5 at high effort
Builder	Running things: builds, tests, containers, migrations, correcting itself from the output	Opus 5.5 at extra-high, with Grok fast as the quick executor (below)
Diagnostician	A real signal to iterate against: a stack trace, a failing assertion, an exit code	Fable when I have it, otherwise Opus 5.5
Surgeon	One wrong line causes a loss you cannot undo: auth, money paths, irreversible migrations	Fable at extra-high, stepping up to max on the second failed attempt. Otherwise Opus 5.5

The order I ask the questions in matters more than the table:

1. Could a mistake here cause a loss I can't undo? Surgeon.
2. Is it many files of the same mechanical change? Fan it out.
3. Is there a real signal to iterate against? Diagnostician.
4. Does it need to run things? Builder.
5. Otherwise it's talking, so Navigator.

Without a rule stated up front, a session picks the comfortable setting, usually "high effort on whatever model is loaded". Then it grinds on a concurrency bug that needed the top setting, or it spends the top setting reading a directory tree.

The execution lane: fast is not the same as thorough

This is the part that surprised me. For pure execution (run the command, read the output, fix, run again), Grok in fast mode is the quickest executor I have. Grok 4.6 has written more code in my Cursor sessions than any other model, about twice the next one. When the loop is tight and the signal is clear, speed wins.

Speed has a blind spot, though. A fast loop tends to fix the symptom in one layer and move on, and the failures that hurt live between layers: a frontend change that quietly breaks an API contract, a migration that disagrees with the ORM, an environment variable that exists locally and nowhere else.

So nothing a fast executor finishes counts as done until a slower pass has read it across the stack. When the work is wide rather than deep, I fan it out: Sonnet workers do the mapping, exploring and first reviews in parallel, and Opus verifies what they bring back. Cheap and wide first, careful and narrow last.

So the rule inside the Builder role is simple. Tight loop, clear signal: Grok fast. Anything that touches more than one layer gets a slow verify pass before it counts.

You don't need the top model to run this

Fable sits at the top of my list, and I don't always have it running. When I don't, Opus 5.5 takes the Diagnostician and Surgeon roles, and before this week Opus 5 did. It held up. Opus 5.5 shipped this week at a lower price, with coverage calling its performance Fable-level, which makes the fallback even cheaper.

The routing matters more than the model. A mid-tier model in the right role beats the best model at the wrong setting, because the wrong setting fails in a way you only notice later.

Vibe engineering

None of this makes the work less fun. The interface can stay as simple as a chat. The engineering is in three decisions a web chat never makes for you: which role this is, which model plays it, and what has to be true before its work counts as done.

That's what I'm building into Code Desks: each desk is a role, a model and a gate, and you run the office from the terminal. It's early and it's open source.

Vibe coders, it's your time to vibe engineer.

What does your routing look like? One model for everything, or have you split execution from diagnosis yet?