Spec-driven Development: How AI Changed Everything (And Nothing) by Simon Martinelli @ Spring I/O 26

This talk presents the concept of spectrum development, which emphasizes the importance of starting software projects with specifications rather than code. The speaker shares personal experiences transitioning from traditional coding practices to a spec-centric approach, where specifications serve as a contract between business needs and AI capabilities. He discusses the three pillars of spectrum development: spec-centric development, context-aware development, and agent experience. The speaker highlights challenges faced in modernizing legacy systems and the necessity of crafting user-oriented use cases, asserting that AI tools can aid in generating code but require human oversight for quality assurance. He also outlines the significance of a lean requirements engineering process, showcasing the use of various tools for managing specifications, including the recent advent of AI-driven solutions.

[music] >> Okay, hello everybody. Um, I'd like to talk to you about spectrum development, but first I'd like tell you a story. So, I'm in a sports club and did track and field. I know you can't see it anymore. But, uh we have great runners in Switzerland. One of them is uh Ditaji Kambundji who is the world champion in 100 m hurdles. And um if you're in

a sports club like me, then you have plenty of requirements for software. So, I'm doing software for my sports club for already 30 years now. Uh we are organizing um competitions for kids and there I do software. But, we also do other um activities like we have a beach party at the annual Swiss holiday. And there we need volunteers. And uh in 2004, during that party, someone

from the club came to me and said, "Hey Simon, uh you're a software engineer. You did software for us and we need a new volunteer management system because the old one is very old. It has a lot of bugs and it will be discontinued. And I heard that there is AI and I'm certainly sure that you can do that." And I did that. So, I started 2024

doing something called wipe coding. And uh who did wipe coding already a few? Who get lost during wipe coding at some point? Yes, and exactly that happened to me. I had no clue what I did. So, I had kind of a volunteer management system that worked more or less, but I wanted to add it more features, but I had no clue if they are there there or

not. I had a lot of code and I lost somehow track on what I'm doing. And so, I said, "Hm, I may have to shift." And then I heard about something called spectrum development that was around Christmas 2025 2000 2024. And then I said, "Okay, that's a cool idea. I want to do that. But, what are the specs? And so, that's the topic of the talk. I

will show you how I did it finally. Maybe some words about me. I'm doing software engineer for a very long time. I'm also teaching. I'm self-employed in Switzerland. I'm working for companies like insurance companies, wholesale, retail, government, um you name it. And I heard first about spectrum development on a page. It's called ainativedev.io. It sounds like something official, but in fact it's a website from a company

called Tessle and Tessle started during that time with spectrum development. Currently they're doing more like skill management and stuff like that. But, what they said was something that I really liked. So, they told that you have three pillars. So, you have uh spec-centric development. You have something called context-aware development. So, you need some context that the AI agent knows what you really want to build. And then

we have something called agent experience uh like developer experience or user experience. So, you should have tools that work quite well or seemingly and you don't have to do a lot with that. And I was attracted by the idea that I should write specs and not code because I didn't write code. So, I in fact, I don't write code for more than a year now. I just

work with that process also with my customers. And um so, I was really wrapping the head around what could specs be. And back then there were no tools, right? So, we will come to to tools. So, spectrum development maybe what's important is you start always with specification, not with the code. The question is who is starting with the specification? I will try to answer that uh as

well. And the idea is that the specifications will be the intent of the application or the system that you want to build and serves as a contract between the business and the AI. And me as a software engineer in the middle, I see myself more like an enabler and not like someone that really does something, right? Then specs should be source of truth. So, we don't change

the code. That doesn't mean that you don't touch the code, but we really don't change the code if we think something is wrong. We always go back to the specs and figure out why the code doesn't reflect the specs, for example. And this helps to reduce guesswork and probably may improve um the quality. But, there is also warning because when I started talking about spectrum development like

more than a year ago now, uh people always compared it to something that we already had. Who remembers model-driven development or model-driven architecture? I did as well. So, it's like more than 20 years ago. We had some tool called Open Architectureware, for example, where we create UML models and then we created code from the UML model and this was not very well. Sometimes it worked very well,

sometimes it doesn't. The problem was it was very difficult to define the whole model that the code was like you wanted to have it. But, the warning here is it's not model-driven. So, model-driven you could remove the code, regenerate the code from the model and you get the same outcome every time. But, AI is non-deterministic. That means you will not get the same output every So, that

