Don't steer the agent, teach it to check itself

Don't steer the agent — teach it to check itself.

There's a debate going around about when to steer a coding agent. One camp says steer it early: a human in the loop in the first minutes, so it never walks down the wrong road. The other says let it run and steer at review, when there's finally something real to look at.

My take: the moment isn't what decides the outcome. What decides it is how well the agent checks itself before it ever opens a pull request. ⚙️

Early doesn't work, because two minutes in you don't know whether your agent is heading somewhere good or somewhere stupid. Recently I was sure it was producing rubbish — then I asked why it went there, and the reasoning was solid and my approach was the invalid one: there is simply no such function in the API. That's its enormous knowledge about the universe overlapping with my imperfect experience of one specific thing. 🤔

Late doesn't work either. You read 1000 lines of change without knowing the research and the path the agent took to get there. It hit a blocker inside its own work and wrote its way around it, and if you don't know the blocker was there, the whole thing reads like nonsense.

So the leverage isn't in picking a better moment to interrupt. It's in what the agent has to survive before it comes to you. Not its own opinion that the work is done — that's the same student writing and grading their own exam. Deterministic checks it must pass: linters, UI tests (Playwright), whatever holds in your stack. Something that isn't the agent, saying yes or no. The less interaction you need while it's still doing fine, the better.

There's a whole direction that says the agent should be steered, and that's cool too — it might grow into the safeguards that actually work. For now, I don't agree, and I'd like to hear from anyone who has made early or late steering genuinely pay off. 👇