AI Native Dev: Shaping the Future of AI-First Software Development - DevOps Chats Episode 12

Speaker A: Foreign. It's Alan Schimmel. Welcome to another episode of DevOps Chat. So this chat is actually, uh, a sit down I did with my good friend Patrick Devoir. If you're familiar with DevOps, Patrick needs no introduction. He literally gave it its name. Um, Patrick is passion has been reignited with AI and he has hooked up into a community started by Guy Diplo,

Speaker B: ah,

Speaker A: founder, co founder, former CEO of Snyk and some others, uh, called the AI native dev community. And it's @ainativedev.il. uh, this conversation is all about that and why Patrick is so passionate about it. I hope you enjoy it. And Again, welcome to DevOps Chat. Hi everyone. Welcome back here to TechStrong TV. My next guest needs no introduction to anyone who's involved in the DevOps world in any way. But really, who knows, he may be more well known eventually for what he's doing around AI and a new kind of movement in AI or a new motion in AI that he's pioneering and talking about. Let me introduce you to my friend Patrick Dubois, who joins us today from his home in Belgium. And Patrick, it's fantastic to have you on. I hope you've been well.

Speaker B: Yes, you know, it's kind of, ah, an interesting time to be alive, let's say it like this.

Speaker A: Yes, it is. It's like that old Irish proverb, right, that you live in interesting times. Maybe a little too interesting, but, um, nevertheless, we're here and the only thing, you know, Patrick, we're of an age. The only thing we know how to do is put one foot in front of the other and keep moving forward. That's all we can do, right? You can't sit and cry or you can't, you know, there's no time and no one's interested.

Speaker B: Are, uh, you saying, like, you try to make sense of reality and when you get old, you think about like, oh, well, compare it to something in the past and then you actually, it doesn't make sense because it's new, right?

Speaker A: And hence it's new. Um, so, Patrick, you know what? Some of our audience may not know what you've been up to for the last year or two. Right? I mean, DevOps is established and it's all of that, but really, AI burst on the scene. And like any curious, intellectual kind of person you looked at, hey, how could this AI help us? How can we use AI? Uh, how can we leverage AI? Tell people a little bit about your journey over the last year or two.

Speaker B: Yeah, so I always jokingly start that after starting DevOps in 2009. I got like pretty bored with it after so many times because we're iterating on the same things and it keeps on being kind of told and uh, it's a story worth selling. But uh, I must say AI reignited kind of my passion around technology, around kind of organizational things. And over the time now of those two years, there's been like two threats, well, many threats, but you know, predominantly, ah, the first one was more about using AI inside of the products. That was the initial craze. Everybody needed it somewhere. You know, the chief product officer was saying we need it, our competitors doing it, kind of, um, how do you deliver products, AI inside of this? And then my kind of interest was with engineering rigor, right, because it's all fun to say, hey, it works, uh, like we used to say, it works on my machine, but how about making it work inside production? So that was kind of my first thread eventually, roughly, um, half a year ago when coding with AI. So it's a different threat. It's not in your product, it's within your engineering. That came kind of more under steam and kind of there were more products, there were more technology, uh, how do we actually deliver things with AI? So that's more AI in the sdlc. Where does it fit in? How does the life of the developer will change? And I'm trying to steer clear of developers are that DevOps was that. That's just clickbait, right. So kind of what is actually happening and trying to make sense of that space. So those are kind of the two areas that I shift in between. And then the third maybe long running thread is how does it change the organization? Because in DevOps there was a technology part. There was automation in the product, in the engineering, the pipelines. But eventually we also changed the way we organize ourselves around a new technology. So that's kind of roughly a longer term running thread, uh, in kind of AI organizational wise. What does it mean? So those are kind of roughly my three threats over that time.