doesn't mean that it doesn't implement the spec each time you do it. But, it may do it a bit differently. And that's the same as you would have two developers and you give an assignment or a task to one developer. One developer will create it like this and the other will create it like that. As far as the outcome works and works it defines a bit what

works means, for example, it passes the tests, then that's fine, right? So, it really depends uh the depends on what you mean by Um but here I really mean that the code doesn't look or may not look the same if you do it twice. And the last sentence is very important to me. So, you're responsible for everything AI generates. So, there is no way that AI could

be responsible for what it does. So, it's always you that have to be make sure that the code works. Now, if you look at uh spectrum development in practice, there are various tools. So, first of all, there's a process. That's the process that I created. It's called AI Unify Process. I will show you that. Uh does someone remember Rational Unified Process? I think all the people with

the same haircut as I have, probably. And do someone have positive memories about Rational Unified Process? Sometimes, yeah. The problem with the Unified Process or most of these Unified Processes is that they are too big, right? Too many artifacts, too many roles, too many whatever. Too many process. But, uh mine is lean. I will show you that in a minute. And there are tools. So, there are,

for example, I'm from Keira or GitHub Spec Kit or Behave that's very popular. But, my problem with all of these tools is a bit I'm not working on greenfield projects usually. So, I'm working for big companies like government or insurance companies, for example, and there we don't do really new development. We add features or we modernize applications, but we don't start from scratch usually. So, the specs

should come from somewhere, maybe. And on the other hand, most of the tools, especially the Behave tool, is very restrictive on how you have to do And uh I have a bit another take on AI-driven development and that's what I uh show you. There's a website. It's called Unify Process .ai. And here you will find uh a process. So, my process, that's for a greenfield project, by

the way. Most often it starts with some kind of a mission. So, some business people or whoever has an idea and want to build software. And then the regular requirements engineering process starts. So, people are gathering requirements. Um they manage requirements. There is the International Requirements Engineering Board, for example, uh where most requirements engineers work along uh how they define the uh the certifications, for example. And

then you have something like a requirements catalog. This could be user stories or documents or any other kind of specification or requirements. That really doesn't matter. Uh what's important in my process is that from that you can also use using AI and derive two artifacts that are very important. Uh one is a domain [snorts] model. So, you need to know here it's called entity model, but uh

most often it's uh a fully domain model that you can maybe create using DDD practices, and then you have kind of a glossary and all the entities that you will have in your system. And on the other hand, I use system use cases. talk about that later on that give you kind of specification that you can use to generate tests and code from that. And very important,

everything that is generated will be reviewed hopefully by someone, either by human or AI. It depends a bit on the process you do. But, we also have other artifacts that we usually produce. I don't talk about that today, but software architecture is something that also can be derived from the requirements. So, that's something that we usually do. And on the other hand, we have something called acceptance

tests. And there, we more or less test workflows and not just single use cases, right? So, that's kind of a split. And at the customer, we work like this. So, we as software engineers, we are responsible for the system use cases. So, we have high coverage on the system use cases, but we don't test the workflows. That's something that the test engineers do, and they work with

workflow specifications that they use to to test. the idea. Now, the question is, why use cases? Use cases is something very old. Ivar Jacobson and other people, they were working on UML in 1992, around then. So, I was 20 back in 1992. So, it's a very long time. I didn't even work [snorts] in software engineering back in the days. And the use cases that they created and

they're still more or less the same template, but is that it adds a lot of context because a use case has a main flow, it could have alternative flows, it could have error flows, and it has pre condition and post conditions and business rules. And this perfectly works fine for certain types of applications. So, as I said, I work mostly for enterprises. So, I'm doing business applications,

and business applications are more or less always the same pattern, right? They have a lot of CRUDs or create, read, update, delete stuff for managing the master data, and they implement business use cases or they implement processes that have to be implemented by you. So, these are more or less these applications also the in the keynote today where we were talking about the software in enterprises. And

these system use cases, I found they could work. So, they are kind of a unit of work. And this could be the specification. And so, I started with with use cases, and it turned out that this really And the good thing about this form of you can give the use case documentation to people from business. You can even give them to the end users, and they will

understand what's written there because this should reflect what they do with the system, right? And that's why I use these system use cases. We will see examples in a minute. So, if we have a greenfield project, you usually have two roles that are involved. So, we have the requirements engineer that or the business analyst or product owners. It depends how you name that role that is working

