AI Native Development - rethinking our workflow

0:05 Alors, Patrick Debois, c'est un peu l'homme qui a trouvé comment coder dans la matrice sans se prendre une tentacule de sentinelle dans la tête. Préparez-vous parce que là, on va passer du simple autocomplite à des agents qui codent tout en parallèle. Accueillons Patrick Debois, qui est AI Product Engineer chez AI Native Dev. Let's go. Bienvenue sur le stage! Dire Patrick, ça va? Oui, ça va bien. Ah, il y a quand même du français. Non, je suis un petit belge. Comme Astérix et Obélix. Il n'y a pas de petits belges. Il n'y a que des grands belges. Nous, on aime les belges. C'est génial. Je vous laisse le floor. Floor is yours, comme on dit. Et je reviens d'ici une petite grosse dizaine, vingtaine de minutes. Je crois que vous avez 25 minutes de talk. C'est pas ça, je dis des bêtises. 25 minutes. Et je reviens pour 10 minutes de questions-réponses qui seront anglais-français, on verra. D'accord? Ce sera. A tout à l'heure, Patrick. Pranglais. Pranglais, très bien. Donc, je vois personne dans la salle.

1:09 Donc, il faut m'excuser, mais on va commencer. AI native development. I think it's about this year that AI while coding took a big step. AI in general, maybe a year ago, and I learned from one of the talks that I have to say which kind of AI. It's generative AI. I'm not here to talk about geopolitics. I'm one of an engineer who kind of likes to tinker with the technology and see what's possible and how it's kind of progressing. And I'm also trying to kind of extrapolate from that how the technology is influencing the way we work, the processes, the people, and then the other way around. I've started this talk or this deck in the beginning of the year, and it's just...

2:11 Kind of evolved and every time there's something new. This is the short version, but there's a longer version. But let's kick it off with, I summarized my first 50 other slides into this slide. And the reasons why I did that, there's a lot of talks about using AI while coding and they promise you all the productivity and that's all great. This slide is just to give some people homework, which means if you're just still using Copilot as a way, you're somewhere on the left of the diagram. If you're using a team of agents that code and make up their own tools, you're somewhere on the right. So it is just to show you that the technology is here to improve and do coding with AI, and it's evolved a lot from what we know as when GitHub co-piloted into the world. And then I'm going to finish that whole explosion of technology while saying a lot of people come up to me is like, how do we introduce this into our company?

3:24 Or management doesn't want to do it or people don't want to do it. So it's always kind of the same story there. Having lived through a few transformations, it is actually always the same story. You find some people who are enthusiastic about it. You kind of ignore the complete naysayers because that's not where your energy should go right now. We kind of nurture that one team and let them explore. You try to remove all bottlenecks for that team to actually explore it to the fullest. So that means kind of try to make them funding. Try to make changes to your process. And then you take it from that one team, then maybe try what they learned into another team. You synthesize the learnings. Then you try to extrapolate this into your whole company. You maybe bring that into your platform team or your developer experience team and you scale this out.

4:27 This, in a nutshell, is the transformation and probably the job. And I hope some of you have been doing that job and have been introducing those development tools into your company. This by itself could be a whole talk, but I'm saying if you did transformations of DevOps, if you did transformation of cloud, if you did transformation of agile, it is always kind of the same process that you go through. It's not different from AI. Yes, the tooling is different, but the transformation process, the getting people excited is the same story. But, right, we're all new. And hey, here I am on stage being the expert on AI. I'm obviously not an expert on AI, right? I am an expert over the years, maybe, at like cobbling things together and integrating things. And that's why I couldn't be an ML engineer. I couldn't be a traditional AI engineer, but I can definitely integrate stuff now with everything having an API in there.

5:28 So nobody's really the expert, and that's why we need to bring the stories out in that world. So who am I? I try to be industry neutral, so maybe not playing between Russia and China or wherever. I come from the world of DevOps, DevSecOps, and my small claim to fame is to bring that to the industry. And I'm trying to just bring similarly the stories out in the world. By the way, I also got bored about DevOps because it wasn't really advancing. And maybe this is a fun new way of looking at things. Also curate some content at a community called the AI Native Dev. And I currently work for Tesla. You can find my LinkedIn and I'll repeat it at the end. And this is the warning because right now I've done probably two minutes a slide, but I'm going to go with two slides a minute. So don't have to take pictures. You just connect with me on LinkedIn and I'll happily send you the slides. So just relax and enjoy the story.