Speaker A: Absolutely. And you know what, Patrick, here's the good news. I think I've never seen sort of um, not a movement, but a technology. If you will accelerate so fast, like the, you know, we're used to living in Internet time crutch, living in AI time is, is yet even more condensed. It seems more compressed. Things are happening so fast. I remember we did the hacke on here in my office. It's got to be a year and a half, maybe more ago. And you know, we were talking very theoretical operationalizing AI, but really using AI to do coding. Yeah, it was, it was a smoke, uh, and mirrors. It was a cheap parlor trick, if any. You know what I mean? It wasn't, it wasn't anything that was sturdy enough I would put my weight on or. Yeah, and I'm not saying it's perfect today, but think about how far it's come in just a year and a half or so. You know, I. We looked at a new tool the other day. Deep source, I think it's open source and it's. It's LLMs. That's really, uh, you know, just specialized for coding.

Speaker B: Yeah.

Speaker A: And it. I mean, heads and tails above what we saw a year and a half ago.

Speaker B: Yeah, that makes, that makes sense. And if I would kind of roughly describe, you know, in a nutshell, what kind of move over year in that space. So initially we thought like, oh, we're going to ask, like, similar to ChatGPT, change our code. Right. Here's a code. Generate me a code snippet. Like, you know, that was the early feeling in there. Then we said like, oh, um, what about, I have a piece of code already. Can you change this? So that kind of required some new tricks. Like, it was not the traditional LLM, but it was the fill in the middle kind of logic that allowed us to insert code in there. That kind of, um, matured into, well, what am I doing on, uh, multiple files? So it wasn't that one file, it was the whole code base that we were refactoring. Uh, so kind of that is an evolvement of people often think about, oh, it's the one LLM. No, no, we kind of progressed. Now the next step was, is, oh, we have all that documentation. Hang on, we can use this to generate better code. So given this documentation, given what I asked to do the change, can you improve this? And so you saw a lot of kind of new, like, where do you get context in your ticketing system, in your documentation, on your Slack, like, you name it, on your runbooks. So all of a sudden all that context was added to the mix, creating better code generation. So that was already kind of like a first sign of, oh, hey, I can actually reuse part of this. And it just got better. That was still, you know, uh, let's say less. Uh, it was kind of a year ago, right. That we ended up. It was getting better and people were getting excited. Um, and then we said, like, okay, but why are we still typing that code? Uh, why are we not continuously prompting? And then later, that kind of Got like tied it into vibe coding. But it was the idea that if I express what I want, it gives me what I need or it doesn't. And when it doesn't, I just tell it like a human person. Please change this. So you got into this more like I specify intents and I don't worry about the implementation too much. Yes, of course we care. But you got into like a higher level of abstraction in that stuff and that, uh, that, that is changing the mindset because generation is becoming cheap and that's something that helps.

Speaker A: Now, uh, let me ask you a quick question on that though, Patrick, because I asked someone today, I was speaking to the folks at Cohee City, they bought Veritas in December. So they're big data management and everything else. They're creating agents and agentic AI agents, uh, to really go through people's data and stuff. And I asked them, do we still need a ux? Do we still need an ide? Or is it all, Are we all destined to just, you know, all of Star Trek? Hello, computer. Um, yeah, where. What do you think the effect is on that? Are we moving away from the standard interface?

Speaker B: So you have the, on the one hand, the spectrum that people says like, you don't have to look at the code anymore.

Speaker A: Right.

Speaker B: And ah, it's a little bit like, well, why are you still looking under the hood of the car? If it works, it's great. Right. And I just need my dashboard with some lights and I don't care about the machine working anymore. Um, there's a couple of problems with that. And I often refer to a paper called the Ironies of Automation, which was also instrumental in resilience engineering and in the aerospace about like automating things. So the more you automate, the less you're still used to doing that job.

Speaker A: Right.

