Code Is Cheap. Software Isn’t. | Markus Eisele (EN)

This talk discusses the transformative effects of AI-assisted coding on software development. The speaker shares insights from 18 months of experience using various AI tools, emphasizing that while code generation has become easier, the challenges lie in understanding and managing complex real-world codebases. They explain the risks of AI hallucinations and the importance of providing context for AI models, highlighting the distinction between generating code and comprehending the implications of that code. The speaker advocates for a structured approach to software maintenance and development, recommending smaller, manageable tasks and incorporating verification at every stage. They conclude that while AI can enhance productivity, it cannot replace the essential engineering judgment and careful stewardship needed in software development.

[music] >> Welcome to JCON. I was I was playing around over the last couple of months and it's almost 1 and 1/2 years with AI-assisted coding. And I learned a lot. And I thought that is an opportunity for me to glue this into a keynote. And I wanted to make sure to bring you a little bit of the lessons learned today. To be honest, I like to

talk and I like to listen as equally. I really want to talk to all of you. If you have questions that we cannot answer right here in the larger audience, please make sure to stop by the IBM booth because that's where I'll be hovering around most obviously. And I I'd be delighted to answer all your questions. The keynote is titled code is cheap, software isn't. And I

think this is what all of this burns down for me personally. When you start using AI assisted tooling, everything feels magic. Seriously, I had the best time. When I installed all the CLIs, all the IDEs, and I thankfully have an opportunity to play with all of them, I was just mind-blown. Like literally, even the first trials with ChatGPT, I was excited as my kids were when they

figured out that they can use that to do their homework. Um and and it is actually a cool thing. Um you can all get all the scaffolding, all the boilerplate, all of this ultimately was gone. Like as in I don't even have to use Lombok anymore. This goes way beyond, right? Like all the interfaces, everything is automatic. That is auto-complete in the form of a unicorn. That

narrative does change very, very quickly if you start throwing AI at real code bases. And if I say real on this slide, I do mean real. Not a cargo tracker example, not something that we can find out there that is closer to spring or any other technologies. Um I mean real code bases, millions of lines of code. Something that you have developed carefully inside the boundaries of

a customer, maybe even using custom authorization frameworks, or the famous old model-view-controller controller frameworks that were carefully modernized over time and still follow some very delicate patterns that are deemed to be super important by the business. When you throw AI at things like this, it breaks in unexpected ways. And this is probably the most risky part of using this new tooling. And ultimately, it makes us realize

that writing code really has never been the problem. We've been scaffolding, we've been defining architectures, we've been doing all kinds of things in the past, and what really is easy is the plain syntax of the language. We can parse that. I mean, it is machine-readable. Like that, there's no undefined space in all of it. Also, generating boilerplate is so easy. Um what is not easy is figuring

out the meaning behind certain constructs, the intent behind certain implementations. It is not really easy to refactor invariants, everything that is implicitly encoded in these large code bases. And I personally love to talk about insurance cases. That is where I earned my first consulting stripes feels like 100 million years away, but still, have you ever heard about long-running transactions? Like stuff that starts somewhere when you open

a contract and runs for years, literally, and whenever something changes, they recalculate cycles back to the date when you opened the contract. Like we're talking about transactions that are business transactions, obviously, running over years. This is not necessarily something that just has an transaction annotation on a class. This is something that is deeply buried. No, not in one class, in a ton of classes across the code

base, mostly anchored in the database. That is one of the premier cases where you will run into a lot of challenges. And I like to call this implicitly encoded knowledge. And that is the hardest hardest hardest piece. And this is ultimately where these systems fail across the board. It's not the obvious stuff. It's not the scaffolding. It's not the will generate something greenfield. It is the careful

maintenance and expansion of existing software. And as I mentioned, hidden in the functions, there's a ton more. There's contracts that originate in downstream systems. There's a ton of non-functional requirements that have operational roots. We all remember these fancy systems sitting somewhere in a customer account that can't be changed because it's the only remains of a specific type of hardware, and I'm deliberately not talking mainframes here. Um

like there's a lot of other things that we could even distantly imagine that have operational context that does carry into the code base, but not in the means of an explicit transaction or even a class or marker that makes this very obvious. what really makes coding with AI assistance really hard. What happens if we still are brave enough to throw an AI assistant at these We'll get

