Talk Before You Type: The Case for Design-First AI Collaboration

There is a habit that most developers fall into almost immediately when working with AI coding assistants: you open a chat, describe what you want, and ask for code. The AI obliges. You paste it in, tweak it, paste it back, ask for changes. Repeat until something roughly works.

It is fast. It is also frequently wasteful.

Rahul Garg’s latest entry in his Patterns for Reducing Friction in AI-Assisted Development series makes a case for a different approach: treat the AI like a pair programmer at a whiteboard, not a code vending machine. The pattern is called Design-First Collaboration, and the core idea is to establish alignment at progressive levels of abstraction before any code gets written.

The analogy to whiteboarding is apt. When you work with a human colleague, you do not usually walk up and say “write me a function that does X.” You sketch, you ask questions, you identify assumptions. The cheap moment to catch a misunderstanding is when you are holding a marker, not when you are three hours into an implementation.

With AI, developers routinely skip that phase. The result is a kind of hidden cognitive tax: you spend energy reconciling what the AI built with what you actually needed, rather than spending it on the hard parts of the problem.

What the Pattern Actually Looks Like

The structured conversation Garg describes moves through layers:

1. Goal alignment — what problem are we solving, and why
2. Approach alignment — what strategy, what constraints, what trade-offs
3. Interface alignment — what does the boundary of this thing look like
4. Implementation alignment — then the code

Each layer is a checkpoint. If the AI proposes an approach that misses a constraint you care about, you catch it at layer two instead of layer four.

This maps well to how experienced developers think anyway. The discipline is in explicitly externalizing that process instead of letting it collapse into “just write the code.”

Why This Matters More Than It Sounds

I have noticed in my own work that the quality of what an AI produces is almost entirely determined by the quality of the framing I give it. A vague prompt produces vague code. A prompt that includes context about why something needs to work a certain way produces something I can actually use.

The design-first pattern formalizes that intuition. It is not about slowing down — it is about spending the time earlier, where it costs less.

There is also a subtler benefit: it forces you to think clearly before the AI does anything. Writing out a design conversation is its own form of rubber duck debugging. Sometimes you realize halfway through the alignment phase that you did not fully understand the problem yourself.

The Friction Is Real

The honest objection to this pattern is that it feels like overhead when you just want to bang out a quick feature. And sometimes that is fair — not every change warrants a whiteboard session, real or simulated.

But for anything with meaningful scope or ambiguity, the design-first approach is not slowing you down. It is front-loading the thinking that would have happened anyway, just at a point where reversing course is cheap.

Garg’s framing is worth sitting with. The instinct to jump straight to code is deeply ingrained, and AI assistants make it easier than ever to indulge. The pattern is a deliberate counter to that instinct — and the reasoning is solid.