Spec-Driven Development

Workflows where human-authored specifications are the primary artifact and AI implements against them — with live debate over whether specs replace or complement reading the code.

Also known as: spec-driven development, specs-to-code, specs-to-code (the movement he opposes), PRD (product requirements document), PRD, AI PRD, destination document / journey document, sedimentary spec, grill-me (skill), Grill Me, spec-anchored, amnesiac AI, change brief, change briefs

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (33)

• Kent Beck's Post Kent Beck · 2026-10-08 source ↗ Reader 🖥️
  The common framing of Spec-Driven Development — write the complete specification, then implement — rests on a false assumption that implementation teaches you nothing that should change the spec, whereas TDD's tight test/code/fail/pass loop is structured around the opposite assumption: that you will learn continuously and must feed that learning back immediately.
• Nils Brede Moe's Post Nils Brede Moe · 2026-09-23 Reader 🖥️
  Teams that genuinely pursue value from AI-assisted coding may work slower at first, because AI shortens code-writing but does not shorten the harder, team-level work of learning to specify tasks, verify quality, and build a shared practice — so the real productivity gain comes not from AI writing code faster but from the team developing a new, common way of working.
• Agentic AI and Code Reviews Zach Davis, Michelle Gill, Elisabeth Hendrickson, Angie Jones, Sha Ma, Randy Shoup, James Wickett · 2026-09-14 source ↗ Reader 🖥️
  As AI agents generate code faster than human attention can scale to review it, code review must be reorganized from a single human merge-time gate into a layered, risk-tiered verification system — deterministic checks, continuous author/review-agent loops, structurally independent adversarial review, and specialist multi-agent review — with human judgment deliberately reserved for intent, strategic risk, and accountability rather than mechanical inspection, and every automated decision recorded as a durable, auditable artifact.
• Presentation: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs Cassie Shum · 2026-09-12 source ↗ Reader 🖥️
  A knowledge graph earns its place in agentic software engineering less as a retrieval-accuracy mechanism (an edge that has largely eroded as models got better at parsing raw context) than as an organizational substrate for four practices: assembling task-specific context bundles, tracing decision provenance from idea to production, treating code rather than spec as the ground truth of system behavior, and making agent activity visible enough to audit and manage.
• Article: When Spec-Driven Development Pays Off Nitin Garg · 2026-09-10 source ↗ Reader 🖥️
  Treating a specification as a versioned, approved governance baseline does not make code reviewers find more AI-generated bugs, but it does convert each finding from a hunch into an attributable claim tied to a named requirement and an accountable human decision-maker — a benefit real enough to justify its measurable time cost only on hard, multi-constraint work built by capable-but-imperfect models, not as a universal practice.
• LIVE: Uncle Bob on Software Fundamentals in the Age of AI Matt Pocock (host) with Robert C. Martin ('Uncle Bob') · 2026-08-19 source ↗ Reader 🖥️
  Software fundamentals (clean, well-partitioned, deeply-structured, well-tested code) matter just as much in the agentic era as before — not despite AI's speed but because of it — because agents hit the same complexity wall humans always have, just at a different threshold; the right response is not to impose human disciplines (like strict line-by-line TDD or heavyweight upfront specs) on agents, but to encode human values as deterministic, automated gauntlets (crap scores, mutation testing, dependency rules) that agents must pass through, while reserving strategic judgment — architecture, module boundaries, what's worth building — for humans who must now learn that judgment by experiencing the agents' own tactical gauntlet.
• When AI Writes the Code, Specifications Need an Exit Strategy Markus Eisele · 2026-08-17 source ↗ Reader 🖥️
  When building software with AI coding agents, a specification should be a temporary 'change brief' that describes only the delta between current and intended behavior and expires at release, because durable system knowledge belongs in the native artifacts engineering already trusts to stay synchronized with the code — schemas, types, tests, policies, and telemetry — not in permanent prose that inevitably drifts and consumes an agent's finite context budget.
• Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture Stella Berhe, Stephan Bragner, Vikram Maran, Anand Jayaraman · 2026-07-14 source ↗ Reader 🖥️
  Because AI has decoupled writing code from understanding it, engineering organizations must run spec-anchored specification-driven development, test-driven development, and architectural fitness functions together as one verification system so that their combined artifacts form a versioned, queryable "context store" — making comprehension a lifecycle property of evolutionary architecture that both human reviewers and AI agents can draw on, rather than a pre-merge concern that AI-generated speed otherwise outruns.
• A cautionary tale about AI in tech writing: Why "Trust but Verify" is the only way to scale Betsalel (Saul) Williamson · 2026-07-13 Reader 🖥️
  The genuinely scalable use of AI in technical documentation is not to trust the LLM's raw output but to wrap it in a software-development-style pipeline -- specs as ground truth, deterministic tools (linters, formatters, style checkers) doing everything mechanical, and human 'trust but verify' review concentrated only on the residual, non-automatable judgment work (procedure validity, UX intent, omission, accountability) -- so that the 8-hour/17,500-word claim is evidence not that AI collapses the verification burden of technical writing but that a disciplined pipeline can relocate and compress it enough to make speed and rigor compatible.
• Why AI Coding Agents Still Need Clear Specs Markus Eisele · 2026-07-08 source ↗ Reader 🖥️
  AI coding agents don't eliminate the cost of specification, they relocate it into downstream correction loops and human review, so the real discipline is locating — and validating — a task-dependent sweet spot on a U-shaped completeness-vs-cost curve, one that shifts toward much stronger contracts as more agents are chained together.
• mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? Matt Pocock (AI Hero) · 2026-07-08 source ↗ Reader 🖥️
  Pocock announces that v1.1 of his Claude Code skills repo now composes a complete agentic coding lifecycle (Grill -> Spec -> Tickets -> Implement -> Code Review), whose headline addition, /wayfinder, decomposes a plan too big for one session into agent-sized chunks mapped as GitHub issues with blocking edges so the work can be parallelized.