together with end users, with people from the business, and they create an entity model and use cases. And they may also use AI already to do that, by the way. So, as I mentioned, Board, they have so-called micro credential. It's called called AI for RE. So, they have guidelines and prompts and stuff like that for requirements engineer how they could work on requirements engineering and requirements management

with AI. And then we we get these use cases, and then we can use the AI agent to generate code and tests. We have the software engineer here who is responsible for the output. He can review that. So, he will review the use case. So, what we usually do in the process is we go ahead and first thing that we do, we let AI review the use

case if it's ready for implementation, for example, and then we generate test and code. Depending on what you're doing, you could use also test-driven development. So, for example, if you're doing a REST API or a library or something, then test-driven development works very well. If you're doing UI development, then test-driven development may be kind of hard because you don't know exactly how the UI may look like

before you start, But, that's the greenfield flow. But, usually we have a different flow. And the different flow is called I call it brownfield workflow, and in the last like 7 years, I was more or less working in modernization projects, and I'm currently working in two modernization projects, one for Covenant and another one where we kind of recreate the ERP system for the largest wholesale company in

Switzerland, and we use that workflow. So, here we don't start with the use cases, we start with what we have. So, that means we take the code, we take documentation, we take Jira, we take Confluence, everything that we can find and feed it to AI and let AI extract the use cases. We also have sometimes business processes that we can take to get an idea what use

cases we could have in the system, and this will recreate the missing pieces that we have currently, and from there we can generate the new application. So, we don't do something like COBOL to Java transformation that Entropic was talking about a few months ago. We really just reverse engineer the specification and then create the code. The reason [snorts] for that is when we started with modernization project

2 years ago, we were doing it manually, so without AI more or less. And then the guideline was, don't create new features. We were not allowed to add new features because we want to to transform the old application which was Eclipse RCP together with JBoss and EJBs to Spring Boot and Vaadin to the front end, right? And when we finally went to into that process here, we

realized that now we can do whatever we want. So, as long as we can describe it in the specification, it really doesn't matter if it's an an existing feature or a new feature. And this gave our project a huge boost because now the end users get new features that they were waiting for many years already because in the old system, it was probably not easy to implement,

and we can do that now, and that has a very positive effect on the modernization project because usually modernization projects are not very well received because they change a lot for the end users, and they prefer to stay with the old system. So, that's kind of a benefit. for this talk here, because we are at SpringIO, I created something for you. I created a brownfield approach for

you. You may all know Spring PetClinic, If you haven't seen it, I can go to it. Does it run? No. Then, I start So, Spring PetClinic is called Spring PetClinic, by the way, because for Java EE or J2EE, there was the Pet Store that was like kind of the demo project for and Spring also was looking for kind of a similar um project, and they created PetClinic.

So, that's the reason why. And what we can do here, we have a home screen. We can find owners by name. And then, we can edit the owners, and we can add pet visits. So, we have something like that. And we also can list all the veterinarians that are working in our um pet clinic. So, that's the idea of of this project, and it has an error

page. So, that's it. And what I did, I recreated the use cases for that project, but this time as use cases, and I want to create that as a new modern application. That was my And what was created, in fact, was the entity model. as you can see here, everything is code. So, also the diagram here, that's a mermaid ERD diagram that was created here. That has

just the names of the entities because you don't need the attributes here. That's just to visualize the dependencies between the entities, for example. And then we down here, we have kind of tables with attributes, description, type, precision, lengths, and some validation rules, and that was extracted from the old code. And uh this will be then used for sure to create uh the data model and also the

domain model. And on the other hand, we have recreated And these use cases here let me make that bit bigger. Um are grouped. So, I didn't tell AI to group that, so that's something that it did. And uh we have welcome page, we have the veterinarians view, and we have the order management and the error handling more or less. So, that's uh pretty much what we uh

wanted. And uh then I uh told AI to also uh the use cases. And here you see use for Cloud Code. I have a marketplace, so marketplace is kind of a way how you can distribute plugins for Cloud Code that may contain skills, sub agents, um and MCP definitions. there is also a use case template, that's why it always looks the same. We also use, by the

way, uh status tracking on the use case, so we don't do um all projects that I'm currently working, we don't use Chrome anymore, so we don't have any sprints left. So, we really work use case by use case, so to say, and that's more a compound flow and not a uh uh Scrum flow with fixed time boxes, because that doesn't make sense. And to give you some

