Spec-Driven Development with AI: From Use Case to Running Java Code - Simon Martinelli

This talk focuses on the concept of spec-driven development and its implications for software engineering, particularly in the context of AI-driven development. The speaker discusses his personal journey in creating event management software for a sports club and addresses challenges faced when using generative AI tools like Agent KAI. He emphasizes the importance of a spec-centric approach where specifications serve as a contract for both tests and code, advocating for incremental and iterative methodologies. Additionally, the talk introduces the idea of context-aware development and agent experience as vital components for utilizing AI effectively. The speaker contrasts this modern approach with historical methodologies like model-driven development, highlighting the need for clear specifications and alignment between requirements and generated code.

[music] >> My talk is about back-driven development. And this talk is because of I'm in a sports club in Switzerland, so I did track and field when I was a bit younger. But I'm still a big fan of track and field because especially because we have very fast women in Switzerland like the Dutch Akamponchi. She won the 100 meter hurdles. And in the sports club I do

software since 1997 already. And we have uh competitions for kids and there I do software to create ranking list finally. And I also do other software for club. I'm also in other clubs where I do software. And in the sports club we not only do sports events but also do some social events. So we have a beach party in the summer. And there we use an app

to manage volunteers because we need volunteers to for for example in the kitchen or um in other places. And there we were using an application that was a bit old and they asked me in summer 2024, "Hey Simon, you did so much software for us already and now we have AI, you can do that just in 5 minutes." And I said, "Okay, that's a brilliant idea and

that's the perfect pet project to try Agent KAI." And I started in fall 2024 using Windsurf because that was one of uh earliest tools that you can use to do that. And I started. So I was just prompting. I said, "AI, please create an event management software." And it did and it worked. But suddenly around Christmas, I noticed, "Hmm, what exactly did I do? Where I am?

What features are missing?" And I had no clue what I did. And also the code probably was not uh like I liked it usually. So, I was looking for something else or another approach to do that in a better manageable way. Um and then I found a website. It's called ainativedev.io. Uh it's not an official thing like you may think about. So, we have cloud native foundation

and stuff like that. These are official foundations. AI native dev is just a company Testal. They're creating tools around spec-driven development and skill management and stuff like that. They also do conferences on AI-driven development. But what what was very interesting to me was that they were talking about AI native development and said, "Okay, look, we have three pillars if you want to do software with AI. First

of all, we need a spec-driven approach or a spec-centric approach to make sure that AI can cover the intent that we have what we want to do with the software. On the other hand, we need something called context-aware development. So, the agent must understand the full code base. I will cover that in the end because AI-driven software development also has an impact on architecture and on tool

choices, maybe. And finally, we need something called agent experience like we need user experience, developer experience. We now also have agent experience. So, we need tools that uh work with you as a software engineer or also autonomous, for example, on GitHub or somewhere else, right? And that was the idea of that. And I thought, "Oh, spec-centric development, that sounds something that I could use for my project.

And effective development says that we should start with a specification, not with a code. By the way, that sounds like waterfall, right? So, we do a lot of specification and then we do the code. A lot of people are agreeing because especially the older ones because they probably seen that time. Uh but that's not the case. So, the point is that specification should be done before code,

but in a more incrementally iterative way. So, or in an agile way. That's something that's very important. And specification should cover the intent. And it serves as a contract for tests and code and everything, right? And it should be the single source of truth, so we don't look at the code anymore. So, that's not true. We don't We look at the code, but the code is not

the most important piece of our application. that's something that a lot of people don't like because they tell me, "Hey Simon, you're wrong. The source of truth is always the code because that's what executed." And I always tell them, "Yes, for sure, but that doesn't define the intent because I do a lot of software modernization and if I do reverse engineering of the code, for example, if

I create uh activity or sequence diagrams from a method, then what I see couldn't be the intent, right? I call that balcony architecture. And by that I mean you are a member of a team and the team is not the team that initially created the application. So, you don't know the application very well and you get a certain feature that you have to implement. And probably this

feature is a bit complicated and you should have recreate the whole method. But you're afraid of doing that, right? And what do you do? You add an if here, a switch there, another if here, and that's what I call balconies in the code. And so, probably this is a problem, especially in modernization, we do reverse engineering of code, then we somehow reverse engineer the reverse engineered code