• New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets Matt Pocock · 2026-07-08 source ↗ Reader 🖥️
  Agent-assisted software work is best handled not as ad-hoc prompting but as an explicit, skill-mediated development lifecycle — interactively grill the human into a spec, split the spec into tickets each scoped to a single agent session, implement, then code-review for refactoring smells — fronted by a dedicated planning phase (Wayfinder) that externalizes large, foggy plans onto the shared issue tracker so they survive beyond any one context window, with research, prototyping and TDD as first-class supporting stages.
• Software Design in the Agentic Age: Place Your Bets Mathias Verraes · 2026-07-07 source ↗ Reader 🖥️
  In the agentic age, code-level quality becomes automatable but high-level software design and rigorous (ideally executable) specifications remain decisive human-led work, so under deep uncertainty about AI's payoffs and externalities teams should bet on design rigour, executable specifications, and the ability to revert from agent generation back to human engineering.
• We've Stopped Arguing About Whether AI Changes Software Greg Herlein · 2026-07-07 source ↗ Reader 🖥️
  The debate over whether agentic AI transforms software engineering is settled; the transformation is a shift in the center of gravity of the work — from writing code to specifying, verifying, and curating knowledge.
• Why did Martin Fowler invite 60 engineers to a ski resort? Ivett Ördög · 2026-07-05 source ↗ Reader 🖥️
  The turn to AI-built software has reopened rather than resolved the foundational questions of the craft — should humans still read code, how do we know it works, does code quality still matter, and how do we manage newly-empowered citizen developers — and the author's connective throughline is an optimistic one: AI democratizes building while the disciplines that make code good for humans remain exactly the ones that make it good for AI.
• The Org Age of AI: A Collection of Enterprise AI Adoption Guides Turing Post · 2026-07-04 source ↗ Reader 🖥️
  Across its 'Org Age of AI' series, Turing Post treats enterprise AI value as gated by a sequence of organizational and engineering problems — workflow redesign, organizational legibility/maturity, the contrast between AI-native startups and existing enterprises, the workflow (not the model or agent) as the true unit of adoption, verified self-improving 'flywheels,' spec-driven engineering discipline, and workload-appropriate hybrid infrastructure — in which raw model capability is conspicuously absent from the list of binding constraints.
• Software Design in the Agentic Age: Placing Your Bets aardling.eu · 2026-07-03 Reader 🖥️
  Even though no one yet has evidence that classic code-design and domain-modeling discipline is necessary for agentic development, the author bets on maintaining it anyway — high test coverage, sound domain models and Ubiquitous Language, disciplined Bounded Contexts, and code quality — because doing so is the dominant strategy under uncertainty (cheap to unwind if unnecessary, expensive to retrofit if not) and because it preserves the option to revert an organization from agentic code generation back to human engineering if AI's economics or reliability falter.
• What Survived Contact Sam Ruby · 2026-07-01 source ↗ Reader 🖥️
  When agents write the code, rigor does not vanish but migrates to the objective and its evaluation; directing an agent is therefore a management act (a hire, not a tool-use) whose one non-delegable duty is owning the objective and the oracle that checks it.
• Spec-Driven Production Grade Development In The Age Of Vibe Coding Lee Boonstra · 2026-06-18 Reader 🖥️
  Because agentic coding has eliminated the implementation bottleneck and shifted it downstream to the humans who must review, integrate, and govern AI-generated output, production-grade development requires treating specifications as a disposable-code-enabling source of truth, redesigning team review culture (risk-bundled PRs, conditional approval, no-blame norms, tiered continuous reviewers) around that volume, and backing both with defense-in-depth technical guardrails (sandboxing, policy servers, context hygiene) rather than relying on speed of writing or any single control.
• How we Claude Code Claude · 2026-05-22 Reader 🖥️
  As models get more capable and agents are trusted to run longer on more ambiguous tasks, engineers should stop trying to hand-constrain Claude up front and instead let it interview them into a spec, review that spec through richer, denser artifacts (HTML, not long Markdown), and build verification directly into the artifact itself (as an agent-readable DOM contract) so the same checks can run under human, agent, and headless (CI) supervision alike.
