Robert Hoffmann, Christian Denich: Forget Developer Platforms, Think Developer Productivity!

This talk features Robert Hoffman and Christian from Amazon Web Services discussing the concept of developer productivity in the context of platform engineering. They emphasize the importance of a developer-centric approach in building developer platforms, shifting the focus from traditional platform management to enhancing developer experiences. The speakers introduce the developer experience (devx) framework, which highlights dimensions such as feedback loops, cognitive load, and flow state, all integral to measuring developer productivity. They also explore the role of generative AI in improving developers' workflows and productivity, suggesting that coding companions can aid in various stages of the software development lifecycle. Ultimately, they advocate for a shift in mindset towards understanding and enhancing the developer experience as a means to foster innovation and reduce unnecessary workload.

[Music] hello everyone welcome to the second talk of today and in the session we will have Robert Hoffman who is a Senior Solutions architect and Christian who is a senior customer Solutions manager both at Amazon web services and they will talk about forget developer platforms think developer productivity so gentlemen if you are ready I'll leave the stage to you thank you and hello everyone uh so I'm

Robert I'm a Senior Solutions architect and I have Christian with me today as well and uh yeah as a title title implies we want to talk about platform engineering but what we really want to do is thinking about hey um how what is a better way to actually build uh uh developer platforms how can we be more customer Centric and when we say customer Centric we really

mean developer Centric right because developers are your customers for that developer platform and you want to give them the best experience and especially you want to give them them what they need now during this talk we will see that the definition of what is actually productivity um what is developer experience which is closely connected we will see that um there's really a broad um scope of things

you need to think about when thinking about the developer and that scope will also lead us to discuss uh gen tools and that will be the part of Christian to show you how can we actually make development much easier uh with cool gen uh Companions and we will go Way Beyond the like coding things uh you typically see uh and we will really see how uh gen

companions can help throughout the whole life cycle of the develop so let's Jump Right In so the gist of the talk uh is basically saying well let's do not lose yourself in like traditional platform engineering where you build a platform but you really operate uh a lot of software on your own in your platform teams which takes up a lot of time and instead you would focus

more on integrating readymade services that are already available so you have the headp space to actually think about developer productivity and um in the rest of the talk we will dive deeper into uh what is developer productivity actually how could you actually measure it what are good proxy metrics for that but before we dive fully into it uh let's take a step back uh so how did

be get here in the first place so there's this guy Thena fogles and that's the CTO of Amazon and uh in 2006 so quite some time ago um there was like an interesting interview with him where talked about how uh teams at Amazon actually build and operate products and essentially what he said is well he thinks a good way to to build it is to also run

it um and that catch race you probably heard it before right you build it you run it so the idea is really that developers should be in contact with a day-to-day operations of their software and he thinks this is really like critical feedback that you need uh to improve your service and also somewhere around this time maybe one or two years later the whole idea of uh

also devop started so um kind of adding to that the idea of devops is to hey how can we move Developers and uh development and operations closer together to also have tighter feedback loops and improve our services so that's all great right um but fast forward to today this just this little issue here on this uh post stamp you see on the right um and that is

uh complexity so just as an example I have the cncf landscape here but I do not really want to throw CN CF under the bus that's that's a talk for another day but essentially what you can see here is um there's a lot of stuff to think about as a developer when you create a new service you have a lot of cool capabilities to build service to

test them uh to roll them out to make them highly available with kubernetes and a lot of other cool services but uh it's it's still uh a lot of cognitive load for the developer to figure out all these tools and maybe even run some of them and this is very really where platform engineering comes into the picture of saying okay uh we want to make this easier

for developers uh we want to open up that ecosystem for them um and basically remove that EXT strainless cognitive load and help them to be more self-sufficient with these Cool Tools so okay then great let's build a platform and I'm just showing here like a highle picture of our developer platform could look like um this is again from a cncf platforms white paper um there are a

lot of pictures that look more or less the same so you see that you need a bunch of capabilities for developers uh to actually run applications so you see like infrastructure like compute and networking they need to store data in like object stores and databases they need some messaging um and they need a lot of supporting services so we see identity management uh we see service binding

artifact storage um observability tools all these kinds of things and then on top of that you also want to make it easier for developers to actually use that stuff to find that stuff um and that's where you have the platform interfaces and there you see things like just plain old documentation templates um maybe even uis like backstage or special apis and clis that really help to use

uh the bottom layer of these capabilities that's all great but what we sometimes see with customers is that you can lose yourself in building the perfect platform here so essentially um you you have your you know textbook platform of how you want to build it and you start building a lot of services you start running a lot of services and you kind of lose sight on focusing

