Ask About Design Patterns Before You Start Coding

The diff solves the problem. It's also the brute-force solution you'll refactor next sprint.

The default behavior

You're reviewing code the agent just produced. It compiles. It handles the edge cases. Every line does what you asked.

But there are three nested conditionals where a strategy pattern would do. There's a chain of if-else blocks that screams for a state machine. The agent solved the problem the way a junior developer would: correctly, but without recognizing that established patterns already exist for this exact situation.

You accept the diff because it works. You add "refactor this" to your mental backlog. The backlog grows.

The unlock

The fix is two words, applied before the agent starts writing code.

"I just actually unlocked a new one recently that I'm going to use a lot more going forward and that is to ask the agent what design patterns we should apply to the problem we're trying to solve up front."

John Sterns, Roo Cast S01E11

The prompt shift is simple: before you describe the feature, ask the agent which design patterns apply to the problem you're trying to solve.

Not "implement this feature." First: "What design patterns should we consider for this problem?"

The agent recognizes patterns well. Strategy, observer, factory, state machine, command: models have seen thousands of examples. They know when a problem fits a known shape. But they won't apply that knowledge unless you ask. Left to default behavior, they write code that works without thinking about whether established abstractions already solve the structural problem.

Why it works

Models are trained on codebases that include pattern implementations. They can identify when a problem matches the shape of a known pattern. But without explicit prompting, they optimize for "produce code that compiles and passes the immediate test" rather than "produce code that fits the architectural conventions of this codebase."

Asking about patterns front-loads architectural thinking. The agent names the pattern, explains why it fits, and then writes an implementation that uses it. The resulting diff is closer to what a senior developer would write: not just correct, but structured.

"Those magic words, design patterns, is creating much more elegant implementations than just kind of the sometimes the brute force solution that we'll go to by default."

John Sterns, Roo Cast S01E11

The tradeoff: this adds a step. You're not diving straight into implementation. For trivial tasks, it's overhead. For anything you'll maintain for more than a week, the upfront investment prevents the "technically correct but structurally messy" pattern that creates refactoring debt.

The prompt pattern

Before the implementation prompt:

What design patterns should we consider for [problem description]? Consider the existing codebase structure and explain which pattern fits best.

Then, once the agent identifies a pattern:

Implement [feature] using the [pattern] approach you identified.

This works because you're asking the agent to do pattern recognition, which it's good at, before asking it to generate code, which it will do however you let it.

Pattern-first vs implementation-first approach

How Roo Code closes the loop on design patterns

Roo Code's ability to close the loop - proposing diffs, running tests, and iterating based on results - makes the pattern-first approach particularly effective. When you ask Roo Code about design patterns before implementation, it can identify the appropriate pattern, generate code that uses it, run your test suite to verify correctness, and iterate if the pattern implementation needs adjustment.

With BYOK (bring your own key), you control which model handles the pattern recognition step. More capable models often identify subtler pattern applications, while faster models work well for straightforward cases like replacing conditionals with strategy patterns.

The key insight: Roo Code knows design patterns from its training data, but it won't apply them unless you explicitly ask before implementation begins.

Why this matters for your workflow

If you're shipping features weekly, the cumulative effect of brute-force implementations adds up. Each "works but messy" diff becomes a future refactoring task. Each future refactoring task competes with new feature work.

The pattern-first prompt doesn't slow you down much: one additional question before implementation. But it shifts the quality of the output from "junior developer who solved the problem" to "senior developer who recognized the pattern."

Over a month of feature work, the difference shows up in how much time you spend refactoring code that the agent could have written correctly the first time.

The rule

If the task involves any branching logic, state transitions, or extensibility concerns, ask about patterns first.

The agent knows the patterns. It just won't use them unless you ask.