• [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero AI Engineer (channel); speaker: Matt Pocock (AI Hero) · 2026-04-24 source ↗ Reader 🖥️
  AI is not a new paradigm for software engineering — the fundamentals that make working with humans effective (small tasks, vertical slices, deep modules, fast feedback loops, alignment through dialogue, TDD) are exactly what make working with AI agents effective; the path from idea to shipped feature is therefore a deliberately planned, human-driven pipeline (align → PRD → vertical-slice Kanban → AFK implementation → QA) in which the codebase itself is treated as the battleground, not the spec.
• It Ain't Broke: Why Software Fundamentals Matter More Than Ever Matt Pocock (AI Hero conference talk, AI Engineer) · 2026-04-23 Reader 🖥️
  Because AI amplifies the cost of bad code through software entropy, investing in software design fundamentals — shared understanding, ubiquitous language, deep modules, TDD, and deliberate architecture — matters more in the AI era than it ever did before.
• Sam Hatoum's Post Sam Hatoum · 2026-04-20 source ↗ Reader 🖥️
  Spec-driven development with AI is not waterfall because waterfall's fatal flaw was slow feedback, not specifications themselves, and AI collapses the feedback loop from months to minutes — making specs more essential, not less.
• Ashutosh Singh's Post Ashutosh Singh · 2026-04-10 Reader 🖥️
  Traditional product specs fail for AI features because they lack the technical specificity engineers need; PMs must replace vague feature descriptions with precise behavioral definitions, golden examples, failure-mode handling, cost/latency constraints, explicit scope boundaries, and eval criteria.
• No, AI Did Not Kill Agile Andrea Laforgia · 2026-04-00 source ↗ Reader 🖥️
  AI accelerates building software but does not reduce the epistemic uncertainty about what to build, so the iterative learning loop at the core of Agile becomes more important, not less, when coding is nearly free.
• Fragments: February 18 Martin Fowler · 2026-02-18 source ↗ Reader 🖥️
  AI-assisted software development is best understood as an amplifier of a team's existing practices rather than a disruptive break, so the field's real work is rebuilding the human-era practices that are predictably breaking—through emerging disciplines like the supervisory middle loop, risk tiering, TDD-as-prompt-engineering, and platform 'bullet trains'—amid far more shared uncertainty than settled answers.
• Fragments: February 4 Martin Fowler · 2026-02-04 source ↗ Reader 🖥️
  AI is reshaping the developer's relationship to understanding: it can erode comprehension of the systems we build, is wisely used to navigate toward an answer but never trusted for the answer itself, and may make code cheap enough that the specification becomes the durable engineering artifact.
• Coding Agent Development Workflows Nick Tune · 2026-01-07 source ↗ Reader 🖥️
  Making an autonomous coding agent reliable enough to go from ticket to mergeable pull request requires converting as much of the surrounding process as possible into explicit, versioned, tool-agnostic artifacts — deterministic scripts, a single shared source of truth for conventions that every agent and review tool reads, and structured task templates that reject underspecified work — because agent reliability is bounded by the explicitness of what surrounds it, not by the model's capability alone; and the harder unsolved problem this creates for teams and organizations is deciding how explicit conventions must be, who owns them, and at what level (team vs. org) they should be standardized.
• Gene Kim on Vibe Coding - Part III | Episode 412 | Troubleshooting Agile Douglas Squirrel · 2025-12-24 source ↗ Reader 🖥️
  Agentic coding tools work by letting the AI observe and check the effects of its own actions rather than just chatting, which shifts the developer's job from writing code to decomposing problems into task graphs and delegating pieces to AI — a scarce, teachable combination of specification and delegation skill (not raw coding ability) that now determines who benefits, while the same power that makes the tools valuable (a 'sawzall') makes them dangerous if used past their original disposable-prototyping purpose without guardrails and supervision.
• 10 Things Developers Want from their Agentic IDEs in 2025 Kate Holterhoff (RedMonk) · 2025-12-22 source ↗ Reader 🖥️
  Developer demand on AI coding tools shifted decisively in 2025 from reactive assistance (autocomplete, suggestions) to autonomous delegation across entire codebases, and this shift produces a more sophisticated, partly self-tensioned set of ten concrete demands — simultaneously wanting more autonomy (background agents, parallel orchestration) and tighter control (predictable costs, human-in-the-loop gates, rollbacks) — that agentic-IDE vendors must satisfy without losing sight of the premise that these tools exist to serve developers, not replace them.
• No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer AI Engineer · 2025-12-02 source ↗ Reader 🖥️
  Solving hard problems in large, brownfield codebases with coding agents requires treating the context window itself as the scarce, team-visible resource to be engineered — through a research/plan/implement workflow with deliberate, frequent compaction — rather than either unreviewed 'vibes' or an over-literal, semantically diffused 'spec-driven development'; and the harder, still-unsolved problem is adapting team workflow, review practice, and culture to a world where most shipped code is AI-authored, not improving the agent tooling itself.
• Just Talk To It - the no-bs Way of Agentic Engineering Peter Steinberger · 2025-10-14 source ↗ Reader 🖥️
  As coding-agent models (specifically GPT-5-Codex) get good enough to read a codebase and follow short, direct instructions on their own, most agentic-engineering 'harness ceremony' — subagents, RAG, elaborate plan files, custom hooks, MCP servers — becomes charade that works around older model limitations rather than exploiting current model capability, so the highest-leverage practice for a solo developer is to talk to the model directly and let judgment (about blast radius, context budget, and when real structure is needed) develop through intuition rather than process.
• Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices Wes Reisz · 2025-01-01 source ↗ Reader 🖥️
  AI-first software delivery is not one-size-fits-all: teams should choose between supervised and unsupervised agentic approaches based on code longevity and their ability to verify outputs automatically, using structured human-AI collaboration (RIPER-5) to preserve engineering discipline — because AI amplifies whatever practices you already have, good or bad.

Propositions touching this concept (20)

By publication month, oldest first (extraction month when no publication date is known).

2025-10

• explicitcontestedHe has moved away from heavy upfront spec-driven development (a big spec, then hours of unattended building) toward an iterative discuss-then-build loop with the model, reserving a written, cross-model-reviewed spec (drafted with Codex, critiqued by GPT-5-Pro) only for genuinely tricky features.
  Just Talk To It - the no-bs Way of Agentic Engineering · p5

2025-11

• explicitSpec-driven development repeats the waterfall mistake when it tries to front-load a large, comprehensive specification disconnected from code; the valuable version keeps specs thin, with tight build-test-deploy loops on small slices.
  How AI will change software engineering – with Martin Fowler · p10

2025-12

• explicitSpec-driven development (requirements.md/design.md/tasks.md as a durable, shared human-AI contract) appeals to developers because it survives context-window limits and session boundaries, giving agents a persistent source of truth to check implementation against — even though critics frame it as a return to waterfall.
  10 Things Developers Want from their Agentic IDEs in 2025 · p7
• explicit'Spec-driven development' as a term has undergone semantic diffusion (per Fowler's 2006 framing, and the earlier fate of the word 'agent') to the point of uselessness as a label — now meaning anything from a more detailed prompt, to a product requirements document, to literal code-as-assembly, to documentation for an open-source library — even though some version of the underlying discipline (compressed intent, verifiable feedback loops) remains valuable under the author's own preferred framing.
  No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer · p9

2026-04

• explicitcontestedThe 'specs-to-code' approach (edit specs, never look at code) is just vibe coding renamed and does not work; the code is the developer's battleground.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero · p5
• explicit⚡ disputed & corroboratedSpec-driven development with AI collapses the feedback loop from months to minutes.
  Sam Hatoum's Post · p3
• explicit⚡ disputed & corroboratedThe specs-to-code approach produces progressively worse code with each iteration due to software entropy.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever · p2
• explicitdevelopedAn adversarial interview process (Grill Me) produces better shared understanding than the default plan mode in AI coding tools.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever · p6
• explicitcorroboratedThe specs-to-code movement is vibe coding by another name.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever · p14
• explicitAI is making technology evaluation itself harder, not just technology adoption, because semantic diffusion (overlapping new terms like 'spec-driven development' and 'harness engineering') and extremely short tool half-lives (some tools under a month old, built by one person with a coding agent) outpace the normal maturation cycle a radar relies on.
  Technology Radar, Volume 34 · p1

2026-07

• explicitRunning spec-anchored SDD, TDD, and architectural fitness functions together, on one cadence, as a single verification system produces the context store as an emergent byproduct; none of the three disciplines is individually new, but their deliberate integration is.
  Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture · p6
• implicitThe article assumes a single, sufficiently coherent organizational "design intent" exists to be captured in one spec-anchored specification, rather than multiple stakeholders holding competing, unreconciled intents that the spec-authoring process itself would need to negotiate.
  Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture · p11
• explicitAs AI increasingly writes production code, 'vibe coding' is no longer adequate for enterprise reliability; concrete specifications, testing, and verification (spec-driven development) are what let coding agents build software that stays reliable as projects grow.
  The Org Age of AI: A Collection of Enterprise AI Adoption Guides · p4

2026-08

• explicitSpecifications in Martin's current practice are deliberately ephemeral — they are not persisted or returned to as a parallel artifact to the code — and he is skeptical that 'spec-driven development' as a durable-artifact practice will work, since his own experiments with it did not go particularly well.
  LIVE: Uncle Bob on Software Fundamentals in the Age of AI · p15
• explicitA change specification (a 'change brief') should contain only a short, bounded list: intended outcome and non-goals, known unknowns needing human judgment, affected system boundaries and authoritative interfaces, constraints that differ from current behavior, and acceptance criteria for the risky path.
  When AI Writes the Code, Specifications Need an Exit Strategy · p4
• explicitestablishedDiscovery of missing information continues throughout implementation — reading a module, building a prototype, running a test, or inspecting production data all surface unknowns that were invisible at the start — and the change brief remains part of this ongoing loop rather than a document fixed before work begins.
  When AI Writes the Code, Specifications Need an Exit Strategy · p7

2026-09

• explicitdevelopedSpec-Driven Development relocates the primary review gate from implementation to the plan: once intent is reviewed and hardened up front, code review's job shifts from trying to catch what went wrong to verifying that a trusted, already-approved plan was faithfully executed — because by the time code exists, the most consequential (and hardest to reverse) decisions have already been made.
  Agentic AI and Code Reviews · p7
• explicitdevelopedBurnout is a live risk of intensive AI use (e.g. under spec-driven development); burned-out engineers produce worse work, don't push back or report problems, and eventually leave, taking institutional knowledge with them.
  Are You Getting Your Money's Worth from AI? · p17
• explicitSpecification governance imposes a real, measurable, recurring cost: spec-anchored review took about 48 minutes versus 27 minutes for code-only review (p=0.043), plus an ongoing up-front discipline of authoring and re-synchronizing the spec/HLD/LLD baseline as the system evolves.
  Article: When Spec-Driven Development Pays Off · p8

2026-10

• explicitThe common description of Spec-Driven Development assumes that implementation produces no learning that should change the specification.
  Kent Beck's Post · p1

Tensions

Open gaps (52)

• incompleteTeam adoption is treated as an exercise for the reader. Pocock's answer to 'how does this work in a team?' is essentially: 'the upstream becomes team-shared, the downstream is one or two devs managing the pipeline.' He gives no story for: review queue scaling, distribution of PRD-authoring authority, who owns skills/coding-standards as a shared asset, code-review burden as a team-wide labour question, or how juniors learn craft in a workflow where most code is agent-written.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Cutler on overload and accountability culture; Beck on socio-technical change; Fearless Change for the adoption-of-practices angle in the user's hidden-layer interests.
• incompleteThe 'pre-AI books' recommendation is the closing thesis but is left underspecified. Pocock cites Pragmatic Programmer (tracer bullets), Ousterhout's Philosophy of Software Design (deep modules), Brooks's Design of Design (design concept), Fowler's Refactoring (small steps) — but does not give a reading list, nor a mapping of which insight from which book deploys at which point in the workflow. This is the load-bearing connection to the user's craft tradition and is left as a 'go buy them on Amazon.'
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: The user's library already covers Beck (small steps, TCR, simple design), Hickey (Simple Made Easy), Yourdon & Constantine (Structured Design), Meadows (Thinking in Systems). The mapping work is for the orchestrator to do: e.g., Pocock's 'don't bite off more than you can chew' is Fowler-on-refactoring; deep modules is Ousterhout; tracer bullets is Hunt & Thomas; design concept is Brooks. The honest gap is that Pocock does not even mention Beck — surprising given Beck's TCR is operationally close to red-green-refactor as Pocock practices it.
• incompletePocock's workflow structurally mirrors Anthropic's harness paper (planner / generator / evaluator) and Böckeler's adaptive-control framing, but he does not name them or compare. The grill-me skill is alignment; the PRD-to-Kanban is planning; the AFK Ralph loop is generation; TDD + manual QA + reviewer-Opus is evaluation. Surfacing this overlap is essential to placing his workshop in the broader 2026 AI-coding discourse.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Anthropic harness paper, Böckeler on adaptive control, Addy Osmani on agent patterns (in the user's saves) — all map onto Pocock's lifecycle with different vocabulary.
• incompletePocock conflates two definitions of 'done': (a) feature shipped with QA-imposed taste, and (b) commit produced by the Ralph loop with passing tests. The transitions between (a) and (b) — especially the merge-and-conflict-resolution at the end of multiple parallel sandbox branches — are sketched (the Sandcastle merger agent) but not interrogated for what happens when the merger itself produces semantically broken code. This is exactly where small-PR discipline matters and where he admits he doesn't have the answer.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Beck on incremental design and TCR; trunk-based development literature; the smallcode failure-mode catalog if it covers merge-stage failures.
• incompleteThe implicit premise that the developer can read agent output well enough to QA, code-review, and impose taste is enormous. Pocock states 'understanding code deeply is going to make you a much, much better developer and get more out of AI' and 'bad codebases make bad agents' — but does not address the developer who is themselves junior, distracted, or not the original architect. The workflow may be most valuable to seniors and least usable by the engineers who most need leverage.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Marcus on code quality (in user's recent saves), Beck on apprenticeship/teaching contexts, Cutler on directly-responsible-individuals and skill distribution.
• uninformedPocock specifically defers the question on conforming to security, architectural, and API-contract constraints ('I'm going to answer that in a bit') and never returns to it. For the user's organizational context (Norwegian senior leader watching governance signals), this is the highest-value question and is left unaddressed.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Security-review skill, Schneier on Security, explainable-AI requirements paper in the user's library, organisational adoption studies on AI tooling in regulated industries.
• incompleteThe article never specifies what a sufficiently rigorous architecture or specification artifact would look like, nor what would make code regenerated from it trustworthy — she flags 'the tools to do this don't exist yet' but does not engage with how much verification or re-validation cost such regeneration would carry.
  AI Demands More Engineering Discipline, Not Less — read next: Read Chad Fowler's Phoenix Architecture essays directly, plus corpus material on spec-driven development and executable specifications, for concrete proposals about what a regeneration-safe spec actually looks like.
• illogicalThe essay's optimism that encoding knowledge into systems will yield 'discontinuous returns on investment' sits in unexamined tension with her own earlier caution (the database-migration aside) that formalizing user expectations into a replayable, automatable spec has historically proven extremely hard — the two claims are never reconciled.
  AI Demands More Engineering Discipline, Not Less — read next: Read failure-mode literature on requirements formalization and specification languages to assess how much of the promised 'discipline dividend' is attainable versus aspirational.
• missing evidenceThe entire framework is grounded in a single three-month engagement. No DORA metrics, no controlled comparison with unconstrained approaches, no data on defect rates or rework costs. The talk is honest about this, but it means the prescriptive claims rest on practitioner intuition rather than empirical evidence.
  Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices — read next: Studies measuring productivity and quality outcomes of structured vs. unstructured AI-assisted development; DORA-instrumented teams using agentic workflows.
• tensionThe talk argues that (1) AI amplifies whatever practices you have, and (2) pair programming is essential for reviewing AI output. But if your practice is already strong enough to benefit from amplification, why is the review burden so high? The high review burden suggests the AI is generating output that doesn't match team standards — which is the amplification-of-weakness problem the talk warns about.
  Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices — read next: Research on AI code quality vs. human code quality at different experience levels; studies on code review effectiveness for AI-generated code.
• scope limitationThe framework addresses coding agents exclusively. It does not address other AI applications in the SDLC (testing agents, deployment agents, monitoring agents, design agents) or how the supervised/unsupervised choice might differ for those. The 'shifting left' claim is broader than the framework can support.
  Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices — read next: End-to-end SDLC automation literature; agent architectures for testing, deployment, and operations.
• evidenceNo data, case studies, or examples are provided to support the central claim that these six practices actually change engineer behavior. The argument relies entirely on the author's authority and the reader's intuition.
  Ashutosh Singh's Post — read next: Look for empirical studies on spec quality and engineering compliance, or case studies from AI product teams.
• scopeThe post assumes a team structure where PMs write specs and hand them to engineers. It does not address embedded/cross-functional teams, pair-programming approaches, or iterative spec development — all common in AI product development.
  Ashutosh Singh's Post — read next: Explore literature on AI product development process models (e.g., Google's ML product management practices).
• depthThe assertion that engineers 'shouldn't' make failure-mode decisions is stated without justification. In practice, failure modes often require deep technical knowledge (e.g., model calibration, confidence thresholds) that PMs may lack.
  Ashutosh Singh's Post — read next: Consider shared-ownership models where PMs define user-facing fallback behavior while engineers define technical thresholds.
• incompleteThe paper is written entirely from a Google/Antigravity-and-Gemini-CLI vantage point — every tool, product reference, and worked example (Antigravity, Gemini CLI, ADK, Spanner Graph, Vertex AI Agent Engine) is a Google product — so every claim about what 'coding agents' or 'AI' can or should do is implicitly a claim about this specific toolchain's current behavior, never flagged as distinct from more general, vendor-neutral claims about agentic coding.
  Spec-Driven Production Grade Development In The Age Of Vibe Coding
• incompleteThe three-tier continuous-review spectrum and the 'Where to start' closing section both frame tier adoption as a single team's own choice, but never address who decides and pays for a Tier 3 investment (knowledge-graph infrastructure, dedicated evaluation/observability, on-call ownership) when the triggering codebase or compliance requirement crosses several teams' boundaries — the same single-team vantage point as the first gap, applied specifically to the review-tooling investment decision.
  Spec-Driven Production Grade Development In The Age Of Vibe Coding
• uninformedThe approval-fatigue/burnout claim ('frequent AI users are 45% more likely to experience high burnout') is sourced to a single press report of industry survey data (CNBC citing Quantum Workplace) rather than a peer-reviewed study or the author's own organization's data, and the proposed remedies (Digital Quiet Hours, Agent Insight Sessions) are asserted without any evidence that they specifically reduce AI-approval-driven burnout, as distinct from general workplace wellness practices.
  Spec-Driven Production Grade Development In The Age Of Vibe Coding
• incompleteThe article treats finite senior-reviewer capacity as the crisis that pushed conformance checking onto automated fitness functions, but never asks whether spec-authoring capacity is symmetrically finite. The social practice it prescribes for spec-anchored SDD — "the spec is authored and reviewed like code, with diffs and approval, and amended when reality diverges from intent" — reintroduces a human bottleneck at the intent layer even as it removes one at the structural layer. If spec review cannot keep pace with AI-generation speed any better than code review currently does, the context store risks simply relocating the reviewer-capacity crisis from PRs to specs rather than resolving it.
  Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture — read next: Read against extract-eisele-ai-coding-agents-need-clear-specs' U-shaped cost curve of specification completeness (heavier specs front-load human effort) and extract-agentic-code-review's documentation of reviewer capacity already collapsing under AI-generated PR volume, to test whether spec-authoring is next in line for the same collapse.
• incompleteThe Amazon outage is presented as an outcome of the exact context gap this article diagnoses, but the article's own cited source (CNBC) attributes the outage to "changes merged without proper review" — a review-gate failure — not to a documented absence of persisted intent, behavior, or conformance records specifically. The causal attribution to the context gap, versus a more generic review-diligence lapse, is asserted rather than demonstrated from the available reporting.
  Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture — read next: Follow further Amazon incident reporting or post-mortems, if published, to see whether investigators identified a missing intent/behavior/conformance record specifically, or a simpler story of a skipped approval step that a context store would not by itself have prevented.
• incompleteThe U-shaped cost curve and its variants (single- vs multi-agent, BDD vs prose) are presented as illustrative line charts with no axis units, no measured data points, and no cited study — the model is asserted as intuitively obvious rather than empirically demonstrated.
  Why AI Coding Agents Still Need Clear Specs — read next: Look for empirical studies quantifying rework/correction cost under varying spec completeness with AI coding agents (e.g., controlled comparisons of BDD vs prose-spec agent tasks, or DORA-style research) to test whether the curve's shape and minimum location actually hold.
• incompleteThe essay proposes a spec-validation ('critic') agent as a cost-lowering step but never addresses who or what validates that critic, or what happens when its critique is itself wrong or incomplete — an infinite-regress problem inherent to using agents to check agents.
  Why AI Coding Agents Still Need Clear Specs — read next: Look at multi-agent debate and self-consistency literature, or formal-verification framing of 'who verifies the verifier,' for how (or whether) this regress is bounded in practice.
• uninformedThe claim that specification, not implementation, has always been the hard part of software engineering closely tracks Fred Brooks's essential-vs-accidental-complexity distinction, but the piece never engages that lineage or the decades of requirements-engineering literature built on it.
  Why AI Coding Agents Still Need Clear Specs — read next: Fred Brooks, 'No Silver Bullet — Essential and Accidental Difficulties of Software Engineering' (1986); also classic requirements-engineering work distinguishing validation ('are we building the right thing') from verification ('are we building it right').
• incompleteThe cost ledger treats 'the human' as a single, already-aligned oracle who knows what the spec should say; it never addresses the more common real-world case of multiple stakeholders disagreeing about intent, which is a large share of why specs are hard to write and validate in the first place.
  Why AI Coding Agents Still Need Clear Specs — read next: Organizational and requirements-engineering material on stakeholder conflict and specification as a negotiated artifact, not merely an accuracy artifact — relevant to team-space and change-adoption thinking about how groups actually converge on shared intent.
• incompleteThe spec-only library is demonstrated on a trivial, cleanly specifiable domain (timestamp-to-phrase formatting); the piece does not address whether spec-plus-tests scale to domains with emergent, under-specifiable, or performance-critical behavior, where the spec may grow as complex as the code it replaces.
  Fragments: February 4 — read next: Read on the limits of spec-driven development and where specifications stop being cheaper than implementations.
• incompleteThe claim that specification and delegation skill (not coding skill) predict agentic-coding success rests on two correlated anecdotes (a private-equity observer's prediction, later 'corroborated' by one executive's performance-review pull) — no systematic study, sample size, or comparison group is offered, so the magnitude and generality of the effect is unverified.
  Gene Kim on Vibe Coding - Part III | Episode 412 | Troubleshooting Agile — read next: extract-isdahl-agentic-ai-in-the-sdlc#p3 (independently argues reskilling toward decomposition/communication is required) and extract-farley-studied-150-developers-using-ai#p9 (decomposition as the central durable skill, from an actual 150-developer study) for more systematic versions of the same claim.
• incompleteThe 'amnesiac AI' framing assumes no progress on persistent AI memory (RAG, project context, long-term memory). If AI memory improves, the strongest argument for specs (external memory) weakens — though the argument from verifiability would remain.
  Sam Hatoum's Post
• illogicalThe thought experiment ('if coding became instant') proves too much — it assumes zero implementation cost, but actual AI implementation is not zero-cost. The gap between 'minutes' and 'instant' may matter more than the post acknowledges.
  Sam Hatoum's Post
• incompleteThe talk never addresses how HTML specs (or the design-direction mocks) stay synchronized with the app over its lifetime after the initial build — whether they, like the Markdown 'second system' the corpus elsewhere critiques, drift out of date as the code evolves, or whether they are explicitly meant to be discarded once a build is accepted.
  How we Claude Code — read next: extract-when-ai-writes-the-code-specifications-need-an-exit-strategy — its 'change brief' framing (specs as bounded, expiring artifacts, with only durable facts promoted into schemas/tests) directly addresses the lifecycle question this talk leaves open.
• incompleteSeveral central claims — that HTML specs net-reduce token cost, that Opus 4.7's vision model materially improves screenshot-based feedback, that the verification framework meaningfully improves reliability — are asserted from the presenter's own experience with a single demo repo, without any measurement, benchmark, or before/after comparison.
  How we Claude Code — read next: Compare against the corpus's recurring pattern of unreplicated single-author agentic-workflow anecdotes (e.g. extract-anatomy-of-an-agent-harness's own unquantified 'giving the model a way to verify its own work improves quality 2-3x' claim) for how thin this evidentiary base typically is across the corpus.
• incompleteThe talk gives a clear correction loop for design/visual intent (screenshots, HTML mocks, iterate) but no equivalent correction loop for the interview-derived requirements spec itself — what happens when Claude's interview-based extraction gets the requirements wrong is not addressed.
  How we Claude Code — read next: extract-claude-code-best-practices and other Claude Code workflow pieces in the corpus for how spec/plan review loops are typically closed.
• incompleteBeck asserts that implementation teaches you things that should change the spec, and treats this as self-evidently true without any example, data, or anecdote in this post — unusual for his style elsewhere, where personal anecdotes typically carry the argumentative weight. The post also doesn't address the version of Spec-Driven Development that the corpus has already documented as explicitly built around iterative discovery (extract-when-ai-writes-the-code-specifications-need-an-exit-strategy's 'change brief' as part of an ongoing loop) — so it's unclear whether Beck is critiquing SDD as such or only a naive/batch variant of it that more careful SDD proponents have already moved past.
  Kent Beck's Post — read next: extract-when-ai-writes-the-code-specifications-need-an-exit-strategy#p6 and #p7 make almost exactly Beck's point with evidence and detail (exhaustive upfront spec recurs and is 'engineering-useless'; discovery continues throughout implementation and the spec should remain part of an ongoing loop) — worth reading together to see whether Beck's one-liner and that article's longer argument are the same claim or whether Beck is attacking a strawman the more sophisticated SDD literature has already addressed.
