KI kostet viel mehr als nur Entwickler-Jobs...

In the last week, we looked at in the video why software developers have to deal with AI. Especially those who are rather skeptical and opposed to the whole thing. Today, we'll take on the opposing side. Today, we'll look at why every company that develops software or has anything to do with software development urgently needs to revise and question its business model, because while software developers still have a little time, companies no longer have this time and must as quickly as possible see that they bring their sheep to dry land with AI. And we'll look at this this week at the place where probably most software development companies or companies that have something to do with it are coming together in Europe, namely at the Weoper World Congress in Berlin with 1600 exhibitors, I believe, 16,000 developers, and that was already incredible last year. We'll go through the conference together. I'll show you not only the conference, the congress, but especially examples of companies and tell you exactly why these companies have to reposition themselves and sometimes completely rethink their business model, because it no longer exists or has radically changed. We're driving into Berlin now, and then we'll clarify this topic precisely. It starts after the intro. Enjoy. [music] [music] [music] So, it's well past midnight. I've now finished my slides for tomorrow, the points for tomorrow, how I want to record for the video. I've already looked for people I might be able to chat with, if it all works out. What will it be about? So, first of all, this is the Weeveloper World Congress. You might have seen the video from last year. If not, take a look. I show the whole conference there. It's a huge thing. In the last video, we discussed the consequences of AI development on software development, on quality, on speed, on costs, etc. And first of all, the response to the video was fantastic. Thank you again for that. Um, the focus just went in the wrong direction a bit. The focus later was only on these 2 million euros, on this factor of 93, where I said in the video, it doesn't matter at all. The point is, we can develop with very good quality at an increased speed, and that will sustainably change our software development. That will change you as software developers, that will change a profession, that will perhaps also change the form of your team, we don't know that precisely yet. But what it will change, and I'm very, very sure of that, is your company, because this whole AI thing and the increase in speed that we're getting and the way we will develop and also the entry barrier that we need to develop software, that is fundamentally changing our industry already. I can give you countless examples, which I will sprinkle in again tomorrow, but it will change everything even more strongly in the future, and no matter what kind of software company I imagine, it will affect more or less all of them. And currently, I'm of course doing a lot of AI workshops for developers, but I have at least as many meetings and workshops with managing directors, with boards of directors, where we correct the AI strategy for the company, which is often already finalized in a strange direction, because the insights from the past few weeks, in which direction this is going, are forcing companies to radically rethink. And especially, of course, in the area of software development, because new possibilities and completely different perspectives are simply emerging there, than was the case half a year ago or a year ago. Which companies will we look at? We will start with the software service providers, i.e., the companies that make a living by developing software products for other companies on commission, or making adjustments, or doing anything else. Next, we will look at the standard software providers, i.e., those who develop a standard product and sell it on the market, whether it's on-premise at the customer's site or as a software-as-a-service solution, and also the perspective of customer customization. So, often such companies make a living by carrying out customizations for the customer on the standard software, and then invoicing these customizations accordingly, but also by maintenance contracts, licenses, etc. The third part will be that we will talk about the software teams that do in-house development, i.e., those who are in larger companies and develop software for internal use, for internal departments, or for any other purposes, because a lot will change there too, and above all, a completely new perspective, a new attack vector, will emerge. The next stop will be the companies that do offshoring, nearshoring, i.e., body leasing, either with employees from the European region or from other distant countries, India, I don't know, Vietnam, and whatever else there is, because I think one of the biggest upheavals is imminent there, and also with partly social consequences that are very, very concerning from my perspective. And we'll wrap it up with the last two types, namely with the framework providers, i.e., the companies that develop software that is then used by other software developers, tools for example, components, frameworks, or whatever. And then the last category, the tool providers, for example, database providers or providers of platforms that we as developers can use to integrate into our software. And I believe tomorrow DB will be there, Couch DB will be there, so a lot of companies that we can look at as examples, because I also have a forecast for them that doesn't go in a very good direction for these companies. How correct all of this is, we can, of course, discuss again in the comments. You are welcome to write how you see things and, above all, of course, which industry you belong to. Are you more standard software development, are you more in-house development, do you develop tools, or whatever you do? Tomorrow the conference is exciting because it's the biggest developer congress I've ever been to, and I think it's unique throughout Europe. Worldwide, there are two other branches of the World Congress, one in India and one in North America. And I was extremely impressed last year because the sheer number of exhibitors on the one hand is overwhelming. Every company that has a name in software development is really there, and above all, the number of participants is simply fantastic. Last year, 16,000 were announced, and I'm pretty sure they were there. It's a huge exhibition center with two large halls with an incredible number of stages integrated into them. I'll show you a bit of that tomorrow. I'm packing my things now. I'll connect all my camera equipment so it can charge until tomorrow. You don't see that. It's spread out everywhere here, because it will be a strenuous day. Not only tomorrow a workshop and a session, but we also have to put the video together somehow, and that will be extremely stressful. I'm packing up, going to bed, we'll see each other again tomorrow morning, and then we'll drive to the trade fair and look at these things and the event and clarify where companies are running into risks and where they need to act. I'd say good night. [music] [music] [music] So, arrived [music] at the conference. First of all, very important, we have to make a few assumptions in this video. You've discussed in the last videos whether the efficiency gain is all correct, what the factor is, what about the prices, bla bla bla. We'll leave that aside for now. We'll assume two different scenarios, and I'd say there's the famous Damocles sword. The first is a bit of the Damocles sword that is relevant for the first three types of businesses or companies, namely precisely this efficiency gain. We can discuss whether the efficiency gain is there or not. There are different statements about it. There are various studies that the efficiency gain is marginal. Various CEOs of UB, for example, say that they don't notice any efficiency gain in software developers. I cannot confirm that at all from practice. For me, it's the exact opposite. Of course, it depends on whether I'm working on a legacy project or a greener Greenfield project. Therefore, we assume the efficiency gain is there. The first type of company we'll look at are the offshoring/nearshoring companies. So, the companies that offer labor on a body-leasing basis, either from near or far abroad. And we heard a presentation here yesterday where the whole thing was described as "cheap hands." And this concept is indeed an older concept. We've been using it in software development for decades. On the one hand, we've always had cheap development forces, but on the other hand, we've also had extremely massive efforts in other areas to prepare the work that was then done in India, China, Vietnam, etc. And that is the effort to transform requirements, to send them from a domain where predominantly German is spoken to a domain that is located somewhere abroad. And I'd say software development has never been really strong in requirements analysis, and one of the big advantages of in-house teams has always been that the paths and communication channels are relatively short between the requirements side and the developers, and that must be taken into account very, very carefully there, and a lot of time, money, and effort must be invested in perfect requirements, in people who understand these requirements on the other side, but of course also in quality assurance on our side, where we verify things, where we do tests, where we control architecture and quality. But if developers become significantly cheaper, significantly faster here in German-speaking countries, then precisely this one final big argument for offshoring/nearshoring falls away. That means that this is suddenly a model that is no longer needed in this form or a similar form. And this is not science fiction. I am currently involved in three projects, and there we are trying to bring software development back. In two projects in Vietnam, we are bringing the whole thing back to Germany, and in one project in India. And even there, we don't know yet how much faster the developers here will become with AI, but the amount of problems that have always existed with offshoring/nearshoring development has burdened the teams I work with for years, for decades, and made the work very, very difficult. And the first field trials that we are now conducting with German developers using this software, which is being partially redeveloped, for example, because the quality coming from abroad was so poor, are quite convincing. In the last video, I showed you my experiment. Many in the comments acted as if it was my isolated experiment and wouldn't work in practice. No, it works exactly like that in practice, and I currently have numerous projects where we are implementing exactly this one-to-one, unfortunately also in the offshoring/nearshoring area, unfortunately because here in Germany or Europe we have a social system that can cushion something like this if a company in India or Vietnam suddenly finds itself without orders and has to lay off many people, but in such countries, that is not the case. And that, I must honestly tell you, is one of the most unpleasant things about AI at the moment. Precisely such projects where you know that we in Germany currently have no other option than to pull out of the projects. And in reality, you know that the people down there, who already don't have the best job prospects there, suddenly find themselves without work from one day to the next. Terrible, catastrophic, but that's just the situation right now. And while I see solutions and numerous possibilities for all other types of companies we'll talk about shortly, how companies can transform, I must unfortunately state directly here that this is an endangered model and that, in my opinion, it no longer has a real future. [music] So, the next type of company are the framework providers. Framework providers is quite broad. I mean companies that offer libraries in one way or another that we can use in programming. Classic examples are manufacturers that offer UI components, libraries, for example, DevExpress, Telerik, and all those. When we used to develop web applications by hand, when we developed WPF, Windows Forms, Swing, AWT applications, we often relied on using exactly such component libraries, because if we look at DataGrid, the classic example, it makes no sense and is not worth the money that would have to be invested to develop something like that ourselves, because it is standard functionality. This standard functionality is usually provided by such component manufacturers for multiple platforms and with a very extensive and, above all, tested logic behind it, which has already been used in many other projects. Developing something like that yourself, if you don't have the entire know-how in this area and would have to test and rework a lot, is often not a real option. So, and here, for example, at the DevExpress conference, there are some manufacturers who used to offer such component libraries, but you can see that they are no longer promoting them at their stands, because in my projects, for example, one of the first things that fell victim to this AI thing was these libraries, where we used to have a large part of the controls on the UI, for example, developed by third-party manufacturers, but then at some point had to or were able to develop it ourselves. What are we realistically talking about with these standard things? These components usually have an incredibly large range of functions. But what you really need is only a very small fraction of exactly this functionality. And this efficiency gain of AI is also visible in many open-source areas, because especially the component libraries in the Blazor area, for example, I'm very active there, have received an incredible boost in the last one and a half years, because an incredible number of new, very extensive controls have been added. A colleague of mine, a former Zubi Jan, recently developed a complete component library for Blazor with AI integration, etc. Something he probably would never have done before, and a component library that is now open source. I'll put the link in the video description, which you can use in your projects, and this is especially true for open source. Of course, it has many disadvantages. You read a lot about it, that they are drowning in push/pull requests because all sorts of nonsense is committed there, but they benefit a lot from it, and I think this is also the final death blow towards component manufacturers, and in the experiment I showed you two weeks ago, it wasn't similar either. I used to use component libraries, but I don't use them anymore. I had the controls developed myself. I used to use numerous component libraries for reporting to generate my invoices, my certificates, my offers. Now, more or less, everything is created in HTML, rendered in HTML, and then exported to PDF. I no longer need component libraries for that. And just the license for that, for example, would have cost me about €1500 per year if I hadn't received it for free as a trainer. And you can also feel this at the conference here in many places, especially when you talk to participants, that they all say that exactly this is one of the things they noticed first, that they can resolve this dependency on such companies, and above all, they are also much more creative and have things built into their controls in a very, very short time, which would never have been built in before, and which standard providers don't have in their portfolio at all. But you also see that many manufacturers here have shifted their business model. Away from the things that can be generated with AI themselves, these usual controls and component libraries, towards real added value, real services that cannot simply be provided with AI. In reporting, for example, they are increasingly moving towards reporting servers, i.e., really highly complex constructs that have to be supported, maintained, etc. in some way. That is the straw to grasp at, this or other types of services, to which many are currently clinging, where many seem to be shifting their business model. [music] So, after the first Damocles sword, which we just discussed, i.e., the efficiency gain that comes with it, the second one is added, namely the topic of Vibe coding. And we already have a long tradition in software development of trying to find the technology that allows us to create applications without software development knowledge. In the past, it was something like Excel. Today, there are solutions without which our industry, our entire global industry, probably wouldn't function. I'm still waiting for the nuclear power plant that is controlled by Excel and Exo. Um, but now, after the flops with No Code, Low Code, it's actually No Code, the next variant, namely exactly Vibe coding, i.e., the development of applications without any knowledge of software development, so that, for example, in the business department, you can directly develop an application that does exactly what the business department wants. And after all the approaches we've had in the past, where you always had to say, yes, but that's not possible, and at some point other limits will be reached because you'll need a real programming language, etc., you have to say here with Vibe coding at the moment, first of all, you don't know, you simply have too little experience in this area, but it seems to work reasonably well for smaller applications at first glance. That means people who have never developed software are starting to write larger applications, and you might say now, yes, those are smaller applications, that's nothing serious yet. No, it isn't. And this is no longer a future scenario, it's already reality. In the last three to four months, I've received numerous inquiries from companies that have no idea about software development, but are still starting to replace large parts of their software with their own products. For example, I have a customer who had their ERP system, their CRM system, and the shop system. The shop system is actually the core application in such a company, if I'm doing e-commerce, they had it completely developed to save the costs for Navision, for Dynamics, and for Shopware, Shopify, Shopware. And this seems to work at first glance. And as I said before, this whole No Code, Low Code, Excel approach was always functional, but in the end, we found out, yes, it's a shitty idea, or many things could have been seen from the beginning. But if I look at this share of Vibe coding now, I have some argumentation problems, because I'll tell you honestly, the volume of applications, the size of applications, and the functionality of applications, and the satisfaction of users that results from it, speaks for itself and speaks volumes, and it's simply too early to make any statements from a software architecture and quality perspective. A month ago, we looked at an application that was completely Vibe coded. The managing director who developed it didn't even know with which language. When I asked with which platform, he said, don't ask me such technical things. And we then looked at the application, it was a .NET application with Blazor that was chosen, and I looked at the source code, the architecture. The project had been developed for over two to two and a half months with Vibe coding, and the structure was not a one. It wasn't a two either, but it was somewhere between a 2 and a 3. So it was a perfectly acceptable solution, and it's not like many claim that AI produces total bullshit and the source code is terrible. When you start from scratch, a consistent architectural model develops more or less on its own, and whether it's always the right one is, of course, another matter entirely, but the point is, the source code I looked at in every situation was actually such that I could maintain it, and as I said, the approach is simply too new. We have too few software products or projects that we could look at to really form an opinion. But I strongly assume that in the end, with AI, when I implement new functions at the beginning, it always sends out such explore agents first and looks at how the application has implemented it so far and then implements it anew. And I strongly assume, and I'm already seeing this in initial projects, that if the structure eventually becomes so messed up that it's no longer really human-readable, then it will also become more difficult for the AI to understand how an entire application works, and then it will start to introduce errors. But as I said, in the five or six projects I've looked at that were Vibe coded, I haven't seen these problems yet. But as I said, they weren't huge applications. We just have to give it some time and see how it develops in the future. In any case, you see it in more and more areas. We'll get to the three customers shortly. I see more and more, both with my clients and with companies that do Vibe coding, that instead of going through huge loops and spending a lot of money, they prefer to develop these things themselves and end up, which is also what I'm always surprised by, with applications that are architecturally and qualitatively, apart from the function, in terms of what the business needs, simply very good, because those who have the problems, who need the functionality, who have to solve a special problem in business, are precisely the ones who develop it in the end. [music] [music] And with the second Damocles sword, we also come to the representatives, most of whom you probably belong to, namely those who offer software services, i.e., those who develop software on behalf of customers in some way. And there we simply have to accept the reality that the development of software, leaving quality and architecture aside, has become significantly easier. That means the entry barrier for software has gone down very, very far, and now allows people even with little computer science or programming knowledge to build such software applications in the end. Now, of course, the point is, the more people can do this, the more people can perform this craft, although the people who do it are not performing the craft, but the more people can now produce software, the more capacity we naturally have on the market. That means, the cheaper the prices will naturally become. On the one hand, because we will have an oversupply of capable people who are able to build programs, I call it not software development, and on the other hand, of course, because, as we said in the first Damocles sword, we are significantly faster in the end with the entire software development. The more people can now develop software, or the more people can create software applications, let's call it that, the cheaper the prices will naturally become. In addition to becoming cheaper because of the oversupply, we will also become significantly faster. That means, in sum, if we were to put a price tag on the entire software development, we would probably see that the costs for software in general would fall sharply. I would say that software development or software products themselves are premium goods, but due to this shift in AI, I strongly assume that in the coming years it will definitely become the case that we will not go into a cheap segment, but we will see that the costs for software production, and thus also the license costs, because that is demanded by customers, will also decrease accordingly. If we take an example, a service provider with 20 developers, for example, then with these 20 developers, they could previously do two projects. These projects had to be priced in such a way that they could pay these people. In the future, however, it will be the case that these 20 developers will perhaps have ten different projects, and now two people walk through the picture who weren't seen by the camera. That's how it is. He stops, smokes, I like that. The camera can't be seen. That means, in the future, we will have these ten projects, for which the companies receive less money because software development is becoming cheaper, to generate more or less the same revenue in the company in order to be able to pay the existing staff. That means, in order to work cost-effectively with the company, we need to acquire more projects. We need to ensure that we work for more customers and carry out more software projects in parallel with these 20 people. The big problem now, however, is that currently, I hear this even from my clients who are software service providers, orders are breaking away on a large scale. Orders are breaking away, of course, on the one hand due to the current economic crisis, we don't need to sugarcoat that, but even from their customers comes exactly this statement that they no longer need feature XY or extension ABC, because they now have capable people in-house who can do something like that themselves and develop something like that themselves with Cloud Code or Codex. What is important from my perspective for these software service companies is that in the future we will see a very strong shift in these companies from my perspective, namely we are no longer providing typing work, no pure coding work, but the remaining aspects of software development will remain: the collection of requirements, customers who don't know what should be done, the provision of these applications, deployment, operation, and sometimes even support. And software development now with Vibe coding or with efficiency gains, we can build large applications relatively quickly, but in the end, we still need some trusted person or trusted entity with whom we can talk about the provision, who discusses the requirements with us, who carries out this eternal work of asking the customer questions until we have a reasonably clear picture of what software development can be. And not least, of course, the topic of quality assurance. Besides requirements, in my opinion, quality assurance will become extremely important in software development in the future, because regardless of whether with Vibe coding or with proper coding, if we use AI, we create incredible amounts of incredibly large functionalities that are integrated into these applications at tremendous speed, and building them in, generating them, is one thing, but being responsible for the functionality and being able to guarantee afterwards, yes, that actually works, that's another matter entirely. And yes, we can generate tests with AI, but there are definitely limits to that too. And just the surface functionality is only one perspective. That means, in my opinion, these companies have to work most strongly on their strategy and have to ensure that they are future-proof and take advantage of this drive right now, because now we are relatively at the beginning, now it can only be done, but often it is, the larger the company, the big oil tanker, you know the quote, the more difficult it will be to turn this big oil tanker around in a storm when it really gets going. At the moment, it's more of a gentle breeze to turn around, but I actually already have clients who have big problems getting enough projects to pay their people. So a gentle breeze might be an understatement, but here and there it's already a bit of a stronger storm than just a breeze. [music] [music] Next stop are the standard software providers, i.e., those who operate a standard product that they then sell to customers and then earn their money through maintenance contracts, licenses, and of course customer customization. And the argument for standard software, why it should be built, why one should build one's own development capacities, invest the money, when on the other hand one can buy a product that already offers the same functionalities, which have been tested over years and decades and with which one would achieve the goal just as well, only much cheaper and with less effort for maintenance, deployment, etc. And in times of AI, the question is of course completely valid to say, okay, on the one hand we have extremely high costs for this standard software, and on the other hand, of course, an extremely high dependence on this provider. That means, with AI, we could also go ahead and develop it ourselves. That's a valid approach at first. I've already mentioned two or three examples where my clients have done exactly that and Vibe coded it. And by the way, it's not limited to Vibe coding. Of course, we also have companies that are now building small development capacities and can build high-quality applications accordingly with Harness, etc. One of the things that is always forgotten in this context with standard software, solving it with AI, is that we can of course copy functions with AI, without a doubt. We can implement them more or less. But standard software usually lives not only from implementing Forms over Data, i.e., databases with a few forms on top, but from business processes. Business processes that are common in the industry and have grown over years and decades in standard software and have therefore also achieved a certain maturity. And precisely that is what we don't get with the approach of AI new development or Vibe coding in the end. The same applies to maintenance, operation, and support. If I now go as a software developer and develop the whole thing with AI, then at the end, someone still has to take on exactly these roles of deployment, maintenance, operation, etc. If we now look at the companies, I would say, based on the trend in the last half year, that companies offering small standard software are definitely massively threatened. Even with the larger ones, it depends on what end-customer segment you have. First of all, regarding the small tools. I always have my favorite example in the experiment I showed you two weeks ago, for example, with my old software, I always used the software-as-a-service calendar so that you would get a link from me, see my calendar, and book an appointment. I think I paid €20 a month for it, and because I didn't want to pay the costs and because the API didn't offer what I needed, I had it developed myself with Cloud. It took 15 minutes, I had the functionality I wanted directly in my software without any revenue. And for such companies.

