Simon Martinelli - Lessons from Spec-driven Development - AI Native DevCon June 2026

Summary

Simon Martinelli shares lessons from applying spec-driven development with AI to business applications. The approach grew out of a volunteer-management system he built with AI coding tools. When another organization wanted to reuse it, he realized he lacked a clear account of what the software did and how its features should change.

AI Unified Process

Martinelli’s AI Unified Process is a process-oriented approach intended to cover more of the software development lifecycle than developer-focused specification tools. Its core specifications are:

• Use cases, which describe behavior through preconditions, scenarios, alternative flows, and postconditions.
• An entity or domain model, which describes the main data concepts and their relationships.
• Supporting context, such as architecture guidance, UI designs, or API specifications.

Rather than turning a requirements document into a plan and then a list of implementation tasks, the process uses models and use cases to guide code and test generation more directly. Martinelli argues that use cases are detailed enough to communicate with both business stakeholders and developers, and that AI can work effectively with the established format.

For new systems, requirements engineers or product owners develop and review specifications with AI assistance. For modernization, teams reverse-engineer use cases and the domain model from existing code, tests, and scattered documentation. Business stakeholders then review those specifications before the team generates or changes the software.

Tools, guardrails, and workflow

Martinelli stresses that specifications alone are not enough. AI output also depends on the surrounding “harness”: skills, architecture rules, guidelines, guardrails, and access to relevant documentation. These need to match the project’s technology stack and should be refined over time.

His practical recommendations include:

• Use framework or vendor tools to scaffold projects instead of asking AI to create them. This can help avoid wasted effort and outdated dependencies.
• Keep general instruction files concise. Martinelli cites research suggesting that larger system prompts may increase hallucinations.
• Put detailed implementation procedures in reusable skills, and use MCP-based search for large documentation sets.
• Review generated work according to its risk and business impact. More critical functions warrant more scrutiny.
• Treat specification changes as changes to the source of truth, then ask AI to apply them to the existing code rather than regenerate the whole application.

Architecture and team implications

AI-assisted work requires the relevant code and context to be available together. Martinelli says that many small, tightly interconnected microservices—and their corresponding front ends—can make this difficult. A large monolith can also overwhelm the available context.

He recommends considering self-contained systems: vertical slices that group a UI, business logic, and database around one part of an application, usually within a single project or repository. This can make it easier to provide AI with the context for a specific area while allowing different systems to use different technologies.

In Martinelli’s projects, faster implementation cycles also change team practices. He described small teams of one or two developers per self-contained system, continuous flow rather than fixed sprints, and use cases tracked in a Kanban-like way. Some teams use trunk-based development and ongoing collaboration or peer review instead of pull requests.

Demo and examples

Martinelli reverse-engineered the Spring PetClinic demo application into a use-case diagram, an entity model, and detailed use cases. He then used a skill-based workflow with Claude Code to implement a simple use case—the doctor list—which he said took roughly a minute and a half.

He also described enterprise modernization work, including ERP systems and a government case-management proof of concept. His point was that modernization should not be a straight “lift and shift” between programming languages or platforms. Specifications give teams a way to reconsider workflows and add features while changing the underlying technology.

Main takeaways

• Specifications can make AI-driven development more consistent, but effective results require suitable architecture and project-specific context.
• Development may become much faster, while requirements and specification work take on greater importance and shift earlier in the process.
• Specifications can serve as durable descriptions of system behavior, potentially supporting future implementations with different technologies or interfaces.
• The approach is not necessarily waterfall: Martinelli describes working incrementally, one use case at a time.

Reviews, guides, and tutorials mentioned

• Live technical demo: Reverse-engineering Spring PetClinic and generating a doctor-list implementation from a use case.
• Review practice: Risk-based review, with ongoing peer review in some teams instead of pull requests.
• Requirements guidance: The International Requirements Engineering Board’s AI-for-requirements-engineering micro-credential and related prompting guides, skills, and materials were mentioned.
• This was a conference talk and demonstration, not a formal product review.

Main speaker/source: Simon Martinelli. Other source: The session host introduced Martinelli and moderated the brief audience Q&A.