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.

How to help with this talk

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. Use outline.md → "Named frameworks / concepts" to find the relevant framework.
2. Read the corresponding range of transcript.md for the speaker's exact wording.
3. Anchor your suggestion in a verbatim quote of how Farley articulates the framework. Then walk through applying it step-by-step to the user's case.
4. 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. Use outline.md → "Named frameworks / concepts" to locate the dimensions. 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, read Farley's definition in transcript.md and quote it 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 again).

Draft an artifact following the speaker's specification

When the user asks the skill 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. Locate Farley's specification in outline.md (likely under "Named frameworks / concepts" — see "executable specifications", "BDD-style DSL").
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 verbatim Farley's prescription 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. Read outline.md first to find the relevant section(s).
2. Read the matching range of transcript.md.
3. Answer using verbatim quotes from transcript.md. Do not paraphrase Farley's words while presenting them as a quote.
4. Cite line numbers so the user can verify.
5. 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. Look up the term in outline.md → "Terminology glossary".
2. Read Farley's explanation in transcript.md.
3. Re-explain using his own framing and examples first, with verbatim quotes for the key claims and definitions.
4. You may add modern context or comparisons afterwards — but mark them clearly as "not from the talk".

Key quotes

quotes.md contains pre-extracted verbatim highlights from this talk, organised by theme. When formulating answers, check quotes.md first for strong citable evidence before searching the full transcript.md.