AI Native Dev: Shaping the Future of AI-First Software Development – DevOps Chats EP12

Hey everyone, it's Alan Hummel. Welcome to another episode of DevOps Chat. So this chat is actually a, a sit down I did with my good friend Patrick Vois.

If you're familiar with DevOps, Patrick needs no introduction. He literally gave it its snag. Um, Patrick, his passion has been reignited with ai and he has hooked up into a community, started by Guy Dipo, uh, diving of founder, co-founder, former CEO of sny, and some others, uh, called the AI Native Dev community.

io. This conversation is all about that and what Pat, 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.

You know, my next guest needs no introduction to anyone who's involved in the DevOps world in any way, but really he who knows, he may be more well known eventually for what he's doing around AI and a new, new kind of movement in ai or a new motion in AI that he's kind of pioneering and talking about. Let me introduce you to my friend Patrick Debar, who joins us today from his home, and you're in Belgium. And Patrick, it's fantastic to have you on.

I hope you've been well. Yes. You know, it's kind of, uh, an interesting time to be alive.

Let's say it like this. Yes, it is. It's like that old Irish proverb, right?

Yeah. That you live in interesting times. Maybe a little too interesting, but Yeah.

Um, nevertheless, we're here and, and the only thing you know, Patrick, where of in age, the only thing we know how to do is put one foot in front of the other. Mm-hmm. 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.

I you say it like you, you try to make sense of reality, and when you go 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? So, right. Yeah.

And, 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 then, you know, it's all of that.

But really, you know, AI burst on the scene and like any curious, intellectual kind of person you looked at, Hey, how can this AI help us? How can we use ai? How can we leverage ai?

Tell people a little bit about your journey over the last year or two. Yeah. Um, so I, 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, it keeps on being kind of told and it's, it's a, it's a story worth telling. But, uh, I must say AI reignited kind of my passion around technology, around kind of organizational things and o over the time now of, of those two years, there's been like two threats. Uh, uh, well, many threats, but, you know, predominantly, uh, the first one was more about using AI inside of the products.

That was the initial craze. Everybody needed it somewhere, you know, uh, the, the chief product officer was saying, we need it, our competitors doing it. Uh, kind of, uh, how do you deliver products within inside, uh, AI inside of this?

And then my kind of interest was would engineering rigor, right? Because it's all fun to say, Hey, it works. Uh, I know like we used to say it works on my machine, but how about like, making it work in inside production?

So that was kind of my first threat eventually, roughly, um, uh, half a year ago when coding with ai, so it's a different threat. It's not in your product, it's, 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 SELC. Where does it fit in? How does the life of the developer will change?

And I'm trying to steer clear of, you know, developers are that DevOps was that, you know, kind of that that's just click bait, right? So kind of what is actually happening and trying to make sense of that space. So that, those are kind of the two areas that I shift in between.

And then the third, maybe long running tread 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 the 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 were kind of roughly my three threats over that time. Absolutely. And you know what, Patrick, the, here's the good news.

I think I've never seen sort of a, not a movement, but a technology, if you will accelerate so fast. Like the, you know, we're used to living in internet time, time crutch, living in AI time is, is yet even more condensed. It seems more compressed.

Things are happening so fast. But I remember we did the hackathon here in my office, it's gotta 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 smokey mirrors, it was a cheap parlor trick. If, if any, you know what I mean?

It wasn't, it wasn't anything that was sturdy enough, I would put my weight on it. 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 the, it's open source and it's, it's LLMs that's really, uh, you know, just specialized for coding. Yeah.

And it, I mean, heads and tails above what we saw a year and a half ago. Yeah, that makes, that makes sense. And if I would kind of roughly describe, you know, in a nutshell, what kind of move over a year in that space?

So initially we thought like, oh, we're gonna ask, like similar to chat GPT, change our code, right? Here's a code, generate me a code snippet. Like, you know, that was a, the early feeling in there.

Then when we said like, oh, I, 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 kinda logic that allowed us to insert code in there that kind of, um, matured into, well, what am I doing on multiple files, right? 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, 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 to change, clearly 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 run books.

So all of a sudden, all that context was added to the mix creating better code generation. So that was already kinda 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 it 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, and that later, that kind of got like, tied it into vibe coding. And, 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 intent 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.

