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

[00:00:00]Okay, we are going to go ahead and get started. Thank you guys for coming.

[00:00:04]Again, another time slot with a bit of competition, but you guys are the smart ones, I can see. Um this is Simon Martinelli, who needs no introduction if you've been involved in the Java community. Um he is a legend there, and he's going to be talking about some lessons learned from spec-driven development. Let's give Simon a hand.

[00:00:30]>> [applause] >> Hey, welcome everybody. Uh let me start by telling you a story.

[00:00:38]So, I'm in a sports club. I'm from Switzerland, and I live in a very small town, and we do sports events. So, we are mainly doing track and field, and we have competitions for kids already for 45 years.

[00:00:52]And um since 1997, I'm doing software for them, because I realized that uh doing competition and doing competition ranking list and stuff like that uh needs a lot of people back in the days, like we have were 12 to 15 people, and now it's just me using software doing that for them.

[00:01:11]But, that's not the only thing that we do. We also have different events, and we always need volunteers.

[00:01:18]And it was in summer 2024 when we had a public holiday in Switzerland, someone of the club came to me and said, "Hey Simon, we have an issue. We have a volunteer management system, but that's outdated and doesn't work anymore. So, you're a software engineer, and I heard about this AI stuff. You can certainly do that better. Let's go."

[00:01:37]And I said, "Okay, why not?" And then I started to use WinSurf. That was around uh fall 2024, and that was relatively fast, and I had a volunteer management system, but the problem was uh some one else from um music festival approached me and said, "Hey, I heard that you're building a volunteer management system. We need that as well.

[00:01:58]And then I had an issue. I had no clue what I was implementing and I had no issue and no clue how I could change the features so that it will fulfill the requirements of this music festival. And this brought me to spectrum development.

[00:02:13]Um as I was already already introduced, I'm doing mostly Java development. I'm a consultant in Switzerland for 17 years.

[00:02:20]And I'm working for insurance companies, wholesale, retail, government, large enterprises mostly. And I'm doing business applications. So I don't do tools, I don't do products, I do business applications.

[00:02:33]And during that time when I was kind of lost, I found the website. It was called AI Native Dev.io. You may know that.

[00:02:42]It's Tessel.

[00:02:43]And there I found an article from Simon Maple.

[00:02:47]And he was writing about AI Native development and that caught my attention and I read about spectrum development. But at that time, spectrum development was relatively new. So the term spectrum development is very old, right? That's from the 2000s or maybe late '90s. But the spectrum development with AI was relatively new, so I started to think about what could specs be. And because I'm doing business applications, I had a different take probably on spectrum development and I tried to find a way to do that. And so in the meanwhile, if we look at the spectrum development ecosystem, there are flavors of spectrum development. And there is one process-centric, that's my process. I created this AI Unified Process. I will show you that in a minute. But on the other hand, we have tools. We have Amazon Kiro, we have GitHub Spec Kit, we have Behave Method. These are all great tools. And also Tessel created spectrum tools back then, let's say early 2025.

[00:03:50]But they are all in my opinion at least two developer-centric.

[00:03:56]And I try to cover the whole software development life cycle, especially for enterprises where you not are solopreneur, you're someone in a larger team with different roles in a large organization.

[00:04:12]And there's a web website called AI Unified Process. Let me switch that and there you will see kind of a diagram with some colors. So the colors mean that you usually if you're on a green field, I will talk about brown fields as well because I'm rarely on green field projects.

[00:04:31]You start with a vision. And then you start gathering requirements, however you would do that.

[00:04:36]By the way, there is the International Requirements Engineering Board and they just created something called the micro-credential. It's called AI for requirements engineering and they have prompting guides, skills and stuff.

[00:04:47]They're working on that how requirements engineering you can be uh speed up with AI. And then we have testing and stuff like that. And the green thing is probably what's interesting here.

[00:04:59]I was thinking about what could be good specs that AI understands, but also all stakeholders in the project can understand. And I ended up with SysML use cases. By the way, who knows SysML use cases? Who knows that?

[00:05:15]Not a lot of people as I thought. So in SysML use cases were created by Ivar Jacobson back in 1987.

[00:05:23]And then later on we had UML and OOP and stuff like that. That was that movement late '80s, early '90s. But I was using SysML use cases for when I was working for Swiss Railways early 2000 and this quite worked well as a communication specification between stakeholders and developers back then. And I thought, "Okay, if that worked back then, why shouldn't it work together with AI?"

[00:05:50]And then we need something else. I call it the the entity model, but it's more like a domain model. So, it depends if you're doing domain-driven design or how you work. Uh these are the more or less usually the data at at the end, but we need to model that.