6:31 So we're all cloud native. Let's get AI native, right? And so we see these things happening. It's just taking longer. The chats are everywhere. Like, what does it really mean? Nobody knows. I tried to distill this into four patterns, and I'll be honest, in the beginning of the year, I had no clue. I still have no clue, but I have a few more clues. So the first pattern that I see happening is after you got the whole story about people using more AI for coding, what is actually happening? Yes, they might be producing more code, not one file, 10 files, 50 files. It doesn't matter. They basically will become a manager of agents. And the real problem is not about producing more code, it's actually doing the review process. And it's something you quite quickly become aware when these coding agents actually start chewing out a lot of the code.

7:33 So how do we deal with this? What is basically happening is we're trying to reduce cognitive load when we review that code. And I'm going to show you a few examples, and they're not like very polished, but it's to show you that that is a bottleneck. On the left, The typical diff view, right? You look at a PR and it's, you know, it's a lot of text. It's not going to be three lines with AI. It's going to be a lot of text. You can look at the chat view, even more text. I don't have time to read that. And then you use AI to summarize the AI. It's not really working. The third way could be more clever by annotating some of the pieces with code with kind of hints and clues and synthesis while reading the code. So this is the piece on the right, something that Cursher did in one of their tools. So a lot easier to read the summary instead of looking at the code and the diffs.

8:38 We do not have to limit ourselves to text divs. Why not like a visual div of a diagram? Maybe the architecture has changed. Maybe some of the class diagrams. So I want you to get in the mode of like, what can we all do to review our code better? Okay, this is a lot easier to see than some diagram code that is out there. And then our friends at Google were looking for a solution for their notebook LLM. And they said, okay, let's put it in a coding agent. And then while it's generating all that code, let's make a podcast. And so in the morning, we'll listen to the podcast. And then we actually know what the agents did. And then we can speak into our voice and we say it. Obviously not very practical, but there's some truth to that. Like the main point is a little bit of thinking about not your IDE as it is right now to do the code reviewing, but there is something brewing in that world. There's a concept called the moldable development environment, where actually your IDE will adapt to the task at hand.

9:46 And right now, it is mostly focused on kind of producing code. But that will change. It's going to be about managing the agents and actually reviewing code. And you see the first signs actually happening in the tool. And there were a few mentions about MCP as one of the tools. But what you see right now is MCP is also breaking through kind of not only being on the back end, but trying to surface some pieces on the UI. So if the agent needs your help, it might bring some piece of UI in there. So it's not that static as we think the IDEs might be. And then I'm sure you all heard of vibe coding, kind of one of the words of the year. But what if the agents are actually vibe coding an app to review the change? They're actually optimizing for you to verify whether it was successful, yes or not.

10:48 Kind of things that people are experimenting with. Okay, enough of the review, but can we kind of just say, like, skip the review? Some tools, they start reversing that process by saying, hey, let's auto-commit. If you don't like it, you can re-fork cover. So they're kind of changing every review, but it's becoming more like a management by exception if you don't like it. Interesting. But I wouldn't trust it without a fail-safe system to go back. And that's why in the coding systems or the coding agents, you see rollbacks happening. Much like we had containers, much like we had all the infrastructure of rollback, that is now coming to your coding agents as well. And then, of course, if we're managing all these things, we also want to say, AI, you are not allowed to touch our tests. You're not allowed to touch these files. So it's almost like we have to deal with the management of who gets access to what on our systems while reviewing the stuff.

11:54 And then we have to worry about costs, right? In the IDEs, you start seeing, much like FinOps or anything, you start seeing kind of, hey, this is how much an interaction costs. Now, there's a little bit of a fallacy, like $20 or $100 might be much for a developer. In the grand scheme of things, it's maybe not that much. So don't prematurely optimize, but it definitely gives some visibility of what you're trying to accomplish there. And the main point is that if you remember the story when Dev and Ops started, it was devs throwing things over the wall, things they've never done themselves. They were responsible about that in production. This is exactly how it feels with AI. AI generates the code. We don't think about the code generation anymore. We are going to be responsible for running it and when it fails. So in that sense, we're all ops. And if I would extrapolate the story of DevOps in a nutshell, we had infrastructure as code, abstraction, automation, go faster.

