The 4 Patterns of AI Native Development — Patrick Debois

Today we're going to talk about the four patterns of AI Native Development, and how AI has impacted our development workflow. Over this period of GenAI craziness, technology has advanced from simple LLM to kind of RAG and indexing our codebases, adding more functions that would be MCP, and all the way up to agents.

And we see the first hints of teams of agents kind of emerging, and kind of all that technology is really great as such. And we've seen this explosion before with cloud native, like a new way, new way of working.

Andright now it still feels maybe a little bit that we're sprinkling AI on top of this, and but what does it mean to be AI native? What's the new kind of set of practices that we're heading for? Now, with any new technology,right, it impacts our tasks.

And a tasks that we do is different, it's not just about coding and typing. We kind of work together, we collaborate, and we do a set of different things. And so what happens is that, like, parts of our job, or parts of the tasks, actually either get replaced, enhanced, or there come new tasks.

And that's kind of like that AI native thing that we're looking for, what is happening to the way we are workingright now. I kind of distilled this into four patterns, and we'll talk about each of them in this talk, you know, with the center being we're developer, but we're moving into different areas, and that's the pattern shifts that we see.

Who am I? I'm an independent industry advisor, and I kind of am known for my work around DevOps and DevSecOps, which is a lot of automation, and that fitsright in with the integration with GenAI. And that's why I love talking about, like, software engineering with AI.

And I also help kind of the AI Native Dev community to curate content and to get the stories out, much like this event. Now, the first pattern is from producer to manager. And it is when we are used to being the producers of the code, and all of a sudden we have agents that are producing the code.

So we need to manage those agents. And that's the first pattern shift that we see, from producer to manager.

It is already very visible in a way that, like, the AI is generating the code, and while we spend less time in the coding, the reviewing time goes up. And we didn't do the kind of thinking work anymore, so now we have to do the thinking work in the review.

So our cognitive load is going up. So that is one of the things that is very visible in a lot of places where AI is added to their workflow. Now, we try to reduce the cognitive load by coming up with new ways of reviewing the code that was generated, not just the diff view, red, green, it's a little bit clunky.

The chat view is very verbose, but on theright side, you see that the review kind of strips whatever we need to review the code into almost like a summary. And then we kind of say, yes, no. So that is the what matters view, and it's one way of dealing with becoming that manager.

At a glance, you can say, yes, no, this is good code. Now, as we're doing more kind of multiple files reviewing, we can do this step by step. So breaking down and kind of making sure there is a flow, how we review is another way of kind of dealing with the managing of the code.

And why should we restrict ourself just to be reviewing text? There is an example of creating a diagram of what has changed, a lot easier to review, and a lot easier to spot kind of any errors or any impact on that.

And this brings me to the concept of a moldable development environment. We expect kind of the editors to adapt themselves to the code review at hand, to whatever domain, whatever kind of specifics that we need to review. So that is maybe a trend that IDEs will end up with, and not just end us with an endless stream of text.

And that also helps reduce the cognitive load. Now, why we even bother to reviewing? Aider was one of the first to say, like, let's auto-commit, and if you don't like it, you can review, because now we still had the manual kind of step of saying yes to commit.

This flips the chart. Now, it uses some heuristics to say, I kind of accept the risk, or the impact is low, but obviously it is an interesting kind of evolution in auto-accepting those commits. Now, auto-accepting, also what we saw emerge is the longer running agents, there's been checkpoints, because we don't want to generate the whole kind of like terrain of thought and kind of generation.

We can jump in from a certain point and regenerate from there. So kind of that is also helping us not having to review the whole kind of iteration over and over again. And we do want to set constraints, like AI, you cannot touch this, much like a manager sets the roles, you can do this, you cannot do that.

We can say, lock the file, and we can also say what permissions the agents have. So similar to setting kind of good guardrails for what the AI can do. We start worrying a little bit more on the cost, as this is longer running.

It is not just about that one prompt, it is about, like, that long running prompt. So how long did it take? Well, in this case, almost $10. So we want to keep an eye on the cost of whatever tasks is doing.

Again, this is us managing a team of agents and not just doing the work. So this was the first kind of pattern. We manage whatever code is being produced. Now, if we take it step back, we want to also think about, like, what do we actually want the agents to build?

And this is pattern two. We are increasingly going from caring less about the actual implementation to specifying the intent to the agents. This is what we want, figure it out, like, run with it. The first one that I kind of saw, it was a simple Markdown file as a specification file that you added to the prompt.

This was a very simplistic way of kind of adding specifications instead of us having to rewrite over and over again things in the prompt. And this really helped to kind of build that shared functionality, whether that is functional or more technical as a specification.