on on what your developers actually need so some of the let's say signals we sometimes see that show you that it goes into the wrong directions is what I would call the downward spiral of platform engineering and essentially you can see it from the very far already and it's typically uh being uh in a state where your platform team runs too much things and also runs the

wrong things and wrong things meaning here that these are things uh that your developers don't really need the adoption is not super high people like to use different services for that if you leave them an option so you kind of lost your way a little bit and if you zoom into that um in detail it all starts with you know kind of prioritizing the wrong work streams

and and features for your platform and from there you kind of starting start Reinventing the whe by Building undifferentiated Services so uh you you build the typical Stu because you do not really know better and this typically happens because you're not close enough to your user to your customer which is the developer so uh some some typical issues we see is that platform teams or engineering teams

not talking enough uh to developers to figure out what's actually the biggest friction Point what uh what problems are developers really facing um and what's the best way to solve it maybe even a in a very Scrappy way right without boiling the ocean um now you go further into the spiral and the next thing that's happening right you build all these undifferentiated services and you're running them

so now you're spending most of your resources on that and um sometimes we hear a lot of frustrations from platform engineering leaders who are saying well people are asking me for new features and so on but I really I don't have time I just need to you know keep the lights on with the stuff I already have and feels so frustrating because I want to help people

but I'm kind of caught up and already running the things that that I have already um and then from there it's also um something that that we see from time to time is that these teams that are running these Services they are really clinging to that service they feel like this service is their reason of being and that this is their identity essentially so and and often

you can spot it very e easily by saying oh uh what's what's the team called running the kubernetes cluster well it's the kubernetes team right you basically put their identity in the in their name right it's not it's not like the compute team or something which is a little bit more broader but it's it's the kubernetes team so now when you have a discussion on like okay

shall we still run kubernetes in-house should we move to a different container service well the kubernetes team thinks well but my name is kubernetes is so what am I going to do then so um this is also a problem where like we hear from leaders that they're really thinking about broadening the the ideas of of the team broadening the scope uh to be less reliant on on

just one service um and U let's say side problem that's sometimes arises as well is like believing to be good at at building abstractions so building abstractions over service over infrastructure it's it's really hard um it's what cloud is trying to do it's what Zas is trying to do and even they get it wrong some of the time so sometimes uh to add up all to all

of that um we see teams really being caught up in building the perfect abstractions but it's really hard to do that they are leaky when something goes wrong the developer you know all the complexity behind the abstraction is like spit out out and is falling on the feet of the developer and they are really confused so you can also lose a lot of time in building like

the perfect abstraction and finally uh to lock yourself really in into into your misery here in the spiral is like you you live in kind of an echo chamber and you're only measuring what you already have so you you do you know you want user feedback but you might not do it in a holistic way so maybe you have Comm right so you ask um your developers

hey do you like my kubernetes yes cool okay but you're not asking them more broader questions like hey what's what are actually your problems what are you facing day to-day um and these questions are difficult uh to deal with but that's really where where the value lies in as we say working backwards from from your developer so how did we end up with that downward spiral well

um the problem is um as we stated in the beginning uh that you weren't thinking enough or we weren't thinking enough about developer productivity uh it didn't work so much backwards from the developers um and that's a nice catchphrase right everybody can say that oh you just need to think about developer productivity but how do you actually do that in practice is the is the million dooll

question here um and thankfully there's some you know Recent research uh recent content from a lot of thought leaders that really help us to figure out okay how should we think productivity and um one great framework I want to introduce you to today is the devx framework and that is really a framework to uh basically improving developer productivity through developer experience and uh you probably know the

authors because there are some a very well-known Bunch um these are the same thought leaders that o brought you other Frameworks like Dora and space and um in in the latest thoughts here they basically model developer experience in those three core Dimensions that you see here so feedback loops cognitive load and Flow State and they're basically saying that a developer needs all three of these to be

really productive and together they make up developer experience and developer experience is great proxy for developer productivity uh you might have seen there's a lot of discussion on like how to actually measure developer productivity but it's very hard to do and uh it looks like a better way to do it is to actually think about developer experience and use that as a as a reference point uh

for productivity um so uh you can probably imagine what the things are about so feedback loops is about hey if I make a change how fast can I get feedback for that then you have the cognitive Lo that's one I think that's a little bit better understood and that's a lot of uh that's a point that's talked about a lot U when we think about platform engineering

