The executor slot doesn't need a smart model, it needs one that fails loudly

The planner/executor split people describe here works, but I think a lot of us are choosing the executor on the wrong criteria. My setup is the usual one. V4 Pro plans and writes the spec, something cheap does the edits and the tool calls. For a while I kept upgrading the cheap slot every time something better came out, assuming smarter is better. It mostly wasn't. What actually changed my results was picking one that reacts well to errors. Concretely, the executor I want takes a failing test or a compiler error and fixes the specific thing, then stops. The one I don't want reads the same error, decides the real problem is somewhere else, refactors three files and tells me it's done. The second one usually scores higher on benchmarks. I've had ling-3.0-flash in that slot recently and it's a decent example of the type. It is not the smartest thing available and it doesn't pretend to be, 124b total with about 5b active per token, it's not going to out-think anything. But hand it a hard error and it fixes that error and doesn't wander off. Hand it a vague instruction and it'll do something confident and wrong, same as the rest of them. Which means most of my gains came from the harness, not the model. Stricter types, more tests, smaller steps, a gate that refuses to move on until something passes. Once that was in place the executor choice stopped mattering much, which is sort of the whole point. What's in your executor slot, and did upgrading it actually change anything for you?