to really have that what initially probably uh was the idea. Now, when people hear uh spectrum development, they say, "Okay, that's cool. We just create specification and we generate code, like we did that before, right?" Who remembers model-driven development? The idea of model-driven development was like around 25 years ago or so, and there we had UML modeling. So, we did a lot of lot of UML diagrams,

and then we tried to create code directly from that. There were tools like Open Architecture Ware, for example, that that model-driven approach. But the problem with the model-driven approach was that it's what it was not flexible enough. So, it covers about 80% the problem that you had, and the rest or the remaining uh percentage you had to do somehow by hand, and this broke the whole idea

of model-driven uh code. But but a lot of people assume when they use agents uh for the first time, they think, "Oh, that's like a compiler. I write specification, then I generate code, and I can delete the code and regenerate the code." That does work. So, it regenerates the code on every attempt, but it doesn't create the same code. Now, the thing that we should uh think

about this, and I think uh this was also mentioned in the keynote this morning, this uh non-deterministic behavior of the question is, what exactly is non-deterministic, or where is it non-deterministic? If you have tests and say, "Okay, every generated code will fulfill the tests." Is it then deterministic or not? It has the same behavior, right? So, from a behavior point of view, this is deterministic, right? But,

the code that is generated is not the same. Sometimes it has this flavor, sometimes it has that flavor. If you change the model or if you change the tool or even to change the LLM, for example, then you will not have the same results. That's And that's something we have to work around. And especially the last sentence here on this slide is the most important. You're responsible

for the code. So, even if AI generates something, you as a human can be the only one that is responsible. And AI cannot be responsible, right? That's very Now, if you look at spectrum development in practice, uh there are a lot of tools. So, we have Amazon Kiro, for example, GitHub SpecKit, Be Mat, uh Open Spec, and so on. So, a lot of people are creating tools.

The problem with the tools is they do not really fit the work I do. So, who of you is working on a greenfield project? Not a lot. The others are doing maintenance or brownfield projects or modernization work, something like that, right? Then you can't really use these tools because they have a process that reminds me always to someone like me as a solo programmer in a pet

project. So, someone who does everything. But, in reality, you have business analysts, you have requirements engineers, you have software architects, engineers, testers. You have a lot of people around that. And you cannot do their work, right? Especially the most time-consuming work that you have to do is speaking with the customer. So, they find out what they really want and not the programming, maybe, right? And that's why

I created the process around that because I found it interesting what could be the specification. We have or let's go to the website and I can show you that. Who remembers Rational Unified Process? Are there people? Not so many. Most of them are retired, probably, in the meantime. Usually, I ask if they have good memories and no one will raise his hand because Rational Unified Process was

a a huge process and it was a process framework and not a process per se. That means you have to customize that and use just the artifacts and the role that you really need in your project and not the whole thing. Uh but what I really liked with the Rational Unified Process, it was incremental and iterative. So, before we talked about Agile even and it was spec-centric.

And that's what something that I realized when I uh did my project. So, just to give you a short introduction, usually, you if you are on a green field project, you have something like a vision. Someone has to an idea for software. And then uh people are starting to gather requirements. They create a requirements catalog, usually user stories or something. They use maybe the main driven design

practices like event storming or domain story telling. And then, on the other end, you have someone that defines some testing strategy and acceptance testing something derived from the requirements, right? So, that's no different from any other approach. But what's different is what's happened then. So, the green phase here is where we can already use here you can also use AI by the way. So in Europe we

have the international requirements engineering board. I don't know if you know that in India as well. And they have certification. Uh certification for requirements engineering, requirements management, requirements for whatever. And they created something called AI for requirements engineering. That's a certification where they provide guides how you could use prompts and AI for requirements engineering, right? So I don't cover that one. That would be a uh its

own presentation. But if I have the requirements uh catalog, what I usually would do as a human, I would use that and maybe uh extract domain models. I would extract uh use cases or something else from it. And that's exactly what I wanted to as well. So I can extract from the requirements catalog uh system use cases and entity models. So that means I need somehow or

entity model, domain model doesn't have to be only entities. But what I need is I need something like a database. So to uh it's important to note this. Usually I do business software. So I do ERP systems, CRMs, uh business case management software, or volunteer management software. And this software is always the same, right? You have a lot of UI, you have a database tables, you have

business logic. So these are more or less always the same kind of applications. And uh so we need the entity model to get an idea about uh the database model, especially also the relationship between the entities, the validation um rules for the entities. And for that and with that we can then generate, for example, database migrations. uh because I was thinking of this Rational Unified Process, I