so how much stuff do I need to keep in my mind to complete a task and then finally there there's Flow State so the ability to really go into the zone go into uh into Tunnel Vision on focusing on your task not being um uh basically being somehow pulled out of it through meetings or other things so um typical questions here are okay how how much time

do you have uninterrupted to work on your tasks and so on and what I really like about this framework is that it's very user Centric and it's a specific user right we're not modeling someone who wants to buy a television we're modeling the developer and what is important to them um and so the developer is really put in the center here and that works very well um

also in an Amazon context um because we have this working backwards methodology where we think about okay how can we create a product um that works for the customer and um with such a customer Centric approach uh as Jeff basos our founder also famously said um the great thing about having this uh customer Centric approach is that uh customers are always very uh dissatisfied even if they

on the surfice they report everything is great so really talking to your developers figuring out what is bothering them uh what what they want to rent about uh is a great way to build a developer platform that actually works for them now going a little bit more into this uh idea of the working backwards process which is something you could also do to improve your platform or

uh create the initial version of your developer platform you can see here how we typically do it so there are five questions hey who's the customer in that case it's the developer what insights do we have about them what's the prevailing problem uh what's the solution and and the benefit for them how can we describe it to them how can we describe the experience and how can

we actually measure that hypothesis that we have and how we can we measure uh that success and as part of that process uh we build a bunch of artifacts that you can see here so there's a fictional press release that basically announces the product and of course you can also use that internally it doesn't have to be something you you sell externally you basically imagine how would

you um basically introduce the new capabilities of your platform internally maybe in your internal social network uh typically we also draw some visuals they can be super Scrappy but they just help to get the idea across and then there's like um Extended documentation like in F queue that goes more into detail what is actually built there what is it what is it not which is also very

important and that is like the the general process we use uh to put ourselves in the mind of the customer and um work backwards from them uh to figure out what is a great product for them now this is a very generic process um so how can we enrich it with devx well uh we can use that devx framework um to really Zone in on the developer

Persona here uh so again uh as as you remember we have those three dimensions of feedback loop State and um now we can basically uh figure out more about the developers problems um through like uh three dimensions three layers uh one is the perception layer uh where you really ask the developer what their perception is of how easy it is to do certain things so for example

uh here you ask hey what what kind of frictions uh friction do you have um in in your feedback loops how how fast uh is it to actually validate a local change for cognitive load uh you're asking hey how easy is it for you to debug a production system and for Flo State you're really asking hey what is your feeling how many hours per week do you

actually are you actually in flow and can work uninterruptedly now the the questions you're using might vary so this is not like a comprehensive list and uh the idea here really is um you um you figure out what are the right questions uh for your company but the important thing is to really touch upon all those three dimensions and then you enrich that um with a workflow

layer and a workflow layer that's more of a quantitative measure so the first one is really qualitative because you ask people and then in the workflow layer you really ask quantitative uh questions uh you try to get measurements out of your system maybe your cicd system and you put those qualitative and quantitative measures together uh to figure out what what can be improved and what are the

main problems uh your developers are facing finally to round it up you also add kpis and these are really like Northstar metrics because uh you always want to figure out the changes I do in in total in in in in the sum are are they actually improving things or are they making things worse and this is where the kpis are helping you so you ask for things

like Hey how do you feel about your overall productivity and ideally um doing something like a survey or an interview which is a good way to to gather this data um you would want to see that this goes up maybe uh every half of a year or something now uh when you look at that um some people might raise the brows because uh we're talking a lot

about um uh qualitative um data here so asking people asking about their opinions and so on and um there are a lot of misconceptions about that so can we actually trust data we get from hums um I I don't have time today to dive really into that um but I have a really great article recommendation for you here it's on the Martin F Fowler blog it's co-written

uh by one of our colleagues from Amazon Tim Cochran who is part of our software Builder experience uh team that tries to make um the Builder experience better at Amazon and they have written a great article that's basically about uh making the point that uh to measure developer productivity you should really prioritize or at least start with Gathering data from humans rather than Gathering data from systems

and they make a lot of great points why this actually works um um they remove a lot of misconceptions and there's actually a lot of good um uh how to get started um guidance in that article there's even a survey template in there that you could send to your developers or use for interview questions um to figure out what their problems are so um if you're going

out of the stock and saying well that makes all sense but I need you know some more Hands-On guidance directed guidance on how to get started this is a great article uh to read so um definitely recommend that one so the sum it up um we said in the beginning uh we want you to think about developer productivity first uh we just saw um you can basically

