The popular advice is to leave meetings with a summary, assign owners, and move on. That sounds disciplined, but it often creates the exact delay that slows product teams down. The summary strips away the questions, trade-offs, and clarifications that produced the decision. Engineers then reconstruct intent from a document, a design file, and scattered Slack threads before they write the first line of code.
Conversation driven development takes a different position. The meeting isn't overhead before the development begins. It can be the richest development artifact the team creates, provided the conversation becomes structured, searchable, reviewable context. The practical objective is simple: shorten the distance between agreement and the first trustworthy commit.
Table of Contents
- Why Your Best Development Artifact Is the Meeting You Just Had
- What Conversation Driven Development Actually Means
- The Meeting to Living Plan to First Commit Workflow
- Benefits Product Teams Notice First
- A Real Scenario Where Conversation Becomes Code
- How to Adopt Conversation Driven Development on Your Team
- Common Pitfalls and How to Avoid Them
Why Your Best Development Artifact Is the Meeting You Just Had
The assumption that a meeting is a cost and a specification is the work is backwards for ambiguous product problems. The specification usually records the conclusion, while the conversation contains the reasoning that makes the conclusion usable.
A product manager might say that customers need “faster onboarding.” An engineer will immediately need to clarify which users, which path, what counts as completion, what existing behavior must remain unchanged, and which edge cases matter. Those answers rarely appear in a polished post-meeting note. They live in the exchange itself, often alongside a Figma frame, a whiteboard sketch, or a tentative decision that someone later revises in Slack.
The write-up loses the useful uncertainty
Post-meeting notes fail in a predictable way. Someone writes the decisions, omits the discarded alternatives, and turns open questions into vague follow-up tasks. A developer who wasn't in the room reads the result as settled fact. A week later, the team debates the same issue because nobody can see why the original choice was made.
A conventional minutes format can still help, especially when it preserves decisions and owners. Teams that want a practical structure can use this best minutes of meeting format, but the format should be treated as a starting point for executable context, not as the final artifact.
The hidden bottleneck is decision lag, the time between a team agreeing on intent and an engineer producing the first implementation that can be reviewed. During that gap, context decays. Engineers switch to other work, designers update screens, and stakeholders remember the decision differently. The team may measure delivery using familiar DORA metrics and agile DevOps practices, yet still miss the cause of the delay because the lost context happened before the code entered the delivery system.
Practical rule: If the first commit requires someone to retell the meeting, the meeting wasn't connected to development.
Conversation becomes a primary artifact when the team preserves more than a transcript. It needs intent, decisions, unresolved questions, constraints, examples, and links to the work that follows. That record can then guide a living plan, an AI coding assistant, a human review, and the eventual pull request.
What Conversation Driven Development Actually Means
Conversation driven development, or CDD, is a closed-loop workflow in which team conversations provide the primary specification and training data for AI-assisted development. The team shares an early idea, reviews the resulting dialogue, turns meaningful utterances into structured examples, tests the end-to-end interaction, tracks failures, and updates the system based on what users and teammates said. The Rasa explanation of conversation-driven development describes this loop in the context of AI assistants. The same logic applies when the output is product code, a PRD, tests, or an implementation plan.
CDD isn't a return to unstructured “vibe coding.” Traditional specification workflows try to settle requirements before implementation. Agile user stories make the work smaller and easier to prioritize, but they can still flatten a complicated discussion into a few acceptance criteria. CDD keeps the interaction that resolves ambiguity. The conversation serves two roles: source of truth for intent and regression material for future behavior.
The interaction pattern is older than current AI tools
The underlying pattern has deep roots in natural-language computing. Terry Winograd developed SHRDLU at MIT between 1968 and 1970, and the system was issued as technical report AITR-235 in early 1971. It demonstrated a complete loop of intent, clarification, and action inside a constrained domain, anticipating conversational development interfaces by more than 50 years (historical reference).
Modern CDD attempts to scale that loop across real teams and codebases. GitHub announced Copilot on June 29, 2021, and the Codex paper followed on July 7, 2021, describing a production system that paired a GPT model with publicly available code. Copilot X extended the interface into chat, pull requests, and documentation assistance in March 2023 (timeline of AI coding). A living document approach gives the conversation somewhere durable to evolve instead of forcing the team to restart from a static brief.
The important distinction is not whether humans type prompts. It's whether each exchange changes a shared, inspectable artifact and whether the team can test that artifact against future work.
The Meeting to Living Plan to First Commit Workflow
Start with a meeting that contains a real product decision, not a routine status update. Design reviews, feature discovery, architecture discussions, and launch planning are good candidates because participants need to resolve intent and constraints together. Capture the conversation in real time, including decisions, alternatives, assumptions, links, and questions that still need an answer.
The output shouldn't be a transcript dumped into a folder. It should be a living plan with explicit fields for what the team knows, what it has chosen, and what remains unresolved.
Capture the decision while people are still talking
A facilitator or assistant should mark important moments during the meeting rather than asking somebody to remember them afterward. Useful labels include:
- Intent: What user or business problem is the team solving?
- Decision: What did the group agree to build or change?
- Constraint: What must remain true about security, performance, compatibility, or design?
- Open question: What blocks implementation or needs validation?
- Evidence: Which customer observation, design, issue, or technical dependency supports the decision?
Transcription can help, but accuracy isn't enough. Teams need a process for turning audio into usable notes. A practical guide to how to transcribe meeting minutes is useful for the capture layer, while the development workflow must add decisions, owners, and review states.
Convert dialogue into versionable specifications
The next step is to ask a collaborative agent to draft a structured plan from the captured context. That plan might include a Markdown PRD, acceptance examples, proposed files, API changes, tests, and unresolved questions. A technically useful variation is to convert free-form discussion into a machine-interpretable artifact such as handoff.yml, which carries context into implementation (structured handoff example).
The team reviews the plan before code generation. Don't ask the agent to resolve an ambiguous requirement without input. Make it restate the decision, show the assumptions it made, and surface conflicts. A focused rapid planning method can help keep this review short without turning it into another documentation ceremony.
Let the first commit prove traceability
Implementation happens in a shared sandbox or branch where the agent can inspect the plan, repository, design references, and approved decisions. The first commit should link back to the relevant plan sections and identify any assumption that changed. The agent can draft code and tests, but a human still approves the scope and the behavior before merge.
That sequence collapses the gap between meeting and implementation because context follows the work. It also gives the team a clear failure boundary. If the code is wrong, reviewers can ask whether the conversation was ambiguous, the plan lost context, the agent misunderstood the plan, or the implementation violated an approved constraint.
Benefits Product Teams Notice First
The first benefit is not raw typing speed. It's less decision lag. When the plan forms during the conversation and reaches an implementation environment immediately, engineers don't spend the next work session reconstructing what the group meant. They can inspect a proposed plan, challenge a questionable assumption, and move toward a reviewable change while the decision is still fresh.
That matters particularly for small teams. A founder, designer, and engineer may all hold different parts of the feature context. CDD places those parts in one evolving record instead of relying on one person to become the translator between product intent and code.
Fewer archaeology sessions
Slack is useful for coordination and terrible as a long-term specification system. Search results often reveal a phrase without the surrounding decision. A reaction can look like approval. A later message can supersede an earlier choice. Engineers then spend time tracing links, opening old threads, and asking people who may no longer remember the context.
A conversation-linked plan makes the reasoning inspectable:
- Decision history: Reviewers can see what changed and why.
- Open questions: Unresolved issues remain visible instead of disappearing into a task list.
- Design context: Figma frames and implementation notes stay connected to the relevant discussion.
- Onboarding context: A new teammate can understand the trade-off without interviewing everyone involved.
Lower context-switching costs
CDD also reduces the number of times people translate the same idea across tools. The meeting produces intent, the living plan turns intent into implementation context, and the coding environment receives the approved version. That continuity helps engineers work in tools such as Cursor while product and design teammates continue in their own environments.
The gain is organizational as much as technical. A traceable record helps teams review whether the shipped behavior still matches the agreed behavior. It can support governance conversations because reviewers can identify who approved a decision, which constraints applied, and where human judgment entered the process.
The value isn't that an agent remembers everything. The value is that the team can inspect what the agent was given.
A Real Scenario Where Conversation Becomes Code
A small product team is discussing an invitation flow for a collaborative workspace. The product manager wants invitees to reach the workspace quickly. The designer proposes a compact modal with email entry and a confirmation state. The engineer asks whether existing members should receive invitations, whether an invitation expires, and whether the sender can invite someone who already belongs to another workspace.
The group agrees to keep the first version narrow. They decide that existing members should see a clear message rather than receive a duplicate invitation. Nobody resolves the expiration behavior because it seems outside the immediate design. The meeting ends with a short summary: “Build workspace invites with validation and confirmation.”
The conventional path drifts
The engineer opens the summary, the ticket, and the Figma file. The ticket says “invite users by email.” The design shows a success state but doesn't explain duplicate membership. The engineer implements a generic invitation endpoint, the designer adjusts the confirmation copy, and the product manager later notices that existing members receive an email anyway.
Nobody made an obvious mistake. The problem is that the decisive clarification stayed inside the meeting. The summary preserved the feature label but not the behavioral rule.
The CDD path keeps the rule attached
In a CDD workflow, the meeting record marks the duplicate-member decision as an explicit acceptance example. The unresolved expiration question remains in the living plan, tagged as blocked for a later policy decision. An agent drafts a Markdown PRD containing the user flow, validation behavior, error states, and links to the relevant Figma frame.
The engineer asks the agent to propose the endpoint and tests in a shared sandbox. The plan, not an isolated prompt, supplies the context. The generated tests include the existing-member path because the conversation recorded it. Before the pull request is opened, the product manager reviews the behavior against the living plan and answers the expiration question, either by narrowing the scope or approving a defined policy.
The tools don't need to be identical for every teammate. A designer can work from Figma, an engineer can use Cursor, and the team can preserve the shared reasoning in versioned Markdown. The critical requirement is traceability, each implementation choice should point back to an approved conversation or an explicit follow-up decision.
How to Adopt Conversation Driven Development on Your Team
Don't start by capturing every conversation. Choose one meeting type where ambiguity regularly causes rework, such as feature planning or design review. Tell participants that the purpose isn't surveillance or perfect transcription. The purpose is to preserve decisions in a form that helps people build and review.
Use this adoption sequence:
- Choose a bounded pilot. Pick a feature with a clear owner, an accessible repository, and enough uncertainty to benefit from clarification.
- Define the source of truth. Decide whether the approved living plan, repository file, issue, or another artifact governs implementation when tools disagree.
- Capture structured context. Record intent, decisions, constraints, evidence, open questions, and links while the conversation happens.
- Add a human approval gate. Require a person to approve the plan before an agent writes code, and require normal review before code ships.
- Run the loop. Ask the agent to draft the plan, challenge assumptions, implement a small slice, generate tests, and report deviations.
- Review the failure. After delivery, identify where context was lost and update the workflow rather than blaming the model.
Governance must be designed before adoption
Local-first tools that sync decisions, transcripts, and artifacts as plain files can reduce vendor lock-in and make review easier. They also make retention and access policies concrete. Decide what gets stored, how long it remains available, who can export it, and which conversations must stay outside the development record.
Keep guest access controlled when external collaborators join. If the team shares a localhost preview for immediate feedback, define which data can enter that environment. Coding agents should receive only the approved context they need, not an unrestricted archive of private conversations.
Security review belongs in the workflow, not at the end. Teams introducing agents should understand common AI agent vulnerabilities, then apply least privilege, approval checkpoints, secret handling, and audit logs to the specific tools involved.
Track qualitative signals first, then formalize them. Useful measures include intent lead time, decision-to-commit lag, the number of unresolved questions carried into implementation, and how often reviewers find behavior that contradicts the conversation. The purpose isn't to reward more captured text. It's to learn whether the team reaches trustworthy implementation with less reconstruction.
Common Pitfalls and How to Avoid Them
CDD fails when teams confuse more conversation with better specification. A status meeting, social call, or routine handoff doesn't need to become development context. Capture discussions when they contain decisions, requirements, constraints, or unresolved product behavior.
The opposite failure is preserving a raw transcript and calling the job complete. Free-form dialogue is difficult for agents and humans to use consistently. Convert it into explicit, versionable artifacts before implementation, with clear distinctions between approved decisions, suggestions, assumptions, and questions.
Privacy creates another boundary. If conversation becomes the system of record, the team must define retention, access, deletion, export, and sensitive-data rules. Don't feed an agent an entire meeting archive when a reviewed plan is sufficient.
Human review remains necessary because an agent can produce plausible code from a mistaken interpretation. Require approval before write actions in sensitive repositories, inspect generated tests rather than treating them as proof, and use formal or symbolic tools when correctness, security, compliance, or safety depends on exact behavior.
Finally, don't eliminate async deep work. Conversation should accelerate clarification, not force every design decision into a live meeting. Give people a way to comment on the living plan asynchronously, record a decision when the issue is resolved, and keep the artifact current without creating another meeting treadmill.
SpecStory, Inc. provides tools that save AI conversations across development tools as searchable Markdown, preserving the reasoning, decisions, and trade-offs behind code. If you want to connect meeting context to living plans and implementation without making one vendor your only workspace, visit SpecStory, Inc. and explore how its workflow fits your team.
Newsletter
Get new posts in your inbox
Bring your team together to build better products. Fresh takes on remote collaboration and AI-driven development.