remembered that they were using SysML use cases. Who of you know SysML use cases? Not so many, right? I would say no one. Okay, then it will be an introduction to SysML use cases today. Uh the point is SysML use cases have a clear structure. They were invented by Ivar Jacobson back in 1992. That's a very long time ago. I was 20 by the way back then

and didn't do software And these SysML use cases were then flowing into this UML driven development that we had in the '90s and we will see a use case after that. But we also have a software architecture, but I don't talk about that today. But with the entity model and the SysML use cases here, we have enough information to generate um code and tests. Now, what do

we want to generate first, code or tests? It doesn't matter, but it depends on what you're doing. So, if you have a SysML use case for a REST API, for example, you may want to do test-driven development, right? Or if you do a library or service or something like that, you usually do test-driven development, so you can generate the test first, verify that, and then generate the

code. If you're doing UI development as I do usually, so I do full-stack development by the way, mostly, then you can't do test-driven development very well because the UI changes and it's too hard to anticipate how the UI would look like to do a really test-driven approach, right? So, but it it doesn't really matter. So, finally, we will get tests. And what's very important, as you can

see here in the diagram as well, we always have the human in the loop, so someone has to view that or check that, review that, maybe fix it, or at least change the use cases, for example, if something is not correct or the empty model, and then maybe regenerate. Usually, we don't regenerate because that's too slow and too expensive because models are getting more and more expensive,

as you may heard, especially from Anthropic. And so, we do kind of just applying the changes, like you would do as a human. You don't throw away your code and rewrite it, right? So, you do um this changes as well. So, that's the process, more or less. let's get to uh the use cases. So, that's a use case diagram from UML. And uh these bubbles there are

a single use case. How they are related to user uh use case usually covers multiple user stories. S- And for example, here we have uh register a new owner. So, we will do a reverse engineering from the spread Spring Pet Clinic project. Let me show you that in a minute. And there we can And uh this would be usually multiple user stories, probably with acceptance criteria. A

use case is different. It has a structure, and we will see that in a minute. And the good thing about use cases it covers the whole uh behavior. It's clear for AI. Uh a friend of mine from Germany talks about uh semantic anchors with AI. So, what's a semantic anchor? That's something AI knows. So, if you ask AI, create me a system use case, AI knows the

system use case specification from Ivar Jacobson. So, you don't have to tell more. Or if you tell AI, create tests in a behavior-driven design manner then AI knows that. And that's so-called uh semantic anchors uh where you don't have to specify more. Just give it the right name or the right abbreviation, and it knows exactly what to mean. the best thing about the use cases, in my

opinion, is not what this mentioned here. The best thing that we have is that it's human readable. So, what I did here, because as I said, I do mostly brownfield project, I used this project. Does anybody know that, maybe? We are Spring developers here. Then you should know that. Note the the history of this project is when we had J2EE, that was invented in 1999, then they

created a sample project or a sample application that was called Pet Shop or Pet Store. Um and when Spring was created in 2003, they thought, "Okay, we also do something with pets, but we don't copy that one from J2EE, we create a new one, and that's called Spring Pet Clinic." So, what we can do here, we have a home screen, we can look what vets we have

here in the system, and we can search for owners, and the owners have pets, and here we also can see that some owners have multiple pets, and then we also see the visits, and you can edit the pet and that visit and something like that. So, it's a crowd application, right? It's a very good starting point because the guys at Spring or in the Spring ecosystem created

multiple versions of that with different UIs, so there's probably a React version and Angular version, um a Spring Thymeleaf version, a Vaadin version, uh you name it, right? And this is a classical legacy And what I do here, if I have a legacy application, I could reverse engineer the use cases. So, get back to the slide for a minute. That is a greenfield workflow of my process

or of any spec-driven uh workflow. So, usually you have someone who creates that or generates that, whatever. In my case, it's entity model and the use cases. And responsible for that is usually someone from the business, so a requirements engineer, product owner, or business analyst. Whatever the name is of this person. And then we have a software engineer that does a first review. He also uses AI

to do reviews of the use cases because AI is much more powerful in requirements management than humans because it can find duplicate, it can find some misconceptions, you can find gaps in the use case, for example, with the help of AI. And depending on in which industry you are, AI may know about the use cases. So, for example, I'm working for Swiss government in a project and

for the parliament. And how a parliament works in Switzerland is open source, so to say, because that's written in the laws, in some um documents how they should do their business cases. And so, AI knows already about that. So, if I now generate a use case for that, AI probably knows better than I how this should work. I also work for retail and wholesale and insurance companies,