[00:06:05]And these things together with some software architecture, I will talk about that later, uh can be used to directly generate code. Because the difference from my approach to the tool approach is the tool approach is always the same. So, usually if you look at Amazon Kiva, for example, you have product requirements document. From that you generate some plan, and out of the plan there will be tasks, and finally AI will implement the tasks. I skip the plan task phase. I just use SysML case and entity model and generate code directly. So, now SysML cases are not enough because usually there's a UI, for example, or you if you build an API of an API spec, so you need additional information to that. So, the SysML case just defines the behavior, but how it looks can be, for example, a Figma design that you can integrate with MCP server and directly interact with Figma out of that. And then usually um code is generated and test is generated.

[00:07:05]The question is in which order? So, I'm mostly doing uh full-stack development. That means I have a UI. And if you have a UI, test-driven development is difficult because you first need to figure out how the UI will look like before you can start to create the tests.

[00:07:22]If you do APIs, for example, I would always go for test-driven development.

[00:07:26]So, start with the tests and then use the tests also to drive the code generation. And finally, uh as we can see always there is a review phase. So, most often things are reviewed. The question is how much review do you need? And that's all about risk management.

[00:07:44]So, I'm currently working on the modernization of an ERP system for the largest wholesale company in Switzerland.

[00:07:50]And if you look at an ERP system, you have different modules in the system that don't have all the same, how should I say, criticality? So, that means if you have the product management or the inventory part, if that doesn't work, that's probably not even a problem because people that are working with that inventory management system, they can just go and grab a coffee.

[00:08:13]If the order management system doesn't work, that's more of a problem because then the company probably will lose money, right? So, you should do risk management and then decide how much review um your code probably needs. But that's not different from AI or manual-driven development. That That's uh just how it works. Now, uh let's have a look in the details. So, if we have a greenfield project, for example, we would start with uh with the specs.

[00:08:45]So, the specs means we have some requirements engineers, product owners, business analysts, um depending on how the people are called in your organization, and they create the entity model and use cases. So, they can also derive that directly from requirements, for example, and uh then we will have a phase where we can review that. So, there will be something like a definition of time, and uh the the software engineer together with AI and the requirements engineer with will decide when the use case is done or the specification is done, and then we use the agent. And the agent comes with what a lot of people were already talking about. So, we need skills, MCP, guidelines, guardrails, whatever. We will see that uh in a minute in a demo.

[00:09:33]But uh because we We do the plan and task phase. We need that in the middle.

[00:09:38]That is probably the most important thing of the whole process. So, that means the skills must match the outcome. That means we need skills that knows how the code and test should be generated and that's not always the same. So, I'm working currently for six customers with that process and all the skills are different.

[00:10:00]Because I have customers that use React and Spring Boot. Others use Vaadin and Spring Boot. That's a Java framework.

[00:10:05]Others are using Angular and Quarkus.

[00:10:09]So, I have a variety of different um frameworks and also um some in-house frameworks maybe that need to be um working in in that context.

[00:10:23]Now, that's a greenfield project, but I really rarely do that. What I do mostly is software modernization. So, I'm doing modernization for uh enterprise applications for about 8 years now.

[00:10:35]And there I just uh change the process. That means I extract um use case and entity model from code and test and documentation. Maybe I have Confluence, Jira, whatever. Because usually the documentation is spread around um multiple artifacts that we have. And then we have the entity model and the use cases. They will be revised or reviewed by the business people and then we generate the new code.

[00:11:02]Because there are a lot of ideas that we can directly transform maybe from COBOL to Java. So, that's also something that I'm Tropic is is telling us, but that never worked. So, we did that like 30 years ago, COBOL to C or COBOL to C++ or something, but that's not helpful because that's just lift and shift. And modernization is not lift and shift.

[00:11:26]Modernization is rethinking how people are working with the software, integrating features that maybe are not there. And because of this reverse engineering, we also have a positive feedback from the end users because we are not transforming from one technology to another because we're going over use case and identity model and we can integrate new features.

[00:11:50]Because usually you don't do that. So the guideline when we started with the modernization project 2 years ago was we want to have the exact same system just in another technology and you don't add new features because we don't want to introduce new bugs.

[00:12:06]And now we can just do that because we just change the specification.

[00:12:11]Now the question is maybe why use cases?

[00:12:15]Because user usually people are user stories or any other product requirements document. The point is use cases are very well defined and even AI knows how to write use cases because it's around for a very long time. That means we have the use case that has usually that form, right? We have precondition, post conditions and we have scenarios.