hallucinations. do I like this word? I don't know. It is kind of established now. Everybody has an idea what that means. We've all seen the wildest text combinations being generated. And in the very rare cases cases it actually was a great poem. Um it was still something completely made up. I like to call this predictions. Um I mean, it is statistically generated token output. We we all

agree on this, right? So, we're not talking AGI. We're not talking intelligence. These things still are statistical generators wrapped in super intelligent harnesses. And if you don't give them enough context, the wrong thing happens. The model completes your mental picture without even asking you. Are talking to you. It basically just does what it can do based on its training data. It's AI completion. It's not intelligent, but

it's completion. Pretty much. The first real important takeaway is based on what the AI sees, which is matching a sameness in patterns, a sameness in the question, in the structure it sees right in front of it, is not [snorts] something that carries architecture. carries boilerplate, simple constructs, but this is nothing that can actually pay forward respect to certain complexities that are grown in code bases. It can

also not anticipate non-functional requirements that are written down. So, this is important to remember that you cannot base your future developments just on simple patterns and sameness approaches. Because ambiguity also turns into assumptions. And the more you follow up on these paths, the deeper you go down these rabbit holes and continue prompting your models without further and the right the more the model guesses. So, this is

like a spiral, literally a rabbit hole you're falling into. And it's not obvious. It's not that the model's telling you anything about this. These things are insanely confident. If you think I'm confident, I'm not even a tenth of what these models are throwing at us. Um and we all have experienced that, right? So, stay aware that these models do not have an indicator about wrong or right

or what is actually important right now. Clever prompting will not save you. In no way. Absolutely not. Every single piece of structure or information that you can present to a is going to beat every single clever prompt. Everywhere, across the board. The question is, what do you want to achieve? Do you want to solve the task you have at hand right now? That might be solvable with

a prompt. If you want to build structure that lasts longer, you need exactly that kind of context that is built up that you can ground the model or your agents in. Why I'm not talking about agents more and why I'm using them all most interchangeably? Because things are shaping up. We are at the very forefront of research. To me personally, this is the biggest experiment in an

industry that ever happened. Like we all are using tools that are actively being researched and pushed forward while we are using them to build productive software. That is a pretty big experiment. So, a lot of the knowledge we're seeing today coming out of these agents, chat machines, whatever is actually baked into the models. That's what we call training data. But there's much more showing up in harnesses.

Who has taken a sneak into the leaked source code of Claude? Or not that many. I expected more. That was pretty interesting. There is a lot of software engineering in these harnesses. Um and that kind of made me feel better because it took away a lot of that magic that these large language models underneath are supposed to replace all of us. There's software engineering involved here. So,

keep that in the back of your head. What helps really good when working with agents, large language models, with the whole context and magic generation machines in IDEs or CLIs is you need to separate what you want to achieve from the how. And you also need to make sure to validate everything. Who has open Claude running? Oh, okay. That is not bad, but a little bit less

than I expected. one of the promises of Open Claw is that it runs agents in a loop like all night long. I have to admit, I personally still have bad feelings if I leave an agent just run to grab a coffee on my machine unsupervised. My strong recommendation for you is pay extra attention to the verification step. No matter what you do and what kind of agent

harnesses and what kind of tasks you're running, make sure that verification and validation is always the last point in your personal process. How do we How do we define a what? How does what actually looks like? I said >> [snorts] >> prompts can't save you. So, obviously a modernization prompt like this is not going to cut it. That is way too simple, how can we how can

we change a prompt like this to be more efficient? And how can we separate these individual steps and bits and pieces? Let's tie this back a little bit to what an AI needs in terms of boundaries. We need to create a context for the models, for the harnesses, that actually define defines good boundaries. Something that is actionable, that is practical, that is implementable. And I've been entertaining

a thought just yesterday. I was thinking about my teenagers because they called me, they wanted money, but that is normal. But, I I was also thinking how I taught them in the past, like how was my parenting style. And whenever I think about large language models, I'm being reminded about my parenting style. What does work with my teenagers? You cannot do this is something that does not

work. That is kind of the the exact opposite of what I want to reach, right? Uh for large language models, I tend to feel similar. Instead of telling them what not to do, I'm trying to explicitly tell them what to do. And guess what? Our attention span, like even up to the old age I'm in, is limited. That basically means we cannot remember 150,000 things that we're