and there is more or less the same, especially in wholesale and retail. Uh you have large retailers here like uh 7-Eleven, for example, or um others that I've seen in the exhibition hall. And so, AI knows about their business processes, how that works, right? And then, once we are ready with these two, then we can start generate code and test. But as I see it, you I

said, usually I do brownfield projects, and there we have kind of a reverse approach. So, what we are doing, we taking the existing system and reverse engineer with the help of AI AI entity model and Now, there is a bit of a problem in that approach because usually all the applications are monolithic applications and they could be fairly big. So, you must find a way how to

deal with big applications. So, for example, you could start with AI and try to find modules in the application and then reverse engineer module by module because every system has modules. Either you see it directly or you don't see it because it's hidden behind spaghetti code, but there are modules. Sometimes they are simply not visible. And then you can start over doing module by module, for example.

Now, uh what I did in this project was more or less uh something like that. So, I used Cloud Code, but it really doesn't matter is not the right word. It's not so important which of the AI agency you use. They are all similar, so you can use uh Codex or Gemini CLI or Cloud Code or GitHub Copilot or what else, but they behave a bit different.

So, that means if you know one very well, you shouldn't switch because then you will lose the things that you learned how to work with that tool when you go to some other tool. But, the most important thing is maybe you don't need exactly how to know how this tool work, but I will show you that in a minute. So, what we could do here is, for

example, say, "Okay, I could uh do a reverse engineering and if we work with AI, uh we always do as talk. So, here I do diagrams talk and say, "Okay, create use case diagram with PlantUML, for example." Um all the text files that we have, like the system use case, entity model, everything like this, is usually markdown, because it's very simple to deal with that. So, AI

can read Word documents or PowerPoint or Excel. This That doesn't really matter. It can also parse PDFs or capture screenshots, Um but markdown has another important um advantage, you can put it in version on version control. And you can see the difference that you had when working like that. So, what we uh do in my current project, for example, so the use cases are created by the

business people. Or No, that's not true. We do reverse engineering of the use cases, and then I send the use cases to the business people, they do a review, and send it back. So, they use Word because they use that collaborative workflow in Word. And I have a doc chain or a doc tool chain. That means I do markdown, create Word document, they send me Word document

back, and I uh extract the text in markdown from uh the Word document. So, that's already done. I hope you can see it. Here we have now a use case diagram. And you see, I didn't say much, so I have no big prompt, because according to that what I already said, it's clear for uh AI, because AI know, okay, that's PlantUML, that has that syntax, um and

uh use case diagram is And here, finally, it found out, okay, we have a welcome page with with the pets. Then we can register new owners, update owners, add pets, find owners, we can view veterinarians. We can do other things, right? And that's what was extracted from code. For Lux. Usually, you have more input, so a lot of my customers are using Jira, so the Atlassian tools.

So, we use the Atlassian MCP connector to get data from there and to mix that together with what we found out in the code. Um now, for you maybe so you will get the slides anyway after that, but that's the project that I'm using here. It's a a up pet clinic, so that's my my clone And I'll give you a minute to do a picture. Okay. So,

let's have a look at this project because there I already prepared things. let's close that. did there I reverse engineered um the whole project and uh this created use case model. Um as you can see this looks a bit different from that what we've seen before. So, that's this nondeterminism. So, that really sometimes it creates this nice boxes around, sometimes not. So, you can try it multiple

times, whatever, but by the end you will go ahead and just edit that because you may want to change the numbering, the text, Right. And the interesting thing or the good thing about these use cases is first of all it gives you the use cases and on the other hand you also have uh the roles in your system directly. So, these are called actors in use cases,

but they usually translate directly to roles in the security system, for And now, uh here in my project I already implemented so the view welcome page. So, I think I can start the application. and let's have a look at that one. And here that's the pet clinic, right? So, that's what it did. Wait a bit. All right, like this. But here there's nothing. Wait, there's nothing as

well. well. >> If you create software with AI, you should do the scaffolding by your own. So, I will never go ahead. So, I'm using Vaadin. Does anybody know Vaadin? It's a Java framework. It's already very old, but it was renewed a few years ago. So, I can do full stack Java development also for UI. I use Postgres, Flyway, Test Containers, Spring Boot. Um and I don't