Sure. And that, that, that is changing the mindset because generation is becoming cheap. And that's something that helps.

Now let Me ask you a quick question on that though, Patrick. 'cause I, I asked someone today, I I, I was speaking to the folks at Cohesity, you know, they bought Veritas in December. So they're, they're big data management and everything else, and they're creating like agents and, you know, agent AI agents and, uh, To, 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 a Star Trek, hello computer, right? Um, yeah.

Where, where, what do you think the effect is on that? Are we moving away from the standard interface? So You have the, on the one hand, the spectrum that people says, like, you don't have to look at the code anymore, right?

And 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, I don't care about the machine working anymore.

Um, there's a couple of problems with that. And I, 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 there, the less you're still used to doing that job, right?

So, because the automation take cares of that. But there's a couple of things. When the automation gives you the output, you still need to know what good looks like, right?

So, 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 eh, 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, we're trying to do our best to kind of overcome that. Now 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 could 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, um, think of it as um, cognitive load reduction for reviewing and understanding what happens if, 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, you know, showing us some information, helping us maybe with a diagram of the code, maybe understanding with like, uh, summarizing the changes, then we can do that judgment.

That would be great, right? Mm-hmm. 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 multiple development environment.

So it adapts itself to whatever you are doing as a task. It, 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 wanna see a diagram, it's a lot easier to see what changed, what is the impact.

And that moves it to 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 we re remember the test that I mentioned.

Then we had some CICD system. We kind of deploy this automatically and so on. But then we had monitoring.

So we're still kind of figuring out what the coach and version of monitoring is of those agents. And if you stick 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 agenda 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 dunno what it will be in production, but you, you kind of see that. Uh, and then we had observability because then we couldn't anticipate what was going to be wrong. So we needed to 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. Yeah. We were not used anymore to deal with any failures.

So what do you do as a fireman who's not used to de dealing with fires, fire Drills, You train them, right? Right. So whatever we say about the automation, we had to work on observability and all this stuff and training.

Now you can take the shortcut and don't care about all that stuff and just figure out like, I'm gonna get the coding. Well, that's your choice and that's your appetite for risk. You know what, right?

That's exactly, that's a risk management solution, understanding that it's fine as long as nothing happens. Yeah, indeed. Yeah.

But life doesn't work like that. 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, you, 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. Uh, and, 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, 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 industry, learning what the practice would be. And there's always gonna 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 out about this is, is what I love in these kind of chaotic, emerging times, uh, and learning from each other. You know, we, we did a Textron gang show this morning. We had a bunch of people talking, and one JP Morgenthal was on, and he said something that made sense to me, which is even if it's good code, when you do coding, you could look at the code you wrote, kinda 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, you, 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? Mm-hmm.

You don't know whether you know that unless you're gonna do some sort of analysis to, you know, and, 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 gonna troubleshoot something, right? Whoever's had a computer system where we didn't have to troubleshoot something. So I 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, you're still going to need to have that done. And, 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.

Mm-hmm. Yeah. 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 Willis' book just came out that we've been doing AI for hundreds of years, really, right? Yeah. Um, 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. Yeah. That's what why I love it.

Like I've never learned so much in that short of time in my career. Absolutely. Right?

And I, I agree. It's, it's, I've seen a lot, but yeah, No, but these are no doubt about it. Now, I wanna turn a little bit, you, you've coined sort of a new phrase, if you will, a new, I don't want to call it methodology per se, but share with our audience what, what you are really kind of talking about now.

Well, thanks for giving me that much credit. I, I didn't coin it this time, so, but, um, like Guy Pja, uh, one of the farmers, Oh, guy Shark Snake, right? 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, 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 kinda like the coding, and they say it's a copilot. And, but what fundamentally changes and what's nice is that we're like, I looked around, I I couldn't completely find like a home perfectly, and they were really thinking about it, and they call it AI native death. And that's kind of where they asked me like, can you help us make sense of AI native death?

And, um, the interesting part is they asked me, can you kind of describe the principles? And you know, I'm, I'm didn't ask you to rocket manifest Manifesto, didn't they? Yeah, yeah, yeah.

So everybody wants that, like, including you, Alan, right? And you know that that's not me, right? I, I, I can't push things.

