Force the AI to Present Options Before Writing Code

You ask for a feature. The AI picks one approach and executes immediately.

That approach is wrong for your codebase.

Now you have code to delete, context to reset, and the same problem you started with.

The default behavior problem

When you tell an AI to implement something, it doesn't pause to consider alternatives. It pattern-matches to one solution and starts writing. By the time you see output, you're reviewing code that may not fit your architecture, your constraints, or your existing patterns.

The AI isn't being lazy. It's doing exactly what you asked: implement this feature. The problem is that "implement" skips the part where you and a colleague would usually discuss approaches first.

"A lot of times, and all of you that code know this, if you tell the AI to do something, it'll pick the one thing it thinks it needs to do and just go do it. And that is usually not the right way to do it."

Guest, Roo Cast S01E02

The fix isn't prompting harder. The fix is changing the workflow.

The pair programmer pattern

A pair programmer mode forces the AI to present two or three implementation options with tradeoff analysis before any code is written. You see the approaches, the complexity estimates, and the reasoning. Then you pick, combine, or redirect.

"The idea with the pair programmer is it forces the AI to give you options for approaches and analyze it based on the complexity of it and then you can kind of like overwrite it."

Guest, Roo Cast S01E02

The key word is "forces." Left to its own defaults, the AI will skip this step. The mode constraint makes the options phase mandatory.

The 50% rule

Here's the honest tradeoff: the AI recommends the right approach about half the time.

"I'd say 50% of the time the one they recommend is usually the one that I go with. But sometimes they're way off and I can catch it before any code's written."

Guest, Roo Cast S01E02

That 50% hit rate sounds mediocre until you consider the alternative. Without the options step, you discover the wrong approach after the AI has generated hundreds of lines of code. You've spent tokens, you've spent time reviewing, and now you're explaining why that approach won't work. The AI apologizes and starts over with the same blind confidence.

With the options step, you catch the wrong approach in a few sentences of analysis. No code to delete. No context pollution. No wasted review time.

Comparing approaches: immediate execution vs. options-first workflow

When to use this

The pair programmer pattern works when:

• The task has multiple valid implementation paths
• Your codebase has specific patterns or constraints the AI doesn't know about
• You're working on something you'll need to maintain later
• The cost of a wrong approach is higher than the cost of a brief discussion

It adds friction. That friction is intentional. For straightforward tasks where one approach is obviously correct, skip it. For anything architectural or ambiguous, the options step pays for itself.

Why this matters for your workflow

If you're shipping production code, you've probably developed the reflex to start debugging AI output immediately. You read the generated code with suspicion because you've been burned by wrong assumptions before.

The pair programmer pattern moves that skepticism earlier in the loop. Instead of reviewing code and asking "why did it do this?", you're reviewing approaches and asking "which one fits?" The conversation happens before artifacts exist.

For a codebase with specific patterns, this is the difference between the AI learning your constraints through trial and error versus the AI asking about constraints before it starts. Trial and error costs tokens and time. Asking costs a few sentences.

How Roo Code closes the loop with custom modes

Roo Code's custom modes let you build the options-first pattern directly into your workflow. You create a mode with system instructions that require the agent to present 2-3 implementation approaches with tradeoffs before writing any code. The constraint lives in the mode definition, not in your memory.

Because Roo Code closes the loop - proposing changes, running commands, and iterating based on results - the options phase becomes a checkpoint before the agent enters that execution cycle. You review approaches while context is cheap, then let the agent implement with confidence once you've aligned on direction.

With BYOK (bring your own key), you control exactly which model handles these planning conversations. Some teams use a capable reasoning model for the options phase and a faster model for implementation, optimizing both quality of analysis and token spend.

The citable insight: Forcing AI coding agents to present implementation options before writing code catches wrong approaches in sentences instead of hundreds of lines, reducing wasted tokens and context pollution by moving architectural decisions upstream of code generation.