want that AI does that. So, the architecture work is done by myself. That's very important. Because if you go ahead and say, "Okay, create the Spring Boot project." And you don't specify the version, then the first step that you have to do is you have to modernize your Spring Boot application. Because it will certainly create an old version. And it's simply to go to start.spring.io, for example,

and start the project there. Or maybe you have guidelines from your company how you must create projects, maybe a project template, something like that. And so, you always should start by your by your own. What I also created is guidelines. So, created is a bit uh not the right word. The They are were also kind of generated. But, here, for example, here we have information um how

it should look like. So, you don't need to to read it to really. But, uh it has some information that uh we have package by feature. In the package, we have UI and the domain package. The UI is for the UI. Domain is for everything else. We have a core package where we have common things. Then, we have some information how things should work. We have information

how data is loaded. I'm using jooq, j o o q. That's a Java DSL to write SQL statements like query DSL that you may know. And then, we have some information about uh view conventions and Flyway scripts and stuff like that. Right? So, But is derived from um the code that I created. And then I have the same for testing because what in is running on the

server and that's why I can do something called browserless testing. So, if you may know Spring Boot, there is the Mock MVC where you can test um controllers without even running a web container and you can do that as well. So, these are really integration tests. They're only very fast. So, an integration test runs around 10 to 20 milliseconds. Whereas I would also create, for example, Playwright

test or Selenium or Cypress test, but they run way slower. So, um a regular Playwright test or an end-to-end test runs around 3 seconds, for example. So, we can't do use that for develop. And then we have some naming, for example, the test classes have the same name as the use case and so on, right? And these are so-called guidelines or guardrails. A lot of people putting

them into the Claude or Agent MD file. So, the Claude or Agent MD file that we have here is the so-called uh system prompt. And this will be used with every prompt that you do. And uh there is a study from uh university in Switzerland. They say the smaller this system prompt file is, the better. So, it's even better to have none instead of a big one.

Because this leads to a hallucination, probably. So, that's something that they state in their study. But you know, AI studies are very difficult at the moment, so you should repeat that every few months because they become outdated after they were published, probably. But anyway, so what they have here is uh general purpose and the stack and uh especially how we can test and run these things for

AI because uh compared to a to a junior developer, you always have to tell AI what to do. The junior developer some when uh understands uh what he should do, but AI forgets with every prompt. So, that's important that you provide this context at every point. And then we also have some little things there. I could strip that down um and then tell it would be simple.

But now let's go to a use case and I take use case where we can see the This is that one. And this is a typical use case. So, use case usually have an ID. IDs are important. Also, if you have uh requirements or if you have business rules, you should always use an ID like with the naming schema that I use here because then you don't

have to talk a lot to a AI. You just can say use that. Or you can use AI also to have kind of a matrix, so to see how things are related. AI can then generate that and uh and use that, for example. And here we have uh use case usually starts with a precondition. So, what has to be fulfilled that use case can be run. And

then we have uh a main success scenario. That's the happy path. And then we have some alternative flows. For example, this application here also has a REST API with JSON. And then we have uh post conditions, for failure conditions, and then we have some business rules. So, that's a very short use case. I can show you uh a bit of uh slightly bigger ones. So, this is

my project and here I have so many use cases. I have to split them somehow. That means we have here a use case diagram or a use case over view diagram that doesn't show use but kind of epics in the system, so to say, or modules, whatever. It's hard to say. And here we touch the volunteer management system, and here we can, for example, manage events. And

here you can see also that I use this diagram also as kind of a tracking tracking system to see if the things are implemented or not. And if you look at the create event use case, you can see that this can be way longer, And I can also show you another one that's even bigger, but you can read it. Uh that's in German. But uh what we

do here, for example, so that one is way longer, as you can see. And now this is a bit difficult to understand for humans, right? AI has no problem with that, but humans may have problems. So, what we do, we create activity diagrams directly from the use cases, because a use case, more or less, is an activity diagram. So, you can visualize that. And that means uh

we can um or the business people can review the diagram first and review if the workflow is correct. And here also see some links to business rules, for example, and so on, right? So. What I also do with use cases, I do um mirror um an implementation tracking, so that I know where I am. Um AI is helping me with that as well, so I can see

that more a bit more than a third is implemented from all use cases. We have 82 use cases in that system. And so I have the tracking. And if you're talking about tracking, uh we should also talk about uh team sizes and team workflows, uh using tools like Jira, for example, it make sense anymore, because everything you need you have in your So, that means we have