um take that term and replace it with developer experience so developer experience is a productivity uh we showed you how you can use that devx framework uh as a to set your mindset uh for for how to think about the developer and what their needs are and um how and this can actually give a lot of cool benefits so one of them is uh you can uh

using devx uh as a guidance right you can change the core identity of some of your platform teams you know maybe move the kubernetes team to a more broader scope um and focus more on the experience then on a particular service or technology and uh when you do that and work back from the developers with that framework you also see that the scope of of your work

actually increases a lot in the sense of like there's many many ways to improve the productivity of a developer it's not just about running a particular service could be as simple as you know there's just some Vicky page missing for some initial guidance maybe developers just need a new laptop uh because the current one is slow um or they just need help getting started and uh j

i companions uh actually the right uh guide here for them um to get started and uh what cool things uh we can do with with j i companions today to really cover the whole life cycle of developers that's uh what Christian is going to next I thank you on mute Chris thank you okay then let me go back one slide so thanks for joining and this is

the the second part and um we'll be talking about how you can unlock the next productivity front here with Jenny I let me jump right into it with a study by McKenzie and Company and this study shows the global economic impact of gen and like the key takeaway here really is 75% of the estimated Global annual gen impact really stems from just four functions and this is

Marketing sales this is product and R&D customer operations and software engineering and software engineering really stands out to me in this case because if you add those bubbles up you will end up at roughly 900 billion Global annual gen impact just by productivity boosts before we go how to how we can achieve that let's talk about about how we can productivity and for this I would briefly

cover the most popular three Frameworks I'm starting with Thora I think this is really the most widely adopted and most popular one talking about deployment frequency change lead time change failure rate and time to restore a service a more recent framework is called space and space is recognizing more that development is a soot technological process and adds more dimensions for toora um to to Really capture that

so they are capturing satisfaction and well-being communication and collaboration and also efficiency and flow the last framework and Robert walked you through that already is developer experience or in short devx it's about increasing the Flow State reducing the cognitive load and shortening feedback loops and well gen will change a lot on what we are going to measure in the future and how we are going to measure

it and activity and output based metrics will get even less useful than they are right now I think the mental model behind develop experience will still hold true if you increase the flow time and reduce cognitive load and shorten feedback loops you will end up productivity and the key takeaways on on that slide basically are there's not a single dimensional metric to capture to to actually measure

productivity you will need quantitative data think about Dora instrumentation Telemetry but you also need qualitative data surveys like Robert pointed out talk to your customers um and do surveys and the last one also um Robert touched upon that a develop experience or devx is likely the best proxy to productivity so how can we increase developer experience and there is a by Harvard Business Review um about employees

in general not only developers that employees are more engaged significantly more engaged and staying are more likely to stay Beyond three years in the company if they have the right technology supporting their work the right technology can mean a lot right it can be tools can be platforms but what really is transformational right now is generative AI there's basically not a single talk or Summit without it

right now and for a good reason um this McKenzie study really shows that developers using gen feel more happy can focus more on meaningful work which is more satisfying and they longer and more often in the Flow State that's I think this is great proof on how you can improve the Flow State and reduce cognitive load but just staying more focused on meaningful work but to go

beyond studies and to real use cases let me start with one I guess every one of you is um quite familiar with coding companions so they're translating natural language to multiple code suggestions they can me your developer style and they hopefully know your internal code base they can do security scanning and open source reference tracking so they will hint you okay where's the code from which licens

is used which saves you a lot of work in the postprocessing because it like compiles a list um helping you to to know which um licenses are applying so my adoption however my sorry my observation is however that the adoption rate is quite low talking to large German Enterprises I found that less than 20% I would say less than 20% are really using coding companions at scale

and that means there is a lot of opportunity left because just by adopting coding companions you're a lot more likely to to complete a task successfully and you're on average 57% faster there a lot of studies out there showing that but talking about devx we know that's just some hard metrics there must be more and there is developers using coding companions are feeling more productive they spend

less time searching which helps them to stay longer in the flow and overall this leads to higher job satisfaction so this is actually what we need and so coding companions are great right but the typical developer is just spending 4 hours and 21 minutes coding per week that's 52 minutes per day and even if you check like the N top top 90% in that study still they're

coding less than 2 hours and 10 minutes per day and while at first this seems a little bit odd it absolutely makes sense right development is much more than coding and given the landscape Robert was laying out there's a lot of like designing and deciding to do before you actually start development but there's even more um and this gardner study sorry really shows the typical developer is

