Experiences from two years of AI-driven modernization

Many reports about AI-powered Spec-Driven Development come from greenfield demos or small projects. My experience is quite different.

For the past two years, I've been supporting companies in modernizing large business applications using the AI ​​Unified Process. This involves multiple teams, legacy systems, and various departments. This presentation will show what has worked well in these projects and where we've encountered challenges.

The focus is on four key questions: How should specifications be written so that an agent delivers usable code? How much of the generated code should we actually review, and where is the effort worthwhile? What are the practical benefits of skills and MCP servers? And where have we reached the limits of this approach?

I'll provide concrete examples from ongoing projects, including those we've discarded. This will make it clearer what Spec-Driven Development can actually achieve in large legacy systems and where its limitations lie.

Source code: https://github.com/ai-Unified-Process/petclinic

Transcript

1. Experiences from Two Years of AI-Driven Modernization Simon Martinelli
2. 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
3. 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
4. AI Unified Process (AIUP) • Requirements first • Specs, not code • Proven roots • Based Use-Case, adapted for AI coding agents • Built for data-centric applications • Works for new but also for existing systems • Full traceability • Use cases link to its tests and code
5. 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
6. Greenfield Workflow
7. Brownfield Workflow
8. Why Use Cases?
9. Modular architecture reduces the context size
10. Single ecosystem simplifies guardrails
11. 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
12. https://github.com/ ai-unified-process/ petclinic
13. Set the Guardrails • Don’t use AI to scaffold the application • Guidelines define rules that can be checked deterministically • 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!
14. Conclusion • Specs, in combination with guardrails, help to make development sustainable • It accelerates development, but you are responsible for the quality • Know your architecture and domain
15. Thank you! • Web martinelli.ch • EMail simon@martinelli.ch • Bluesky @martinelli.ch • X/Twitter @simas_ch • LinkedIn https://linkedin.com/in/ simonmartinelli