13:04 Then we learned it's not about that. We need to actually have tests. If you want to go faster, we need better breaks. That's the saying. And then when it is in production, we actually need to verify and monitor. And then all the way up to, we have to monitor the unknowns, the observability. And then came chaos engineering. And chaos engineering, in a way, you could say, this is to look at the blind spots of things we didn't know and kind of keep us on our toes. But it kind of always went to a way that it's like the fireman's drill. You have to train for the failure. And it's something that people will forget or often forget is they believe like, if you put enough money in that, the automation will be perfect and we don't have to rely on it. But guess what? When it fails, it's your responsibility. You have to be aware. You have to understand the problem. So this is kind of like you go fast, but then you have a counter act. So all the people in the room thinking about like optimizing the ROI of your developers, firing people is actually what you mean.

14:11 No, right? They have to be there when things fail. They have to understand. So whatever you save maybe in faster coding, you'll have to invest and keep investing in training. Of course, you can take a risk. I've had my startup. I've taken risks. Who hasn't, right? So it's a risk game. What do you allow or how much you invest in these pockets? Because, you know, it will always say you're right. And when it fails, it will also say you're right. So be aware, this is not the perfect technology to deal with. So we're not writing the code ourselves. We're managing the agents who do it. We're trying to make sense of the money they spend. We're all managers. But let's go one step earlier in the process. What do we tell the agents to build? This is typically maybe an architect, a QA.

15:12 They put like quality assurances for actually the code being implemented. So it's the second pattern. Some of you might be familiar with some of the prompts and reusable prompts in a tool called Cursor or others. Everybody has a way to specify the agent. What you'll see is that the whole continuous prompting actually will shift to specifying more reusable prompts. Luckily, There's been a standardization across agents to use the same files. Before it was maybe your cursor rules, your cloud rules. It's almost like good that we're reusing that. And what you start seeing people do is they're not going to that continuous, almost like micromanaging the agent what they want. They start writing specifications. Very early science where people just creating a markdown file and just saying, read that file. And when I change it, do the changes.

16:14 It's a different way of thinking about it as the ephemeral prompting and more having a consistent kind of requirements document. GitHub called this two words intent-based coding. You specify the intent. The agents will do the implementation, and then you tell whether that's good or not, and you're kind of the manager again. So if you really want to specify how the technical rules are, you can do it in your technical specifications. If you want to specify the business requirements, you do that in your business requirements markdown. So it's about reusing those pieces. Now, the holy grail that people have been looking for, okay, but what's the language we do that? In essence, it doesn't matter. The LLMs are okay to use whatever system you're doing. It is more what you put in those documents. It's like, hey, I want people to do X, but can I write the test in there?

17:16 It comes back BDD, behavior-driven development. You write tests, you write things it needs to adhere to, so you start writing those down. And that's why you'll see tools appearing like GitHub SpecKit. And disappearing as well. And Kiro. So the whole point is that in Kiro, you see you have the vibe coding, which is basically micromanaging and you're in the closed loop, to more spec-driven, which is I give you the requirements, run it, and then give me the result. Two different modes, two valuable ways of doing things. And what's interesting is you start using more and more of those requirements. You also notice that people have been starting to put good engineering practices in those requirements. So not just the functional requirements, but also kind of more non-functional. And it's funny, I had a conversation about like tech debt and people adopting tests and all that stuff.

18:25 And guess what? If you want AI to actually perform better, don't use big prompts, which is basically like smaller prompts and kind of break down the whole requirements into smaller pieces. You want modular code bases because otherwise it gets caught up in too big code bases. It really needs up-to-date documentation because if your documentation is not up-to-date, the AI will give better results. And you want to have things like naming conventions, all that stuff more consistent. And then lastly, people learn, hey, actually tests are our brakes to make sure that AI doesn't go off the rockers. So what was interesting when I gave this presentation to her, I said, oh, we should do this to our code base. And I was like, why weren't you doing this in the first place? But now AI? I don't get it. Like, it's good practices, but they help both. It's good that AI is actually resurfacing them and making them hot again to do that.