use cases and in my project also the product owners are using Git, by the way. So, they also work on the use cases directly in IntelliJ, for example, or some use Bitbucket with the online editor to work and change that. And so, the some you some companies still have Jira, but that's more like compound board to keep track where we are. But, we don't use Jira and

Confluence anymore to capture user stories and documentation and stuff like that. That all moves to the Git and to Markdown. And on the other hand, the team sizes are very small because the work here is not typing. The work here is capturing requirements, reviewing and writing use cases, reviewing and writing entity models, for example, the entity model uh looks like that. I placed in my project here.

It's a bit big, so we take the one from the pet clinic. That's way smaller. So, here we have the model, so without attributes because that just blows up the the diagram. We just need the dependencies and then we have like attributes and description and stuff like that. And this could be way more extensive than you already have the glossary of your application, for that means we

our companies are working And to give you some numbers about the team size, with we're doing an ERP system modernization where the team used to be around 25 people for the old system. Now, we are a team of two. So, the other are still working, right? And we're doing modernization, so we can work massively in parallel. That's the good thing about that. In the current project, I'm

a solo developer. I do everything by my own and I just work 20% for them just one day per week. And they have two product owner requirements engineers. They work full-time. Because working on the specification on the use case is way more time-consuming. Now you can say, "Yeah, but does that make sense?" Uh the point is yes, because you did that work as well today. You didn't

see it, right? Because someone was sending you requirements in form of user stories. And then what happened? You start to implement maybe directly and figured out, "Oh, there's missing something. How can I do that?" And then you add these iterations to figure out exactly what the user needs. So we just take that in front of that. But it's still not waterfall because we work really use case

by use case. So the point also what's very important tell you that you can work in parallel That's not so true. That sometimes work for your pet project, but not for a real application. And the reason is use cases or also user stories depend on each other. So you can't start with the use case if that one is not finished, for example. So that limits the work

in parallel a lot. And that's something that we we um that we don't go as fast as we thought. Because a lot of people say you are 10 times faster. That's I would say I'm 100 times faster. Because I can tell generate the code for the use case. This takes 3 minutes, If I had to write that by hand, I don't know, maybe an hour, something like

that's not the work. The work is figuring out what this pet clinic is doing and describing the use cases and checking if the use cases are correct. And then iterate, generate code, check if it it works, then go back to the use case, uh maybe change the validation rules because they were incorrect and stuff like that. And the most important work is figuring out why the code

is not reflecting exactly what's written in the use case. It's that's usually because the use case are not precise enough. So, now we have use cases, and what we can do now, we can generate code. the important thing here is that let me check if I didn't commit something. We want to prompt as few as possible. So, I don't want to prompt, right? So, if I want

to implement that, I can just uh which use case is it? 02 implement use case 002. That's all. >> Daniel >> The most important thing with agentic AI nowadays probably skills. Did you heard about skills already? And skills more or less cover all the knowledge that is needed for uh doing the work. So, I also created some tools or tools and skills, not tools. Uh they live

in GitHub. They are marketplace because um in contrast to other um agents, Cloud Code solved the distribution of skills and the MCP definition and stuff like that. They call that marketplace. And there you can have skills and stuff like that. And they have something called the AI the up core, and there I have some MCP definitions like contact seven. Contact seven is a general purpose MCP server.

MCP server for those who don't know, MCP stands for model context protocol, and it's an API for the agent. So, it defines tools what the AI can use from that. A lot of people say MCP servers are not good because they fill the context, and that's true because if the agent um calls all MCP service, give me the tool definitions, then you have wasted context. But Cloud

Code, for example, is able to do that lazy. So, it doesn't fill up the context anymore like that. And here we have skills, for example, I have skill for requirements engineer and they can generate the use cases with This on top here is the name. So, with Cloud Code, you can directly execute skills. So, before they were distinguished between uh commands and So, the slash means that's

a slash command and with a slash I can directly execute the skill. That's why I could write implement use case 002. And then we have a description and the descriptions define when the use cases can add use cases when the skill should be used. So, AI agents will figure out by themselves skill should be used for a particular And there are companies like Tesla that I also

mentioned, but others that provide skill evaluation tools. So, you can write your skill or generate your skill and then you can use these tools to check if the skills would be used by AI and that's very helpful. So, they have a score how good the skills are and then you can can use that. And here, for example, the idea is to extract the use cases from um

