Adopting an AI-driven software organization is hard | Marko Klemetti

Thank you thank you everybody I'll start with a claim so I will claim that developer experience and AI driven development are the two key initiatives for the future of software development and allow me to explain So currently we are in a place where we try to kind of push both from different directions so we have the a driven development helping us with the development and then the developer experience platform engineering pushing from the operation side and now we're gotten to a point where a dear colleague of mine Yan who might be here or might not be here he said that why do we use AI driven development to write code to tell stupid computers what they should be doing and we already know that where we are at the point with development is it's indeed helping us write code for itself or stupid computers and we already know that this is due to change in the future so what aiid driven development will push us to do it will automate beyond our current imagination and I see that in the same way platform engineering developer experience will do from the other direction so allow me to demonstrate let's see so I always say when doing any live sessions or live coding or whatever I fail alone but today we can succeed together so let's see what's going to happen so um I've created an application template it was like a this weekend was super Grim it was like rainy this slushy you know Finland I had my morning coffee I hadn't been coding for a while and I was like I'm going to be on stage on Tuesday I'm going to code something so I made a react application template to kind of show what platform engineering could be and how AI driven development helps there so the the code itself is like relatively simple I've only used AI to generate any of it and I'd love to walk you through more code live whatever um just to show what happens is ah good the code that I already had appeared again no um and then I borrowed from TV2 so last last spring in t do London we were on stage with Emma and we were talking about the TV2 is platform engineering and they've made a CLI and I'll come back to this later but I also wrote a CLI it's called T do CLI and what it does it's my platform engineering so let's create a project let's call it Copenhagen T dock I'm using the template react application template almost almost there and then I'm going to use a domain so when the new domains were released I realized that there is one particular domain that interests me and is still free and it's of course T do hopefully works and let's try so I don't know what's going to happen so it creates a repository based on the template it clones it and then it creates a project in versel and those who haven't used versel I encourage you to because if you have been doing developer platforms or similar uh in your is versel is kind of showing the way where you should be going with it so it created Copenhagen T dock here and let's open the link oh no deployment not found and this is for me of course this is this is the worst moment because currently we're in the moment where only I can fail but let's refresh I have a page [Applause] W so using platform engineering starting from a template releasing an application to domain T do. hopefully that works now you get your cameras out you scan the QR code or go to T do. hopefully. Works and we'll see if it actually works or not oh amazing amazing So I myself was Voting with the QR code you can already see I was trying to think which side it should be so that where it would end up okay so here we see when coming into this session of course I primed it with AI and you're currently voting and way more than I thought by the way and you can see the votes pouring in already all simple code if you go to GitHub Marco react application template you'll find it there this is literally less than 50 lines of code and yet there it is good so for those who don't know developer experience is an overall experience developers have about their work and today we've been talking Lots about developer experience but there is one particular thing that I want to say out loud because I'm taking the company's perspective here it's the productivity so you saw already I spent 2 hours coding an application on Saturday morning with a cup of coffee I made a template out of it any one of you can do what I just did in the same amount of time time that I just did so productivity and of course there's lots of other things in the satisfaction and engagement and especially Dan and Emma work talking about how the platform engineering helps developers but always when we're going to the Future think of it more as a fundamental change in how we actually create software coding will be Sudoku it will be something that we'll be enjoying doing in the future as well but both of these directions will be pushing it into smaller and smaller low role in the organization good now into the topic of my talk so I'm going to go through three failures of organizations of today so when they start doing things like these why do they fail and the first failure is implementing AI driven development did not yield the results that we expected two years ago one year ago I was on this very stage and I said AI co-piloting will help developers be 55% faster and to be honest on Saturday when I was coding the application for your enjoyment here I did spend only like 2 three hours to make it which means that I really did spend more than like save more than 80% of my time but it was my individual time I was working on it alone we see that organizations who have R&D usually spend at most 10% of their resources into coding and if you go and make it 55% faster you'll be Max 5% faster as an organization and usually it's even less than that if we go and look at the organizations further we already know that the managers have defined these AI driven development and developer efficiency as their top priorities and yet they don't even know what that means let alone that they would be able to measure it in the organization like I have nothing against surveys but when we go and look at the productivity survey is not the only way that we can do it like I'm rather I say survey does not show those kind of results alone it will so show the satisfaction if will show the engagement it will give some signs of productivity but in all honesty you have to put in place more metrics than that and yet with everything that we here talk about developer platforms organizations haven't actually implemented them very well which means that we still see the the regular developers spending most of their time with the tooling that they use and one interesting fact which I want to raise out is 55% of the code merged into main lines or the the main code has vulnerabilities that are found only then and now if we take some learnings from some of our customers on in the manufacturing uh and Automotive these are kind of like combined results I want to bring three out when you have your co-piloting expectations at 55% you make a survey and you ask was it 55% Improvement everybody will say no but what we found is that most of the people working with AI driven development will say that yes it saved me 3 to four hours per week which is 10% and 10% already for any organization is a huge Improvement so implementing AI driven development is kind of it's something that that's very natural to do if you can expect three to four hours per week it's it's very significant second thing that we've noticed is that the developers end up writing more compliant and consistent code so if you plug in let's say tools like sneak or black duck or the gitlab security tooling you will quickly notice that when you use Aid driven development AI assistants are today already trained on models that help you create more consistent code so the code is better it's less complex it avoids some of the security problems that you would introduce yourself and it's kind of a metric that you didn't think of at the time when you just brought co-pilot in it's something that's come as a natural surprise on the background and a third thing I want to raise is that of course when we talk about the platform engineering and AI driven development reducing the need for coding and maintaining tooling and tinkering it will be for traditional organizations a big shock and especially in Continental Europe organizations will need to have approvals from the worker unions to be able to use these kinds of tools in the future so we've already identified that we're on the brink of a big change and the old structures don't necessarily support that as well good next failure we're unable to scale new technologies and initiatives ac across the whole organization and the organizations who try to put for example developer platform in place or the organizations that have just said that here's your selected a driven tool and go ahead and use it they quite soon notice that part of the organization did part of the organization didn't one of the big reasons for this is thank you Stefan Dan for the slide by the way um is that the development centr decentralizes so developers aren't put into functional categories or functional teams they are in cor functional teams they have to work with m multiple components multiple different parts of the application infrastructure you have in your organization it's becoming more decentralized and developers have more as we've said cognitive load and they have to be able to understand more kind of connections around to be able to create features while at the same time we see that the tool chains are centralizing so instead of the teams running their own tool chains the trend is trying to bring the tool chains back together we've now 15 years in devops and there are literally hundreds of tools that big the bigger the organization the more tooling they have and the direction is getting too centralized yet somewhere along the way it kind of stops and if I pick an example from diimler truck um in 2001 Mercedes-Benz and damal truck decided to part ways they become two different stock listed organizations and dier truck was told that you can use the Mercedes Benz tool chains for 3 years and then on you're on your own so what they had to do was that they had to build their own tool chains their own tooling environments based on what they had but because they started a fresh they real I that they can actually do two things bring all of these like Jas and gitlabs and githubschool where you are future proof and what happened was they really did reduce their application landscape by 40% so what they were able to do is scale the tool chain into the organization because they had to most organizations don't have to they don't have the feeling of urgency they don't have the feeling of must which means that it easily land short then a third one there's always a new tool to fix the problem but our people aren't using the ones we've already introduced and this is something that I often see for example when creating tools like the platform engineering CLI or you have a backstage running somewhere you want to use that kind of an environment for your all all of your organization but people don't move there easily so let's take a look at something you've surely all seen before the technology adoption curve following from the innovators early adopters all the way to late majority and lard and in talks like these like the one I'm having here currently and the ones that you will listen today you will see that most organization organizations focus on the easy part of implementation the easy part of the innov ation curve the adaption curve you'll see that when you go to the innovators an early adopters with the clis that you've created you say that we have these kubernetes clusters here you can just start using them earlier with Helm and now with backstage or some other tool they will be like this will help my day so much and you can focus on developer happiness you go to them you ask them what kind of tooling they would like you create that tooling for them they start using it and you have a happy group of people within the organization however it's a known fact it's a minority minority in that organization the problem comes from the late majority and the lards and there the way how you start doing the changes similarly as what diimler did as well so you build functionalities within your automation let's call it platform engineering or developer platform and you make sure that you focus on productivity so you make it easier for the developers to use that tooling you make them Faster by using that tooling and you then you add a certain level of control and it doesn't mean controlling these people it means the same way as we used to have continuous integration which started from from a basic build you did a build for your team for your developers and when you started adding new tools into the continuous integration it was already pushed into the automation stream that you had like if you added security or lining or unit testing it became a natural part of the stream that your people were already on and today the challenge is how do you change the parts of the organization that are reluctant to change and there are two ways the other way is that you put in place the control and the other way is that you force yourself you force the whole organization to change we've been talking about the developer platform and I'm going to take a small stab at it myself as well um this is also a very natural place to push all of your new Innovations and we've been talking about the aien agents for example today and you'll probably hear some more about those as well developer platform is a natural place similar to the traditional continuous integration Loop to abstract it out and provide it to your developers as a service to kind of find a way to have the control and the productivity and then you provide the Ser like you provide these tools as a service essentially but once again the same way as developer happiness for organizations it starts from the efficiency because then the efficiency drives also the budgets and investments into changing the organization this is also thanks to uh our dearest Oh's team uh past and present so when we look at how organizations today even while you would call it a developer platform how the former kind of the way we thought of devops was like the the teams are decentralizing you have your infrastructure you have all of the complexity there and then you say you build it you run it the same essentially similar way as I just did you build it you run it but then it's on your responsibility and the abstraction that has been built with developer platform on top of that is something I want to also as said I want to show give you a picture slightly different kind of a picture of what developer platform should be as of today so you've heard of hopefully team topologies if you haven't then find out the point is you have one part of the team topologies is to have a platform team which is providing services to developers and considering developers as customers then you have the developer teams and instead of just having the U build you run it you build a platform where you have the reusable components so you already saw you already saw my uh react application template which is something that I said it's public you can go and pick it up and some people want to have it as so-called inner Source you have them as reusable components design system from ikas presentation if you were there is a super good good example the tooling so AI driven tooling what all of the automation all of the infrastructure automation you would provide through this kind of a platform but then the other part which is as important as all of these like reusable tools is building the knowledge base and building the service Management in such a way that you at all the time you aim into making implementing a system like is easier for the organization than what's the Alternatives I had to include a screenshot from TV2 I asked for permission although this is this can also be found live uh on the internet and here's the TV2 here in Denmark they kind of platform engineering CLI and this is how it looks it's very much much similar to the one that I showed you I just used all of these cloud services to make my life easier but in serious organizations of course you would have the same context but you would build it into your own domain and you could have like I can deduce that there's kubernetes and and probably some terraform here and there and then Helm charts in play but the concept is same it's made for the developers from the developers point of view making their life easier good so as a summary of my talk today we now know that AI driven development the platform engineering developer experience are making developers life much easier it's changing the way we're working as digital organizations the changes happening it's of course everybody's own responsibility if they jump on board or don't but there are four things I want to share to you the first one is usually the benefits might be somewhere else than you thought as I said if you only send surveys if you only look at door metrics if you only go to co-pilot API and see how many pool requests were done compared to the previous ones you're probably not seeing the big picture what actually is brought with these kinds of concepts of tooling the second key thing is to to make these ways of working more easier to use than the Alternatives and I said like continuous integration is a super good example because once continuous integration is implemented you never want to go back into manual building the same kind of a way of working applies here as well whether it's aan development or platform engineering or providing infrastructure Automation and then the third one is when we have the technology adoption curve the innovators are easy the bigger the organization the more people you have there that have already solved these problems for themselves making it centralized only serves that group of people unless you go and make the big change within the organization and of course it's easier said than done but the way to do it is by balancing the autonomy and stand standardization so making sure that the people on right can work in the ways that they feel most comfortable they already know what they're doing and then bringing the same platform with a mild Push by control to the majority of the organization and there the last one is if you're not making it mandatory for the organization you have to find a way to make it mandatory this change will not the same way as agility this change will not happen by itself maybe last thing to say about the innovators in the organization so if you build the AI driven development the platform engineering within the organization in such a way that you're never surprised then you've done something wrong thank you [Applause] [Music]