Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Spec-driven Development: How AI Changes Everyth...

Spec-driven Development: How AI Changes Everything (And Nothing)

AI makes coding faster, but we’re still stuck with the same old problem: code becomes the source of truth. What if we flipped this around?

This talk shows a new way to build software: the AI Unified Process. Write your requirements once. Let AI generate everything else - diagrams, models, code, and tests. When requirements change, everything updates automatically. No more outdated docs.

You’ll see how to write requirements that AI understands and keep everything connected from business needs to working code. Based on a real-world project, we will see how this works in practice.

This isn’t about replacing developers. It’s about letting AI handle the boring stuff so we can focus on what matters - understanding what the business needs.

Source code: https://github.com/simasch/aiup-petclinic

Avatar for Simon Martinelli

Simon Martinelli PRO

April 12, 2026

More Decks by Simon Martinelli

Other Decks in Programming

Transcript

  1. About Me • 30 years in Software Engineering • 25

    years with Java • Self-employed since 2009 • Teaching at two Universities • Co-lead Berne, JUG Switzerland Get 20% off: APAUT
  2. AI Native Development • Spec-Centric Development • Clear intent/specs guide

    AI to generate meaningful code • Context-Aware Development • AI agents understand full codebase context • Agent Experience AX • Autonomous AI tasks enhancing developer throughput https://ainativedev.io
  3. Spec-driven Development (SDD) • Start with the specification, not the

    code • Specifications • Define the intended behavior of the system • Serve as shared contract between intent and code • Are the single source of truth • Reduce guesswork and improve quality
  4. Three Levels of SDD Level 1 Spec-first Level 2 Spec-anchored

    Level 3 Spec-as-source • You write a spec before you write code. • The spec becomes the input for the AI coding agent. • When the feature is done, the spec is not needed anymore. • For the next change, you write a new spec. • The spec stays in the repository after the feature is done. • When the feature changes, you update the spec and the code together. • The spec is the longterm reference for humans and for the AI. • The spec is the only thing a human edits. • The code is always (re-)generated from the spec. • Humans never touch the code. Source: https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
  5. Caution: AI Is Not a Compiler • AI code generation

    isn't a compiler - it's an assistant! • Many developers expect AI to work like a compiler • Precise input → perfect output • But that's not how it works • It’s not comparable to Model-Driven Development • AI is non-deterministic and makes mistakes • You are responsible for the output!
  6. SDD in Practice • Stakeholder-centric • AI Unified Process AIUP

    https://unifiedprocess.ai • Developer-centric • Amazon Kiro • GitHub Spec Kit • BMad Method • OpenSpec • … and many more https://kiro.dev https://github.com/github/spec-kit https://github.com/bmad-code-org https://openspec.dev
  7. Set the Guardrails • Don’t use AI to scaffold the

    application • Guidelines define rules • Standards, architecture, testing • Skills capture repeatable tasks • Implementation, testing, refactoring, reviews • MCP connects tools and context • Documentation, code examples, quality checks • Human?) review stays essential!
  8. Impact on the Architecture • Modular architecture reduces the context

    size • Self-contained Systems • Single ecosystem simplifies guardrails • Full-stack frameworks
  9. Impact on Teams • Smaller team size • 12 developers

    per self-contained system • No more sprints • Continuous flow • From Scrum to Kanban • Progress tracking on use cases
  10. Conclusion • Specs, in combination with guardrails, help to •

    Reduce non-determinism • Make development sustainable • It accelerates development, but you are responsible for the quality: • Review, understand, and test the output • Know your architecture and domain
  11. Thank you! • Web martinelli.ch • EMail [email protected] • Bluesky

    @martinelli.ch • X/Twitter @simas_ch • LinkedIn https://linkedin.com/in/ simonmartinelli