but we have now to uh specify specify use cases and the skill itself has an And the skill also can have templates. So, that's why my use cases all look the same. So, that's something that I can put there. And for the implementation, so I as I said, I'm using WatIn and Token stuff. There is a specific skill for that. Here we have MCP service for WatIn,

for Caribou testing, for Token. These are two I did by my own. Then we have for Java talk, there's an MCP server that's created by James Ward. He has a talk tomorrow about MCP or on Friday, I think. And then I have Playwright. Playwright is an end-to-end testing tool, but this can also be used to remote control the browser to do screenshots, to inspect the web page,

to inspect the DOM, to capture the HTML code, capture CSS, and things like that. And that's very helpful if you work with web And the scale here that I uh just is just about uh use this use case. So, we can also pass arguments, as you can see here. And then it uh says what it should do and what it should use and also what it shouldn't

do, for example. And now this is done and we can restart the application and see. So, it usually takes around 3 minutes to implement the use case. The size doesn't matter really much. It's kind of a uh thing. And here we have the veteran is. And as you can see, it's very non-deterministic because I tried it when I was preparing for the talk, I had no data.

And this time it creates some data. Yep. That's uh more or less how it works. And then I can go ahead and say, "Okay, I have them. Now, please also I don't use the scale here because uh the browser less testing has changed in Vaadin, but because it's a Vaadin application, uh Cloud knows it enough to create the read the correct tests. >> You got it. >>

And we let that run and we can see what it does. >> Doing it. >> No. What I said what's very important are these guidelines and guardrails. So, that means the more narrow your guardrails are, the less non-determinism you have, or the less hallucinis- hallucination you will have. Because it can just use what is there. For example, usually I put in the in the system prompt that

it AI is not allowed to change the Maven poem, or the Gradle file, or the the NPM file, because I don't want that AI is taking care of the dependencies, and of the dependency versions. It can propose dependencies, but I verify that by my own. So, I don't want to do that. I also don't want that AI is creating security code. That's something that I do by

my own. We have in the ERP system very complex price calculation, because in the wholesale domain you have prices per customer, or discounts, whatever. That's the most complicated part of the And we keep that as it is, and we kind of reverse engineer it, but we do that by hand, because that's the most important part. CRUD applications like that you can just create, because it really doesn't

matter how this looks like. It's more important to check if the database access is okay, so that you don't have an N+1 select problem, or something like that. Additionally to these guardrails, you can define guidelines, as I have shown you. Just add markdown files, but don't put that information directly in the code or agents files. I keep that separate. Then use skills, or create your own skills.

So, there are many skills around. Be very careful if you use these skills from people other than me. But, let me Now, the point is, you may have heard about prompt injection, or any other security risk that you have when you're doing agentic AI. And if you have you skills from somewhere, and there are skills there are huge. So, for example, if you're using Oracle database, Chris

Rice from the Oracle team created skills and there are a few hundred of these skills. And first of all, if you just install that, maybe you just have too much. But on the other hand, if you don't read the skills, you don't know what the skills do. Because maybe there in the skill could uh delete the database or whatever. And then you may lose data or you

have other problems, right? Then uh I MCP servers are great still. So, I would highly recommend to go to the talk of James Ward. Because some people say MCP servers are not good to everything with skills. Now, that doesn't work, right? Because um I created, for example, for the took library an MCP server. And that's what this does is parts that could be done in skills. So,

I provide uh code examples, But I also have the whole documentation of took in my MCP server. And I created embeddings and store that in a vector store, so you can have vector search um the documentation. And you can't do that with skills, right? So, MCP servers has uh always their place, but use it um probably what works best for you. Then let's see if this is

done. Uh this is still working. Perfect. Then as I said in the beginning, AI driven development may have impact on the architecture. First of all, a lot of people are going back from microservices to monolithic I was a fan of did that idea until I realized now that's a bad idea Because the context will be too big. Like the ERP system has around 2,000 database tables, for

example, and a lot of code. And you won't want to have that. So, you should go ahead and do self-contained systems that I was already talking about yesterday and split your application in manageable parts. Not only for you, but also for AI. And you have the same problem, Because if you want to know everything about monolithic application, there's too much load for you to capture. So, too

much context and they have the same problem. So, if you split I would really highly recommend self-contained system because the UI is part of the use case. If I would do the pet clinic with an Angular or React AI UI and with microservices, for example, then I would need uh probably kind of a mono repo that AI has access to everything because AI will not You don't

