simas_ch AI unified process for specs
- Simon Martinelli’s AI Unified Process reframes AI coding as spec-driven engineering, with requirements, use cases, and entity models — not code — as the source of truth. - The concrete workflow runs from a business requirements catalog to AI-generated diagrams, entity models, use-case specs, code, and tests, with review gates at each step. - It matters because faster code generation worsens drift in long-lived enterprise apps unless teams keep product intent, architecture, and implementation synchronized.
Enterprise AI coding has a boring-sounding problem that turns out to be the whole game — drift. Specs say one thing, backend code does another, the UI grows its own logic, and six months later nobody knows what the system is actually supposed to do. Simon Martinelli’s AI Unified Process is an attempt to fix that by moving the center of gravity away from code and back to specifications. The core claim is simple: if AI is going to generate more of the system, then the spec has to become the real contract. ### What is the actual idea? Basically, AI Unified Process says you should start with structured requirements, not prompts and not code. Those requirements become a small set of stable artifacts — a requirements catalog, system use cases, and an entity model. AI then works downstream from those artifacts to generate diagrams, code, and tests. The point is not just speed. The point is keeping business intent visible and traceable all the way into implementation. (martinelli.ch) ### Why is code-first the problem? Because code always wins in practice. Teams write requirements, then the code changes, then the docs rot, and eventually the implementation becomes the only thing anyone trusts. AI coding tools can make that worse by accelerating output without fixing understanding. Martinelli’s pitch is that faster generation just gets you to the same maintenance mess sooner unless requirements stay central. (martinelli.ch) ### What are the artifacts here? The load-bearing pieces are pretty specific. First comes a business requirements catalog written with stakeholders. Then AI can derive business use-case diagrams and entity models, which are reviewed. After that come system use-case diagrams and detailed system use-case specifications in markdown. Only then does application code get generated and reviewed. That sequence matters because each layer is supposed to narrow ambiguity before the next one starts. (martinelli.ch) ### Why do use cases matter so much? Because they describe observable behavior instead of implementation steps. That makes them a better contract for AI than a task list. Martinelli draws a sharp line here: “requirements -> plan -> tasks” is not spec-driven development in his view — it is task scripting for an agent. Useful for small features, maybe, but fragile for enterprise systems because the artifact mixes intent, design, and implementation into one temporary instruction sheet. (martinelli.ch) ### So what keeps everything aligned? Review gates and versioning. The specs live as markdown and diagrams-as-code in Git, alongside the application code. That means changes can be diffed, branched, reviewed, and audited like software. When requirements change, the downstream artifacts are supposed to be updated in a controlled chain — diagrams, models, specs, code, tests — instead of letting backend and UI drift separately. Human review stays in the loop the whole time. (martinelli.ch) ### Where does architecture enter the picture? This only works if the system boundary is clear. Martinelli ties the process to Self-Contained Systems — basically bounded contexts with their own data, rules, behavior, and spec set. The reason is practical: AI needs a closed world. If business logic is smeared across frontend code, backend services, configs, and shared infrastructure, the model has too much ambiguity and too much blast radius. (martinelli.ch) ### Is this just theory? Not entirely. He has been presenting the approach in talks and a demo feedback app built with Java 25, Spring Boot 4.0.3, Vaadin 25, jOOQ, PostgreSQL 17, Flyway, and Spring Security. The app itself is small, but the point of the repo is to show the process artifacts sitting next to the code — use cases, entity model, and generated implementation evolving together. ### What’s the real takeaway? (martinelli.ch) The useful part of this idea is not “let AI generate everything.” It is “make the spec durable enough that generation does not destroy coherence.” If AI keeps getting better at writing code, the scarce thing stops being typing and starts being shared understanding. Martinelli’s process is really an answer to that shift — less prompt theater, more contract discipline. (martinelli.ch 1) (martinelli.ch 2)