supposed to do, but we can remember five things, maybe. So, defining boundaries and constraints are coming down to like the real high-level value points that you want these agents to follow is exactly the solution of the definition of what to do, and um that can be architecture, that can be non-functional stuff, that can be the explicit pieces that are not easily to derive from the existing code

bases. That can also be something fickle like security. But maybe you forget that I'm talking about security because I personally do not want anything security sensitive being designed by these systems. And if you've ever thought about throwing any of them at a simple OECD login flow, you can see magic happening. >> [laughter] >> Depending on the available documentation and training data, the results will be vastly different,

and I can tell you most of the time insecure. stick to team conventions, stick to things that, as I said, cannot be derived from code directly. I think that is the one magic piece that will put you in front of a lot of other teams working with these approaches. And another interesting aspect when you start defining the context is defining the size of the task you want

these systems to do for you. And this is where I tie it back to another thing that I've seen fail in our industry across the board over and over again, and that's kind of the big bang theory. We do modernization like all of them. And we'll modernize everything. Um, and ideally in a back big bang, right? Why is that so interesting? It it has a psychology effect

to it. It promises the new land. It promises to solve all the problems at once. I can only recommend resist. >> We all know it does not work like this. Um, we run into too many unknowns. Like every single thing that you experience doing a big bang modernization or rewrite is going to happen if you build too big of a task for your agents. Do yourself a

favor and cut them small. Do the thinking front up. Some people call it plan and planning, by the way. I'm uh I'm still old fashioned. I like thinking. I'm not totally opposed of uh actually thinking a problem through before I throw it at an AI. So, yes, it's emotional. Like forget about all of this. We want tasks to be small. We want to make sure that we

express everything that is necessary and that we cut them in a way that gives agents a chance. we can try approaches over and over again, right? This is nothing that we can only try once. So, you have a big opportunity if you cut your individual tasks smaller to do them more often. So, use that as an opportunity. You get more feedback. It's so much easier to work

with these systems. You will see how decomposition wins in the long term. It is something that not only makes your life easier, it will be the path to success for yourself. And uh this is just an example, but you can start with a module. Hey Marcus, that sounds so familiar to what we did with microservices back in the day. Yes, thank you. Exactly. That is definitely something

that we could draw future future anticipations from. We like even if we have AI right now, that does not mean we have to forget all the lessons learned in the past. At the end of the day, we're still modernizing systems. We're still trying to push our implementations forward. Why should everything that we learned so far be completely lost? Base everything you do on your knowledge, on the

things, on the best practices that you've already applied in your code base. But use the better tools today. That is what will help you. And what also helps me a lot is having rollback plans. So, if you're not using Git locally, um you can do this. Many agents love Git in so many ways. And even if it's just a local repository, you don't have to spin up

another 150 ones on GitHub publicly and zync and push and do whatever. Just use Git in it locally and give the agents a chance to roll back. That is so easy. Engineering is a discipline that sounds very German in the first place, but I think it's a very good discipline for building resilient systems. And to me personally, AI does not need to change this. Like we don't

need to forget everything we learned just because there's now AI. If there's one useful Monday morning coffee rule for you all to apply, it's If a task is too complex to explain in a couple of sentences, it is most likely way too large for your agent to implement. Or for safe delegation. Like depending on how you run your agents, um I'll leave you all experimenting with the

ways you do it. Open claws or agents in the cloud, there are plenty of opportunities. As I said, I'm old-fashioned. I really like to see what these things are doing, so we'll keep it there. So yes, we've moved from prompts to systems. And I think this is what I what I really like in the agentic engineering software development life cycle. Moving from local isolated wins all the

way to creating context and building complex systems going forwards with reusable workflows. If you hadn't had a chance to um listen to my talk uh 2 days ago um at the very first slot, I think it was 9:00 a.m. It was recorded. I was talking through a couple of really concrete workflow examples and how they can look like. Think in workflows, even with AI agents. This is

super super important. Turn the chats you're building into your operation system. Make sure that you can use the agents in the way that your workflow runs. We decompose all of this into various assets. They are kind of mingled underneath this big large term context engineering. I don't know if it if I like it, but at the end of the day outside of agents MD and skills and

whatever commands are supported by the individual agents, you also see some pretty old-fashioned things in this list. ADRs architecture decision records. That is a brilliant way to capture non-functional requirements. I've also thought about building a little framework because I can now that basically encapsulates all the non-functional requirements as annotations. In your classes that gives you a agents a direct way to read information about certain decisions or

