Interview Driven Coding: The AI asks, I decide

On 11 November I have 60 minutes at the Vibe Coding Event to show, live, how I get from an idea to a working prototype. The project is a small paint app in the browser, with a brush, colours and three layers. The audience gets to pick two extra features and add a request of its own.

The whole talk fits into one sentence: the AI asks, I decide. I call it Interview Driven Coding. This post describes how the talk is planned. The examples come from the dry run the evening before, with real questions, real answers and real numbers. How it goes live, and what the audience chooses, I don't know yet.

The problem with the big prompt

The usual approach goes like this: you write one long prompt that is supposed to cover everything, and you hope the AI builds the right thing from it. The trouble isn't what's in the prompt. It's what you didn't think of. The AI fills those gaps anyway, with assumptions, and you only notice once the code exists.

Interview Driven Coding flips that around. I describe the idea roughly, and the AI asks questions until the requirements are clear. Its job is to find the gaps. My job is to decide. Facts that live in the code or the repo, it looks up on its own. Decisions come to me, each with a recommendation.

This is the planned flow for the talk: two interviews and three points where I step in, at the requirements document (PRD), the plan and the merge request. A lot runs automatically in between, which is exactly why the human decision points need to be clearly marked.

Step 1: The interview about the paint app

SpecFab runs the requirements interview. For the talk I cap it at eight questions. Where a question concerns the audience, I'll pass it on to the room and take a show of hands.

In the dry run, a few questions came up that I wouldn't have asked myself:

• "Should several visitors use the app at the same time, say via QR code and server sync?" No. One device, one canvas, no server. Had I not ruled that out, a backend would have ended up in the plan.
• "How should undo work with three layers, one history per layer or a shared one?" One shared history that always takes back the last stroke, whatever layer it was on. I hadn't thought about that before.
• "Does the eraser only clear the active layer, or does it paint white?" It makes pixels on the active layer transparent. Sounds like a detail, but it decides the whole layer logic.

Those are exactly the things a prompt would have missed. The AI would have built them anyway, somehow. Live, the questions will be worded differently, and the audience decides which extra features go in. The topics should stay much the same.

In the second interview, about the tech stack, SpecFab suggested in the dry run implementing undo with stored image snapshots (ImageData). That works, but it's hard to test. I corrected it: every action is stored as plain data (tool, layer, colour, size, points), and the layer is redrawn from that. You can check it with node --test, no browser needed. One answer, one architecture decision, before a single line of code exists. I have that correction ready for the talk.

Step 2: Cutting the plan

From the interview, SpecFab produces a plan made of stories. In the dry run, the first proposal had eleven. For a prototype that has to be built live in a few minutes, that's too many.

I did two things, and that's exactly what I plan to do live. First, a comment on the plan: fewer, smaller stories, at most four acceptance criteria each. That got it down to eight. Then I delete the "Security Review" and "Documentation & GitLab Wiki" stories by hand.

That isn't distrust of the AI. For a real product both stories are right, and I'm glad they are in the plan by default. But only I know this is a live demo that gets archived after the evening. The AI can't know that context. It proposes, I decide.

With the trimmed plan, Claude Code built the six dry-run stories one after another through my story workflow: about nine minutes, 33 passing tests, one merge request. Live there will be fewer stories, because the audience picks only two of the four extra features.

Step 3: A request from the audience

Towards the end of the talk I'll ask the audience for one more feature. I don't know in advance what it will be. In the dry run I played it through with a spray brush and created an issue with exactly one sentence: "Should spray like a spray can."

Nobody can work properly with an issue like that, human or AI. So my /gitlab-refine skill takes over. It reads the code, notices the description isn't enough, and interviews me in rounds. Live, I'll hand those questions to the audience.

The first round had four questions: Which spray pattern? What happens when the mouse stands still? Should the density be adjustable? What is explicitly out of scope? Only after that, in the second round, did it ask about the button's name and position. A question whose answer depends on another open question never goes into the same round. That keeps the interview short: two rounds, about three minutes.

Afterwards the issue had a description with context, goal, eight requirements, four acceptance criteria and a list of what's out of scope. The original sentence stays on the issue as a comment. With /gitlab 7, Claude Code then implemented it, including two code reviews and a merge request. From "in progress" to "ready for review" took just under four minutes. The review caught a real gap along the way: no test checked that the dots are actually spread evenly. The test was added before the merge request was opened.

Live I'm planning more time for this step, because every approval takes longer on stage than at a desk. That's why it keeps running in the background during the Q&A.

Why I plan it this way

Interviews cost time up front. Answering eight questions takes longer than firing off a prompt. I'm betting that the time pays off later, because less gets built wrong and less has to be undone. Whether that holds under time pressure on stage, we'll see on 11 November.

The gates are the other half, and the first half doesn't work without them. When the AI builds stories, runs reviews and opens merge requests, I need fixed points where I look: is the goal right, is the scope right, does the code go in. For me those are the PRD, the plan and the merge request. In the talk I want to make exactly those three points visible.

The tools in the talk: SpecFab for interview, PRD and plan, GitLab as the control centre, and Claude Code with my story workflow and my GitLab skills /gitlab-prepare, /gitlab-refine and /gitlab.