Speaker B: So because the automation take care of it. But there's a couple of things. When the automation gives you the output, you still need to know what good looks like. So that's kind of like tricky these days. Like, how do you know that the code it was produced was actually good code? Okay, maybe I'll give it some tests. And then we're back to, oh, we have to write tests. Okay. That could be part of the specification. Okay. But if it's almost like a human. When a human says, like generates me something and you are also the judge. Hey, you know, I, I don't know. Okay. People have tried to have one model critique another model and we're trying to do our best to kind of overcome that now, uh, the clue is if you take that a step further and it's not about the code it produces, but it's running in production and it fails. So who comes in, right, who still understands that? Because that person didn't go through the process of thinking how it was done. It's almost like diving into somebody else's code base, which is messy, not meant for you to be understood. Uh, and yeah, how do you make sense of this now? There are signs that some of the tools are actually entering that space. And it's almost like think um, of it as, um, cognitive load reduction for reviewing and understanding what happens if the tools start helping us adapt, almost like the IDE or whatever for the problem at hand. And they help us make sense of this either by showing us some information, helping us maybe with a diagram of the code, maybe understanding, uh, summarizing the changes, then we can do that.

Speaker A: That would be great, right?

Speaker B: So the whole concept of changing an IDE into something for review or whatever the task is at hand, there's a term for this and it's called like the moldable development environment. So it adapts itself to whatever you're doing as a task. It is not per se, the code. It could be code, but maybe there's other ways. If you're writing some terraform code and it is about aws, you want to see a diagram, it's a lot easier to see what changed, what is the impact. And that moves into a multiple exception. If the exception happens, we have something to show us and understand what fails. Now, I often talk about the journey about the automation of DevOps. And you know, early on we had, hey, let's generate some code and do this better. Okay. We had get some local tests and that was good. So remember the test that I mentioned? Then we had some CICD system. We kind of deployed this automatically and so on. But then we had monitoring. So we're still kind of figuring out what the co version of monitoring is of those agents. And if you take that a step further after monitoring, we had resilience engineering for when it failed. We kind of adapted the architecture of our systems. So you see before, uh, for example, in ide, like if you take Client or a few of the other new agentic coding things, there's like a checkpoint that you can roll back. Yeah, right. So you see there's, there's something there that's like becoming a safety net of when you do the coding. Um, I don't know what it will be in production, but you kind of See that uh, and then we had observability because then we couldn't anticipate what was going to be wrong.

Speaker A: So we needed a better way to

Speaker B: understand situational awareness and to go that. And then if you want to top that in the DevOps journey, the last part was chaos engineering. We were not used anymore to deal with any failures. So what do you do as a fireman who's not used to dealing with fire drills? You train them.

Speaker A: Right.

Speaker B: So whatever the automation we had to work on observability and all this stuff and training. Now you can take the shortcut and don't um, care about all that stuff and just figure out uh, like I'm going to go to the coding. Well that's your choice and that's your appetite for risk.

Speaker A: You know what? Right. That's exactly. That's a risk management solution. Understanding that it's fine as long as nothing happens.

Speaker B: Yeah, indeed. Yeah.

Speaker A: But life doesn't work like that.

Speaker B: True. And so kind of um, it is interesting like any new technology it was there with, you know, whether it's mobile or serverless and you name it cloud, the first phase is always about making it work. Why? Because that's the thing that gets you the value immediately. Ah. And then you kind of hopefully make it a little bit more robust. So in the island, while that was the initial kind of talk of the town early on, now everybody's talking about evals and testing and observability. Right. So you see that's kind of a next part. Uh, and then the struggle. How does it work? It's non deterministic. We don't know how to test this stuff and kind of people. But you see that evolvement just happening and it's interesting how that kind of automation pattern somehow repeats itself. But we're just as an uh, industry learning what the practice would be. And there's always going to be the one person who says like ah, I'm doing this. Oh this is really interesting, we should all do this kind of. And that's why community and getting stories that about this is what I love in these kind of chaotic emerging times, uh, and learning from each other.