19:32 And the nice thing of requirements, it is also a way that you can align on as humans, humans and agents, and agents and agents, because you've written those requirements quite well. So that idea of a prompt basically will evolve into a bunch of specifications that will get broken down into prompts. That's how you have to think about this. And we're, you know, you hear terms like prompting, engineering, you put exclamation marks, you put things in capitals, all that kind of trickery. Context engineering is making sure the AI knows what it needs to know, and then you expressing your intent, and actually be more clear, more direct, is the intent engineering. So this is the field that QAs and architects will feel best. And we're heading into a world that we care less about the details and the actual implementation. We can just run that by AI. But if you keep managing the specs, that is what we're focusing on.

20:36 So higher level abstraction and dealing with that. Not gonna lie, it's not all gonna work. If you write too many specifications, like people, things get confused. There's also like politics in specs. You need to write A, but you actually mean B, but you had to put it in from security, and it's conflicting and it's messy. But it is a way of kind of reaching a higher level of abstraction. Now the third piece is we've got the architects and the architects can say, hey, this is how you should build this. This is all the requirements. But it's actually the product owner that decides on, hey, this is actually the feature that will bring us money. So what they want to do is they want to explore fast prototypes to get feedback from their customers. And here's one of the tools they really love, like lovable, is they can express and build it your own. They often come up to me and I say, if I would ask that to our internal IT department, it would take me a month to get maybe the attention of a developer on a team to work on this.

21:41 Now I can do it myself. And the good thing is they actually learn what they really want by doing the prototype as well. Because the prototype is relatively cheap, they can ask for options. Hey, I want it dark, I want it white, I want it like this. So this is a good way of exploring, almost like exploratory testing, exploratory product design on what they want to build. And what you'll see is that maybe it's not only to do kind of variations of design, you could do that of variations of technical implementations. And of course, you can use the same parallelization of agents to do multiple tasks as one. But then the problem actually becomes, how do we make tasks more independent of each other? Again, the world of product owner is used to kind of define and say, hey, here's a piece, independent piece, you do that, you do that, and then you come back together. So if you have the agents trip over each other, you have the same problem.

22:43 So there's an art, there's some fun, and there's some improvement. People have been doing this on their laptops by checking out multiple Git code bases or from the same repository, have multiple agents, they have multiple results, and then the merge things. But we could also do this in a container. And what you'll see is that more of these tools actually are leaving the developer's laptop and are just starting to run headless in the cloud to do things. So it's going to be cheap to kind of build those variations and do those runs. And now we actually need a system to manage the agents, much like we have our Tira board or Kanban board. We need a backlog system for agents where we assign things, hey agent, do this. In our company, the developers love to assign, please write me the docs, please write me the tests to the agents, the pieces they don't want.

23:45 It doesn't matter. It's a visibility of flow and follow-up. And so the IDE, and I talked about this, is about managing the multiple agents at the same time and actually looking at the different pieces. And it could be in your IDE, it could be on the web. Like all those sessions become more asynchronously as coding. And then the last pattern is about how do you extract this as knowledge? Because we've learned all these things, we know what to build, we know how to build it, we got the feedback how it was built. And where do you look for knowledge? Right now? Maybe in documentation. We feed that to the agent. Does a better job. But you can use that knowledge to take your code base and actually turn that into a lesson as well, maybe for new people joining as well, or the drain of people leaving might be different right now because people can explore the code bases. And so what you see is that learning of knowledge is becoming an integral part of actually decoding agents and the models as well.

24:54 So that's the ultimate form, right? We've been running, automating more, we know what to do, but keeping That knowledge is actually the instrumental part. Onboarding new devs, I mentioned that. And the agent is also to be onboarded as well. It is not just readable for humans, but is your documentation optimized for agents to consume? It gives a different view. It's almost like SEO optimization, but agent optimization from all the pieces of documentation you have. And you start seeing tools that we use as humans that have an equivalent mode for agent use. This is a simple button, like an NPM install, but it has a setting when you say cloud code, it goes true, it behaves differently because it's optimized at that time for agent. And we could do this not like while we did all the coding, let's save all the knowledge.