implementation Make sure that you package them. That is the best way. I love shipping them and I've already heard the first couple of people talking about company wide rollout of skills. Not a big fan of that, but um put them in get. Everybody can look at them and that's probably good enough for most of the reusability of these skills. What we're trying to reach ultimately is to

make architecture and the intent behind software explicit. We want to make sure that we can review what is being built and as I said the artifacts that I'm working with are plenty but comparatively old-fashioned. You're more than welcome to change that. There are for your personal workflows, not mine. Sorry. Uh there are people who are who really rely on Git. Uh there are people who actually love

wikis. There was a hype just a couple of weeks ago about building your personal wikis for knowledge base. Um I think ADRs are probably not a bad place to start. You can also have a bunch of policy docs or you can build your own context servers. What whatever you want. Just giving you that kind of as a homework. Um to think about a little bit more. If

you combine the why with the how, we are still missing the what. Uh the verification pieces. So, how can we how can we make sure that whatever is being what we want it to see generated? In Java, it's pretty simple. We're talking tests. That is the traditional JUnit test suite. Um maybe if you're lucky enough to use something like Quakus, you can even easily spin up complete

integration tests and also codify them using Rest Assured going directly against the endpoints. That is all perfect. Make sure that you're not asking one of these artifacts to do the work for all three. Make sure that you're separating exactly these three pieces from each other. What is also interesting is um I've seen this happen a lot of times. People are throwing everything at agents. And that includes

Word documents. Like somebody wrote a nice little architecture document. You find that in your stack somewhere on a shared drive, and the first impulse is, "Hey, I'll just throw this couple of Word documents at the thing, and it will do the magic, right?" That is not helpful. context engineering is called context engineering for a reason, because it needs our brain to make sure that we're picking the

right information. And yes, we can bet on context windows potentially expanding, but you should also know that context windows degrade engine results very quickly. Um that basically starts at 40%. So, the smaller your context window is, the less information you can actually use effectively in these windows. just think about it. Treat it as Make compression of information for You are second most important rule. You are in

charge, and you are the one guiding the agents or your IDEs or whatever. You need to answer a couple a handful of questions with the context you're providing, and that's about it. No Wiki dumps, no nothing. Anything else turns into noise, and will lead to weird predictions that you are really not interested in. Encode it as much as possible. Um there's no need to, as I said,

just dump a ton of information at it. Um if you a way of phrasing specific modes, like IBM Bob um encourages, if you're using skills, if you're using commands, all this doesn't matter that much. Um Tribal knowledge needs to turn into something that is reusable and usable by the agent. And I I don't care. I'm not in love with skills. I don't I'm not in love with

agents.md. It all comes down to the specific context behavior you Um so, it's open to you and your experimentation. They do solve different problems. Ultimately, um I have I'm not sure how many of you had an opportunity to download uh IBM Bob, for example. Bob leads with modes, which is a very convenient bucket that you can switch individual packages of knowledge. you can also use commands across

these modes that makes it a little bit easier. They all solve different problems, slightly different approaches. We all agree that they end up being part of the context that the agent sees about your software project, but uh they are loaded at different points in times and can be triggered uh in the context of your workflow at different points in time. So, it is important that you make

sure to um make to build this into a workflow that works for you personally. Why am I not talking about teams that much at this talk in general? I'm not convinced how much is reusable and how much is personal preferences for working with agents. I do know that I run my agent interactions very different to what my team uh colleagues do. So, if it's a good idea

to standardize on a set of skills and commands, I don't know. I do know that the raw context for a specific software project should be shared. If every team member needs the same commands, that is a completely different question. So, I'll keep it to my personal preferences for now. I'd be super eager to learn about your experiences when you've done this on a team scale more explicitly.

This is an example a really simple safe refactor skill. That is something that absolutely has reusable um potential and can be rolled out to the team. Break it down in steps, define the boundaries, come out at the very tail end with a human review, which as I mentioned earlier is uh to me personal the only security boundary that we should really all respect and make sure it's

taken care for. And um there can be a lot of assumptions in these small commands and there can be a lot of power in these commands. I've uh had insane success almost encoding sub workflows into commands or skills, whatever you call them. I'll try to be a little bit more abstract here. So, a command can help you with a ton of context engineering tasks even. So, you

