⚠ Speaker labels absent. This transcript was provided without per-speaker labels and contains visible speech-to-text artefacts (e.g. "alza" likely = "AI/Eleven Labs", "deals activated without people", "tynatics", "rainbow" likely = "the repo", "Brigitte" likely = a misheard name, "two news that actually searches" likely = "tool/use that…"). The talk is single-speaker (Patrick Debois) bookended by a brief MC intro and outro. No Q&A is captured. When quoting, preserve the artefacts verbatim and optionally annotate [transcription artefact]; do not silently "correct" them.

Section 1 — MC intro

So. You. Re very lucky people. Are about to. Hear. Perfect. As the product. Patrick Debois. And. The curator. Of. AI Native. The movie. Says. No does the farm of DevOps. Going in terms of first to organize their what they get in 2009 and co-author of DevOps Handbook. This was generated by an alza. I can tell by the love of God anyway today he's going to be talking to us about coding agent scale themselves and neither do you see the rise of enablement give it up for Patrick.

Section 2 — Framing & disclaimer

Thank you for coming disclaimer this talk was first started in on Friday so it's a brand new talk basically you sky stole my thumbnail on the field so I come up with a different. So it's a little bit experimental but we get rid of that. So he here has kind of like the struggle of scaling it gently coding within our organization we call it deals activated without people. So development is changing. And I think the best phrase to say is we're not building the thing we're building the thing that builds the thing that's kind of the new mentality and left and right you know kind of accurate program so there's a little bit of a sprinkle of context that you might hear the skills a little bit of hardness engineering that is in there but. It is pieces of the puzzle that are largely technology pieces right now? But I'm going to talk at like what does it mean to use those. So one of the things is everybody's reinventing the will which is great with a new technology coming about because you're all learning but it's not sustainable every time first DevOps everyone that was building their own deploys you know cloud everybody was building their own history that is not sustainable right that's not where you want to go for. But you know. Enablement and you all know the term developer enablement it doesn't by itself you have a team for that you have people that kind of actively nurture that with your board and that is not about how you become a better agenda decoding per se but how do skill is asked. And the good news is you already know how which is and you'll see that in the talk. Everything that's good for you that we've been advocating for years on good engineering practices. Is actually good for agents. And what's good for agents. Seems to be good for people. Because maybe it's because the alarms have been mirrored on our behavior and maybe that's that but maybe some pieces right. And it's not just about vibe curling like hey I build an app but how can I make the app sustainable work secure all those pieces that's where engineering kicks in again? This probably could be a two hour talk but I got like 20 minutes left.

Section 3 — Enable the agent (developer level)

We're going to enable the agents that's what a lot of people talk about. One of the top briefly also like what do you do to your local team? What goes into the platform and how do you think about this hip in the organization? Enable the agents when you make it work. Like DevOps we've come up with an internal. The product engineer it wasn't enough that we call them AI engineers because I was confusing is it AI in the products for software all of a sudden we have a new term the I product engineer. Customer focused shouldn't our deaths have been customer focused? Nothing there but the nice thing for me is it's another silophila that kind of requirements I figure out what we need to build how to build it is common blending towards.

The way that I want people to think and I mentioned like building the thing that builds a thing. One of the mindset challenges that people have is even if the agent gets things wrong they jump in and they correct a mistake. What they really should be doing is improving the system that builds the code and he proved that so they don't have to do it again so it's not about fix the code and fix the system and a lot of system engineers and the platform people they think in system mentality and that's why it's also quite natural to kind of think in those terms it's for me right now in the industry still wouldn't like one of the predominant mistakes is that you still go in and jump in and correct and take over. Mortality should change to fix the system and have the ejected flow.

So I mentioned like what good looks like. Claude learned that we should have planning before doing something. We should have testing to see what are the agent did something well or not or whether we pull the trick and change functionality within one. I always say like I never knew I would see the day that developers would write on their own but they learned that actually by writing specs or whatever you call it context all of a sudden it takes to come back. And then if you add observability the agent can actually kind of observe themselves and improve. Nothing new, it's just rehashed within a mindset. It's not how the agents doing that stuff.

Okay, so that's reusability comes into not changing the context in the prongs. You think about reusable specs kind of make that and that goes to both harness components, tools based on reusable. Now it's very tempting to not listen to whatever happens in the production. And yes as a dev you've never been used to it like you have been told like you know the only thing that matters is how your end user is having issues. And those have been signals that we've been trying to educate that like whenever you see a signal that is not performing well change the system and improve that. So that is how you have to think about that. Smaller task no surprise there like big cost. The agent goes in all directions. That's true. And then you measure actually before that happens.