have a front-end and a back-end developer. You have one He can do everything at once. So, it doesn't make sense to to do the split anymore. So, full-stack frameworks probably help. Doesn't matter in which ecosystem you are, JavaScript, Python, Java. It's completely um not relevant because it works everywhere. So, let's see if that's done. Yeah, we have some tests And now the important thing is the code

review is not that important. But I can we can have a look at at this view. So, that's uh what in code that's very simple because it's plain Java. It looks like all good old Swing application or something like So, I know that framework very well and I can immediately see if it's correct or If I would use Django, for example, from the Python ecosystem, I have

no chance to do that. So, it takes me much longer. So, if you want to do reviews very quick, then you should use frameworks that you know very well. That's just the point. I think someone I think uh Venkat already talked about that this morning. on the testing side, and that's the important thing, because these tests here are white box tests. So, AI takes the use case

and takes the implementation. And that means it tests what's implemented. Even if the implementation is wrong, the test will be green, right? So, you should review that. That's more important than the code. So, the tests are very important. What I did here, I have a notation uh that I can relate to the use case and the business rule, for example, in the tests. Um there's not much

to test because there are not a lot of uh things to do. Um and what I'm currently working on is on an IntelliJ plugin that I can directly navigate from the use case or business rule to the markdown file and the other way around, and maybe I will have some coverage on on the use cases. That means if these are white box tests, then these are just

regression tests, right? So, they help to find out if AI breaks something, but they don't help to say this application works correct. And therefore, it's very important also to create end-to-end tests for this, but the end-to-end tests shouldn't see or AI shouldn't see the code when creating the end-to-end tests. That means you should create the end-to-end tests, for example, with and with an agent, but against the

running application, not against the code. That's very important. And to give you an idea what's the difference between use cases and then to end tests. in the wholesale domain, that's again in German. That's a good thing, by the way. Um with AI, the language doesn't matter. So, use the language that you know or that your business people know. And that's why the use cases are all in

German and not in English. In early days we would do it in English because we say there is everything must be in English. But as of today, it's better to have it in the language everybody in the team understands best. And that's very helpful because you have to read that. And if you read the use case in in your language, then you are faster than if you

have to read it in a foreign language. What I want to show you is here uh the testing team does something else. They do not test use cases. So for us as developers or software engineers, we are making sure that the use case is tested. We have a test coverage above 95% so the remaining few per- percentage cannot be tested because that's probably code that never runs

or only runs in uh error situations. We also do not we usually don't do mocking because AI is very good at uh test data generation. It can it even knows that I'm in Switzerland. If I that if I say, "Okay, create uh test customers." The test customers look like real with Swiss phone numbers, Swiss email addresses, So we are responsible for the use cases and the testing

team is responsible for the whole workflow. And what they do, they create workflows. And as you can see here in the diagram, you don't have to be able to read it. It references the use case. So with that, we also can see, "Okay, do we have a workflow that tests all the use cases?" And so that's more or less the thing that we use. We also created

tests for them. Um or Playwright tests, Playwright skills for them that they can generate code. Because our testing team before was using traditional testing tools, so we had to record the tests and you parameterize the tests and then you run And they are now fully on code. So, they use agents to create end-to-end tests and also test data and stuff like that. to conclude, um the specs,

but also the guidelines around it, really help reduce the non-determinism, but you have to define what that exactly means for you. So, if the tests are green, your application is working and to end tests are green, then it's okay. It doesn't matter if it's not the same code generated than we had before when we change something. And the second point here is something that's very important to

me because I'm working for like 7 years in modernization projects and that's sometimes a pain because we have to reverse engineer everything. I more I hope is with that approach in 10 years we just generate code in something else. And maybe in 10 years we don't even have a UI because everything is chat based. Maybe, I don't know if this will be come But we are really

kind of a sustainable uh piece of documentation that we can use also in the future. And important for you as a software engineer, review, understand review tests, test the output. Use all the tools. We use SonarQube, we we use JSpecify, for example, to check nullability. We use modern JUnit tests, stuff like that with parameterized nested tests, everything. So, the software engineering, in my opinion, goes not away.

It's more important than ever. But we don't do is typing. But we need to understand and to architecture, design. We decide on how the software should look like. And that's also you need to know the architecture, you need to create the and you need to know the domain very So, you as a software engineer are more valuable if you know the domain than if you know the

technology in detail, maybe. But I would say that's probably more or less every always the case because you don't need to know the full technology, maybe if it's software, but you need to know what exactly that you implement. So, that's it. >> [music]