[00:12:37]Usually have a main success scenario and then you have alternative flows. And if we compare that with user stories, we can see that user stories are just a collection or a use case is a collection of user story usually. So one user story is usually a flow in a use case and in my opinion or in my experience use cases are better than use cases because they are simply bigger.

[00:13:03]And so we have that.

[00:13:05]And I created a small project. So do we have Java developers here by the way?

[00:13:10]You certainly know the application that I was already displaying before. We have the Spring Pet Clinic. So that's kind of a demo project from the Spring Framework.

[00:13:21]Just some history. Spring was using Pet Clinic because before we had Java Enterprise Edition and they had the pet shop. And they wanted to stay in this pet industry, so to say, and they created that. So, what we can do here, we can uh see the doctors, we can uh find owners, and owners have pets. For example, Eduardo Rodriguez has Jewel and Rosie.

[00:13:46]And for example, um Jewel is here and uh has a broken leg.

[00:13:55]And we can add the visit. So, that's more or less that. Um that's a very simple a very very simple application, but it's more or less what I'm doing.

[00:14:02]So, I don't do that simple applications, but I'm doing business applications. So, we have UIs, data, stuff like that. And [snorts] what I did, I reverse engineered um the pet clinic. And that's a use case UML diagram, by the way. And this is quite helpful because on the diagram we have actors, so we have two, the visitor and the clinic user. And these usually are also roles in the system. And then we have like use cases. They are grouped into parts or in modules, whatever. So, we have a welcome page with the the doctors, then the owner management, the pet management, and uh finally the visit or the the visit management that I just did.

[00:14:43]And uh when I do reverse engineering, I just go on that level. We also have an entity model, so that's usually derived from the database model. It depends if you have a SQL database or other database, but usually you have information to cover that. And uh here we have a diagram that just contains uh the types that we can see how things are related in the system, and then we have definition of of the entities.

[00:15:08]Um I will talk about architecture in a minute because uh working like that or working with AI, in my opinion, has a huge impact on the architecture styles or which architecture fits well. And then we have uh created or reverse engineered uh the use cases. Let's go and look at that one. That's the the [snorts] list of the doctors. And here you can see that we have an actor, we have pre-conditions, scenarios. And this one also contains an API that's irrelevant. That's was just reverse engineered. And then we have post-conditions. And the post-conditions are kind of acceptance criteria if you think about user stories that can be verified in tests to check if the use case finally was successful. And from that, because I have skills and everything, I just can call implement. So that means in those projects, we don't prompt. So we have skills for everything and we iterate on the skills. So we try to improve them constantly. We share the skills in the organization. That's kind of a problem currently, because not everybody in the organization is maybe using the same agent. So we need some skill distribution.

[00:16:18]I'm using Cloud Code here. I do things that I usually don't do. So I don't run it here inside the IDE. That's just for for demo purposes. And now it it looks at that. What I also have and what you heard in the last talk if you were here in that room, I have a Cloud MD.

[00:16:39]And this more or less has not much inside, but the very important part.

[00:16:44]Where is it?

[00:16:46]Somewhere I can't find it, but somewhere there's a reverence to some guidelines.

[00:16:50]So we have guidelines for architecture for example, how we structure the application, how the package structure looks like, what tools we are using that AI knows about that. But most of the things are in the skills. And my browser also comes with skills. So if you go there, and we don't have time to to look at that, but if you go there and look at it, you see there are two levels of skills. So we have skills primarily for specification and there is skills specific for one stack that I'm using.

[00:17:20]But I stopped adding more skills for more stacks because there are so many combinations out there that that's probably a thing that the company has to do.

[00:17:29]And now it it works on that.

[00:17:31]And maybe I go back to this one because I was already talking about that. In my opinion, uh the architecture has an impact on how well things work. So, first of all, in the past 15 years or so, we were doing microservices.

[00:17:52]And most of my customers did microservices in a very naive way.

[00:17:57]So, they have way too many microservices because they were focusing on the micro in microservices.

[00:18:04]And that's probably a problem, so they have this distributed big ball of mud.

[00:18:08]So, I'm working for an insurance company and they have around 500 microservices.

[00:18:13]And that's kind of an impact because they also have a kind of 500 micro front ends. And they are kind of related, right? So, we have an N2M relationship between uh front end and back end. And that's the worst case scenario.

[00:18:31]Because if you have if you want to work with AI on a certain part of your system, you have to have the context.

[00:18:37]So, you need the code that the AI should work on in a single place, at least on your machine or wherever you work with that with AI.

[00:18:46]And if you have 500 microservices, a lot of components somewhere, and you have to mix and match that, that becomes very difficult.