The funny part is. Everybody builds their own context. Well I had my Claude MD and you see the copy and paste being told on the internet like use this use that. And all sustainable right so what you want to do is you want to standardize like a library within your team within your code base. No shared partners. Should take this but within Tessl we have now five or six harnesses being built. Which is great for learning but probably only a few should survive after that is done. Because that issues. You have to maintain the spanish it's not the one thing it will change it will not be up today and eventually another problem that we're facing is as we're putting more pieces like you know you go to your triage ticket system you're kind of maybe reviews or customer database all those visas have not been set up well for access control. It's a running problem that we have. We're getting better at that there's maybe new specs that come around but this is what it gets hard. We've learned about this kind of just limit the kind of the blast wall of everything that you're doing for ages. So that's the same thing as we would do before for use.

If there's one mindset change. That I want almost like what do you tell a developer right now in a jet decoding that's already a gender coding? I would stress this. Every time you do something. Think about not repeating this again. And this was the mentality also for devil sublimation like whatever we do it's not it works on my machine it works with my agent it works like you know my snowflake machine or anything. It is make it repeatable. And that kind of gets you in a motion of improvement. I hope no surprises there so far.

Section 4 — Enable the team (team lead level)

But what about the t? There's the T lead that now what is their job? So they're not only helping the humans. They're helping the agents as well. Because they're team members. Right have that mentality of going through is important. Because basically what I think they're going to be like accountable for is. In a pause and that's so important developers performance and kind of like what they deliver and the quality and all those pieces. But increasingly it's also what your agents how well they're performing because they're part of that system as well. You can say this is the quality if you're owned like a microservice system this is also your ownership of whatever feedback you're building. But now the tools that you're building to build a thing is also a piece of your responsibility that you should be tracking as well. What's good for you is good for you. One and a half token spend go up through the roof. Just felt it something vague. You want to run it overnight and see what it did all the things that it spent. Not years from right sharing the context and kind of no surprises like keep it like predictable what you're going with a goal that you're going for.

Some of the new practices and I tried to that's kind of what I'm like challenging myself with I can tell you a generic transformation story in the company and say well developers need to use hackathon give everybody a tool great like we're self-gratulated ourselves but what is changing? Here's a few kind of new things. Like curriculum. It was almost like the pair of contact fry what's your style? What do you put in? What is important? So kind of that is tynatics. What is the definition of dark? Is that the code is going on or was there more to it is that the agent doing its best and how that's performing that becomes part of your definition of thought. So you need a kind of metric. And one of the metrics that I really like is how many turns does an agent need to do. To do the right thing? If you start measuring that you're actually looking at how efficient am I feeding how efficient is my harness to make that a better optimization in that much like you look at your team members how do you kind of make them work together well. Some things similar to the retro how did we work? Is how did our agents work? And they do that at the end and then they feed back into the next cycle so very similar but quite concrete of what people are doing now in those kind of dynamics.

The philosophy metrics are great but there's more to it right because we work there's like the terms of the authentic things. You got to educate people because not everybody's in excellent writer in skills and prose so that is innovation much like you would do training for people regular coding and one of the kind of hard challenges is they used to be the coding rock star. You kind of have to translate it almost into you're the amazing context provider that tells the agent which is the great like agent whisperer right because that is what you're aiming like want to get them into not everybody wants to do it they still want to deal with the code but it's also a great way to have almost the skeptics. Because they said an AI can't do what I do right maybe you can write down what it is you do that we can make the case better. And that kind of shared library has also kind of a little bit of a challenge if you put it in the rainbow and it's like yeah it's in the rainbow. It's becoming grounds which has pro icons like who has the ownership of certain pieces of libraries of skills and other pieces.

So if I want to get them in the mind shift. Team leaders should think about like my agents are team members too how did I find gold KPI and we are measuring the performance how I made them play well with my team? And all those pieces everything you already know but kind of a different level agent.

Section 5 — Enable the platform

All right let's scale this up. One developer, few developers team. Enable a platform. Scale this how can they work? It's a very common pattern every time a new technology we had the agile team we had the DevOps team we have the agentic naval team. It's the incubation team that starts to change. And that maybe we mimic that into next theme into the next team eventually we think we should put them everything in a share later and we don't have everybody doing the boilerplate over and over again. That's that. So these people built for the team that builds the thing that does the. Thing. Right and I think they're natural people who will think about optimizing the whole. Great I got skills but how do they work together across teams? Can they be reused across teams? I write my Claude MD but can I put pieces of that? I have a harness and a pipeline cannot make that reusable so that's their mindset.