numbers, so that's a very small use case, you know, so we can go through it. So, we have use cases, who's the actor, what's the goal. And then we have some uh preconditions. I mean, the first one is a silly precondition, you can delete that, that And then we have uh the main success uh scenario, user clicks on a link, and then it displays um the grid.

Um here we don't have any requirements for the UI, but usually you have maybe UX designer who uses Figma, for example, and Figma is uh quite well integrated, because it has an MCP server, that means it also AI can generate Figma designs, but AI can also read through the MCP server the Figma design. So, you don't need to export that somehow, the AI can directly use that.

That's the way to go. Or in another project, in the government one, we don't want to change the look and feel of the UI, so we just use screenshots as the input for AI. And that's good enough to know the structure of of the the code. Here, we have everything in text, so that means uh it tells that the grid has uh first name, last name, and

then a comma separated list of specialties, for example. And then we have some alternative flows, because there must be a REST API. And we have some post condition that uh what happens when it's when it works. Then we have some business rules. I mean, the first one is not a business rule, that's more a constraint that would be in um kind of a non functional requirements documentation.

And then we have other things that that may go here. And in practice, this use case could be very long, so we have use cases around 26 pages, for example. So, if you would export it in in Word. And in the government project, the relationship between uh requirements engineering and me as I'm the only developer currently for that proof of concept, and I work uh one day

per week for them. And they have two full-time requirements engineers working on the specs. So, that's quite a shift from uh software engineering to requirements. But this time, it's uh for them it's a big chance, because replacing the old system is quite difficult, because no one knows what it actually does. So, we have code, and we have a lot of bugs, and we have a lot of

missing features in the existing application, and now we are trying to reverse engineer that and fix that. So, that's like a two-phase thing. So, we recreate the use cases, that works pretty well from the code, and then they spend quite a lot of time, first of all, to go to the application and verify if the use case is correct. And then secondly, verify if the use case

does what it should do, because in some cases that's not what the application currently does. So, that's a lot of work uh on the requirements engineering side. On the ERP modernization side, we don't have that much effort, because we just can recreate the use cases, and we as developers, because we are experts in the system, can re- do the review by our own. So, we know the

existing system, or not I, but the other people working with me know the system so well that they can review the use cases. So, we are not uh having requirements engineers on that And that's it. And uh I already um started the application or created the application for you. some advice, um do the scaffolding of of the application by yourself. So, go to start.spring.io, and uh create

your application, maybe also follow what Daniel was talking about before, so create your security the configuration by your own, maybe with the help of AI, but don't use, for example, Cloud Code to create your application, because if you do that, the next step that you have to do is to modernize this application, because Cloud Code will probably create a Spring Boot 3.7 application and not a 4.0.5

or something, right? So, it's better to to do that by your own, and you can also use uh guidelines for I will show that for testing and and for for the application. And that's the first view that I already created, because that's just displaying the picture. The design is a bit different, because I didn't tell how the design should look like. Um but I but I like

to show you is if you want to implement the use case, too. So, this um let's go back to the old application here. So, we want to uh view the list of the veterinarians. We can just go here, and as I said, I have uh some plugins for uh Cloud Code, and I just can type implement use case 002. So, that means I don't do any prompting

here. So, the question is where's the prompt? This um {slash} but in AI app, but in Chuke, implement is a skill. So, in the beginning, Cloud Code does distinguish between commands and skills. Now, everything everything is a skill, and you can directly call skills. And if you go to the marketplace, for example, that's simple GitHub repo, then we can find this skill somewhere That's the implement skill,

that's just a skill uh markdown. By the way, that's more or less the agent skill standard, and uh could also be used with GitHub Copilot or any other tool. Just the marketplace and plugins are uh specific for um Cloud Code. And here you see a skill, and the skill has a name, obviously, that's how you call it. And then you have a description. So, this part here

is called the front matter, and this tells AI when to use the skill. So, in my case, I don't it doesn't have to figure out to use it, because I directly call it. But if I would say just implement use case 002 without the {slash} in front, then it will probably find that, because here in the front matter says, if I the user wants to implement the

use case or build a UI or something like that, use that And there are tools like Tessel, for example, where you can validate your skill. So, they can evaluate your skill, if the skill is is okay, if the skill is used or can be used. They even work on on testing tools that they um use or execute the skill somehow, and then uh monitor the output, and