Speaker A: You know we did a tech strong gang show this morning. We had a bunch of people talking and one JP Morganthau was on and he said something that made sense to me which is even if it's good code, when you do coding you can look at the code you wrote, kind of like what you said before, you could look at the code you wrote and you wrote it and you kind of. It looks right to you, you know what I mean? You could follow the logic, you could follow the syntax, you could follow it. It looks right when it's someone else's code. And in this case, code generated by AI, you said looks good. How do you know it looks bad? You don't know whether good or bad unless you're going to do some sort of analysis to, you know, and like you say, notate in the idea. Okay. This is what this is, this is what that's doing. But you also need that if you're ever going to troubleshoot something. Right. Whoever's had a computer system where we didn't have to troubleshoot something. So I, I don't know if that ever goes away. Maybe AI will help us do that analysis as well as generating, as you say. But you're still going to need to have that done. But the other thing that we spoke out today is. Look, Patrick, God willing, you and I are sitting here in 2029 and we look back on 2025, April 2025, and we laugh and chuckle because things were so immature then.

Speaker B: Yeah.

Speaker A: Compared to 2029, let's say it's just four years away. Um, we have to remember that, that this is still, you know, I know John Roylance's book just came out, that we've been doing AI for hundreds of years, really. But the fact of the matter is this is still a very new sort of technology and it's ever really quickly changing right now. So if you blink, it changes.

Speaker B: Yeah, that's why I love it. Like, I've never learned so much in that short of time in my career. Right.

Speaker A: I agree.

Speaker B: I've seen a lot. But.

Speaker A: Yeah, no, but these are. No doubt about it. Now I want to turn a little bit.

Speaker B: You.

Speaker A: You've coined sort of a new phrase, if you will, a new. I don't want to call it a methodology per se, but share with our audience what you're really kind of talking about now.

Speaker B: Well, thanks for giving me that much credit. I think coin it this time, but, um, like Guy Pajarni, one, uh, of the farmers, so kind of like, um, he started calling this maybe more AI native dev and kind of specification centric in a way that, you know, kind of like we mentioned the intent and you look at the specifications and I've been looking for a while, uh, and going to several different conferences and there's always this mixture about like, okay, there's people from the data world and they talk about training models and there's people around kind of like the coding. And they say it's a co pilot. But what fundamentally changes and what's nice is that I looked around, I couldn't completely find a home perfectly. And then we're already thinking about it and they call it AI native dev. And that's kind of where they asked me, like, can you help us make sense of AI native dev? And, um, the interesting part is they asked me, can you kind of describe the principles? And, you know, I might ask you

Speaker A: to write a manifesto. Did they? Yeah, yeah, yeah.