The other mindset. That we don't have yet enough. Is and I've been asking for AI coding vendors for like many times I go to your business like right you're great so you're doing getting all the feedback a proven. Do you do any learning of things that goes in prod? We don't have a question. There's no request of people learning about bliss and you end up being in another group of vendors that talks about AI within the platform and they do all the observability. By combining both is apparently the same mistake as we're not learning from what was put into the wild within putting the wild was within our test environment in the test run but it was not about renting the coding. So the other piece idea is. Hey I need a memory I need other pieces that all the agents share a backbone that's what they're going to provide not every team is going to build that infrastructure right now that's what they do because they're experimenting the learning it's okay but eventually that will sink somewhere central.

So well there's a good platform that's good for people it's good for the eye subserve. If you think about like somebody going through hoops of copying skills and so on. You just want to simply pull in that friction needs to be very. Much yous want to put the best practices in place maybe we have some security is getting all those pieces. Down okay themselves yous want to make that easy path of something they put on that test oh when they first accomplished monitor right agent observability of what your coding agents are doing has to hold an organization you want every team to spin up their own kind of monitoring and observability no just use the central tool because now we can find insights and learn what is missing in context of what are pieces that are missing that we should address if I may be some new skills for will have a new tool that addresses that central view is used because it will kind of transcend the knowledge across the organization and not just your team. And then putting the garbage in place.

So this brings things to what we have a registry to do our code so we can have a registry for our skills and we want it to be versioned and we will have a registry for MCP skills harnesses agents agent pipelines it doesn't matter at the same pattern discoverability somewhere central reusable self-serve to pull this in. Half gateways one of the first pieces that product people put in place when using AI is a gateway and an MCP and so on. For coding we're like but once you start putting a harness of agents that work together you say hahaha no we need a gateway we need the observability all those pieces in place and the evap platform do that centrally and then ownership right.

When you're in a platform team there is kind of this red pose that everybody shares to your repositories usually and then the one I kind of get like abandoned. Nobody knows right remember the time that we had to like buy two news that actually searches all our repos or they still active are they still maintain who owns this is the same piece there as well. One of the challenges is much like. Hey you should write tests that's a great idea sure I'll do it after my project when I have time it's the same excuse me write eval well you know we'll do that after the project when I have like. Picks making that easy making that self serve is definitely something you're offering a token.

Now one of the challenges and I think it was mentioned this morning. I built the skill that's great I want to share that with somebody else look at it like yeah I'll like it for 99% let me kind of change that one bit and then becomes a fork. That same mentality is like you want to roll your own but you want to make it extensible right so you want to make sure that everybody's contributing to that central place. And then you need to have a way not just to test that when it's the mind within the mind of the developers but you also need to do the maintenance is it still secure is it still optimizing when I change the model it's similar to an external kind of company changes the API and you didn't change anything that occurred but all of a sudden your tests are failing this is the same thing that you're trying to do but now for skills for harnesses and pieces there as well as long as you don't have that testing and that repeatable thing in place you will have that same problem.

And so the no ownership of share components is that whenever somebody pushes is that you have to ask who owns this who's going to retain this who has the budget to do this that is kind of the question you go from there.

And I think their mindset should be. You're really really special person. But the way you work is. I'm sorry to bring it to you. Right. Now how many people told me this DevOps thing. Yeah, we can't do it in orange like we're special you don't understand how we work guess what after a while everybody could do it right that mentality of breaking this is the same thing with pipelines well you know what they are like let me compound the kernel because I know exactly what I need who cares like you know it's beyond it spins up it's great right I'm not saying you shouldn't but it should be more deliberate where you kind of put the customization in place and you always see this with people saying like oh I really need to have my coding agent really fast and then they guess what you know it runs in the background I don't care that much I want to have it like produce the right results note that it's like instant feedback so I can reply to it in the real time so kind of that is looking out through those things.

Section 6 — Enable the organisation (VP level)

Enable the organization. More towards the VP engineering. So okay their dog they'll be orc that builds for the team stuff most of the family and I think this is probably you know the broadest enabled ones rule of them all. Right now we're kind of struggling what have we put in place give everybody the tools great okay and I'm like. Right let's what is already spend over everybody and it's kind of challenging that. I think where previous job and I'm not saying it's going to be replaced I should still hire engineers that should ship reliable and it's a stainless pace. That I think they need to work on how to enable the system. Is that people creating tickets flying easily into what the agent has accessible. Maybe the platform team can all look at until a VP comes in and say let me look kind of these groups and you have to kind of work together which is quite two children on the playground but you get the idea.

