The 4 Patterns of AI Native Development

Today, we're gonna talk about the four patterns of AI-native development and how AI has impacted our development workflow.

Over this period of GenAI craziness, uh, technology has advanced from simple LLM to kind of RAG and indexing our code bases, adding more kind of functions that would be MCP, and all the way up to agents, and we see the first hint of teams of agents kind of emerging.

And kind of all that technology is really great, uh, as such.

And we've seen this explosion before, uh, with cloud native, like a new way, new way of working. And right now it still feels maybe a little bit that we're sprinkling AI on top of this.

And but what, 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 tasks that we do, um, is different. It's not just about coding and typing. Uh, we, we kind of work together, we collaborate, and we do a, a set of different things.

And so what happens is that like part of our job or part 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 working right now? I kind of distilled this into four patterns, uh, and we'll talk about each of them, uh, in this talk.

Um, you know, with the center being we're a developer, but we're moving into different areas. Uh, and that's the pattern shifts that we see.

Who am I? Um, 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 fits right 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, uh, 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, uh, 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 the right side, you see that the review kind of strips whatever we need, um, to review the code, uh, into, uh, almost like a summary.

And then we kind of say yes/no. So that is the What Matters view, uh, 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, uh, multiple files reviewing, we can do this step by step, so breaking down and kind of, uh, making sure there is a flow.

Uh, how we review is another way of kind of dealing with the managing of the code.

And why should we restrict ourselves just to be reviewing text? Um, there... This is an example of creating a diagram of what has changed. A lot easier to review, um, and a lot easier to spot kind of, uh, any errors or any impact on that.

And this brings, uh, me to the f- uh, the concept of a moldable development environment. We expect kind of the editors to adapt themselves to the code, uh, review at hand, to whatever domain, whatever kind of specifics that we need to review.

So that is maybe a trend that, uh, IDEs will end up with, uh, and not just end us with an endless stream of text, and that help-- also helps reduce the cognitive load.

Now, why we even bother to reviewing? Um, Aider was one of the first to set, like, let's auto commit, and if you don't like it, you can review, because now we still had the manual, uh, kind of step of saying yes to commit.

Uh, this flips the chart. Now, it uses some heuristics to say, "I, I kind of accept the risk," or, "The impact is low," but obviously it is an interesting kind of, uh, evolution in auto-accepting those commits.

Now, auto-accepting, um, also what we saw emerge is the longer running agents. Uh, there's been checkpoints because we don't wanna generate the whole kinda like train of thought, uh, and kind of the generation.

We can jump in from a certain point, uh, and regenerate from there. So kind of that is also helping us not having to review, uh, the whole kind of, um, iteration over and over again.

And we do, do wanna set constraints like, "AI, you cannot touch this," much like a manager sets the rules. "You can do this. You cannot do that." Um, we can say, "Lock the file," um, and we can also say what permissions the agents have, so similar to setting, um, kind of good, uh, 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. Uh, it is about, like, that long-running prompt.

So how long did it take? Well, in this case, yeah, almost $10. So we wanna keep an eye on the cost of whatever, uh, task is done. Again, this is us managing a team of agents and not just doing the work.

So this was the first kind of pattern. Uh, we manage whatever code was being r- uh, produced. Now, if we take a step back, we wanna also think about like what do we actually want the agents to build, and this is pattern two.

We are, uh, 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, uh, that I kinda 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 wanna build, um, AI can help us build a plan. Uh, this was, uh, GitHub kind of adding this task-oriented, uh, and translating whatever we want it to do, uh, step by step.

Um, and that brought us to all 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 tasks.

It becomes, uh, kind of like the specification. It builds a plan, and then it does the code. Uh, that is definitely, uh, a new kind of, uh, direction, uh, 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, um, coding, um, 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, uh, and watching it do and, uh, work out that intent. But this pattern number three is that we...

How do you find, uh, find what is the right intent that we wanna build? So we wanna discover IDs, we wanna discover, uh, the, 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, uh, designing and making much faster to design kind of, um, prototypes. That's one way of kind of exploring like, "Oh, it needs to be like this, it needs to be like that."

Um, we all know kind of like vibe coding, uh, building prototypes is a lot faster right now, so we can kind of do this, um, with a tool like Lovable or Bolt or any of the other tools.

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

And then that kind of whole design to going to code and kind of like doing design again and then modifying the code, uh, that's, 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, um, 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, uh, of getting the, 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. Uh, the one step that even goes, uh, uh, kind of, uh, like after that is that whatever we learned in that process, whatever content we produce, we wanna turn into knowledge because that's kind of 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, uh, what we learn on the process. It could also be production issues, uh, 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, we, uh, wanna improve on, um, 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, uh, or a person leaving. Uh, all valuable things. There's a lot of knowledge lost usually, so helping, uh, AI helping us there is very useful, um, in that process.

And then one thing you might have seen, uh, over the years is that like somebody tried a feature, it gets dismissed, it got tried again. So maybe it 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, uh, in any of the, the tickets or the architecture diagrams. But now, right now, it keeps that as knowledge, um, on board.

And then when we actually do this more in the flow, we, we chat, we, 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- either both for actually the, 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, uh, and to also improve actually the coding, uh, 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, uh, land of operations, uh, by becoming a, a, a, instead of a producer, a manager.

We moved, uh, to more of the QA and the architects, uh, by moving towards the intent. We did more discovery like a product owner, and we turned data into knowledge, uh, 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, uh, us helping to do fa- faster typing as such.

If you wanna learn more about, like, the landscape of all the tools, I also curate the landscape ainativedev.io. We roughly have about three hundred tools now in our landscape, um, for you to explore.

Uh, obviously, there's a lot of tools. Um, you can also subscribe to the news, AI Native Dev, um, and, um, anything that, like, we really focus on anything that is at the intersection of coding software engineering and AI, which makes us, uh, a little bit unique in that space.

Thank you very much. If you're enjoying this talk, um, send me a message on LinkedIn. I will also forward you the slides, uh, or you can kind of subscribe to my YouTube channel.

Have fun, um, exploring all these kind of new ways of working, and I hope to be back for more. Thank you.