Speaker B: So everybody wants that, like, including you, Alan. Right. And you know that that's not me, right? I can't push things. I'm an observer. Right. And so that's why I call it the, uh, native death patterns, not principles. And I started like describing the things that I see in tools. And obviously it's a narrative, but it is kind of what I observe and the way that I try to make a mental model of the world. Now you can have the whole discussion about, well, if it's Dev, are, uh, DevOps included? Are security people included? You know, in a way, everybody's a dev now. Everything is as code. So I'm kind of skipping that, like, thing and don't read too much per se into a label. DevOps was a bad label because everybody call it like DevSecOps, Biz, DevSecOps and whatever, Op. Um, so just think of it like when there's a new emerging tech, have a label, put the stories under the label so we can find and share that story. Right? And I came to this as four different patterns. And it's not rocket science, but it is a little bit. Just making a structure of this. So imagine you're a developer right now. You do all the coding. We briefly touched about it that, um, you're doing the coding, but all of a sudden somebody else is doing the coding, right? So where you first were the producer, now you become the reviewer. And if you look at it even further, you become the manager. Like somebody's working for you. You just say, hey, this is what good this? Yeah, just go to production. No, no, no, this is failure. Please fix this. So kind of is the first pattern is from producer to manager. And it's almost like a dev will start becoming the ops person that reviews and get everything that needs to be decided. So a typical mature person developer will already have affinity, maybe in the ops part, but now as they do less of the coding themselves, they might be going there. So that's kind of first direction. Now if you Go back a little bit earlier instead of just being generated. Um, we talked about specifying things, right? So that's the new role. It's not about just watching and then saying the code is good. If you go earlier is that, uh, just write the specifications and help us write the specifications. If you are somewhat of a senior developer, you're already doing this because you try to understand the business domain and you help the business domain. So you are going from implementation to intent. I tell the intent, I capture the intent of what needs to be built, right? And you see that in more and more tools they go to don't give a prompt, but give me a product requirements document. And so you see that popping everywhere in code editors that some kind of interface of these are the tasks, this is the description, these are kind of the specifications of things that need to be done. So that's kind of like the second one. Now how do you know what you want to build? Because you know, you can write specifications, but if you have no idea what to build, uh, you come into the realm of the product owner. The product owner is the one that's supposed to do this. Now a product owner these days, they can build fabulous prototypes because of this new thing. They can try, they can see what works because they often have this discovery phase, what is actually what we want. And they start with a vard, they try a few things, they try something else, they see what sticks. And after that period of more creative exploratory, they know better how to write the specifications and that the specifications go to code and then we do the management in the review of the code. So you see it's like a build up in there. Now all the knowledge about a domain, if your company is in medicine or your company is in marketing or kind of here in video production or something, or conferences, you have domain knowledge, right? So whatever you'd like to do is to capture actually knowledge because that's your competitive edge. If everybody's able to do the coding, everybody's doing the exploratory, what is the part that is left for you is to capture the knowledge and to be the best at, uh, dealing what kind of knowledge you have. And it's not just about the exploratory, but it's keeping track of what did we learn today in the past, what is new, what we can actually get from there. And one of my favorite examples of this is there's Devin, which is the automated kind of coding agent that took the world by, you know, storm and kind of they had like a Big marketing messaging around that. One of the features is imagine you're chatting with your coding IDE and say, hey, um, I want to have this code produced and these are my prompts and this I want to do it asks the end user, I think this is important. Should we save this as knowledge? And obviously this helps the AI by keeping track of the memory of this knowledge, but it also helps the human. So if we start building that knowledge, the next person coming into the code base, they have access to that knowledge. So kind of that flywheel of building things up in exploratory and then having the AI capture the knowledge and kind of that is in a way that what I see happening in many of the tools now, it doesn't sound spectacular, but it's in a way that if a new technology comes in, it has an impact on people's tasks. Now, uh, some of the tasks will be automated, some become obsolete, some will be just assisted. And that means that people are going to do different tasks and some of the tasks are changing. And that's kind of what I see is the transformation or kind of the transition, more than transformation that the developer is going through. So you see people caring deeply about the code, then they kind of, hey, this is what I want. So kind of that gives people a, uh, journey. Are you going to go more into reviewing code and operational code? Are you going to go more into the exploratory phase of that? And maybe over time people accumulate that experience in different things. So that's in a nutshell what I think about the patterns and how you can think about how your life is changing as a developer or as an IT person. And it also helps the manager, um, to understand how they have to coach the people in engineering to kind of like be prepared for the new job. So not just say you're, you're, you're the expert in coding. No, no, no. You kind of have to give them a little bit of everything so they kind of get that maturity. So it's not just full stack, it's more that kind of full task. I, I don't have a better word for this.

Speaker A: No, I, I think it's a great word. So do you envision AI native dev, uh, as an intermediate sort of way station or where we may get to relatively short long term? Or is, is it, is it the ultimate destination? Is it the last stop on the train? You know?

Speaker B: Yeah, Um, I think there's a. The product Lovable says this is the last coding editor you will ever use. Right. So, ah, big bold Statements which is kind of pushes us forward. Now I often make the comparison with, um, autonomous vehicles. So there is a certain belief if we just throw enough money at the problem, that will get to where we kind of dream to be. Now it's proven that there's always something in the way or something in between. So it might take a long time before we get there. Now, it doesn't mean it's less useful, but it's just we have to cope with that intermediate state. Now if you ask me how long that intermediate state would be, it could be two years, it could be 10 years. I don't know. The one thing that, uh, if you say we were looking back in 2029, right, uh, kind of on this, this technology is inherently flawed. It is a completion. It is not an exact thing. So I still have to think in my head, like, we could get close, but I cannot deal in my head that we can make it perfect on this. So there will be human element, there will be a review, there will be something. But will it be faster? That's also kind of under debate. All the time we spent in speeding up the coding will spend in reviewing and training. So is it just shifting complexity around? It might be. Um, but also, I don't know, all the breakthroughs, you know, of whatever these crazy people of the models are doing. Right.

