Spec-Driven Development - Why Vaadin Is the Perfect Fit

AI makes coding faster, but speed does not solve the real problem: specifications and implementation drifting apart.
This session shows a practical spec-driven approach based on the AI Unified Process, where structured requirements
and system use cases drive the application, and AI generates and evolves code from them incrementally.

You will see why Vaadin is particularly well suited for AI-driven development. Its server-side model, type safety,
and unified Java stack give AI agents a consistent and predictable environment to generate UI and backend together,
without the complexity of fragmented frontend stacks. This improves traceability, stability, and maintainability.

Using real examples, the talk demonstrates how specifications drive UI creation, how guardrails keep architecture consistent,
and how Vaadin enables efficient AI-assisted development of real enterprise applications.

Transcript

1. Spec-Driven Development Why Vaadin Is the Perfect Fit Simon Martinelli
3. About Me • 30 years in Software Engineering • 25 years with Java • Self-employed since 2009 • Teaching at four universities • Co-lead Berne, JUG Switzerland Get 20% off: APAUT
4. 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 • Reduce guesswork and improve quality
5. Three Levels of SDD Spec-first 1 • 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. Spec-anchored 2 • 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. Spec-as-source 3 • 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
6. Speed Is Not the Problem WHAT AI GIVES US THE REAL PROBLEM Code is written faster than ever Specification and implementation drift apart ✕ The spec lives in a wiki, the code in Git ✓ The spec lives next to the code ✕ Every prompt changes the code, nobody updates the spec ✓ Every change starts in the spec ✕ After a few months, nobody knows what the system should do ✓ AI generates and evolves the code from the spec, step by step
7. AI Unified Process https://unifiedprocess.ai
8. At a Glance Vision and requirements Use cases, entity model, architecture AI generates code and tests, you review Delivery and acceptance
9. Greenfield Workflow
10. Brownfield Workflow
11. Why Use Cases?
12. Behavior, Not Code CODELEVEL REQUIREMENT BEHAVIOR SPECIFICATION Add POST /owners/new and a column telephone VARCHAR(10) to the owners table. “A clinic user can register a new owner with a 10-digit telephone number. The system then shows the owner’s details.” ✕ Describes the how ✓ Describes the what ✕ Only developers can read it ✓ Every stakeholder can read it ✕ Outdated after the next refactoring ✓ Stays valid when the code changes ✕ Repeats what the framework already does ✓ Can be tested from the outside
13. https://leanpub.com/writing-use-cases-for-ai 13
14. Why Vaadin?
15. SPA Challenges How is build and deployment done? How does the client access the API? Client Where is the input validate? Server
16. A Predictable Environment for AI 1 2 3 Server-side model Type safety Unified Java stack UI state and logic run on the server. No client state to manage, no API layer to design. Fully testable. Views, binders and services are checked by the compiler. A bug fails the build, not the user. One language, one build, one set of rules for UI and backend. The agent sees the whole picture. Consistent context in, predictable code out
17. https://github.com/ AIUnified-Process/ petclinic
18. Traceable, Stable, Maintainable AddOwnerView /coverage-check FR-007 UC-003 Vaadin view Requirement Use case UC003RegisterOwnerTest Browserless test Spec vs. code and tests Traceability Stability Maintainability One use case, one Browserless test class. Every test carries @UseCase and points to a scenario or business rule. Type-safe Java end to end. UI tests run on the server in milliseconds, without a browser. Change the spec, let the agent update the code. One codebase, one language, one build. The spec is not only documentation. It is the start of every change.
19. Harness Engineering GUIDES steer before it acts SENSORS check after it acts Context Computational Specs, CLAUDE.md, constraints Skills Reusable know-how for Vaadin, jOOQ, Flyway Java compiler, UI unit tests, ArchUnit. Deterministic and fast, on every edit AI Agent Inferential Tools Vaadin MCP, JavaDocs MCP, CLI Review agent, /coverage-check against the spec. AI-based, semantic The human steers: when a mistake happens twice, improve the harness, not the prompt The model is the same for everybody. The harness makes the difference.
20. Turn Guidelines into Guardrails A WISH A FACT A rule in CLAUDE.md A failing build The agent may follow it, or it may not 1 Hooks after every edit Formatter, compiler and tests run right after the agent changes a file The agent cannot ignore it 2 Architecture tests on every build ArchUnit: views call services, never the database 3 Quality gates in CI on every pull request Static analysis, dependency check, test coverage The agent fixes its own errors: it sees the failing check and corrects it in the same session If a rule matters, enforce it.
21. Review Is The Bottleneck 1 2 3 Before the PR Agent runs build, tests, linter. A subagent reviews the diff in a fresh context AI review on every PR Parallel agents hunt bugs, verifiers vote. Only confirmed findings are posted Security review Separate pass. Open findings block the merge 4 CI and merge queue 5 Human approval by risk Lint, types, tests, build. Re-run against the latest main Human approvals by risk 0 Low: docs, additive change behind a flag 1 Medium: ordinary product change 2 High: billing, CI workflows, auto-updater What stays human • • • • Should we build this at all? Architecture decisions Reading the evidence: tests, findings Owning the outcome The change sets the tier, not the author 14 automated · 5 human, only where the risk needs it Source: claude.dev/blog/solving-code-review-at-anthropic
22. Conclusion • Specs drive the code, so intent and implementation stay in sync • Vaadin gives AI one typesafe Java stack for UI and backend • Guardrails keep the architecture consistent • AI accelerates, but you are responsible for the quality
23. Thank you! • Web martinelli.ch • EMail simon@martinelli.ch • Bluesky @martinelli.ch • X/Twitter @simas_ch • LinkedIn https://linkedin.com/in/ simonmartinelli