This is already a massive problem. Um, exactly, um, that customers are starting to replace this software with their own development. But for large companies, it can also go in a similar direction, because I'd say, if you now have a large standard product, but have many customers who don't use the entire standard product, but only small areas of it, because these small areas you can then see as a small tool and the customers can then develop them individually for themselves again. But also for those who really have large customers, I'd say those who have a large standard product, of which the customers use everything. One of the things you always have to keep in mind, you've seen the AI development in recent months, in recent years, it's simply incredible. It's getting stronger and stronger and I see absolutely no end to it. That's why I also see the industry at the end of the day facing similar problems, because it's getting faster and faster, because it's getting better and better, and at the end of the day, these industries will also face similar problems at some point. What you've also seen repeatedly in recent months, what I myself have experienced in meetings with their customers, is that price pressure is increasing, that companies are coming up with exactly this argument, that they would have the possibility to do it with AI or they only hear how cheap software development is becoming with AI and that they are already waiting for license costs to rise significantly in the coming months, in the coming years. Whether this is justified or not, of course, always depends on something else entirely. How do you get out of this whole situation? There are various approaches again. The most exciting approach at the moment, which I'm currently trying to implement with two clients, is that we say, okay, we have a piece of standard software, but you can adapt this standard software for yourselves, and that with the help of AI. This means you simply build in a module where we can essentially code with the help of AI and thus extend the application. This means that you are currently taking the wind out of the sails of many of the customers who come with the argument of AI development, web coding, etc., and saying, yes, you can adapt parts of the application with such a form of web coding, but at the end of the day, you still have the business processes established over years and decades underneath, and can rely on our maintenance and support. As I said, there are other approaches, but this is the most interesting one, I think, at the moment. [music] So, the last option is in-house development. If you have a department in your company, in your group, that develops software, which is more or less used in-house for departments or for any business processes or whatever else, and this is now the first instance that wins in part with this whole AI thing [clears throat], gets new possibilities, because of course one of the central problems that in-house software development companies always have is that they have to make make or buy decisions. This means that a new software product is needed in the company, even though there is a lot of know-how, you then say, okay, should we really develop it, should we take on this burden, we don't have enough developers, we don't have the capacity for it. So you come to the decision, okay, we'll buy the whole thing and not let our internal development department do it, they already have enough to do. And I'd say, if we make these two assumptions, that software development is becoming cheaper, that it's becoming faster, then of course completely new possibilities arise for in-house departments to do more, to do it faster, and for the companies, of course, to develop the whole thing more cheaply in the long run. But one of the things we've had for I don't know, a perceived eternity, is so-called shadow IT. That is, even though we have an IT department, many IT things happen in the company, many products are created, many processes are established, which actually belong to IT, because maintenance and operation are done there, but in reality, they are initiated in the departments because they need a quick, dirty solution. And so hundreds of thousands, billions, probably of different Excel files and Access files exist. We've already talked about that, and I'd say the example that a large part of our economy worldwide is driven by Excel and Access is probably not far-fetched, because I think one of the biggest problems we've always had with shadow IT were tools that offered a very low barrier to entry to map functionalities IT-wise that we need in the department. And with that, we now have completely new possibilities with coding tools with Cloud, with Codex. Large, huge applications can be built there, which are very good for the departments on the one hand, but are of course a risk for the company as a whole, because maintenance is not clarified, deployment is not clarified, whether the code is good, whether the structure is good, whether anyone could ever take over at some point if the AI is actually at its end. And if I now look back at the last six months, if I look at the larger customers where we have exactly in-house development, the whole thing is transforming a bit. We are moving away from models where we develop software that is more complete, i.e., where we deliver the interface and the backend to the department, but the focus is currently more in the direction of, on the one hand, providing very stable backends with REST interfaces, for example, which provide the most important functionalities, and then we enable the departments to individually, so to speak, put their application on top with web coding, but always protected by a framework that we have developed in the respective departments, so that it is ensured that each department can develop its own application, but it is developed with our framework in the end, so that we can control the quality and the structure, and at the same time, deployment is always agreed upon, so that you say, okay, this is how we provide it, and then also regulate the corresponding operation or that we can make the damage classification assessment for the software and so on and so forth. And I find this idea extremely exciting, because developing backends is usually something very technical and abstract. It's not directly possible for the departments through requirements, but the interfaces are. Building them exactly as they want them is really something. And if you look at the combination of these stable backends that are underneath and then the very individually designed frontends that are placed on top by the departments, that's something that, as a software developer, really makes my heart sing, because the combination of it and the results of how the departments work with it, they simply speak for themselves in those areas. So, and while we're chatting and making this video, I just realized that my session is starting soon. That's why we'll do the session first and then we'll take care of the final conclusion and the outlook on how things will continue. So, what do we learn from all this now? What do we take away? This was the largest developer congress in Europe, in the world. I actually wanted to question it, but I didn't. It was big. 16,000 developers, an incredible number of decision-makers, an incredible number of exhibitors, and the topic of AI was, of course, also omnipresent again, and I've had a whole lot of conversations in the last two days with various decision-makers in particular. We have an area at the front where many decision-makers are located, and the surprise that could always be read on people's faces when you talk to them about business models and tell them what's coming for them, that's simply indescribable. Many people always accuse us software developers of approaching the whole AI thing too passively, of sleeping through trends, of not taking things seriously enough, of needing to deal with them more. But here I was a bit surprised at how little companies are actually doing. In the last video, I learned again that many of you interpret things or try to find fault. Perhaps we should just try to focus on what is actually really important in these videos. This has shown once again that there are very many companies out there that know about AI, use AI, but don't really take the true consequences of AI seriously. Whether all of this will turn out as I've predicted here, of course, you don't know. I've already told you in videos, there are no AI experts right now, not even at this conference, but the trend is unanimous, the opinion is unanimous, that a lot is coming for companies. And no matter who I spoke to here, I don't think anyone said that their company's business model will remain the same in the next 15 years. Much more, many people were surprised at how they actually missed this trend and how, at the end of the day, they are not prepared for what is coming. What consequences this has for you, which industry you belong to, I've already said at the beginning, feel free to write it in the comments. But not only you developers have to reorient yourselves, not only you have to rethink your job, your description, but your company and the entire strategy behind it, because let's be realistic, this is also a part of the unknown truth that I actually don't want to speak out. Many companies that we have out there right now will not survive this. Perhaps because their entire business model collapses, because they decide too late to counteract it or to jump on this train. It will cost jobs just as it will cost jobs for developers. Now I've finally said it, it will also cost companies, and I'm already seeing that. I'm already seeing numerous customers who are dealing with declining orders, who are seeing entire products disappear, as I said, who are a bit smaller, etc. And my request to you, whether you are a developer or a decision-maker, you can gladly send it to your boss, just question it. See how you need to position yourselves. The point is, you have to position yourselves. Software developers must take AI seriously. You have to position yourselves, €9 job, to be able to use this new tool, this new instrument, AI, correctly. But companies at least as much. And I would say, for companies, it's almost too late rather than for software developers. And what I also don't understand again and again, conferences like this one, the Developer World Congress, a very, very great thing, I must say. Last year it was already great, again great. The number of people here, the amount of opinions, the amount of exchange. I said it last week after DWX and I'll say it again, what I've learned new here, the new perspectives and so on, even for me, who does a lot in the AI field, it's simply incredible. So again, hats off to all the organizers here, to all the people. Everything's fine, go ahead. [laughter] Everything's fine. Hats off to the look here. I even have a Red Hat Head. Totally cool. Hats off to the organizers. Another great event put on here, and I tell you again and again, both for decision-makers and developers, go to such events, because you simply have to experience the perspectives live, exchange opinions, especially in times of AI, and that will be the case again next year. And this was just another great experience, but on the other hand, also a shocking experience when you look at how clueless some developers, we'll make a video about that too, but especially the companies, are starting into this AI era and are not at all concerned with the risks and consequences. I hope you enjoyed the video and got some insights from the conference. I'm heading home to Winterberg now, a long drive. I'd say, see you in the next video and bye.