And, you know, once we have the things that we want to build, AI can help us build a plan. This was GitHub kind of adding this task-oriented and translating whatever we wanted to do step by step. And that brought us to more like intent-based coding.

So it's less about the chat and the text completion, but it's more about, like, we define the task, it becomes kind of like the specification, it builds a plan, and then it does the code. That is definitely a new kind of direction the tools are taking.

And then the whole tool could be specification-centric. We don't see the code maybe too much anymore. We specify kind of functional requirements, technical requirements, security requirements, and like the whole workflow is around specifications. And then if you go a step further, why kind of still see whatever goes on in that, like, coding process, and you start just having managing the process as a program manager as such.

So this was kind of like specifying intent, and before we had specifying being a manager and watching it do and work out that intent. But this pattern number three is that we, how do you find what is theright intent that we want to build?

So we want to discover IDs, we want to discover and work the problem as such. And that's pattern number three. From delivery, so we care less about it going to production, because we have pipelines and that goes out, we have the manager, we have the specifications, to us discovering what we want to build.

And yes, okay, this is just designing and making much faster to design kind of prototypes. That's one way of kind of exploring, like, oh, it needs to be like this, needs to be like that. We all know kind of like vibe coding, building prototypes is a lot fasterright now, so we can kind of do this with a tool like Lovable, Bolt, or any of the other tools.

What that brings is also it can build multiple iterations and multiple versions, so we can choose the best one. Like, that really helps us to discover what we really want, and it helps us suggest things that maybe we didn't think about yet.

And then that kind of whole design to going to code and kind of like doing design again and then modifying the code, that's a whole process of that is being refined to kind of that discovery process and exploration.

And this is a great example of, like, we all think about vibe coding that it needs to be done for prototyping and discovering IDs, but it could also be done by the customer. Like, imagine they could vibe code the interface that they want on top of your product, similar to almost like an A/B testing on steroids.

They can adapt what they need and how they need it, and that's usually like one of those friction points of getting the perfect product. Now, we explored everything we wanted to build, then we wrote the specification, and then we managed when it was generating the code.

The one step that even goes kind of like after that is that whatever we learned in that process, whatever content we produce, we want to turn into knowledge, because that's kind of like the final play is us capturing all the knowledge, not having to do the same problems over and over again.

Now, it doesn't only have to be code, what we learn on the process, it could also be production issues. So we learn whatever is going on in production, and we bring that to the code. That's one way of learning.

We can also learn from incident response, like what failed, what we shouldn't do, like new guidelines, new technology that we want to improve on, similar to writing an incident response code and taking that as knowledge. We can also turn whatever code we have into lessons, like reducing the onboarding time of a new person or a person leaving, all valuable things.

There's a lot of knowledge lost usually, so helping AI helping us there is very useful in that process. And then one thing you might have seen over the years is that, like, somebody tried a feature, it gets dismissed, it got tried again.

So maybe we can keep actually track of whatever feature in almost like a feature memory, and we're not doing this over and over again, and we keep track of whatever decision that was made, which is currently a little bit more of a throwaway kind of things that ends up in any of the tickets or the architecture diagrams.

But notright now, it keeps that as knowledge on board. And then when we actually do this more in the flow, we chat, we code, and all of a sudden the agent says, I think this is important, let's save this as knowledge.

We kind of get a very beneficial loop, both for actually the human and both for the AI to kind of learn at the same time and keeping that like knowledge. And that knowledge then can then be used to help others with questions and to also improve actually the coding of the solution.

So this is a nutshell word for AI Native Dev patterns. You see, the center was the developer. We moved a little bit to the land of operations by becoming, instead of a producer, a manager. We moved to more of the QA and the architects by moving towards the intent.

We did more discovery like a product owner, and we turned data into knowledge similar to our data engineers. Now, in essence, this is also what good senior developers do. They do more than just the code, and it also shows that AI is beyond kind of just us helping to do faster typing as such.

If you want to learn more about, like, the landscape of all the tools, I also curate the landscape AI Native Dev.io. We roughly have about 300 tools now in our landscape for you to explore. Obviously, there's a lot of tools.

You can also subscribe to the news, AI Native Dev, and anything that, like, we really focus on anything that is at the intersection of coding, software engineering, and AI, which makes us a little bit unique in that space.

Thank you very much. If you're enjoying this talk, send me a message on LinkedIn. I will also forward you the slides, or you can kind of subscribe to my YouTube channel. Have fun exploring all these kind of new ways of working, and I hope to be back for more.

Thank you.