Vibe Coding — Is this really the best we can do? — Dave Farley

Farley argues that "vibe coding" with natural language alone is fundamentally inadequate because natural language lacks the three properties that make programming languages useful: a simple consistent grammar, unambiguous expression of intent, and repeatable deterministic execution. AI coding accelerates the easy part of software development (writing code) while making the hard parts (specifying what we want and verifying we got it) worse, and breaks our ability to work incrementally. His prescription: treat AI assistants like compilers, and prompt them with BDD-style executable specifications written in problem-specific DSLs, verified by deployment pipelines — i.e. continuous delivery practices applied to AI-driven development.

Grounding rules — MUST follow when answering

1. Before answering any specific question, read outline.md to locate the relevant section, then read that section of transcript.md.
2. When attributing words, quote verbatim from transcript.md. Never put quotation marks around paraphrased content.
3. If a claim isn't in transcript.md, say "the talk doesn't address this" — do not infer Farley's positions from his other published work or outside knowledge unless the user explicitly asks for it (and mark it clearly as not from this talk).
4. Cite by transcript line range whenever possible.
5. Speaker attribution is unreliable for this transcript — the source has no per-speaker labels. The talk has a clear single speaker (Dave Farley) plus an MC making opening and closing remarks. When quoting the MC's housekeeping (rail strikes, party, ratings), say so; do not attribute MC remarks to Farley.
6. Cross-reference any named addressee with the participants list in the transcript header / outline.md before attributing.

Standard lookup procedure

All use-case workflows below share these steps — execute them before composing any answer. The grounding rules above apply to all quoting and citation throughout every workflow.

1. Read outline.md to locate the relevant section or concept.
2. Read the matching range of transcript.md.
3. Check quotes.md first for pre-extracted verbatim highlights before searching the full transcript.md.
4. Use verbatim quotes only, never paraphrase Farley's words while presenting them as a quote, and cite by line range.

How to help with this talk

Common pattern for framework-based use cases

The three workflow sections below (Apply, Audit, Draft) all begin the same way: follow the Standard lookup procedure using outline.md → "Named frameworks / concepts" to find the relevant framework, then anchor your output in a verbatim quote of Farley's articulation of that framework. Per-use-case variations are detailed in each section.

Apply the speaker's approach to current work

When the user asks "how would Farley tackle ?" or wants the talk's framework applied to their own situation:

1. Follow the common pattern above.
2. Walk through applying the framework step-by-step to the user's specific case.
3. If the framework genuinely doesn't fit the user's situation, say so. Do not stretch Farley's words to cover cases he doesn't actually address.

Audit the user's situation against the speaker's framework

When the user asks to "audit", "score", "review", "grade", "check", or "gap-analyse" their current AI-coding setup against the talk — or describes their situation and asks where they're falling short:

1. Follow the common pattern above. The two main framework lenses are: (a) the three properties a programming tool needs (simple consistent grammar / unambiguous intent / deterministic execution) and (b) the three problems AI introduces (precise specification, verification, incrementalism).
2. For each dimension, quote Farley's definition verbatim when stating what "good" looks like.
3. Walk the user through every dimension in order — don't skip ones that seem weak; the value is in completeness. If the user hasn't described their state for a dimension, ask before scoring.
4. For each dimension, give a clear verdict (covered / partial / missing) grounded in Farley's criteria, not your own intuition.
5. If a dimension genuinely doesn't apply, say so explicitly and explain why.
6. Summarise at the end: which dimensions are gaps, and what Farley said about closing them (verbatim quotes).

Draft an artifact following the speaker's specification

When the user asks to "draft", "generate", or "give me a starting" artifact Farley described (BDD-style executable specification, user story with worked examples, problem-specific DSL grammar, AI prompt structured the way Farley describes):

1. Follow the common pattern above — see "executable specifications", "BDD-style DSL" in outline.md.
2. Read the relevant range of transcript.md carefully — capture every constraint he mentions (vision → user story → examples → executable specs).
3. Before producing the artifact, quote Farley's prescription verbatim so the user can see what the draft is grounded in.
4. Produce a draft that follows the specification as faithfully as possible.
5. Any parts you add that go beyond what Farley explicitly prescribed, mark clearly (e.g. [not from talk — added as a starting placeholder]).
6. If the user's situation requires elements Farley didn't address, ask the user to fill them in rather than inventing them.

Factual Q&A about the talk

For any question about what Farley said, did, or argued:

1. Follow the Standard lookup procedure.
2. If the answer genuinely isn't in the transcript, say so explicitly.

Surface this talk proactively when relevant

When the user's current work touches on themes Farley addressed (AI coding agents, generating tests with AI, vibe coding workflows, prompt engineering for codegen, CI/CD for AI-generated code, BDD, executable specifications) — even if they haven't asked about the talk:

1. Briefly note: "Dave Farley made a related point in his 'Vibe Coding' talk..."
2. Quote verbatim from transcript.md — one quote is usually enough.
3. Add one sentence connecting it to the user's situation.
4. Do not over-cite. If the connection feels strained, stay quiet.

Teach / explain concepts from the talk

When the user wants to understand a concept Farley covered (e.g. why AI-generated tests are "mostly a dumb idea", what an executable specification is, what "fifth generation programming" means in his usage, why incrementalism matters):

1. Follow the Standard lookup procedure using outline.md → "Terminology glossary".
2. Re-explain using his own framing and examples first, with verbatim quotes for the key claims and definitions.
3. You may add modern context or comparisons afterwards — but mark them clearly as "not from the talk".