need to think outside the box a little bit. I haven't said that you need to do all of this manually when you build your context and your boundaries. You can even use the tools. You just need to verify a little bit What I found interesting is that a lot of people are starting to realize that context and creating context in a careful way is just not enough

for these agents. There's always situations where a provider falls back to a weaker model, where something happens, an agent gets stuck, and you don't really get the full potential out of the carefully created context. this is an interesting screenshot not from that far back that I found on on Twitter. That guy is promoting agent-driven development aggressively um more on the open clock kind of style. And I

have to admit seeing him arrive at TDD, that was my coming home moment. Yes, that is good software engineering. That is exactly what is required. So, let's all think about that um and also make sure that we're not scared to use these things. It's another tool. It's a powerful tool. What you also need um is a handful of more tools. You have the magic in your hands

and form of an IDE or CLI. The thing that helps you more next is an MCP server. And I just brought you a bunch of MCP servers that can help you with curating the right context. One of my favorites is uh Doc MCP. That is a very simple self-indexing machine that runs locally that can build embeddings and basically does intelligent search on your document buckets. That is

the place where you can actually start documenting your internal secure should not be shared kind of information and make it available to the agent locally. That is pretty amazing. So, if a task depends on something that you cannot actively index where no, it's not publicly been part of the training data, that is your inroad to solve that issue. I usually throw Quarkus upstream documentation at it because

yeah, I I and engineering we're always fighting about the amount of documentation that is necessary. I always want more and they always say no, that's enough. So, whenever I have a chance, that is what I use. I just build my own bucket of documentation. They also said, "Hey, we can do better." And they developed something um that I like that I just wanted to present as an

alternative that you might be able to ask for in other frameworks. This is the Quarkus Agent MCP endpoint. It does not only come with a pre-vectorized documentation database and a couple of nice tools. It also has prompts and skills that you can reuse. So, it's basically just an extension for Claude that you could easily pull and install and you're ready from a technical perspective to build Quarkus

applications. A wonderful MCP. One of my go-to MCP servers is Context 7 that helps my agents to stay grounded and up-to-date with latest information. So, no worries about training data cutoffs being in April last year. I don't care about that anymore because Context 7 basically solves this problem for me. Um they have a very generous free tier, at least up to now, that has not let me

down so far. Can only strongly recommend add it to your toolbox and give it a shot because the results are vastly different and this is when you first start to realize how much context actually means for these large language models. Quarkus itself also comes with what they call a Dev MCP. That is your window into the running Java application. Um that is interesting, gives you log files,

gives your agent a lot more information about what's actually going on inside the application. This is available without any addition in your standard Quarkus project. So, you basically just point your agent at the Quarkus Dev UI MCP um and that's pretty much it when you need to debug or find actual information about the application that is running. Very helpful. Personal memory can also be grounding. I've seen

a ton of people wiring up Obsidian or any other wiki-like approaches. Um I've seen people building some very neat Swift integrations with Apple notes. Um I do love Apple notes. That's kind of my personal wiki. Um this you have the world at hand. How you structure information, that's all up to you. And the way to expose this into coding agents is basically MCP. Um this personal memory

can be helpful, but be careful to not run into this earlier mentioned trap to overflow your agents with a ton of unnecessary noise. AI should actually also be super aware of specific bugs happening in your code Um you can do a lot of reviews. What I learned the hard way is that a ton of stuff is not explicitly thrown in Java, for example. There's um there's interesting

situations where exceptions are swallowed in unexpected places in libraries. Everything that is not explicit can't be seen by the um by the AI in general. Um I would love to have something that gives me more opportunities outside of just creating a specific information boundary in the context to let the AI know this. Just be aware that there is a lot of legacy in our past from frameworks

history that is not easy to be meant by agents, not even if you put the right context in. What helps me a little bit is again a phased approach. Doing a lot lot of exploration and experimentation before I actually start changing code bases. And I think 2 days ago on the main thread I had an interesting article that you might be interested in that basically wraps the

Eclipse language server as an MCP endpoint. Stefan Jansen who runs Devoxx Belgium or the Devoxx as in general, he built this as a prototype. It is one of the most simplistic ideas to use something that we all use in our Java based IDEs and make it available to those agents. So that gives them the opportunity to navigate and explore code bases. Pretty amazing. So explore, derive, review

what is happening, do all of this in a phased approach, and the very very very tail end is about fixing and validating. Ask more questions. Like in a good conversation, ask open-ended questions and make sure that these tools are also helping you personally learn a little bit every session you're doing. Yeah, and I do treat code as pull requests. There is no other alternative Everything that is

