| name | talk-farley-vibe-coding-best-we-can-do |
| description | Use when the user asks about Dave Farley's talk "Vibe Coding — Is this really the best we can do?" — including questions about vibe coding, agentic programming, AI-generated tests, BDD-style executable specifications as prompts, problem-specific DSLs, why natural language is insufficient as a programming language, the three properties of programming languages (formal grammar / unambiguous intent / deterministic execution), the three problems AI programming creates (precise specification, verification, incrementalism), fifth-generation programming, AI as compiler, or applying Farley's continuous-delivery-style approach to working with AI coding agents. |
| metadata | {"generated-by":"talk-to-skill","source":"user-pasted-transcript","generated-at":"2026-06-01T00:00:00.000Z"} |
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
- Before answering any specific question, read
outline.md to locate the relevant
section, then read that section of transcript.md.
- When attributing words, quote verbatim from
transcript.md. Never put
quotation marks around paraphrased content.
- 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).
- Cite by transcript line range whenever possible.
- 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.
- 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:
- Use
outline.md → "Named frameworks / concepts" to find the relevant framework.
- Read the corresponding range of
transcript.md for the speaker's exact wording.
- 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.
- 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:
- 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).
- For each dimension, read Farley's definition in
transcript.md and quote it
verbatim when stating what "good" looks like.
- 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.
- For each dimension, give a clear verdict (covered / partial / missing)
grounded in Farley's criteria, not your own intuition.
- If a dimension genuinely doesn't apply, say so explicitly and explain why.
- 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):
- Locate Farley's specification in
outline.md (likely under "Named frameworks /
concepts" — see "executable specifications", "BDD-style DSL").
- Read the relevant range of
transcript.md carefully — capture every
constraint he mentions (vision → user story → examples → executable specs).
- Before producing the artifact, quote verbatim Farley's prescription so
the user can see what the draft is grounded in.
- Produce a draft that follows the specification as faithfully as possible.
- Any parts you add that go beyond what Farley explicitly prescribed, mark
clearly (e.g.
[not from talk — added as a starting placeholder]).
- 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:
- Read
outline.md first to find the relevant section(s).
- Read the matching range of
transcript.md.
- Answer using verbatim quotes from
transcript.md. Do not paraphrase
Farley's words while presenting them as a quote.
- Cite line numbers so the user can verify.
- 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:
- Briefly note: "Dave Farley made a related point in his 'Vibe Coding' talk..."
- Quote verbatim from
transcript.md — one quote is usually enough.
- Add one sentence connecting it to the user's situation.
- 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):
- Look up the term in
outline.md → "Terminology glossary".
- Read Farley's explanation in
transcript.md.
- Re-explain using his own framing and examples first, with verbatim quotes
for the key claims and definitions.
- 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.