• incompleteThe announcement asserts benefits (parallelizable decomposition, better code review, fixed grilling) with no evidence, benchmark, or worked example — support is an anecdote plus a 'Watch the video ->' link. Most tellingly, the comparison the subject line promises ('does /wayfinder beat grill-with-docs?') is entirely absent from the body: 'grill-with-docs' is never defined or mentioned outside the subject line, so the head-to-head is not under-evidenced but wholly missing from the text — the clearest proof that the substance lives in the un-transcribed AI Hero video.
  mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? — read next: Watch and transcribe the linked AI Hero changelog video (https://www.aihero.dev/skills/skills-changelog-v1-1-wayfinder-to-spec-to-tickets-grilling-improvements), or trial the mattpocock/skills v1.1 repo directly, to recover the actual reasoning, demos, and the /wayfinder vs grill-with-docs comparison.
• incompleteThe author argues that Measure and Learn remain expensive and irreducibly human, but does not explore whether AI might also transform these phases — e.g., AI-driven user behavior analysis, automated A/B testing at scale, or AI-assisted synthesis of qualitative feedback. The claim that learning is irreducibly human is asserted, not defended.
  No, AI Did Not Kill Agile — read next: Literature on AI-augmented product discovery, automated experimentation platforms (e.g., Eppo, Statsig), and whether AI can reduce the cost of the Measure/Learn phases
• incompleteThe article never engages with domains where requirements genuinely are well-understood upfront (e.g., regulatory compliance, protocol implementations, mathematical computations). The knowledge-problem framing may be less applicable in these contexts, where spec-first AI development might be entirely appropriate.
  No, AI Did Not Kill Agile — read next: Cynefin framework (Dave Snowden) for distinguishing simple/complicated/complex/chaotic domains; literature on when waterfall-like approaches are actually appropriate
• incompleteThe talk claims AI performs well in good codebases and poorly in bad ones, but provides no data or examples to substantiate this — it relies entirely on the audience's intuitive agreement.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Look for empirical studies measuring AI coding tool performance as a function of codebase quality metrics (coupling, cohesion, test coverage).
• incompleteThe talk does not address who is responsible for the initial codebase quality when starting a greenfield AI-assisted project. If the AI generates the initial code, the entropy problem exists from day one.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Investigate AI-assisted bootstrapping practices and whether initial architecture prompting can produce deep-module structures from the start.
• incompleteThe 'Improve Codebase Architecture' skill is mentioned but described only as 'quite complicated' — the talk does not explain how to refactor a shallow-module codebase into deep modules, which is the hardest step.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Read Ousterhout's A Philosophy of Software Design chapters on deep modules; explore the mattpocock/skills GitHub repo for the actual skill implementation.
• incompleteThe talk assumes TDD is applicable to all AI-generated code, but does not address domains where TDD is hard to apply (UI, data pipelines, exploratory prototyping) or where the cost of test-writing may exceed the cost of debugging.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Look for frameworks on when TDD is cost-effective vs. when other feedback mechanisms (type checking, property testing, visual review) are better suited.
• incompleteThe talk's five tips are presented as independent failure modes, but the dependencies between them are not explored. For example, does ubiquitous language require deep modules to be effective? Does Grill Me only work if the developer already has architectural knowledge?
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Consider whether these practices form a prerequisite chain or can be adopted independently.
• incompleteThis is a single-author, opinionated, model-dependent toolkit. Skill behaviour varies by model (the grilling-itself bug 'especially with Fable'), the design reflects one person's taste ('it brings me joy'), and there is no account of when the full lifecycle is overkill (small changes), how it holds up on large or brownfield codebases, or whether rigid phase-gating (grill -> spec -> tickets -> implement) helps or hinders an agent that might benefit from lookahead across phases.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets — read next: Read on model-dependence of skill/agent behaviour, on when phase gates help vs hinder AI-assisted problem-solving, and on running staged agent flows against large / legacy codebases where the assumptions (clean start, session-sized decomposition) hold least.
• uninformedThe author frames the specs-vs-code and 'throw away code and regenerate' debate as unresolved and untested, without engaging James Herr's already-reported deterministic-generator technique (have the LLM write a DSL/generator once, then produce all code thereafter deterministically from that generator) described in a separate retreat-adjacent conversation — a concrete existing answer to exactly the determinism/cost worry the author raises about full-code regeneration.
  Software Design in the Agentic Age: Placing Your Bets — read next: Read extract-software-teaming-age-of-ai-zuill-herr#p13 (and the corpus's deterministic-code-generators concept) and ask whether that pattern resolves, or only partially resolves, the regeneration-cost/determinism concern raised here.
• incompleteThe essay surveys the debate over disposable, regenerable code but leaves it unresolved by admission: it does not settle when the token and verification cost of regenerating code from specifications beats patching, nor whether frequent regeneration makes the system less deterministic.
  Software Design in the Agentic Age: Place Your Bets — read next: Seek empirical data or benchmarks comparing regenerate-from-spec versus patch-in-place on cost, determinism, and verification of functional and non-functional requirements.
• illogicalThe author leans 'spec-as-center' while conceding the 'code is the better spec, because deterministic' argument is hard to wave off, but never reconciles how a fuzzy prose spec that an agent re-interprets each run can be the durable source of truth when verifiability is the stated quality bar. The essay's own thesis is in tension with the counter-argument it admits.
  We've Stopped Arguing About Whether AI Changes Software — read next: Read on executable/formal specifications, spec-to-code determinism, and whether specs can be made unambiguous enough to be the source of truth.
• uninformedThe collection never addresses how its own later-stage practices interact when they conflict — specifically, whether spec-driven development's upfront, human-authored specification approach (item #7) sits comfortably inside a flywheel's self-generating, self-revising loop (item #6), or creates friction between fixed human-set structure and continuously self-revising automation.
  The Org Age of AI: A Collection of Enterprise AI Adoption Guides — read next: extractions/concepts.yaml's spec-driven-development and recursive-self-improvement entries, and any future Turing Post piece that explicitly reconciles the two.
• incompleteThe whole cross-retreat comparison rests on an acknowledged seam: the author read only the public summary of the earlier retreat, so he cannot separate 'the conversation genuinely grew' from 'the earlier summary simply compressed this out.' The central 'what changed' claim is offered on face value with that limitation showing.
  What Survived Contact — read next: Obtain the fuller record (not just the public key-takeaways summary) of the earlier Thoughtworks retreat and re-run the comparison against like-for-like source material.
• incompleteThe article never addresses teams whose native artifacts are themselves weak or absent (no real schema contracts, thin or no test suite, no telemetry). For them, 'keep durable facts in their native form' recommends a home that doesn't yet exist, and the article gives no guidance on sequencing — build the native artifact first, or use prose as a legitimate transitional stopgap while it matures.
  When AI Writes the Code, Specifications Need an Exit Strategy — read next: Look for material on artifact/observability maturity models, or on how teams bootstrap schema, test, and telemetry discipline in codebases that currently have none, to test whether prose specification is a legitimate transitional artifact rather than pure waste.
• incompleteThe article asserts that its short, fixed change-brief checklist (outcome, unknowns, boundaries, constraints, acceptance criteria) is sufficient to decide and review a delta, but never explains who validates that the checklist was filled in correctly and completely for a given change — the exact 'spec validation' step the author's own earlier companion piece raised explicitly is not revisited here.
  When AI Writes the Code, Specifications Need an Exit Strategy — read next: Read alongside extract-eisele-ai-coding-agents-need-clear-specs, whose 'spec validation' step (checking a spec for internal consistency, completeness, testability before an implementation agent runs) directly addresses the gap left open here.
• uninformedThe mapping of durable-fact categories to native artifacts (API shape to schemas, data invariants to types, security to policies, architecture to tests, reliability to telemetry, release to CI/CD) treats each category as if it maps cleanly one-to-one, without engaging cases where a single durable fact spans several categories at once (e.g., a business policy that is simultaneously a data invariant, a security rule, and a UX constraint), or with prior literature on the difficulty of converting tacit organizational knowledge into formal artifacts.
  When AI Writes the Code, Specifications Need an Exit Strategy — read next: Knowledge-elicitation and requirements-engineering literature on tacit-to-explicit knowledge conversion (e.g., Nonaka & Takeuchi's SECI model), and this corpus's own organizational-forgetting material (extract-3-ways-ai-can-free-orgs-from-legacy-workflows) on how depersonalized evidence surfaces facts nobody wrote down anywhere.
• incompleteThe empirical studies cited (ambiguity repair improving results ~31%, SWT-Bench doubling precision, TLA+ translation reaching only ~27%/9% syntactic/semantic correctness) support 'small specs plus independent verification' in general, but none of them actually measures this article's central claim — that treating specs as temporary and promoting only durable facts to native artifacts reduces total cost or drift compared to alternative approaches.
  When AI Writes the Code, Specifications Need an Exit Strategy — read next: Look for empirical work directly comparing 'temporary change-brief' workflows against both prose-heavy and specless workflows on drift, rework, or maintenance cost — the same empirical gap already flagged in extract-eisele-ai-coding-agents-need-clear-specs#g1 for the U-shaped cost curve, now recurring for this piece's 'expire the spec' claim.
• incompleteThe load-bearing 'delivery beats presence' claim — that a staged spec-then-generate step, not a spec's mere presence, is what worked — rests on a result the author himself reports as p≈0.18 at n=4 with an acknowledged second-pass confound, yet the surrounding prose states the causal claim in confident, unqualified language ('Only the one that treated the spec as a governing artifact... moved the outcome') that outruns the reported statistics.
  Article: When Spec-Driven Development Pays Off — read next: Look for a larger-n replication of the delivery-mode experiment that adds a control arm doing two generation passes with no specification, to disentangle the second-pass confound before treating 'delivery beats presence' as established rather than suggestive.
• uninformedThe framework assumes the specs themselves are correct ground truth ('as long as they are correct'), but does not address how errors introduced at the spec-writing stage -- itself sometimes AI-assisted ('extract this ground truth directly from the codebase') -- get caught, given that the human verification stage (step 5) happens downstream of specs, drafts, and tooling, and is described as targeting prose/flow/terminology issues rather than spec-accuracy issues.
  A cautionary tale about AI in tech writing: Why "Trust but Verify" is the only way to scale — read next: Look for material specifically on validating AI-extracted specifications against source systems, not just validating prose derived from specifications.
• incompleteThe piece treats the shift of the bottleneck from generation to verification as a personal discovery specific to documentation, without situating it in the broader pattern -- already present elsewhere in this corpus -- that verification capacity, not implementation speed, is the new binding constraint across AI-assisted knowledge work generally (code included). The documentation-specific framing adds real value (named tools, a shard-based pipeline) but doesn't acknowledge it is one instance of a wider, already-observed shift.
  A cautionary tale about AI in tech writing: Why "Trust but Verify" is the only way to scale — read next: Cross-read against corpus material on spec-driven software development making the identical claim for code, to see whether the same verification-capacity bottleneck has a consistent shape (or different failure modes) across code vs. documentation.