being generated, I want to understand. There is not a single line of code that I just commit and believe it's working. This has bitten me before, it will bite me in the future, and the amount of bad code that is potentially going to end up in GitHub repositories all over the place is mind-blowing. So let's make sure that we not only look if it compiles, we also

make sure that we understand what code is being generated. That leads directly to the really bad problem that nobody has solved yet. Um with me asking you all to review what has been generated, um that ultimately leads to all kinds of fatigues um and bottlenecks. And the humans are the bottlenecks. And yes, I know what I'm asking for. That will slow you down. That is going to

take away a lot of that potential that AI is promising our industry, but it also gives us security that we A continue learning, sharpen our skills personally, and understand what is being generated. It Believe me, if it looks wrong, it potentially is wrong. It is so simple. >> [sighs] >> The cost you're not paying or not being aware of is your mind right now, your cognitive overload.

I've been running the main thread for more than a year. I've been blogging daily, creating tutorials with AI, creating text articles. There is the opportunity for somebody who loves being online is amazing. But the time it takes to run into burnout with these tools is absolutely short. Like this can happen earlier than you might think. Make sure that you are not mixing fatigue with productivity. What you're

feeling is potentially tiredness. It is absolutely okay to step outside and take a walk around the block. If you have to let your agent run, but make sure that you're taking care for yourself, even if you're using these It is super important. Do protect yourself. Cut tasks small. Make sure that you do pause using these tools. It is important. You are basically risking the outcome. If you

a led code pass unreviewed because you're tired, stop. Make a break. Try the Toyota system. Everybody that is what Toyota invented. Everybody in the factory is allowed to hit the stop button at the line to prevent failures going downstream. That is a lesson that we can absolutely learn. We don't need to replicate failures at lightning speed. We are absolutely knowledgeable enough to stop AI from doing stuff.

Be aware. Just open-eyed protection of the humans. As Java developers, we're not half as bad off as the JavaScript guys. Java is great. Java is amazing. It comes with contracts. It's one of the most well-documented and most well-trained on systems on planet Earth. It is open source, OpenJDK. Adam Bean has been talking about this since a couple of months already. Like we are in a premier position.

Standards and structure are not old habits. This is something that is a foundation for our future. Even in the age of AI, this is an advantage. If somebody is telling you Python is the is the future, I can tell you what the exact number of Python applications in production should be. Zero. >> [applause] >> Practical operating model, um it is a loop. We're we're working in loops,

right? We've talked about the inner loop, the outer loop. Um I think it's uh definitely going to change a little bit. It all starts with intent. That is we've talked about that. Um we talked about constraints. We talked about decomposing tasks, making it small enough. We've talked about rule skills, how to encapsulate that, build this into your workflows. And uh the last part that is also important

to me personally, keep on learning. Like you need to derive your personal learnings from every single coding session. These new tools are new tools uh for a reason. So, make sure that you capture that you find a way to capture what you learned in this session. And this is also true for If you use summarize, if you use compress, this task that you've been working on is

potentially gone and fried context and no longer be usable, but you can still take something away. Um I do ask my task um or my agents to actually summarize what we learned in the session we just ended. So, that is an approach. The loop only works if you're doing exactly that. Code is cheap. Intent is not. It is an engineering discipline. Verification is the base of everything

you do with these systems. The way you're doing it is completely up I am personally absolutely convinced that AI is changing engineering, but it's definitely not replacing it. So, we all are responsible to take this into a future that is actually sustainable, not only for the AI, but also for us personally as humans. Final takeaway. You all almost made it to your coffee. Shape is clearly Build

your intent in a way that AI can actually understand everything. Make sure that you verify what you build. Protect your judgement. Because the AI tells you that something is wrong, it's 50/50 chance it's not. It's not higher. Definitely not. Keep digging. Code is cheap. Verification is everything. If you have an opportunity to um take a look at IBM please do so. It is a good chance to

start working with it. It is free. You get a couple of coins that get you started. You will learn more about coins. You're also more than welcome to watch a couple of smaller videos about modernization, all the boring stuff that you can do with very successfully. And also if you have questions, please come by the booth. Find me. Find my colleagues. And uh let's talk. So, thank

you for your time this morning. Have a great coffee. Have a great last day of the conference. >> [music]