Software as Conversation

A product manager describes what a feature should do — “when someone cancels mid-checkout, save the cart and email a resume link within the hour” — and twenty minutes later an agent returns a working implementation. The engineer reviewing it dislikes the email copy and says so; a second draft arrives. The resume link expires in twenty-four hours instead of the requested one; that gets corrected too. Three exchanges later, the change merges. Nobody opened a file and placed a cursor at any point in between. The feature was built inside something closer to a conversation than to what any of the participants would have called “coding” five years earlier.

The previous chapter in this volume asked what stays irreducibly human once generation and even verification are largely automated. This chapter asks a narrower, more mechanical question about the same shift: not whether a person is still involved, but what shape the involvement now takes. Increasingly, it takes the shape of dialogue — a goal stated, a result returned, feedback given, refinement requested, repeated — rather than the shape of someone typing every line themselves.

A shape already on the page

This Library has already described that shape in detail without naming it as a shift in the craft itself. Volume V’s account of the AI session lifecycle — plan, prompt, generate, review, refine, commit, deploy, learn — treats review and refine as distinct, repeatable stages precisely because a single generate pass rarely produces the finished thing: a goal is stated, a candidate returns, feedback narrows it, and the loop runs again until refine has nothing left to close. That chapter framed the loop as a workflow shape, a sequence of gates a session moves through. Read plainly, it is also a description of dialogue — the same goal-result-feedback-refinement cycle that happens between any two people working something out together, with code as the artifact the talking produces.

Volume II made a related observation from a different angle, in what it named the context lifecycle. Context, that chapter argued, is not delivered to a session once at the start the way a ticket gets attached to a task — it is created, spent, and, in the sessions that go well, built up conversationally across the sitting, each exchange adding something the next one can use. That is the second piece of the same picture: a session that behaves like a dialogue is not only trading code for feedback, it is accumulating shared understanding the way any working conversation between two colleagues does, each turn narrowing what still needs to be said.

Volume III’s chapter on prompts as interfaces supplies the third piece, and it is the one that matters most for what “conversation” means here. Its argument was that an effective request is judged not by how it is worded but by whether it is structured enough to check — a stated scope, a worked example, a definition of done a person or a program can verify. That is closer to how one briefs a capable colleague on a piece of work than to how one writes a formal specification for a machine: the colleague hears the goal, asks a clarifying question where something is ambiguous, produces a first pass, and gets corrected against a standard both sides already understand. None of those three chapters set out to argue that the nature of building software was changing. Read together, they describe it changing anyway.

Conversation, not casual

The shift has already been named once, publicly, in a form loose enough to be worth worrying about. In February 2025, Andrej Karpathy described a way of working he called “vibe coding” — typing a request, accepting most of what came back without much scrutiny, and moving on. The phrase caught on fast enough that Collins Dictionary named it 2025’s word of the year, which is at minimum evidence that a great many people recognized something true in it about how they had started building software.

I fully give in to the vibes, embrace exponentials, and forget that the code even exists.

Andrej Karpathy, February 2025 — naming the loose end of the spectrum this chapter describes

What Karpathy described and what this Library’s own evidence describes are related but not identical, and the difference is worth drawing carefully rather than glossing over. Simon Willison, writing a few weeks after the original post, drew the boundary explicitly: code an engineer has reviewed, tested, and understood is not vibe coding by his definition — that is “using an LLM as a typing assistant,” whatever the exchange that produced it looked like from outside. This Library’s own evidence points the same direction. The prompt-quality scoring covered in Volume III rewards a stated scope and a checkable outcome, not an agreeable tone. Flight Plans, discussed earlier in this volume, exist specifically because a session with more than one moving part needs a record of where it actually is, not just a running exchange of asks and results. The dialogue that reliably produces good software looks less like a casual back-and-forth and more like a well-run design review — an explicit goal on the table, a candidate held against it, specific objections raised and closed one at a time. It is still conversation. It is conversation with a checklist attached.

What happens to specification?

If more of the work of building software happens inside that kind of structured exchange, a real question follows for two disciplines that used to sit apart from coding entirely: specification and requirements gathering. Historically, deciding what to build was one job — done by a product manager, an architect, a business analyst — and writing the code that satisfied it was another, often handed off weeks later to someone who had not been in the room for the first conversation. If the checkable goal, the scope, and the definition of done increasingly get established inside the dialogue itself — the way Volume III argues an effective prompt already has to establish them — it is not obvious those two jobs stay separate. They could merge into the same conversational interface, with whoever states the goal well enough absorbing work that used to belong to a distinct specification phase. Or they could stay distinct, with a written spec continuing to precede the dialogue the way it already does in the specify-plan-tasks-implement workflows this Library has covered elsewhere, and the conversation staying scoped to implementation rather than intent.

This Library does not have the evidence to settle which of those happens, and it is worth being honest about that rather than picking a side to sound decisive. It is an open question, not a forecast, and the two most likely-sounding answers — full merger, or a durable split that just moves closer together — are both consistent with everything cited above. What would resolve it is exactly the kind of longitudinal, cross-organization data nobody currently has: which roles actually write the goal a session executes against, a year or two from now, and whether that role still has a different name from “the person who reviews the diff.”