[00:18:54]Now, there's a movement away from microservices to monolithic or modular monolithic application. And I would say stop here, don't do that because that's not the right way. Because maybe you have like a huge monolith that we have currently ERP system has thousands of database tables and a lot of modules.

[00:19:18]And that's a problem, right? Because the context is too big. So, how can we work on that? And there's an architecture style that's not so well known, but it's approximately um created when microservices were created.

[00:19:33]It's called self-contained system. And the self-contained system architecture just says we create verticals. So, we split our application into verticals which has UIs, business logic, and database in one repo usually or in one project at least.

[00:19:48]Or in one application. And if you have that, if you can split that, and we do that with ERP modernization, then the AI can exactly work on that. And you can also add skills in depending on what technology you're using. So, for example, in the inventory system here we're using Vaadin as I do in my demo. That's a web framework in Java, but for the order management system, for example, we have React in the front end. So, we can have different technology in different self-contained systems.

[00:20:19]Um there's another thing that if you can stay on one stack, so for example, if you stay with the Java stack or uh stay with the JavaScript TypeScript stack or ecosystem, then probably creating harder is simpler because you need to create skills and all the stuff just for one technology. Otherwise, if you do what my customers usually doing, they have a single page framework like um React or Angular and then usually Spring Boot or Quarkus in the back end, they have to create this twice and also maintain that twice, right?

[00:20:52]And once another thing that's also quite interesting is the impact on the teams, and that's the bigger change. So, for those other company, that's relatively simple because that's not a huge team.

[00:21:07]And they already work in maintenance mode, so they don't really do Scrum anymore, right? They don't have fixed sprints. They work on depending on what features they have to implement. But because we uh use like the specs as an input as we also kind of did with the stories by the way in a in a Scrum uh development way.

[00:21:32]But we are way faster, so we cannot wait to weeks. So that's way too long. So we need maybe 2 weeks to do the specification, but we don't need 2 weeks to create the software. And we also reduce the team size. We are uh per self-contained system one to two developers.

[00:21:50]Preferable two because of uh knowledge exchange and maybe it's uh boring to work on a project [clears throat] alone.

[00:21:58]But we reduced that from like five to seven to one to or two.

[00:22:02]And as I said, we do no more sprints. We do continuous flow, and we use the use cases kind of uh in a Kanban way to track the progress. That's all we do, right?

[00:22:13]Then something that or we can go back.

[00:22:16]Man, that's probably done. And what it created is just uh the implementation of that.

[00:22:27]And now we have the list of doctors here. So that's what's created. Oh.

[00:22:33]You're right.

[00:22:35]I really don't like PowerPoint because this changes everything. So that's what's done. It took 1 and 1/2 uh minute or so. And now we see the doctors, right? So that's a simple use case, but that's something that we have a lot in the ERP system, something like that, right?

[00:22:53]And why did this work?

[00:22:55]Uh first of all, because of this guardrails that I was talking about. So, first of all, my recommendation, never let AI create a project. First of all, you just waste tokens if you do that.

[00:23:12]But, if you do that, you probably end up with an outdated application. So, if you have like Spring, for example, in the trial field there's start.spring.io, you can create an application, you get the newest dependencies, you get them the way how the Spring team currently thinks about creating applications. Maybe you have a CLI for your tools, use that.

[00:23:32]Don't use AI for that.

[00:23:34]And then you have to define the rules.

[00:23:35]So, that means you don't put everything in Claude MD or in the agents MD because there's a study from the ETH University in Zurich, and they say the bigger the system prompt, the more hallucinations you get probably.

[00:23:51]So, it's maybe even better to have none of those files than a big one.

[00:23:57]And then you can add architecture. So, we usually do kind of architecture, um or arc42, that's a kind of a format how you can do architecture documentation. Then we add skills, that's the important thing. A lot of people were talking about that.

[00:24:13]And we also have MCP service because um skills shouldn't be that big, and we have huge documentation, for example, for in-house frameworks where we get MCP service in vector search that AI can directly search in the documentation.

[00:24:29]That's um how we do that. And if you do a good job and iterate on that, you really get probably um a near deterministic solution. So, what I did before, I can delete everything, do it again, I will get more or less the same outcome. Right.

[00:24:48]But, very important, the human should review depending, as I said, on the risk, what happens when your system doesn't work or have bugs, then you should uh probably go and add more reviews or depending on if you do reviews by hand or you use AI to review or however you work on that.