give you advice how you can uh improve the skill. And that's what I also did here for that skill. And what we have here is we have some uh don'ts and do's and the workflow and stuff like that, right? And this skill here is specific, because I'm using Vaadin and Chuke as uh libraries. That's made for that one. I'm also working for a customer that uh is

using .NET, so we are modernizing um um also kind of a an ERP system that is uh in forms with direct access to the database, so a two-layer application or client-server application, and we are creating something new with React and the .NET framework, and there we have created skills for that stack. So, the skills should match the stack that you're using or the things that you use.

There are also um skills that are not relevant and not related to to a stack. They are in this AI app core, and here, for example, we have uh use case, not the use case diagram, but the use case spec skill. And here in this skill, um we have instructions, as before, and we also have a template. So, that's why the use case description in my example

Pet Clinic project looks like that, because it used the template from here. So, you can feed a lot of things, but you should be careful, because skills, if you don't know where they from and you don't review the skills can be dangerous. So, skills can be used to do prompt injection or a lot of other bad things. and that's why you should really take care which skills

you want to install and and use by the end. A lot of companies or people are working currently on skill management because somehow you have to share them. As I said, it's here it's it works out of the box out of the box because it's the great in cloud code. But if you have different agents, then you may have centralized agent skill management something, but we don't

have yet something that I would call um a perfect solution. here. So, here I get asked for something and we'll let it run. It takes around usually 3 minutes or something to create that. I already talked about skills. So, you can use that to um have repeatable skills defined that all the people working in the project have the same skills. So, that means either you have company-wide

skills or you have public skills, but you can also have skills for the project, then you can just um put it to the Git repo and everybody can use it. Another thing that uh is also, in my opinion, quite uh useful or MCP servers. For uh Java, there are for example, from James Watt, who is also here. Uh he has uh created a Java doc MCP service,

so the agent can use the Java uh directly. Um then we have, for example, Vaadin MCP server that was created by the Vaadin team who is here. Um and I created one for Torque and one for Caribou testing, that's a testing framework. And these are very helpful. And there is a debate if you want to use MCPs or skills. A lot of people say you don't need

MCP anymore, just use a CLI and the skill. And but that's not the truth because most of the time if you have MCP for documentation, they use a vector store and then you can do vector search for similarities search, for example, which is more efficient and that's why I still prefer MCP server for And there are other guidelines. So, first of all, if you're doing Java development,

uh you already have guidelines and the guidelines is the pom.xml or the Gradle file where you define how the application should look like. I most often also use Spring Boot. So, this already gives some structure in in the application. And finally, in my example project, I created two guidelines. One for architecture, so it says, for example, package by feature and then we have UI and the domain

package inside and stuff And we also have the testing. We don't do testing today, but um Vaadin is special, so Vaadin is server-side. It's not server-side rendering, but server-side programming model. That means you can test Vaadin application so-called browserless. So, like you use a MockMvc, for example, you don't need a Tomcat to run a Vaadin application and these tests then run as fast as unit tests, more

or less. And so, you could have many of them and uh then we also have um uh for example, in in that example, I will show you later on. I have a use case annotation that helps AI to drift to do the drift management because sometimes you have a drift between implementation and specification or specification and test and you can use AI to figure out uh what's

um exactly tested and what not. Okay, let's see how far we are here. That's done. let's go ahead and restart that. So. we have our veteran's table here, right? obviously, that was a very simple case, right? It can't fail. It even produces more or less similar results every time I run that. As long as I stay with the same tool and with the same model, then it

produces kind of more or less deterministic results. Right. let's go to uh the main branch. Like this. Um what I created here for you is an example project and you can see here that it has some tags. There's an initial tag where you can start with it, so that's kind of the reverse engineered project. And I also have a full implementation that you can see how this

looks when it will be uh done. And this one for the last like 5 minutes, I like to show you the testing part of that. We go to the fat, for example, you see that uh the tests in that case here have the same name as the use case. So, as I said, we really test use cases or we implement use case by use case and we

test use case per use case. So, even if you have two use cases using the same view, for example, we have two tests, two separate tests. And these are regular Spring Boot tests with test containers. And these are so-called um browserless tests. So, that looks like this. So, we can navigate to a view, we can get a grid from from the UI, we can uh check the