What this is the organization what's good for people is get free up there might be. Responsible you want to prove this because ownership drives improvement and otherwise it just get followed between the parts. If TA needs to do this and TB needs to do that you're in aligning kind of the direction of the different teams and that's your work and the sustainable pace is well if one team is completely over creating all the rest and they can't look at all the changes you kind of have to balance which team is still struggling, which team needs investment in education which team kind of need to maybe have some help from the platform team to kind of set up their whole new environment.

And then you want to of course worry about the costs as well. So kind of putting that like investment clear that it is beyond. I am buying license for all my tools. What is the investment on education what is the investment of kind of improving the pipeline monitoring how well they're performing and how much do I care about that. That is the tipping point between just saying here's a bunch of tools run over the head I don't know between I care I set the direction this is where I will measure you as the productivity like how much is it redoing the same thing how much efficiency are you getting through there. As well?

And then you put the governance in place. I think it was mentioned already a few times. The skills, the context. Who gets access to what do you mandate that they have to be securities gaps? Do you kind of see whether you only allowed almost like a proof skills almost like what we did with registries you're only allowed to use these because they've been better and the other ones who were not there but we can bring them in we have a process of bringing external skills internally and kind of bring them on to that we set the KPIs and I know there's still sounds a little bit vague and that's kind of what I'm working on like if you any any kind of specific advice more tailored to context and all those pieces that's kind of what I'm trying to describe on the enablement instead of the fake things but we do know that you want to have a KPI for agent quality as well not only the quality of what is your mission because they had some internal part of working system. As usual.

VP struggle to say I'm going to infest with this. But the business doesn't care. Because you need to return now. So that's why you need to make it visible you need to take the pain visible and that was the same with security if you can't show how many vulnerabilities you're having how much that risk is telling that you can't actually start justifying the return on investment only by saying are we at 2x 10x? Looks good to me. Okay so that's not the mentality that we're going for so we want to avoid the quick wins of war and actually make that enablement team much like a platform team it requires an investment go forward Unfortunately.

Section 7 — The barrel mental model & Continuous Learning

There is no playbook. And that's kind of the challenging part is like okay we're all learning while we go and it's a very kind of unsatisfactory thing but I think layer by layer that's the improvement so if you already set the step on the investment you'll virtually the mental model that I usually use is that if you have a barrel there all sides that are hold together. If you do any automation in the past with evolves. If you have one piece of the barrel that is very low. The water will pour through there. So I think the trick is you go on step by step on all the phases you improve part of the governance part of the automation and you go that by there. Instead if you automate everything and you don't have your governance in place. That doesn't make sense.

And that's my pet peeve. Continuous integration. Continuous delivery. And I think with all the contexts that we're accumulating and the tools were basically learning how to go across better and to learn how fast we can do things. And in a world where it's almost. Important to swap in and swap out new technology as they become like a business edge. You have to think about how fast can I adopt something new we're contingent delivery was how can I deliver the existing maybe more stable and. Like in that way. But right now it is about accumulating knowledge within the org across all the teams how your business is going to get better and build better and more reliable tools. For me that is the step of continuous learning.

Section 8 — Debois's own research method

I'm working on this side yes it's on the Tessel but what I actually do is. I have an agent. That looks at all the social posts. And tries to distill those into patterns. There are challenges because vendors who say this is how you do things which I'm trying to find a system that ignores the fact that sometimes vendors are care because they have a good ID. But I try to also find multiple sources about doing the same thing. When I find out the challenge then is are they just referring to the same article like Brigitte does something. So I have to find out like what is your thinking? Is there a similarity? So I'm trying to automate this and it's basically a research tool for me and hope it's interesting for you as well to just find what people are doing in the industry. Because I think surveys right now are just too slow. You can't wait until everybody says like oh you know we're adapting we're just on and that's it.

Section 9 — Close & MC outro

So in a nutshell that's what I would say is agent enablement. If you're interested in kind of sharing maybe some of your stories, what you learned, how you framed, how you help kind of the mindset change how do you think it's changing your teams, ceremonies, how do you think about the problem, how do you defend it to maybe your CFO. I love to hear your stories and if you want to have the slides. Connect with me on LinkedIn and I'll happily share slides in exchange for feedback because that's what you develop it. Thank you very much.

For the two days. So you go find him. That was a great 12th house. So many questions. All right thanks very much. Have a look on this stage and so and that will be the last talk of the day before we go out. It will be great. So I'm really excited about that. See you back here in 10 minutes. I think it's probably a cruiser blown away and I think.