YT YouTube2Text

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

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

by AI Native Dev · 5,113 words · 829 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Okay, we are going to go ahead and get
0:02started. Thank you guys for coming.
0:04Again, another time slot with a bit of
0:07competition, but you guys are the smart
0:09ones, I can see. Um this is Simon
0:12Martinelli, who needs no introduction if
0:16you've been involved in the Java
0:17community. Um he is a legend there, and
0:21he's going to be talking about some
0:22lessons learned from spec-driven
0:25development. Let's give Simon a hand.
0:30>> [applause]
0:33>> Hey, welcome everybody. Uh let me start
0:36by telling you a story.
0:38So, I'm in a sports club. I'm from
0:40Switzerland, and I live in a very small
0:42town, and we do sports events. So, we
0:45are mainly doing track and field, and we
0:48have competitions for kids already for
0:5045 years.
0:52And um since 1997, I'm doing software
0:55for them, because I realized that uh
0:58doing competition and doing competition
1:01ranking list and stuff like that uh
1:03needs a lot of people back in the days,
1:04like we have were 12 to 15 people, and
1:07now it's just me using software doing
1:09that for them.
1:11But, that's not the only thing that we
1:12do. We also have different events, and
1:15we always need volunteers.
1:18And it was in summer 2024 when we had a
1:21public holiday in Switzerland, someone
1:23of the club came to me and said, "Hey
1:25Simon, we have an issue. We have a
1:27volunteer management system, but that's
1:29outdated and doesn't work anymore. So,
1:31you're a software engineer, and I heard
1:33about this AI stuff. You can certainly
1:35do that better. Let's go."
1:37And I said, "Okay, why not?" And then I
1:39started to use WinSurf. That was around
1:42uh fall 2024, and that was relatively
1:45fast, and I had a volunteer management
1:47system, but the problem was
1:49uh some
1:50one else from um music festival
1:52approached me and said, "Hey, I heard
1:53that you're building a volunteer
1:55management system. We need that as well.
1:58And then I had an issue. I had no clue
2:00what I was implementing and I had no
2:02issue and no clue how I could change the
2:05features so that it will fulfill the
2:07requirements of this music festival. And
2:10this brought me to spectrum development.
2:13Um
2:14as I was already already introduced, I'm
2:16doing mostly Java development. I'm a
2:17consultant in Switzerland for 17 years.
2:20And I'm working for insurance companies,
2:23wholesale, retail, government, large
2:26enterprises mostly. And I'm doing
2:28business applications. So I don't do
2:29tools, I don't do products, I do
2:32business applications.
2:33And during that time when I was kind of
2:37lost, I found the website. It was called
2:40AI Native Dev.io. You may know that.
2:42It's Tessel.
2:43And there I found an article from Simon
2:46Maple.
2:47And he was writing about AI Native
2:50development and that caught my attention
2:52and I
2:53read about spectrum development. But at
2:56that time, spectrum development was
2:58relatively new. So the term spectrum
3:00development is very old, right? That's
3:02from the 2000s or maybe late '90s. But
3:05the spectrum development with AI was
3:07relatively new, so I started to think
3:10about what could specs be. And because
3:12I'm doing business applications, I had a
3:15different take probably on spectrum
3:17development and I tried to find a way to
3:20do that. And so in the meanwhile, if we
3:23look at the spectrum development
3:25ecosystem, there are flavors of spectrum
3:29development. And there is one
3:31process-centric, that's my process. I
3:33created this AI Unified Process. I will
3:35show you that in a minute. But on the
3:38other hand, we have tools. We have
3:39Amazon Kiro, we have GitHub Spec Kit, we
3:41have Behave Method. These are all great
3:44tools. And also Tessel created spectrum
3:46tools back then, let's say early 2025.
3:50But they are all in my opinion at least
3:54two developer-centric.
3:56And I try to cover the whole
3:59software development life cycle,
4:01especially for enterprises where you not
4:04are solopreneur, you're someone in a
4:07larger team with different roles in a
4:10large organization.
4:12And there's a web website called AI
4:17Unified Process. Let me switch that and
4:19there you will see kind of a diagram
4:22with some colors. So the colors mean
4:24that you usually if you're on a green
4:26field, I will talk about brown fields as
4:27well because I'm rarely on green field
4:29projects.
4:31You start with a vision. And then you
4:32start gathering requirements, however
4:35you would do that.
4:36By the way, there is the International
4:38Requirements Engineering Board and they
4:40just created something called the
4:42micro-credential. It's called AI for
4:44requirements engineering and they have
4:46prompting guides, skills and stuff.
4:47They're working on that how requirements
4:49engineering you can be uh speed up with
4:52AI. And then we have testing and stuff
4:54like that. And the green thing is
4:56probably what's interesting here.
4:59I was thinking about what could be good
5:01specs that AI understands, but also all
5:05stakeholders in the project can
5:07understand. And I ended up with SysML
5:10use cases. By the way, who knows SysML
5:12use cases? Who knows that?
5:15Not a lot of people as I thought. So in
5:17SysML use cases were created by Ivar
5:19Jacobson back in 1987.
5:23And then later on we had UML and OOP and
5:26stuff like that. That was that movement
5:29late '80s, early '90s. But I was using
5:33SysML use cases for when I was working
5:35for Swiss Railways early 2000 and this
5:39quite worked well as a communication
5:42specification between stakeholders and
5:44developers back then. And I thought,
5:46"Okay, if that worked back then, why
5:48shouldn't it work together with AI?"
5:50And then we need something else. I call
5:52it the the entity model, but it's more
5:54like a domain model. So, it depends if
5:56you're doing domain-driven design or how
5:58you work. Uh these are the more or less
6:01usually the data at at the end, but we
6:03need to model that.
6:05And these things together with some
6:08software architecture, I will talk about
6:09that later,
6:10uh can be used to directly generate
6:12code. Because the difference from my
6:15approach to the tool approach is the
6:17tool approach is always the same. So,
6:19usually if you look at Amazon Kiva, for
6:22example, you have product requirements
6:23document. From that you generate some
6:26plan, and out of the plan there will be
6:28tasks, and finally AI will implement the
6:31tasks. I skip the plan task phase. I
6:34just use SysML case and entity model and
6:37generate code directly. So, now SysML
6:39cases are not enough because usually
6:42there's a UI, for example, or you if you
6:45build an API of an API spec, so you need
6:47additional information to that. So, the
6:50SysML case just defines the behavior,
6:53but how it looks can be, for example, a
6:56Figma design that you can integrate with
6:58MCP server and directly interact with
7:00Figma out of that. And then usually um
7:03code is generated and test is generated.
7:05The question is in which order? So, I'm
7:08mostly doing
7:10uh full-stack development. That means I
7:12have a UI. And if you have a UI,
7:14test-driven development is difficult
7:16because you first need to figure out how
7:18the UI will look like before you can
7:20start to create the tests.
7:22If you do APIs, for example, I would
7:24always go for test-driven development.
7:26So, start with the tests and then use
7:28the tests also to drive the code
7:31generation. And finally,
7:33uh as we can see always there is a
7:34review phase. So, most often things are
7:38reviewed. The question is how much
7:40review do you need? And that's all about
7:42risk management.
7:44So, I'm currently working on the
7:46modernization of an ERP system for the
7:48largest wholesale company in
7:49Switzerland.
7:50And if you look at an ERP system, you
7:52have different modules in the system
7:55that don't have all the same,
7:58how should I say, criticality? So, that
8:01means if you have the product management
8:02or the inventory part, if that doesn't
8:05work, that's probably not even a problem
8:07because people that are working with
8:09that inventory management system, they
8:11can just go and grab a coffee.
8:13If the order management system doesn't
8:15work, that's
8:17more
8:18of a problem because then the company
8:20probably will lose money, right? So, you
8:23should do risk management and then
8:25decide how much review
8:27um your code probably needs. But that's
8:29not different from AI or manual-driven
8:31development. That
8:32That's uh just how it works. Now,
8:35uh let's have a look in the details. So,
8:37if we have a greenfield project, for
8:39example,
8:43we would start with uh with the specs.
8:45So, the specs means we have some
8:46requirements engineers, product owners,
8:49business analysts, um
8:51depending on how the people are called
8:54in your organization, and they create
8:56the entity model and use cases. So, they
8:58can also derive that directly from
9:00requirements, for example, and uh then
9:03we will have a phase where we can review
9:05that. So,
9:07there will be something like a
9:09definition of time, and uh the the
9:11software engineer together with AI and
9:13the requirements engineer with will
9:14decide when the use case is done
9:17or the specification is done, and then
9:19we use the agent. And the agent comes
9:21with
9:22what a lot of people were already
9:24talking about. So, we need skills, MCP,
9:27guidelines, guardrails,
9:29whatever. We will see that uh in a
9:31minute in a demo.
9:33But uh because we We do the plan and
9:36task phase. We need that in the middle.
9:38That
9:39is probably the most important thing of
9:42the whole process. So, that means the
9:44skills must match the outcome. That
9:47means we need skills that
9:49knows how the code and test should be
9:51generated and that's not always the
9:53same. So, I'm working currently for six
9:56customers with that process
9:58and all the skills are different.
10:00Because I have customers that use React
10:02and Spring Boot. Others use Vaadin and
10:04Spring Boot. That's a Java framework.
10:05Others are using Angular and Quarkus.
10:09So, I have a variety of different um
10:12frameworks and also um
10:15some in-house frameworks maybe that need
10:18to be um
10:20working in in that context.
10:23Now, that's a greenfield project, but I
10:24really rarely do that. What I do mostly
10:27is software modernization. So, I'm doing
10:29modernization for uh enterprise
10:32applications for about 8 years now.
10:35And there I just uh
10:38change the process. That means I
10:41extract
10:42um use case and entity model from code
10:45and test and documentation. Maybe I have
10:46Confluence, Jira, whatever. Because
10:48usually the documentation is spread
10:51around um
10:52multiple artifacts that we have. And
10:54then we have the entity model and the
10:56use cases. They will be revised or
10:57reviewed by the business people and then
11:00we generate the new code.
11:02Because there are a lot of ideas that we
11:05can directly transform maybe from COBOL
11:08to Java. So, that's also something that
11:10I'm Tropic is is telling us, but that
11:12never worked. So, we did that like 30
11:15years ago, COBOL to C or COBOL to C++ or
11:18something, but that's not helpful
11:21because that's just lift and shift. And
11:24modernization is not lift and shift.
11:26Modernization is rethinking how people
11:29are working with the software,
11:30integrating features that maybe are not
11:32there. And because of this reverse
11:34engineering,
11:35we also have
11:38a positive feedback from the end users
11:40because
11:41we are not transforming from one
11:44technology to another
11:46because we're going over use case and
11:47identity model and we can integrate new
11:49features.
11:50Because usually you don't do that. So
11:52the
11:53guideline when we started with the
11:55modernization project 2 years ago was we
11:58want to have the exact same system just
12:01in another technology and you don't add
12:02new features because we don't want to
12:04introduce new bugs.
12:06And now we can just do that because we
12:07just change
12:09the specification.
12:11Now the question is maybe why use cases?
12:15Because user usually people are user
12:16stories or any other product
12:19requirements document. The point is use
12:21cases are very well defined and even AI
12:24knows how to write use cases because
12:26it's around for a very long time. That
12:29means we have the use case that has
12:31usually that form, right? We have
12:32precondition, post conditions and we
12:35have scenarios.
12:37Usually have a main success scenario and
12:39then you have alternative flows. And if
12:41we compare that with user stories, we
12:44can see that user stories are just a
12:46collection or a use case is a collection
12:48of user story usually. So one user story
12:50is usually
12:53a flow in a use case and in my opinion
12:58or in my experience use cases are better
13:00than use cases because they are simply
13:02bigger.
13:03And so we have that.
13:05And I created a small project. So do we
13:07have Java developers here by the way?
13:10You certainly know the application that
13:13I
13:14was already
13:15displaying before. We have the Spring
13:17Pet Clinic. So that's kind of a demo
13:19project from the Spring Framework.
13:21Just some history. Spring
13:24was using Pet Clinic because before we
13:26had Java Enterprise Edition and they had
13:29the pet shop. And they wanted to stay in
13:31this pet
13:33industry, so to say, and they created
13:35that. So, what we can do here, we can uh
13:38see the doctors, we can uh find owners,
13:41and owners have pets. For example,
13:43Eduardo Rodriguez has Jewel and Rosie.
13:46And for example, um Jewel is here and uh
13:51has a broken leg.
13:55And we can add the visit. So, that's
13:56more or less that. Um that's a very
13:58simple a very very simple application,
14:00but it's more or less what I'm doing.
14:02So, I don't do that simple applications,
14:04but I'm doing business applications. So,
14:06we have UIs, data, stuff like that. And
14:08[snorts] what I did, I reverse
14:10engineered um
14:12the pet clinic. And that's a use case
14:15UML diagram, by the way. And this is
14:18quite helpful because on the diagram we
14:19have actors, so we have two, the visitor
14:21and the clinic user. And these usually
14:24are also roles in the system. And then
14:26we have like use cases. They are grouped
14:29into parts or in modules, whatever. So,
14:32we have a welcome page with the the
14:35doctors, then the owner management, the
14:37pet management, and uh finally the visit
14:40or the the visit management that I just
14:42did.
14:43And uh when I do reverse engineering, I
14:46just go on that level. We also have an
14:47entity model, so that's usually derived
14:49from the database model. It depends if
14:51you have a SQL database or other
14:53database, but usually you have
14:55information to cover that. And uh here
14:58we have a diagram that just contains uh
15:00the types that we can see how things are
15:03related in the system, and then we have
15:05definition of of the entities.
15:08Um I will talk about architecture in a
15:10minute because uh working like that or
15:13working with AI, in my opinion, has a
15:15huge impact on the architecture styles
15:17or which architecture fits well. And
15:20then we have uh created or reverse
15:23engineered uh
15:25the use cases. Let's go and look at that
15:27one. That's the
15:28the [snorts] list of the doctors. And
15:30here you can see that we have an actor,
15:32we have pre-conditions, scenarios. And
15:35this one also contains an API that's
15:37irrelevant. That's was just reverse
15:39engineered. And then we have
15:40post-conditions. And the post-conditions
15:42are kind of acceptance criteria if you
15:44think about user stories that can be
15:47verified in tests to check if the use
15:49case
15:49finally
15:51was successful. And from that, because I
15:54have skills and everything, I just can
15:57call implement. So that means
16:00in those projects, we don't prompt. So
16:03we have skills for everything and we
16:04iterate on the skills. So we try to
16:06improve them constantly. We share the
16:08skills in the organization. That's kind
16:09of a problem currently, because not
16:12everybody in the organization is maybe
16:14using the same agent. So we need some
16:17skill distribution.
16:18I'm using Cloud Code here. I do things
16:21that I usually don't do. So I don't run
16:23it here inside the IDE. That's just for
16:25for demo purposes. And now it it
16:28looks at that. What I also have and
16:34what you heard in the last talk if you
16:36were here in that room, I have a Cloud
16:38MD.
16:39And this more or less has not much
16:41inside, but the very important part.
16:44Where is it?
16:46Somewhere I can't find it, but somewhere
16:48there's a reverence to some guidelines.
16:50So we have guidelines for architecture
16:53for example, how we structure the
16:55application, how the package structure
16:57looks like, what tools we are using that
16:59AI knows about that. But most of the
17:01things are in the skills. And my browser
17:04also comes with skills. So if you go
17:06there, and we don't have time to to look
17:08at that, but if you go there and look at
17:09it, you see there are two levels of
17:11skills. So we have skills
17:14primarily for specification and there is
17:16skills specific for one stack that I'm
17:18using.
17:20But I stopped adding more skills for
17:22more stacks because there are so many
17:23combinations out there that that's
17:25probably a thing that the company has to
17:28do.
17:29And now it it works on that.
17:31And
17:33maybe I go back to this one because I
17:37was already talking about that. In my
17:39opinion,
17:41uh the architecture has an impact on how
17:43well things work. So, first of all,
17:47in the past 15 years or so, we were
17:50doing microservices.
17:52And most of my customers did
17:54microservices in a very naive way.
17:57So, they have way too many microservices
18:00because they were focusing on the micro
18:02in microservices.
18:04And that's probably a problem, so they
18:06have this distributed big ball of mud.
18:08So, I'm working for an insurance company
18:10and they have around 500 microservices.
18:13And that's kind of an impact because
18:15they also have a
18:17kind of 500 micro front ends. And they
18:21are kind of related, right? So, we have
18:23an N2M relationship between
18:26uh front end and back end. And that's
18:29the worst case scenario.
18:31Because if you have if you want to work
18:33with AI on a certain part of your
18:35system, you have to have the context.
18:37So, you need the code that the AI should
18:39work on
18:40in a single place, at least on your
18:42machine or wherever you work with that
18:45with AI.
18:46And if you have 500 microservices, a lot
18:48of components somewhere, and you have to
18:50mix and match that, that becomes very
18:52difficult.
18:54Now, there's a movement away from
18:56microservices to
18:58monolithic or modular monolithic
19:00application. And I would
19:03say stop here, don't do that because
19:05that's not the right way. Because maybe
19:09you have like a huge monolith that we
19:12have currently ERP system has
19:15thousands of database tables and a lot
19:17of modules.
19:18And that's a problem, right? Because the
19:20context is too big. So, how can we work
19:23on that? And there's an architecture
19:24style that's not so well known, but it's
19:27approximately
19:29um
19:30created when microservices were created.
19:33It's called self-contained system. And
19:35the self-contained system architecture
19:36just says we create verticals. So, we
19:39split our application into verticals
19:41which has UIs, business logic, and
19:43database in one repo usually or in one
19:46project at least.
19:48Or in one application. And if you have
19:50that, if you can split that, and we do
19:52that with ERP modernization,
19:54then
19:55the AI can exactly work on that. And you
19:58can also add skills
20:00in
20:01depending on what technology you're
20:03using. So, for example, in the inventory
20:05system here we're using Vaadin as I do
20:07in my demo. That's a
20:09web framework in Java, but for the order
20:12management system, for example, we have
20:14React in the front end. So, we can have
20:16different technology in different
20:17self-contained systems.
20:19Um there's another thing that if you can
20:21stay on one stack, so for example, if
20:23you stay with the Java stack or uh stay
20:26with the JavaScript TypeScript stack or
20:28ecosystem, then probably creating harder
20:31is simpler because you need to create
20:33skills and all the stuff just for one
20:36technology. Otherwise, if you do what my
20:38customers usually doing, they have a
20:40single page framework like
20:42um React or Angular and then usually
20:44Spring Boot or Quarkus in the back end,
20:46they have to create this twice and also
20:49maintain that twice, right?
20:52And once
20:54another thing that's also quite
20:56interesting is the impact on the teams,
20:59and that's the bigger change. So, for
21:02those other company, that's relatively
21:04simple because that's not a huge team.
21:07And they already work in maintenance
21:09mode, so they don't really do Scrum
21:12anymore, right? They don't have fixed
21:13sprints. They work on depending on what
21:16features they have to implement. But
21:18because we
21:20uh
21:20use like the specs as an input as we
21:24also kind of did with the stories by the
21:26way in a in a Scrum
21:28uh
21:29development way.
21:32But we are way faster, so we cannot wait
21:34to
21:35weeks. So that's way too long. So we
21:38need maybe 2 weeks to do the
21:39specification, but we don't need 2 weeks
21:42to create the software. And we also
21:44reduce the team size. We are
21:47uh per self-contained system one to two
21:48developers.
21:50Preferable two because of uh knowledge
21:52exchange and maybe it's uh boring to
21:55work on a project [clears throat] alone.
21:58But we reduced that from like five to
22:00seven to one to or two.
22:02And as I said, we do no more sprints. We
22:04do continuous flow, and we use the use
22:06cases kind of uh in a Kanban way to
22:09track the progress. That's all we do,
22:11right?
22:13Then something that or we can go back.
22:16Man, that's probably done. And what it
22:18created is just uh the implementation of
22:22that.
22:27And now we have the list of doctors
22:29here. So that's what's created. Oh.
22:33You're right.
22:35I really don't like PowerPoint because
22:37this changes everything. So that's
22:40what's done. It took 1 and 1/2 uh minute
22:43or so. And now we see the doctors,
22:45right? So that's a simple use case, but
22:47that's something that we have a lot in
22:50the ERP system, something like that,
22:52right?
22:53And why did this work?
22:55Uh first of all, because of this
23:01guardrails that I was talking about. So,
23:03first of all, my recommendation, never
23:06let AI create a project. First of all,
23:09you just waste tokens if you do that.
23:12But, if you do that, you probably end up
23:14with an outdated application. So, if you
23:17have like Spring, for example, in the
23:19trial field there's start.spring.io, you
23:21can create an application, you get the
23:23newest dependencies, you get them the
23:25way how the Spring team currently thinks
23:27about creating applications. Maybe you
23:29have a CLI for your tools, use that.
23:32Don't use AI for that.
23:34And then you have to define the rules.
23:35So, that means you don't put everything
23:38in Claude MD or in the agents MD because
23:41there's a study from the ETH University
23:43in Zurich, and they say the bigger the
23:47system prompt, the
23:49more hallucinations you get probably.
23:51So, it's maybe even better to have none
23:54of those files than a big one.
23:57And then you can add architecture. So,
23:59we usually do
24:01kind of architecture, um or arc42,
24:05that's a kind of a format how you can do
24:07architecture documentation. Then we add
24:09skills, that's the important thing. A
24:11lot of people were talking about that.
24:13And we also have MCP service because um
24:16skills shouldn't be that big, and we
24:19have huge documentation, for example,
24:20for in-house frameworks where we get MCP
24:23service in vector search that AI can
24:25directly search in the documentation.
24:29That's um how we do that. And if you do
24:31a good job and iterate on that, you
24:33really get probably um
24:37a near deterministic solution. So, what
24:41I did before, I can delete everything,
24:43do it again, I will get more or less the
24:45same outcome. Right.
24:48But, very important, the human should
24:50review
24:51depending, as I said, on the risk, what
24:53happens when your system doesn't work or
24:55have bugs, then you should uh probably
24:58go and add more reviews or depending on
25:02if you do reviews by hand or you use AI
25:05to review or however you work on that.
25:08So, we don't do pull requests, by the
25:10way, at the moment. We do trunk-based
25:12development and we do kind of an ongoing
25:16review process. So, we work on something
25:19and then we do peer reviews. So, we work
25:22if we are two developers, they work
25:24together and do the review together. So,
25:27they try to explain parts of the system
25:29that
25:30they created with the other. So, we
25:32don't do pull requests anymore in that
25:34those projects.
25:36So, to conclude,
25:37um specs reduce nondeterminism, but not
25:40specs are not enough. So, you need to
25:42harness, you need all the context around
25:45that that this really works.
25:47And something that I didn't talk about
25:49is, in my opinion, specs are very
25:52sustainable or hopefully they will be
25:55sustainable in the future because
25:57currently what I'm doing is reverse
25:58engineering of existing code into specs.
26:02And if we have specs, we can probably
26:04generate the same application in
26:06different technology with a different
26:08UI. Maybe we don't have even a UI, we
26:10have chat or something directly from the
26:12specs.
26:13And
26:15the business people can directly change
26:18the way the system should behave without
26:20developers. So, they don't need
26:21developers um talking about that or
26:24looking into that.
26:26And this accelerates development. The
26:28problem is it it at the moment it just
26:32accelerates development.
26:34Right? So, the requirements phase and
26:36the spec phase takes some time. For
26:39example, I'm working for Swiss
26:40government, for the parliament, they are
26:43uh
26:44have a business case management software
26:45that we want to modernize. And I'm the
26:48only one during the proof of concept
26:50doing something with code.
26:52but we have two product owner
26:54requirements engineers that work on the
26:56spec and they have much more
26:58work to do than I have. I just automate
27:00everything, so currently I'm working on
27:03on the pipeline that they can just
27:05change the markdown files and everything
27:07will automatically generated.
27:09Um so the kind of the work moves or
27:12shifts left. So everything shifts left
27:15to requirements engineering in my
27:16opinion because now that's obvious.
27:18Before like if it is scrum you had 2
27:22weeks to work on the requirements
27:24somehow and then developers were 2 weeks
27:27working on the implementation. Now you
27:29have 2 weeks and then 5 minutes and 2
27:31weeks. Something like that, right?
27:34And the most important thing is you
27:36should know your architecture and domain
27:38and this will lead us to the discussion
27:40about the junior developers, but I think
27:42we stop here
27:44at this. And that's it from my side.
27:46Thank you very much.
27:50>> [applause]
27:54>> Thank you so much, Simon. Um we have a
27:57few minutes for questions if anyone
27:59would like to ask something, okay? We'll
28:01start here.
28:03>> Um thank you for nice hands-on
28:05presentation. I have a question about
28:07use cases. Uh
28:09did I understand correctly that you
28:11initially generate diagram in PlantUML
28:13and then from that diagram you generate
28:16detailed text requirements in markdown?
28:18>> So usually you you would
28:21So on a greenfield project you would
28:23have like a requirements catalog or
28:25something or a product requirements
28:27document and from that I would first
28:29generate the use case diagram that you
28:31have no view what we have.
28:33And maybe this would even give you an
28:35idea how to split your application into
28:37models.
28:38And then from that you can go ahead and
28:40generate that because since use cases
28:42are kind of in the user story included,
28:45right? It's just more detailed with all
28:47the steps. And um
28:50yeah, our requirements engineers and
28:52product owners use AI a lot just to
28:55verify the use cases, to find maybe
28:58duplicates or things that are missing,
29:01and they work a lot on on that with AI.
29:04Yeah, but we go use case by use case
29:06because a lot of people say spectrum
29:08development is waterfall, and that's
29:10simply not true.
29:11It just is It's just requirements and
29:14then test and implementation, but that's
29:17also the case with Agile, right? You
29:18have to do that but but we don't do big
29:20up front design, we just go use case by
29:23use case.
29:28>> Maybe it's a follow-up question,
29:31but like say your user story is wrong
29:34and you need to update it,
29:36what's the flow? Do you
29:39regenerate the whole application?
29:41Do you
29:42append
29:43a new requirement document? I I don't
29:46understand.
29:47>> So, if I have a use case, for example,
29:49let's go here and I have What did I do
29:51before? I think
29:54I did that one, right? And now I see,
29:56okay, there's
29:58What do we have something here?
30:00So, it says that that displays the
30:03doctor with first name, last name, and
30:04the comma-separated list of specialties,
30:07for example.
30:09And now I could go ahead and say, "No,
30:10that's not comma-separated, that's maybe
30:13um
30:15the at sign that I need to separate."
30:17And what I would do now, I would go
30:19ahead and say again the same that I did
30:22before, implement.
30:23Because at the moment, we need to code
30:26or we read the code, right? And I don't
30:29want I could throw it away, for sure.
30:31But then my Git history wouldn't look
30:33nice and it would be harder to review
30:34the changes, right? That would be an
30:36issue.
30:37In my opinion, or not in my opinion, in
30:40opinions of some people is AI doesn't
30:43need the source code. So, I'm a Java
30:44developer, that's bytecode that's
30:46executed. AI could generate the
30:48bytecode, there's no reason to generate
30:51the source code, maybe. Or maybe we end
30:54up with a programming language that's
30:56more AI-friendly and less
30:57human-readable. I don't know.
31:00But at the moment, we just work as you
31:02would if you would do that
31:04manually. So, we really change the use
31:06cases or the entity model, and then we
31:08say just apply the changes. Yeah.
31:13>> I'm so sorry. There's so many more
31:15questions, but we are out of time. You
31:17guys can hunt down Simon and ask him
31:21yourselves.
31:22Um our next session is going to be in 10
31:25minutes, but big round of applause for
31:26Simon.
31:29>> [music]
31:34[music]

About this transcript

This page contains the full transcript of Simon Martinelli - Lessons from Spec-driven Development - AI Native DevCon June 2026 by AI Native Dev, generated from the public captions YouTube serves with the video. The transcript has 5,113 words across 829 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.