25:56 While it's coding with us, it says in this example, hey, I think this is important. Should we save this as knowledge? So while the agents are coding with us and we say, well, this documentation was not up to date. I think now we should do it like this. All that knowledge gets saved in the agents and by the agents. So this might have a standard better shot at keeping documentation up to date because it's being used all the time. And then not one agent, but multiple agents. And if one coded agent learns, we should do it like that. Why doesn't he pass all that knowledge to the other agents so they don't make the same mistake? It's kind of that backbone of knowledge. It's going to be more and more important. And then we can use that knowledge either to engage again with humans and say, humans, you said this, but actually we learned already it's like that. So how many times have people repeat the same mistake over and over again on a project, but now you might save that knowledge? And in a nutshell, these are four patterns, and I know I'm out of time.

27:01 But what is funny when you look at those things, if you're a senior developer, you know you have to care about operations. You know you have to kind of have a good architecture. You know you have to build something for end users. And you know you have to keep the knowledge within the company. So AI is just supporting that journey in a good way to keep us on track. And while some might say, well, requirements and specs, what's new there? We had UML, all reviews. That's just going to be agents solving this. I think, yes, the tools is important, but the craftsmanship of doing this is equally important. And I don't think we're there yet. We can code faster, but all the other pieces still need a lot of love. And I hope you can kind of see that and help your developers through that journey and go from there. So it's almost like there's a new pipeline working on the laptop for the developer.

28:05 And not one pipeline, but you're... eight agents during the pipeline. So for me, this is, I don't know how a DevOps pipeline will look like, but it isn't until this process will settle that we can actually start discussing this for what a new pipeline will look like. And what a new coding metric? I don't know. All the existing quality metrics, flow metrics, they all apply. There's nothing new there. Maybe we want to have the AI better understand us. So maybe one of the metrics is how fast does AI actually understand what we mean? And there's a lot of things we can put into knowledge and go from there. And yeah, okay. We'll still have the what the fucks moments, but it will always say we're right. And I think the actual kind of goal is similar to what Booking.com was. It was not continuous integration, continuous delivery. It is about continuous re-architecting and actually swapping things in and out, new technology being agile at that moment.

29:11 Yes, we had our cloud moment, but how easy it is to swap in a new cloud out, how easy it is to swap in a new coding tool out. You can find more. This is my LinkedIn if you want to scan it. You can find me at the community where I post some stuff. And I happily take more questions about this. Thank you very much for listening. Bravo Patrick, merci beaucoup. Prêt pour une Q&A session? Are you ready? Of course. Maybe we'll be in French or in English, we will choose according to the audience. C'est bon. Ok, très bien. Alors, oui parce que c'est mieux là quand on voit tout le monde. Ils sont beaux, ils sont beaux, non? Ils sont beaux. Oui. Non, oh! Vous n'êtes pas convaincu qu'ils sont beaux, mais ils sont magnifiques. On est d'accord? Oui. Alors, y a-t-il des questions dans la salle? Deux, très bien. Alors, deux questions sur la droite pour moi, la gauche pour vous. Je crois que c'était... Oui, monsieur, d'abord.

30:12 Alors, de bien vous lever, merci, et votre prénom? Laurent. Enchanté, Laurent. Patrick, Laurent, Laurent, Patrick. That was really very interesting. Thank you. So from what you said, and it really makes sense, we will have to make more documentations because a lot of things... Are communicated between people just by voice and not written. But from now with AI, so they don't communicate like us and they will have to read things. And so we will have to put down, write down much more things on in documents. So that makes sense. But I'm wondering whether that might become a new problem because we will be overwhelmed by documents. Yeah, I think it's a good question. I hope we had our wave about knowledge management with the semantic web and kind of dealing with all that information and that drove us to write already more documentational wikis.

31:23 I think we stand a chance with this to actually have it do in line like a show. It tells us what do you think? Should we add it? So it doesn't become too much of a burden. But it also shows that to say whether documentation is good or bad or keep writing it, we still have to understand the system. So that's kind of the counterpart of, hey, let's automate and abstract all the devs away. We still have to know what good looks like. So these systems will help us. It's not going to solve our problem of outdated documentation if we don't put in the work. But I think the main thing is a lot of people almost treat AI as mind reading. Of course, it doesn't know what you want if you don't specify it more in detail. But if you micromanage the knowledge and you give it too much, it's also overwhelmed. So it's the same problem as you would have to deal with humans. But with the new technology, I think we can get like an improved version of our documentation there. So, yeah, you're right.