size, we can do assertions. We can get the first row, we can assert on the row content and stuff like that. So, we have selectors like you would do end-to-end testing. And um as you have seen in my process, we also have the acceptance tests. So, the acceptance tests in my project are done with Playwright. And these are real black box tests because these here are all

white box tests. That means AI to create the test not only sees the spec, it also sees the implementation. And that means it tests what's implemented and specified, hopefully. And it hopefully finds out if there is a specification, right? But these tests are just for us and are more kind of regression tests. The more important tests are the workflow tests with uh as end-to-end test because that's

the truth before the user what he sees. But here to show you, I created this uh annotation just for me that I have a reference between an ID and the business rule and I also have better IntelliJ plugin where I can navigate from the business rule to the test and to the implementation and stuff like that, right? So, that's that's kind of of the ID. Now, um

something that I also like to talk to you is about the impact of the architecture because spectrum development or AI-driven development at all, you should reduce the context. We heard about uh Spring Boot, which is great if you want to build a monolithic application. But if the monolith becomes big, so for example, the ERP system that I'm talking about, we have over 1,000 database tables in that

system. So, that's quite big system. I also modernized a bigger one which has double the size in database tables and that's simply too big. It's not too big for AI, but it's also too big for humans. So, you have a huge load if you're looking at the whole system. So, it's probably better if you split it and my preferred way to split that is self-contained system because

I try to keep UI, business logic, and database in a silo in a vertical slice and that's also very very useful for AI. And what's also very useful is if you have kind of a full stack framework. So, this may be Vaadin as I do. This could be Thymeleaf, for example, or J C or something um more server-side rendered, but you could also we are here on

a Java conference, but you can also use like React full stack, for example, and then you have a single JavaScript stack. The reason for that is that you just have to create the guardrails and guidelines for one ecosystem. So, in Switzerland, it's very popular to have Angular in the front end and Spring Boot in the back end. So, that's called the government stack or I call it

the government stack. And there you have a problem, right? Because everything you do, skills, MCP servers, guardrails, guidelines, all the files has to be created for both stacks. And more work. Let's say like that. But it really on um what you really build. Microservices, on the other hand, may also be a problem uh or not a problem, but you have to find a way how to work

with that. Because if you work with AI on a use case, for example, you need all the code that is involved in locally or wherever your agent runs, right? This It can also run in a pipeline or on a build server or something. But you need kind of, I would say, probably a mono repo where everything is included to work efficiently with AI or you need if

you use microservices a very good open API documentation that AI can figure out which API must be called depending on the use case, right? So that's kind kind of a trade off. I would modular monolith probably as Oliver said in the morning is is probably the best starting point also Cool. So to conclude in my opinion or in my experience now specs help to reduce the non-determinism.

So if I would do white coding I would get something but I would have to read the code and to re-prompt and so I can really rely on the specs and and check them out. So we have very good results. Um to be honest we don't do everything like that. So this back driven thing works very well for this business application types, right? So if we have

complex business logic for example, this is very often done more in a test driven the test are written first or generated first and then the code is generated last but not based on a use case probably maybe more on a interface specification so to say. Then what's also important for me as someone working on software modernization project spec driven may way more sustainable. Means if we have

now the ERP system fully spec we could go ahead and recreate it in 10 years. Maybe. Hopefully. Because AI will be better and faster I assume and then we can just generate that in another stack. But currently and that's very important you should review understand and test everything by your own. So you should really look at and there it's beneficial if you know the stack very well.

So because I know what in an intro for I just can scan the code. So I don't need to read every line because if I look at the code we can maybe do that. The last minute or so what it created here or let's switch back. No, no, let's use that. Doesn't really matter which one. We have repository and I know that that works or looks good

because I know true, right? We also have record here that's also probably a a good thing and that's it, right? If I would do the same demo with JavaScript for example which I also do so I do workshops on spectrum development and also had a customer who said you must do JavaScript with React and React server components and stuff and I looked at the code and I

didn't really understand what's going on. It worked but that's the dangerous part of that, right? So you must understand the code. And on the other hand architecture and domain knowledge is yours or the companies and not AI. So you really need to understand domain, you need to understand the architecture. You should also with the help of AI the architecture work and then you will get much better

outcome when you do that like this. So that's it from my side. I think we maybe one question. Someone has a question? No? All clear? Okay. Thanks a lot for coming and I'm here tomorrow if you have any questions or you want to see a demo or something just approach me and we can do that together. Thank you very much.