Spec-Driven Dev Is Back. But Not How You Think Daniel Terhorst-North & Gojko Adzic

The podcast delves into critiques of "spec-driven development" as a static, one-size-fits-all methodology, emphasizing its inadequacy for creating functional software without iterative feedback. Instead, it advocates for adaptive, human-readable specifications and iterative cyclessuch as behavior-driven development (BDD) or prompt-based feedbackto refine both code and requirements. The discussion highlights tools like Microsoft/GitHub's Spec Kit, Open Spec, and Amazon's Kero, but stresses the need to customize these to individual workflows. Challenges include tools generating dense, unreadable specifications and the limitations of AI in translating natural language into maintainable code, which often fails to align with human intent or readability standards. Historical parallels are drawn to past technologies like CASE tools and model-driven architecture, which overpromised but underdelivered, underscoring the role of human expertise over overreliance on automation.

The podcast also explores the importance of guardrails and deterministic validation in software development, such as custom ESLint rules for enforcing domain-specific coding standards and leveraging CI systems to automate compliance. It critiques the commodification of AI as a replacement for human roles, arguing that deterministic, testable systems are essential for quality assurance. Practical examples include optimizing banking reconciliation systems by replacing inefficient legacy code with set-based operations, reducing processing times from hours to seconds. Additionally, the discussion emphasizes balancing automation with human oversight, highlighting risks of misaligned workflows and the need to prioritize stability and clarity before automating. Tools and frameworks, whether AI-driven or custom, are framed as aids rather than replacements, with a focus on iterative refinement, semantic validation challenges, and adapting existing solutions to specific needs.

• What if you automated spec refinement with lint-like rules for AI-generated code?

  • Move: Develop custom ESLint-style rules to validate AI-generated code against domain-specific constraints (e.g., enforce naming conventions, prohibited patterns).
  • Why Now?: Current AI tools often produce unreadable or semantically incorrect code, requiring manual validation. Custom linters can automate this process, saving time.
  • Expected Upside: Reduced manual review efforts, faster iteration cycles, and higher confidence in AI-generated code quality.

• What if you replaced rigid spec documents with iterative BDD cycles for feature development?

  • Move: Adopt Behavior-Driven Development (BDD) with collaborative feedback loops, using tools like GitHub to refine specs incrementally.
  • Why Now?: Static specifications are brittle and fail to adapt to changing requirements, while BDD aligns with the texts emphasis on iterative refinement.
  • Expected Upside: More responsive development to user feedback, fewer scope-related reworks, and clearer communication with stakeholders.

• What if you built a lightweight CI pipeline to guardrail AI-driven code changes?

  • Move: Integrate pre-commit hooks and CI tools (e.g., GitHub Actions) to enforce rules like code readability, compliance with domain constraints, and branch-specific policies.
  • Why Now?: The text highlights risks of AI misaligning with intent and the need for deterministic guardrails. Current workflows lack this automation.
  • Expected Upside: Early detection of AI-generated errors, reduced risk of flawed deployments, and streamlined onboarding for future developers.

• Adopt Iterative Feedback Loops with BDD Tools: Replace static spec-driven approaches with Behavior-Driven Development (BDD) frameworks like Cucumber or Spec Kit. Use small, incremental cycles with continuous feedback (e.g., unit tests, user reviews) to refine specifications and code dynamically.

• Create Human-Readable Specifications with Linting Rules: Draft specs in clear, concise markdown and enforce readability using custom ESLint rules or similar tools. Avoid verbose, unreviewable documents by embedding domain-specific validation logic directly into code pipelines.

• Leverage AI for Minor Tasks with Strict Guardrails: Use LLMs like Claude for non-core tasks (e.g., UI tweaks, documentation) but automate guardrails via CI/CD pipelines and pre-commit hooks (e.g., ESLint, custom CLI tools) to ensure AI output adheres to coding standards.

• Break Development into Smaller Iterations with Static Simulations: Limit changes to 3 files per step and use static HTML pages or mockups to simulate application behavior before committing code. Leverage GitHub for peer reviews during iterative cycles to catch issues early.

• Automate Repetitive Tasks with Custom CLI Tools: Replace manual workflows with scripts or existing CLI tools (e.g., grep, ESLint) to enforce rules and reduce friction. Avoid relying on markdown-based rules; instead, encode constraints into automated processes like linters or pre-commit hooks.