spending 73% of his time on running and maintaining applications and less than a third on actually doing Innovation and transformation and again this might sound strange but let me walk you through a brief example because it actually makes sense let's say you build your app with your favorite coding when you're done the actual work really starts again right let's say you run your app on a shared

kubernetes cluster and then you do count an error so first thing you have to do is you really need to understand the issues dive into metric understand all the logs maybe you need to interface with your platform team to understand what's going to happen um or if what happened on their side maybe you even need to dive into kubernetes logs yourself right the abstraction broke and now

you need to to learn cators and understand the the issues when you understood the issue you need to design a solution and decide for it then you actually do the coding right then you have all the review pull request and review maybe you need to update your monitoring your observability and then you deploy the fixing production maybe that even happens few times too often and then you

said okay no let's move off that Shar catus cluster let's go fully serverless to get a little bit more time um back from running and maintaining and that's a great approach but maybe it's not enough right you you might choose a better platform but the question really is what do you need to do to switch to really flip that equation right to give the developers time back

on Innovation and transformation and creativity instead of while there are many answers we believe one a crucial answer is having a development companion who really supports you across the whole software development life cycle from understanding designing developing reviewing monitoring and testing to maintaining and in in the next few minutes I'm going to break it down um bit by bit starting with understanding and learning let's say you're

new to the company new to a team you have new responsibilities or maybe you just want to add a piece of functionality to to a code base first thing you always have to do is to understand and learn what are the functional requirements non-functional ones um what is the existing environment and then you go to design and decide for a solution and there's an interesting Concept in

in the realm of devx it's called knowledge Discovery efficiency or in short KD and the KD is a mathematical construct which can like have a value between zero and 100 and is calculated for each developer individually and it signifies the knowledge that developer is lacking or not lacking to complete a certain task so basically when the KD value is zero a lot of information is missing a

lot of learning is required let's say new Frameworks tools languages this means there's High cognitive load and it will take long until the developer can complete the task if the kyd is close to 100 this signifies a solution where there basically is no knowledge Gap everything is known like judging from my personal experience this rarely is the case right you you may have like if you know

stard Trek and you know that Q guy this omnicient allmighty being um like he likely has a kitty value of 100 we don't so the question is can gen AI maybe help us to build an all knowing Q who can like instead of us researching all the time who can simply explain stuff to us this would increase our KD shorten feedback loops and increase the time we

can stay in the flow and also will reduce cognitive load so the answer to the question basically is yes we can do that um you can build a development companion who knows your environment and can help you to understand an existing app requirements and use cases and like how does it know you ask the question you get the answer it knows because it has access to all

your internal document documentation whether it's like atum tool sets whether it's git um wherever document you can add the resources so the development companion knows all about your Internal Documentation and you don't have to search for it yourself all the time instead you can do it in a conversational way so as the development companion knows not only your use cases but also your code he can help

you with creating a user story right a technical user story we can do um development companion can even create a j task for you so this really increases my knowledge Discovery efficiency but it also helps me to like just shorten feedback loop and be faster in the stuff I'm doing so next step is I want to decide for a solution and design it I I have an

idea but I don't know if the services I want to to use are allow listed in the past right we used to tend like we we tend to to to shoot an email to the cloud center of excellence and ask them right feedback loops FAS way is actually just ask your development companion it knows right it has documentation access to it and there you go two of

the services I want to use are allowed one is not why does it know again Internal Documentation and it can even help me to understand okay what do I need to do to get that service allow listed because I really want to use it and there I go I get the answer loops the next step in the development is to actually develop and then to review also

for develop first thing you need to do is to understand your code base and again your development companion can help you with that you can simply ask me okay tell me what the code is doing give me a description and it will break the existing code based down for you telling you okay there's a unique ID why is it used like what is it good for and

you can even ask it for like give me improvements for that or you can ask it for more test cases to increase the test coverage it can even help you to insert it on the in the actual code base maybe you even want to go beyond that you have your code base and you want to add an exist like to that existing base you want to add

a new piece of functionality to support you in the process you can simply ask the development companion hey please add the add product functionality instead of going through understanding learning designing deciding yourself you can start at an elevated precision based on what your development companion actually tells you you get a step-by-step plan what he wants to change how he wants to change yeah you will also add

test cases okay great you get a summary and there is a Smart Action button right code this takes a little bit longer than what you will see here and there you get the solution and instead of like doing everything yourself you can just check what changes did the development companion do and whether you like it and if you don't like it you can iterate over it either

