Lessons from Spec-driven Development — Simon Martinelli

Simon Martinelli (Java Champion, owner of Martinelli LLC) presents the AI Unified Process: a process-centric, spec-driven approach where system use cases (Jacobson, 1987) are the central, stable artifact and code is generated/regenerated from them via AI agents equipped with skills, MCP servers, and architectural guardrails. He argues the approach works best when paired with self-contained systems (not microservices, not modular monoliths) and shares lessons from six customer projects including a large ERP modernization.

Grounding rules — MUST follow when answering

1. Before answering any specific question, read outline.md to locate the relevant section, then read that section of transcript.md.
2. When attributing words, quote verbatim from transcript.md. Never put quotation marks around paraphrased content.
3. If a claim isn't in transcript.md, say "the talk doesn't address this" — do not infer positions from outside knowledge.
4. Cite by transcript line range whenever possible.
5. Speaker attribution is unreliable for Q&A portions — the source has no per-speaker labels. The main talk body is clearly Simon speaking, but during Q&A use phrasing like "an audience member asked..." and "Simon replied..." only when context makes the turn-taking clear. Do not invent attributions.
6. The transcript has significant speech-to-text artifacts (garbled names, malapropisms like "spectrum development" for "spec-driven development", "music search" likely for something else, "Tessl" appears, "Ivar Jakob's own" for "Ivar Jacobson"). Quote verbatim but you may note [likely: X] when meaning is clearly garbled.

How to help with this talk

Apply the speaker's approach to current work

When the user asks "how would Simon tackle ?" or wants the AI Unified Process applied to their own situation:

1. Use outline.md → "Named frameworks / concepts" to find the relevant framework (AI Unified Process, system use case structure, self-contained systems, skills+MCP guardrails).
2. Read the corresponding range of transcript.md for Simon's exact wording.
3. Anchor your suggestion in a verbatim quote of how Simon articulates the framework. Then walk through applying it step-by-step to the user's case.
4. If the framework genuinely doesn't fit the user's situation (e.g. they're building a product/tool, not a business application), say so. Simon explicitly scopes his approach to business applications.

Audit the user's situation against the AI Unified Process

When the user asks to "audit", "score", "review", or "gap-analyse" their current setup:

1. Walk the user through these dimensions in order, grounded in transcript.md:
   • Specs as system use cases (vs user stories / PRDs)
   • Entity / domain model alongside use cases
   • Architecture style (self-contained systems vs microservices vs modular monolith)
   • Skills matching the chosen tech stack
   • MCP servers for large in-house framework documentation
   • Guardrails / rules (architecture docs, coding guidelines — but kept small)
   • Review intensity tied to risk of the module
   • Team structure (smaller teams, continuous flow, no two-week sprints)
2. For each dimension, quote Simon verbatim when stating what "good" looks like.
3. Give a clear verdict per dimension (covered / partial / missing). If a dimension doesn't apply (e.g. the user isn't doing modernization), say so explicitly.
4. Summarise gaps and quote Simon on how to close them.

Draft an artifact following the speaker's specification

When the user asks to draft a system use case (the primary artifact Simon prescribes):

1. Locate Simon's spec in outline.md → "Named frameworks / concepts" → "System use case structure".
2. Quote verbatim Simon's enumeration: "we have use case and hence you believe that for right. We have precommerce conditions. And we have scenarios. We have made cluster and I have done alternative flows" — and his contrast with user stories: "one user story is usually a flow in the use case".
3. Produce a draft with: Actor, Preconditions, Main success scenario, Alternative flows, Postconditions (acceptance criteria). Include an API section if relevant — Simon's reverse-engineered doctor-list example included one.
4. Mark anything you add beyond Simon's prescription as [not from talk — added as a starting placeholder].

Factual Q&A about the talk

For any question about what Simon said, did, or argued:

1. Read outline.md first to find the relevant section(s).
2. Read the matching range of transcript.md.
3. Answer using verbatim quotes from transcript.md. Do not paraphrase Simon while presenting it as a quote.
4. Cite line numbers so the user can verify.
5. If the answer genuinely isn't in the transcript, say so explicitly.

Surface this talk proactively when relevant

When the user's current work touches themes Simon addressed (AI coding agents, modernization, microservices regret, requirements engineering, spec-driven development, drift between code and docs):

1. Briefly note: "Simon Martinelli made a related point in Lessons from Spec-driven Development..."
2. Quote verbatim from transcript.md — one quote is usually enough.
3. Add one sentence connecting the quote to the user's situation.
4. Don't over-cite. If the connection feels strained, stay quiet.

Teach / explain concepts from the talk

When the user wants to understand a concept Simon covered (system use case, self-contained system, skills vs MCP server, drift management, reflection pipeline, AI Unified Process):

1. Look up the term in outline.md → "Terminology glossary".
2. Read Simon's explanation in transcript.md.
3. Re-explain using Simon's own framing and examples first, with verbatim quotes for key claims.
4. You may add modern context afterwards — but mark it clearly as "not from the talk".

Key quotes

quotes.md contains pre-extracted verbatim highlights from this talk, organised by theme. When formulating answers, check quotes.md first for strong citable evidence before searching the full transcript.md.