I'm an observer, right? And so that's why I called it di native deaf Patterns, not principles. And I started like describing the things that I see in tools, and obviously it's a narrative, but it, 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 or DevOps included, our security people included, you know, in a way everybody's a dev. Now everything is as code. So I'm, 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, b DevSecOps and whatever. 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, it's not, 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, and you do all the coding. We've briefly touched about it that, um, you're doing the coding, but all of a sudden somebody else is doing the coding, right? So you, 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 and 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 we 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 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, I tell the intent, I capture the intent of what needs to be built, right? And you see that in more and more tools we'll have, 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 thing that need to be done.

So that's kinda 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, 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 VID, they try a few things, they try something else, they, 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 buildup in there. Now, all the knowledge about a domain, if your company is in, in medicine or your company companys in, in marketing or kind of here in in video production or something, or conferences, you have domain knowledge, right? So whatever you would like to do is to capture actually knowledge, because that's your competitive edge.

If everybody's able to do the coding, every, 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 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, you know, favorite examples of this is there's Devon, which is the automated kind of coding agent that took the world by, you know, storm and kind of, they, yes, 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, I'm, I'm, I, I want to have this co-produced and these are my prompts and this I wanna do. It asks the end user, I, 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, you know, building things up in exploratory and then having the AI capture the knowledge and, 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, some of the tasks will be automated, some become obsolete, some will be just assisted. And that means that people are gonna 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, the transition more than transformation that the developer is going through.

So you see people, you know, caring deeply about the code, then they kind of, Hey, this is what I want. So kind of that gives people a, a, a journey. Are you gonna go more into reviewing code and operational code?

Are you gonna 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 I is an IT person.

And it hope also helps the manager 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, I don't have a better word for this.

No, I, I think it's a great word. So do you envision AI native dev 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? Yeah. Um, I think there's a, the product lovable says this is the large last coding editor you will use, right?

Right. So uhhuh, 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, the problem that we'll 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 we might take a long time before we get there.

Now it doesn't mean it's less useful, but it just had to, 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 dunno.

The one thing that I i i, if you say we were looking back in 2029, right? Or 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, I, 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 spend in speeding up the coding we'll spend in reviewing and training.

So is it just shifting complexity around it might be, uh, but also I, I dunno all the breakthroughs, you know, of whatever these crazy people of the models are doing, right? So Yeah, I mean, and, and that it's not just shifting it around because like for instance, training. So you, you put your time and money into training, your effort into training, and now you're trained.

Mm-hmm. And so it's almost like the difference between CapEx and opex. Mm-hmm.

Do you know what I mean? Yeah. Training to me is a CapEx but it lowers my opex going forward, right?

Yeah, yeah, Yeah. Um, So I, I, I hope I, what do I know? I mean, honestly, right?

I I do 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.

Um, yeah, But let, let me give you that example. If you're, if you're, um, you know, we can all generate images and videos, uh, now thanks to ai, right? Mm-hmm.

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, I have not been trained for this.

My son and my wife, they know exactly what they know, know or 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, and we see the slop coming out of the eye generated, and even if it's a pixel perfect picture, it might not be considered a good picture. And, and that's kind of puzzling in a way, right?

Well, because art's in the eye of the beholder as well, right? Absolutely. And there, and there is that aspect to it.

Yeah. Patrick, we gotta 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. Yeah. What, where, where would you send them to do a deeper dive here?

io. So you can go that site and, and that's kinda like a news 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. So where, Where's the con? Is the conference virtual or in Person?

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. ai, native dev io. We already have 290 tools that we categorize from document to product to review.

I love it. Security tools. So you, 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 there. Definitely, Patrick, God bless you, man. You, you managed to stay on, 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, 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.

io. Io. Yeah, io.

Yeah, we did. We couldn't get the ai, which is Ironic. Go figure.

Well, but IO might be going away. Be careful. Yes.

Yeah. You know what they say, they're taking the top level. Yeah.

Alright, 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 And it's always fun to be on the rollercoaster it together, right? Absolutely screaming. Yeah.

Dr. Tabar AI native dev do io go check it out. We're gonna be back.

You're watching Text Trunk. 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. com, text on tv, and right here on DevOps chat. Until our next one though, this is Alan Shimo.

Have a great day.