via just asking questions why did you do that can you like like this can you change it can you improve it in that way or if you're happy with it you can simply accept it and what you can also see at not at the top sorry at the bottom there are the test cases for the product okay that's great so velopment companion really helped us to develop

a piece of functionality based on existing code the next step in the software development life cycle is to Monitor and test depending on whom you ask it's not the like most favorite part of the development um life cycle and like frequently when you try something the first time it doesn't really work out and then troubleshooting begins what you can do is you have flask a based on

Lambda functions and you try it doesn't work you get a lengthy error message and what you actually want is like a brief overview what's actually going on and here you get that right the coding companion tells you there is a put item it um operation and yeah it seems like you don't have the the right role to to do that and you can ask him okay help

me generate a solution I want to fix that so first step was really lengthy error message summarized in two and a half lines of short descriptive error message and then you even get a resolution right okay this is the explanation what you need to be doing step by step and if you want to be like fast and Scrappy let's go CLI command takes a few seconds to

to it and at the very bottom you always have the option to provide feedback and feedback is really important to to continue the development of the devel companion itself continuously improve it so here you get the CLI command on how to fix your issue this is again reducing your cognitive load right you don't need to digest all the lengthy locks you don't need to um to stack

Overflow the the issue and like try to figure things out you get an analysis you get a solution very fast without switching TPS the last step of the development process is actually maintaining the and how would you do that how can the development companion help you in that case the development companion will take your code put it in a secure environment transform it based on static rules

using also llms for the non-static rules covered codebase and transform it either from an old language to a new one think about Cobo to Java or think about Java 8 20 and this can speed you up significantly and like actually get you back on track to focus not on maintaining apps but actually building Innovations okay one last slide to sum it up basically what we've heard is

developer experience is likely the best proxy metric for developer productivity and while platforms can really help you to increase develop experience you need to make sure that you're working backward from your customers and developers think about quantitive but also qualitative data talk to the people to make sure you reduce feedback loops you reduce the cognitive load and increase the flow time while coding companions are great and

not widely adopted yet in most large Enterprises what you actually need is a development companion who is really supporting you throughout the whole software development life cycle going from understanding to develop testing upgrading and actually what you want is you want to have an all- knowing men who's always available to answer your questions when it comes to platforms um platforms there a lot of great platforms but

you need to be careful they might be providing Illusions rather than valid abstraction and when something breaks your developer still needs to dive deep in kubernetes logs which you actually wanted to prevent so our call to action basically is spend less time trying to build the perfect abstraction instead have a development companion who's actually explaining things to you thank you thank you Robert and Christian it was

very interesting talk personally I knew Dora metrics but space framework I didn't know so I I just learned it it was very interesting and we have a few minutes for the questions I'm just checking we don't have any questions but I want to little bit wait for audience to type their questions and in the meantime maybe I have a question like what do you think what might

be the reason for the low code companion usage some SEC reasons or something else that's we've been talking to some industry leaders about that in the past time and it's really mix um there's still an uncertainty whether like whom is it helping best is it helping Junior developers or senior developers best is it creating great code or is it more introducing so there's a lot of uncertainty

um still around that just just a few questions so there's a lot of uncertainty and it feels like it takes a long time to really have it like valid prototype and then roll it out to think about large Enterprises having 3,000 more developers this will take time to to really get it done but I think we're we're on the way MH I see that makes sense it

might depend on the level of people all right so yeah we don't have any questions yet uh but if you have any less messages please feel free to share and then we can close the session yeah um uh I could quickly add to to what Christen said I think another thing is also everybody is just uh you know playing a little bit of the waiting game because

I think a lot of people have the mindset lot of companies oh I need to decide for one of those companions right I can only have one it costs something whatever so the cool thing is a lot of stuff showed there um if you're using AWS there actually free tier you so you can even use these functionalities without you know paying something or you know getting an

additional subscription it's basically included and I think in the future we will see um more ways to actually use multiple companions right because you could think that there's different agents that have different strengths right one agent is good at creating SQL commands for me one agent is good at using AWS and so on and I I think as as we go along uh this very interesting path

um it will open up and you actually will will have a choice developers have a choice daily basically to use the right companion for the job basically what what Christian showed right there was different it's it's all maybe called q but it's actually different companions that are trained on a very specific task and that makes it easy and I think this is where we're going and uh

as this ecosystem opens up I think it will also be easier for companies um because they feel like they need to commit list to one specific assistant all right sounds interesting yeah thanks a lot for this great session and yeah enjoy the rest of the conference thanks a lot thank you have a great e