32:25 Okay, there was another question, yes, just behind. Thank you for the mic. What's your name? Hi, I'm Emmanuel. Actually, I have a two-fold question. The first one is about the way that developing with the AI. changes the culture of development, meaning the focus is completely switching to doing the code, writing the code to presenting what should be done by the iAgent. And so, for instance, for me, it helped me moving my trash down, like, because I had time to to take my trash waiting for the agent to finish the job. And then the level of thinking I needed to produce to actually tell the agent what to do and refine what I wrote about what they had to do was taking me a lot more energy and a different type of energy. What do you think is the kind of, with this impact, we'll have on everyday's work of a developer?

33:29 Yeah. So first of all, maybe on your remark of, I have to put in a lot of effort to do it. With kind of capturing a lot of what you asked for in more specifications, so it's always available for how you would like to have things, that requires maybe a bigger investment up front, but once you have it, you kind of see the gains of not having to repeat yourself. So that's a little bit like reusable kind of prompts, reusable specs that will kind of save you some time. And I've seen that over and over again. People say investment, but then it's kind of a payoff. So it's a trade-off. How it's changing the developer's role. Yes, you're supervising. I think I try to stress that you still have to know what good looks like. One of the tensions that often come up is, but I actually like to write the code, everything. Like, I like my craft, and that's great, right, if that's what you do. But you weren't there in the company to do your craft fun.

34:33 You're there to make a business, in a way. Now, I think when people say this to me and I say, well, I don't like to do just reviewing what they need to do. I say, do you like to explain how you do things? Are you the architect? And so I try to move them to that role is you want to capture all your knowledge. You want to do like experiments, whether your knowledge is right or not. And I try to move them there. So they're still like. feeding the technical requirements with their knowledge and still doing that. So that's kind of a direction that I kind of steer them from, A, micromanaging what you do, to where it's like B, kind of more of the senior leader that kind of tells how you want things done. And do you agree that the energy of reviewing written statements instead of writing and reviewing your own code is a different type of energy and is initially quite tense and difficult to just capture? Sure. But it's a process that when you kind of go into the IC ladder and you're like a principal engineer, that's what you do.

35:42 So it's a different energy, but it's also a different role. But it's typically because you're mentoring, you're managing to do that. If you want to do kind of still do the detailed coding, I'm not saying these people go away because when things fail, we still need kind of like the more detailed person and that stays, but it might not be on the day to day. So they might have to stay more up to date in case of a failure. So they switch to the ops role maybe when it fails. But I understand it's a different kind of job and maybe they didn't sign up for that. But it was the same with middle management of DevOps. They were there for coordinating between the things and then all of a sudden we kind of moved it away and they had to form a different way of kind of like, and then they became the facilitators of stuff. So that's kind of, we don't know where. This is moving, but these are patterns that seem to be happening. And my second question, if I may, was about costs. Because when you talk about swarms of agents, already looking at the price of some of the models, especially the, for instance, Opus student cloud, which is really expensive, even though it just does a good job.

36:48 But then when you have a swarm of agents all calling and calling your lamps, the bill becomes quite high, especially when Microsoft said that we're only paying $20 a month for the work, and actually the real price would be $1,500. So what's your take about that? But I think the point that I was making on cost is that even if you're spending a certain amount of costs, how much time is it saving? Can you kind of level up your intern much faster? So the ROI kind of shifts to that. Are they all, I think every AI system right now is not it's just not gaining money because they're kind of selling it too cheap for market share so but i do see that like if you want to use the same technology as a year ago like on technical level what it would cost to run it it is going down of course this field is still so evolving there is always bigger and new ones but the older ones actually do go down in cost so

38:00 Where that cut-off is going to happen, I don't know. But it's still the ROI that we're kind of doing. And I think in the first years, it was on the marketing budget because we had to have AI. Right now, it's like your cloud budget. You'll have to have it. But whether that gives you the return on investment and that's kind of... Doing more coding but still doing the review and kind of training it is a little bit shifting complexity in a certain way but you can go faster maybe as a solo person but that's then the cost of coordination that goes down so um it's hard to answer kind of like in general or where this will happen but cost will play a role but i would argue like right now if you can don't let it block you on there thank you so much patrick and bravo merci merci beaucoup merci à très bientôt