Speaker A: So, yeah, I mean, and that it's not just shifting it around because, uh, like for instance, training. So you put your time and money into training, your effort into training, and now you're trained. And so it's almost like the difference between Capex and opex. Do you know what I mean? Training to me is a Capex, but it lowers my OPEX going forward. Right.

Speaker B: Yeah.

Speaker A: Um, so I, I, I hope, I, what do I know? I mean, honestly, right. I don't at this point I just sit here and observe and, and try to just take it in. I, I don't, I don't know enough to know what, I don't know.

Speaker B: Um, but m, Let me give you that example. If you're, um, we can all generate images and videos, uh, now thanks to AI, right. Um, but I have one of those things. I'm colorblind. I don't probably have an eye. I cannot express what a good picture looks like. I have not been trained for this. My son and my wife, they know exactly what they want. Like, the design should be like this. This is cool. This is not cool. So even if you democratize a certain technology, it doesn't mean everybody's able to Use this. Right. And we see the slop coming out of, uh, the eye generated. And even if it's a pixel perfect picture, it might not be considered a good picture. And that's kind of puzzling in a way. Right.

Speaker A: Well, because art's in the eye of the beholder as well. Right. And there is that aspect to it.

Speaker B: Yeah.

Speaker A: Patrick, we got to wrap up. But for people listening and saying, you know what, this strikes a chord with me. This, this sounds like something that makes sense. I'd like to do a deeper dive. Uh, where would you send them to do a deeper dive here?

Speaker B: Yeah. So the community place is ainativedev.IO, so you can go to that site, and that's kind of like a new site where we kind of report on things. We also have a discord for this. Um, we have a podcast around this, and we're also doing, in a couple of weeks, uh, a conference, uh, on this as well.

Speaker A: So is the conference virtual or in person?

Speaker B: It's virtual, yes. Yeah, so. And it's one of the unique things that it's like, solely focused on AI in engineering, uh, to do that. And one of the bonus sites is if you're interested in all the new tools that are coming out, uh, we created a site similar to the cncf, but just for the new tooling. And it's called, like, landscape ainativedev.IO we already have 290 tools that we categorized from document to product to reviews, security tools. So you don't have to feel the FOMO of you're missing kind of whatever new tool comes out. So you can just join us. Ah, definitely.

Speaker A: Patrick, God bless you, man. You managed to stay on the edge of what's happening. Nope. As it keeps going, you keep going with it. That's fantastic. I wish you the best of luck. And it's going to be interesting to see how AI native dev continues to progress as this whole thing continues to turn and gyrate. Please keep us posted. Um, it's a native. Native dev.IO yeah.

Speaker B: IO, uh, yeah, we couldn't get the AI, which is ironic.

Speaker A: Go figure. Well, but IO might be going away. Be careful.

Speaker B: Yes.

Speaker A: You know what they say, they're taking the top level. Yeah. All right, Patrick, I hope to see you in person soon, but until then, keep up the great work. We'll check in with you. It's just. Always a pleasure, my friend. Be well.

Speaker B: And it's always fun to be on the roller coaster together. Right?

Speaker A: Absolutely. Screaming Dr. Dubois. Ainativedev. IO, uh, go check it out. We're going to be back. You're watching techstrung. Hey, everyone. I hope you've enjoyed that conversation with Patrick. It's good to see Patrick's creative juices flowing again. Um, I'm excited by the potential of the AI native dev community, and we'll be following it on DevOps.com techstrongtv and right here on DevOps Chat. Until our next one, though, this is Alan Shimmel. Have a great day, Sam.