Don't Prescribe the Road. Make the Model Defend It.

Photo by Gennady Zakharin on Unsplash.

I used to believe that if I wrote detailed enough instructions, AI would stay on the rails.

So I did the responsible thing. I named the files. I named the sequence. I named the pattern. I tried to remove ambiguity before the model could invent any.

It still surprised me.

Not always in small ways. Sometimes it did an entirely different thing than what I thought I had asked for. Then I clarified. Then it surprised me again. Then I got frustrated, because I had already spent the energy of deciding the path, and I still had to spend more energy cleaning up a path I never wanted.

That was the first lesson: detail is not the same as control.

What I was practicing was a kind of false control. I scripted every turn so nothing could go wrong, then felt responsible because I had micromanaged. The work still wandered. The clarifications still piled up. The only thing I had really bought was the feeling of being thorough.

What worked better

The habit that helped was almost the opposite.

Instead of handing over a finished recipe, I asked the model to tell me the path it intended to take. Then I grilled it.

Why this approach and not the other one? What breaks if we do it that way? Which existing code does this assume? What would you refuse to change? Where is the risk?

That conversation changed the quality of the work. Not because the model suddenly became smarter, but because the decisions became visible before they became commits. Once the path was out in the open, I could reject it, reshape it, or accept it. The result aligned with me more often, because alignment happened early, when changing direction was still cheap.

I still owned the destination: what “done” meant, what must not break, what good enough looked like. I just stopped pretending that owning every junction was the same job.

Direction answers where we are going and how we will know we got there. A recipe answers which exact forks to take. When I gave a recipe too early, I was not really collaborating. I was pre-writing the solution in English and hoping the model would type it. When it diverged anyway, the frustration felt personal: I already told you.

The better contract was simpler. Define the goal and the judgment criteria. Let the model propose a road. Challenge the road. Then commit.

This is familiar if you have worked with people

My story is personal. The pattern is not new.

Hand someone a long recipe and they can still misread one step and end up somewhere else. Hand them a vague “make it clean” and they invent a rewrite you never asked for. The useful middle has always been the same: clear outcome, visible plan, hard questions, then execution. Design review works this way. Good pairing works this way. We already know how to do this with humans.

AI makes the same gap louder. Language stays ambiguous even when you add words. Implementation is cheap enough that a wrong path shows up as a real diff before you notice the misunderstanding. Even the tools admit the problem: plan mode exists because jumping straight to code fails often enough that products built a stage for it.

So this is less a private preference and more a review instinct applied earlier. It fits the same shift I wrote about when the developer role moves from coder to orchestrator, and the same finish-line habit from learning loops. Before the loop runs, you still need a road you can actually own.

Photo by Headway on Unsplash.

Plan mode helped, then plateaued

I use plan mode. I still find it incomplete on its own.

The idea is right: force a plan before implementation. The failure mode is that many plans are hard to understand. They arrive as dense technical dumps. Lots of structure. Lots of words. Not enough clarity. For me, especially as someone who does not think first in English, that kind of plan is expensive to read. I can skim it and still not feel the decision.

What helps me more is a plan in simple language, with one clear analogy when the idea is abstract. Not childish. Just clear.

Something closer to: we have three doors. Door A reuses what we already have. Door B is cleaner later but touches more files. Door C looks fast and creates debt. I recommend Door A because your constraint was smallest safe change.

That I can grill. That I can correct. That I can own.

A plan full of jargon can look professional and still leave you unable to make a real decision. If you cannot explain the path back in your own words, you are not directing. You are approving fog.

When the recipe is the point

Sometimes the road itself is the requirement.

Follow an ADR. Run a known migration. Touch one file because production risk is high. Match a security checklist exactly. In those cases, prescribe the steps. That is not micromanagement. That is the job.

The mistake is inventing a fake path just to feel in control, or accepting a vague plan just because it looks official. If the work still needs discovery, make the model propose a road you can understand, then defend that road under your questions.

What I am practicing now

With AI, my job is not to be the GPS.

My job is to set the destination, define what makes a road good or bad, and refuse to let implementation start until the chosen road makes sense to me in plain language. Ask for the path. Grill the path. Then let the model drive.

I have been through the other version: more detail, more surprise, more clarification, more frustration. The better version was slower at the start and much cheaper after.

Point the direction. Make the model defend the turns. Then move.