Most of what I’ve written about coding agents is machinery: pipelines encoded in markdown, flat teams, testers with browsers. This post is about what I do before any of it turns on, the part that took me longest to learn and matters more than the rest: I have a long conversation with the model about what I want to build. Not a prompt. A conversation, the kind that takes an hour and changes my mind several times.
The principle underneath it is blunt: no amount of intelligence, and no amount of compute, applied to a small specification will get you to the thing you want faster than aligning with the model on exactly what that thing is before anyone tries to plan or build it.
The lie everyone tells themselves
People think they know what they want to build. This is usually a comfortable lie, because what you actually have is a feeling of specificity. You can see the finished thing in your head, gesture at it in a sentence or two, and the sentence feels complete because the picture behind it is vivid. But the picture is rendered at low resolution, and every pixel you haven’t decided is a decision someone else will make for you.
I know this because I watch what happens when the picture meets a draft. The moment I start actually talking through a feature, not describing it but working through it, holes appear everywhere. Directions I hadn’t considered. Pairs of things I wanted that turn out to be in tension. Judgment calls I didn’t know I owed anyone: what happens on failure, who sees what, which of two defensible behaviors is mine. None of those were in the sentence, and each one gets decided regardless, if not by me now then silently, three layers deep in an implementation, by whichever agent happens to be holding the file.
Compute doesn’t recover intent
The tempting move, with frontier models this good, is to skip ahead: hand the two-sentence version to a serious pipeline and let intelligence make up the difference. It doesn’t work, and it’s worth being precise about why. A model given an underspecified goal doesn’t fail loudly; it fills every gap with a plausible default. What comes back is a perfectly valid interpretation of what you said, executed competently, and it is not the thing you wanted, because the thing you wanted was never expressed anywhere. The intelligence amplified the spec it was given. Garbage in was never the problem; thin in is the problem.
That’s also why the real leverage of agents sits where it sits. Agents are spectacular at the mechanical middle of building software: finding everything relevant in a codebase, figuring out the right way to extend it, executing a plan phase by phase. My whole RPI pipeline is that middle, automated. But leverage is a multiplier, and a multiplier is only as good as what it’s pointed at. Point it at a low-resolution wish and you get low-resolution results, delivered impressively fast.
The conversation is the drafting instrument
So here’s what I actually do. Before anything gets planned, I tell the model to have a conversation with me. Its explicit job is to understand what I’m trying to build, not to build anything. And then we talk, sometimes for a long time. The model in this mode is a strange and useful thing: an infinitely patient interlocutor that has read more software than anyone alive, asking me questions I should have asked myself. Every question is doing the same work: raising the resolution of the picture, one decided pixel at a time.
When I feel like we’re at maybe 80% alignment, with the shape right and most of the big forks chosen, I ask it to write a specification document. That document is not the output. It’s the instrument. Reading a spec someone else wrote from your own words is the fastest way I know to find out what you failed to say: every place the model guessed, every default it quietly picked, every sentence where I go “no, not that” is a misalignment that would have surfaced weeks later as rework. So I mark them, we keep talking, and the spec gets revised in the same chat and the same living document, iteration after iteration, until I can read it end to end and object to nothing. That’s the finish line: not a spec that sounds good, but a spec with no surprises left in it.
It’s an unglamorous loop. It’s also, reliably, where the actual work of building something happens. Not the typing, but the deciding. Most of what we call “building” is discovering, one collision at a time, what we meant. The conversation just moves those collisions to the cheapest possible place: a chat window, before a single line exists.
Alignment is what buys autonomy
Then, and only then, the machinery earns its keep. The finished spec is exactly what my pipeline was built to receive: the research agent maps the codebase without ever seeing the spec, the planner gets it in full, supervisors and implementers run the phases, reviewers clear the branch. All of that runs autonomously, and this post is the reason it can. The degree of autonomy I can safely hand my agents is set almost entirely by how aligned we were when they started. Every percentage point short of full alignment comes back to me later, with interest, as review findings, rework loops, or, worst of all, a finished feature that’s correct and wrong.
This is also, I’ve realized, why the discussion-first planning stage in my RPI skill exists at all: it’s this same principle, encoded as process, for features where I skipped the long conversation and need the planner to drag it out of me before writing anything. The workflow is a backstop. The conversation is the real thing.
The shape of all this is counterintuitive, and I think it’s why people resist it: the slowest, most manual, most human part of my workflow comes first, before any of the automation. But it’s the one part that can’t be delegated, because the raw material lives in my head and nowhere else. The agents can do everything else. They can search, plan, build, test, review, and ship. The only thing they cannot do is want the thing on my behalf, and the conversation is how I find out what I want.