[00:25:08]So, we don't do pull requests, by the way, at the moment. We do trunk-based development and we do kind of an ongoing review process. So, we work on something and then we do peer reviews. So, we work if we are two developers, they work together and do the review together. So, they try to explain parts of the system that they created with the other. So, we don't do pull requests anymore in that those projects.

[00:25:36]So, to conclude, um specs reduce nondeterminism, but not specs are not enough. So, you need to harness, you need all the context around that that this really works.

[00:25:47]And something that I didn't talk about is, in my opinion, specs are very sustainable or hopefully they will be sustainable in the future because currently what I'm doing is reverse engineering of existing code into specs.

[00:26:02]And if we have specs, we can probably generate the same application in different technology with a different UI. Maybe we don't have even a UI, we have chat or something directly from the specs.

[00:26:13]And the business people can directly change the way the system should behave without developers. So, they don't need developers um talking about that or looking into that.

[00:26:26]And this accelerates development. The problem is it it at the moment it just accelerates development.

[00:26:34]Right? So, the requirements phase and the spec phase takes some time. For example, I'm working for Swiss government, for the parliament, they are uh have a business case management software that we want to modernize. And I'm the only one during the proof of concept doing something with code.

[00:26:52]but we have two product owner requirements engineers that work on the spec and they have much more work to do than I have. I just automate everything, so currently I'm working on on the pipeline that they can just change the markdown files and everything will automatically generated.

[00:27:09]Um so the kind of the work moves or shifts left. So everything shifts left to requirements engineering in my opinion because now that's obvious.

[00:27:18]Before like if it is scrum you had 2 weeks to work on the requirements somehow and then developers were 2 weeks working on the implementation. Now you have 2 weeks and then 5 minutes and 2 weeks. Something like that, right?

[00:27:34]And the most important thing is you should know your architecture and domain and this will lead us to the discussion about the junior developers, but I think we stop here at this. And that's it from my side.

[00:27:46]Thank you very much.

[00:27:50]>> [applause] >> Thank you so much, Simon. Um we have a few minutes for questions if anyone would like to ask something, okay? We'll start here.

[00:28:03]>> Um thank you for nice hands-on presentation. I have a question about use cases. Uh did I understand correctly that you initially generate diagram in PlantUML and then from that diagram you generate detailed text requirements in markdown?

[00:28:18]>> So usually you you would So on a greenfield project you would have like a requirements catalog or something or a product requirements document and from that I would first generate the use case diagram that you have no view what we have.

[00:28:33]And maybe this would even give you an idea how to split your application into models.

[00:28:38]And then from that you can go ahead and generate that because since use cases are kind of in the user story included, right? It's just more detailed with all the steps. And um yeah, our requirements engineers and product owners use AI a lot just to verify the use cases, to find maybe duplicates or things that are missing, and they work a lot on on that with AI.

[00:29:04]Yeah, but we go use case by use case because a lot of people say spectrum development is waterfall, and that's simply not true.

[00:29:11]It just is It's just requirements and then test and implementation, but that's also the case with Agile, right? You have to do that but but we don't do big up front design, we just go use case by use case.

[00:29:28]>> Maybe it's a follow-up question, but like say your user story is wrong and you need to update it, what's the flow? Do you regenerate the whole application?

[00:29:41]Do you append a new requirement document? I I don't understand.

[00:29:47]>> So, if I have a use case, for example, let's go here and I have What did I do before? I think I did that one, right? And now I see, okay, there's What do we have something here?

[00:30:00]So, it says that that displays the doctor with first name, last name, and the comma-separated list of specialties, for example.

[00:30:09]And now I could go ahead and say, "No, that's not comma-separated, that's maybe um the at sign that I need to separate."

[00:30:17]And what I would do now, I would go ahead and say again the same that I did before, implement.

[00:30:23]Because at the moment, we need to code or we read the code, right? And I don't want I could throw it away, for sure.

[00:30:31]But then my Git history wouldn't look nice and it would be harder to review the changes, right? That would be an issue.

[00:30:37]In my opinion, or not in my opinion, in opinions of some people is AI doesn't need the source code. So, I'm a Java developer, that's bytecode that's executed. AI could generate the bytecode, there's no reason to generate the source code, maybe. Or maybe we end up with a programming language that's more AI-friendly and less human-readable. I don't know.

[00:31:00]But at the moment, we just work as you would if you would do that manually. So, we really change the use cases or the entity model, and then we say just apply the changes. Yeah.

[00:31:13]>> I'm so sorry. There's so many more questions, but we are out of time. You guys can hunt down Simon and ask him yourselves.

[00:31:22]Um our next session is going to be in 10 minutes, but big round of applause for Simon.

[00:31:29]>> [music] [music]