Using an AI Pair Programmer as a Design Partner, Not Just an Implementer

The default way to use an AI coding agent is transactional: describe a feature, get code back. That mode works, but it optimizes for the wrong bottleneck on a project where writing code was never the slow part — deciding what's worth building was.

The interview, not the implementation

A structured design interview — one question at a time, no code written until every branch is resolved — produces something a code-first session can't: a paper trail of the questions that almost got skipped. "Who reads this?" and "what does it cost at scale?" are the questions that kill bad ideas cheaply, and they're exactly the questions a straight-to-implementation session never asks, because the momentum is already pointed at shipping something.

Evidence it isn't just process theater

The blog itself was scoped this way and shipped. The "AI digest" idea went through the same process and got killed before a model existed for it, once the interview surfaced that its output was structurally identical to a Post. Both outcomes — ship and don't-ship — came from the same kind of session; the value wasn't in getting a "yes," it was in getting a real answer either way, on a timescale of one conversation instead of a half-built feature.

What this changes about the working relationship

Treating the agent as a design partner means the most valuable output of a session is sometimes a rejected idea and a written-down reason, not a diff. That's a different success metric than "did it produce code today" — and on a project where the constraint is attention and judgment, not typing speed, it's the metric that actually matters.