Introducing the 4 AI Native Dev Patterns – with Patrick Debois

Simon Maple: [00:00:00] The sheer number of unknowns, like when there are more questions than answers, it's a paradigm shift when there are job roles being created. When people don't even know if there is a job of this name, like a DevOps engineer or something that it's a paradigm shift. I like this. I like this way of thinking about it.

Patrick Debois: And then from those practices that you see people doing, hey, there's a trend towards the patterns and then hopefully from the patterns, we can distill if you're in this situation, this is one, two, three. And then ultimately I'm just going to feed it all the requirements, technical business requirements, it's going to produce stuff.

Similar to the, implementation to intend, maybe the delivery is already automated and all of a sudden it pops up and says, I think this is really important. Should we save this as knowledge?

Simon Maple: You're listening to the AI Native Dev, brought to you by Tessl.

Hello and welcome to another [00:01:00] episode of the AI Native Dev. Now we've got some exciting news coming up because there are a couple of things which Patrick myself and some of the other Tessl, Tesslers in the team who are working on is something called the AI native patterns and the AI native landscape. And we're gonna jump into a couple of these terms and maps and, and really talk about what it means to have a set of patterns in the AI native space, what it means to be able to create a map of the ecosystem with AI native tools, why it's important and most importantly, put this in the community so that we can actually share this as well as get a ton of contributions back because it's really important that for this to stay relevant and up to date, we get a ton of contributions from the community.

Joining me for this episode as mentioned, Patrick Debois and not your first time on this podcast, Patrick, not even the second time. Welcome back.

Patrick Debois: It's my pleasure. [00:02:00] It's so exciting, so interesting to talk about, so my pleasure.

Simon Maple: Excellent. So why don't we, why don't we talk about AI native dev first, Patrick, and when we talk about a paradigm shift in our ecosystem, to what scale are we talking about in terms of changes to our workflow, changes to our tooling, changes to our processes?

When do we start talking about a paradigm shift?

Patrick Debois: Yes, it's a good question. Me personally, in my life it was often when there was a new technology, early days, it could have been internet and the clouds, then mobile serverless, you name it, right? And right now we're at AI as a technology disrupting what we do.

And that's the point, right? Is it just something we can add on and it's fine, like we don't even mention it. It's like a small thing, or is it actually impacting the way we work or, you know, things that we really have to do differently to make it worthwhile. [00:03:00] And so that paradigm shift is not and sometimes I call it like slap on AI, right on the top and you're good and we have an AI product.

Yeah. But once you start thinking about, okay, this is the surface, what can we do deeper? And how do we actually have to rethink? Like we can't take for granted the past or how we did it in the past. And that's where it becomes like a paradigm shift. It is not easy because, you know if it's an emerging thing, we often don't know how is it going to affect us.

And usually it takes a bit of time for us to understand, people are trying certain things and they see What is possible and they look for the boundaries of this new thing that probably overuse it a little bit just to understand what the limits are. But when that's substantial enough for changes and having an impact and having a benefit, you know that, in that case, you could talk about a paradigm shift.

Simon Maple: I like the idea of it being the sheer number of unknowns, like when there are more questions [00:04:00] than answers, it's a paradigm shift when there are job roles being created when people don't even know if there is a job of this name, like a DevOps engineer or something that it's a paradigm shift. I like this.

I like this way of thinking about it. Of course, yeah, you mentioned a number of DevOps movement, the cloud native movement. When we talk about this, is it, is it important? Is it almost like annoying to have a label like this, like AI native, or is it actually useful to, to be able to create that hashtag, that label?

Patrick Debois: Over the past, we learned that whatever label we put on it is probably the wrong label because initially we don't understand fully what it's about and then eventually you understand and then the whole term has taken root. It has happened before with cloud and then we call it cloud native because all of a sudden there was a shift, right?

As we mentioned, with DevOps, it was initially about the devs and the ops sitting together, working together. And then ultimately it became, like every bottleneck, like DevSecOps, [00:05:00] HR, you name it, Fin, they all became part of this. So in that way it's, it's not a useful thing. And. Having it maybe not clearly defined, which is, Agile had this manifesto, it still had a million of questions.

ITIL had 15 books, still a million questions. Whatever you do to exactly define is hard. The way that I express it, if you have a label for good and for worse, that people are like, vaguely understanding or believing or kind of word, the sense of what we're going, this is important to get the stories out.

If you're doing something new, you're trying something, Hey, if I just look at that label and the hashtag, I can see what emerging stories out there. And when you use a new hashtag compared to the old one, you know where the new stories are coming from. So that's very interesting, instrumental especially in this beginning emerging feeling where, you know, we, we don't know where we are.

One of the labels in the broader industry even though we had machine learning [00:06:00] engineers and AI specialists, the term AI engineer took root in a way that, hey, if you're talking about AI engineer, this is a person that bridges the data together with the applications and they're using new technology and they're bringing things together.

So this is again one of the new labels and often it is also when a paradigm shift impacts the organizational aspect. There is also a shift in roles. And like, in this case there's also a bridging of silos again, of bringing two things together that had a friction in the past or maybe didn't need to work together and go from there.

So that's, I think the value of, of a label is, that we can track where the new things are coming from.

Simon Maple: Yeah, and I think one of the things with the labels as well is a lot of the time, like DevOps was a great example of it and cloud native to some extent as well, whereby people actually overused it and meant different things by it.

And that's why I think, the patterns is actually a really strong way of [00:07:00] hoping to demystify a little bit some of the labels as well. Because I think while it's good to have that label so we can refer to this movement, refer to this change in a paradigm shift. It's important to actually be able to break that down and state clearly what does that mean?

And that's a lot of what we've worked, in these patterns today, of course, you mentioned as well that the people, there's a big shift in what people are needing to do, what people's roles are going to need : be, that's obviously something that is a little bit slower to adapt to and it's something that I think is a little bit more emotive as well because when we think about the unknowns, it's okay for technologies to have unknown gaps and to find their own way, but when it's, when it's us as people and humans who are trying to understand our relevance in 5 to 10 years, it's a far more daunting shift.

Patrick Debois: Yes. And questions like, oh, will AI replace my job and what will come of that? Ironically, at the early days of DevOps, everybody said oh, go away or I'll replace you with a shell script, right? That was the [00:08:00] same automation feeling, the feeling that you could be redone and new technology does part of your job or kind of does. Now, I think if you look at it in the broad sense, technology influences the roles and the organization and how we work together. If there's a significant impact, also the other way around, but I think, let's say we're here talking about developers. Developers do a multitude of actions, right? They're not just coding.

They're talking to their, their product owner. They're looking at things in production. They're trying to solve a new problem. So they have a, a bunch of different tasks, right? And if you look at it this way, is that if you unbundle all the tasks of all the things they're doing, some pieces with a new technology get replaced.

Some things get enhanced. Some things just vanishes because it's a solved problem. And so that's how you look at this new trend of the technology. And what we [00:09:00] focused on in, in the kind of how we group things together is if you're a dev, what kind of things are changing about the stuff that you do and how do they actually allow you to do new things or what should you be looking for?

Like when I go to when there's something with my car, I don't know anymore how to fix it. I go to a garage, right? So there's certain level of abstractions that we solved in a certain way that I don't have to understand. I still, in Belgium have to know how to drive, if you take that away, there's something else that could be replacing this.

So this kind of unbundling is important and seeing if technology matures that well in a way that it's not just a simple thing that is added but you can completely take a task over that it's done autonomously then that's a completely different impact. And a model that comes up quite often [00:10:00] in this kind of things is the Tesla model of the self driving car.

How far is it? Does it need a little bit of help? Is it pretty much okay, but is it an exception or can we do everything together? And that's the beauty right now in the technology is that the spectrum is so big. Some things we're only getting started. Other things we're getting better at, and so we're on that kind of almost like a maturity curve or kind of an evolution of how autonomous the technology can help us.

And the more autonomous it gets, the more we are influenced.

Simon Maple: And when we talk about that maturity curve, I think one of the things that we first, need to be able to do really well. Particularly when we think about maturity, which we're obviously at a very early stage at here is be able to describe what good looks like or be able to describe the space that we're in, because then we can understand, okay, are we doing certain things?

Are we doing certain things poorly? Where do we need to improve? And we talked about the naming here quite a bit, didn't we, when we talk about, [00:11:00] we originally thinking about AI native developer or development principles, then practices and we landed on patterns. Why is naming here important?

And secondly why do we even need patterns?

Patrick Debois: Yes, so the way that we defined it was a pattern is something you observe that is happening, right? So and we'll get into the details. A principle is something that people should do. So it's much more harder, like you should do A, B and C. It's almost like prescriptive, right?

We're not there yet at that point because we're still observing and we are seeing what people experiment with and hopefully that distills it ultimately into a set of principles like we could do. Now, how do we learn about this? If people have a bunch of tools and they're trying to see what it can do and they kick different areas and they go a little bit wild, [00:12:00] they're doing a bunch of practices and they're trying stuff.

And then from those practices that you see people doing, hey, there's a trend towards the patterns. And then hopefully from the patterns, we can distill, if you're in this situation, this is one, two, three, you should do that's where initially we had maybe they're thinking about this is principles.

We can tell you exactly what we need to do. And this is turned out maybe a little bit to be over optimistic in the state that we're at, because it's still so emerging and moving so fast. So that's gave it a little bit of a nuance in the meaning. And we settled on patterns right now.

Simon Maple: Yeah. And it's fun actually, when we talk about, I love the phrasing of where, how we talk about it as observations, because it's that fun stage where actually,

we're nowhere near mature enough whereby this is exactly what you said is something whereby we know exactly what good looks like. We need to know, we need you to do these [00:13:00] things in this order to be able to get to where you need to be but what we're even talking about here today, by the time this even gets released and with further community feedback, what we have today might even change slightly, whether it's slightly in the naming, whether it's slightly in the actual activities and things like that and I think I know this is the way you love to work Patrick, but it's you call it building in the open, right?

So being able to think in the open, think on social networks whereby you can get that community feedback. You understand whether what you're saying clicks with people or whether they have cases that actually fall outside of your categorization or your, or the labels that you're making and you adapt it to that.

And I think that's a really important way, particularly with AI native development, which is very broad to make sure we're not just focusing on a specific, the classic coding style, but actually it's much broader than that. And I think one of the things that we're talking about here is this is a very, this is like a V0.1 that we're going to [00:14:00] be talking about. And we'll cover them but one of the things that we really want is for the, for people to have a look, read it, consume it, and then actually say actually, I would love to propose this or here's my feedback on this pattern, because these will change over time.

And we, like we say, we're not at that stage where this is in stone. Yeah, the patterns are on ainativedev.io. Right now there's a few blogs that are available and they will continue to come out. We would love that, that contributions, that feedback, ping us, hello@ainativedev.io or directly to yourself, Patrick across socials, et cetera. But yeah, we absolutely want that feedback. So let's go through. Anything you want to add on that, Patrick, or ready to go through the pattern?

Patrick Debois: No please share. Like this is like a community effort and it's important to grow.

And if you don't share the stories yeah how else are we going to improve our craft?

Simon Maple: Absolutely. So why don't we go through the first one then from producer to manager? Talk us through that.

Patrick Debois: [00:15:00] Yes. So the canonical example of this is you're a developer. You're writing code. All of a sudden with the new tooling, you're not writing the code.

It's being completed, maybe it already generated the whole file. Maybe it generated seven files. So the first thing that people notice is that they'll have to approve things. So they become the reviewer. The pull requests. They say, this is good. This is bad. This is what I want. So instead of being the producer and actually doing the stuff you're having that review and that's important is having to understand what good looks like.

Now, if you take that a step further towards production, imagine something happens, you'll have to manage and say, do this, do that, and you don't have that situational awareness anymore, like much like a manager you're, the things are helping you to understand this. And this is a paradigm shift that maybe [00:16:00] a lot of people don't like because they don't feel they, they still want to do the coding, but it's definitely a pattern that's happening and pushing us to go there.

Simon Maple: And this isn't a one or zero. This is a, there's a sliding scale here, right? As well, if you were to use something like, let's grab a couple of tools. Let's say Copilot for example, and let's maybe pick a Bolt or something like that, bolt.new or Lovable or something like that.

Copilot, obviously you are still, you're much closer to that producer, but you're still having something done in an automated way but obviously the lift is smaller in terms of what it will produce and you are almost like a micromanager for lines of code. Whereas, of course, if you're on the Bolt or the Lovable or whatever it is, side on that far side, the V zero you're expecting more to be automated before you actually look at it.

You're giving much higher level tasks, more feature related tasks than code related tasks and expecting it to fill in that gap. So at what stage are folks AI native here? [00:17:00] Is there a level or are we just on this AI native scale where you know, you might be slightly more producer, you might be slightly more manager, but you exist on this scale.

Patrick Debois: Yeah. So it the different tools, will allow you to do ,different kind of practices. And so that's the pattern distills to it. Like the simple thing is, yes, I accept or no, you're also a manager in a way, but this is like the smallest thing. If you think like broadly I could have seven agents kick off, come back to me in the morning and I'm going to say what good looks like, right?

And that could be something like a DevIn or something completely out there that does cycles, big spectrum on different things and then in production as well oh, things happened, oh, the bots are trying a few things versus the bots tell me where kind of the documentation is. There's a big difference in the spectrum that you can do so it doesn't inherit in the tools and we'll expect the tools to [00:18:00] eventually implement all of those features but different tools will be at a different level of what you can do as a practice in there as well to manage things. And especially the cognitive load comes in there as well, as a manager, like you have to understand the whole system, you have to understand all the pieces, so that's another thing on how can we reduce that as an aspect maybe our IDEs will change on how we look at the code, how it helps us understand the code, how it deals with those issues.

And then ultimately we'll have to do training because we're not that good at coding anymore. So you see, it's like a big spectrum that we're heading towards that direction and it is very similar to the DevOps thing, like automation spectrum on how mature you are, definitely there.

Simon Maple: Yeah. And the second pattern is similar in, it sounds similar, but there's actually quite a fundamental difference between one and two. The second pattern is moving from implementation to intent. Now this [00:19:00] sounds a little bit similar in the sense of you produce implementation, you manage your intent but this is really talking about the focus of how we as developers are looking at what we're actually producing.

So talk us through that.

Patrick Debois: Yes. So the difference between both patterns are the previous one we discussed was more like operationally you're the one who says ah, this is good, this is what I want. The second pattern, see, I wanted to say principle. The second pattern is about I express the intent that it should do.

So I'm not like, after the fact, this is before it gets generated. And also there is a big spectrum. You could say I go into my IDE, I press tab, right? Okay. It got an implementation. If I do a special prompt, I describe what I want. If I go into the chat and have that kind of more iterative loop, what people are now calling vibe programming or vibe coding, you get into I specify what [00:20:00] I want if you take that all the way up to, hey, I'm going to send you an image, please code the front end like this. My back end should have this directory structure, so you get more into specifications, so it's not anymore a prompt, but again, it's a big spectrum. And then ultimately, I'm just going to feed it all the requirements, technical business requirements,

it's going to produce stuff and then I am the manager who has to say, yes, no. So this is how both go hand in hand. Like the first one is probably the ones that people notice the more but the second shift they're going through is like, all of a sudden I'm not coding anymore. Yes, I express what I want through a certain way, all the way up from a prompt to here's a bunch of requirements and figuring this out.

Simon Maple: Yeah. And, at Tessl, we call, we refer to a lot of this as that spec centricity, almost like leaning into something which is more natural language oriented, potentially [00:21:00] but something whereby it's all intent. It's describing what behavior we want a component or, some piece of software to satisfy.

And I think this is a trickier one for us to overcome, I feel as humans, because when we move from a producer to a manager a lot of the time, if you think about the evolution of a software developers role as they effectively, maybe they, as they get more senior, they build a team, maybe, and so forth, they are thinking about things from a higher level, but they're still thinking about it in that architecture and code style.

From the implementation to intent, it's very different because this is a massive mind shift in terms of how we actually provide that information. And if we are shifting away from this kind of this implementation we're essentially trying to produce the right specifications or provide the right requirements, almost like moving to the mentality of a PM, right?

Because that's essentially what that role [00:22:00] needs to deliver on.

Patrick Debois: The first pattern was maybe become more like an ops person because they take in and they say yes, no and when an incident happened, they make decisions. The second pattern is definitely closer to the product owner who says I understand my business.

This is how it should look like. Or as an architect, like this is what I want it to do and how technology look should look like. So there's definitely an impact in there and you just see in all the tools, they're developing more and more kind of that spec centricity built into the IDE.

So it isn't as clunky as, put it in the prompt and give it a markdown file. This will become like a full citizen in the IDE. Is just describe what you need and then we'll go in smaller steps to being the implementation.

Simon Maple: And it's quite interesting you mentioned the IDE there, because we've, when we talk and envision such change, I guess the big question there is, and we don't have to answer this today, but it's definitely something worth thinking about is [00:23:00] is the IDE even the appropriate place to do these things?

Because, perhaps when we talk about implementation to intent, and we're thinking about the written word and how we describe you know pieces of functionality is, we lean into the product manager perspective, but is a more a product manager interface slash tool more appropriate for that.

And we can go into that in a bunch of depth, which I don't think we should today. But it's interesting to think about when we talk about AI native and not slapping AI on, but actually building it in from the ground up, we need to rethink all of these things for it to be a proper a proper paradigm shift, right?

When we think what is the best way of doing this from the ground up? Is, are these assumptions that I'm making about my tool set still valid? Yeah, interesting to see how that goes forward.

Patrick Debois: Yeah, and definitely it depends on how good the tools will become, right? Because if they only do halfway, then we can't have the fully spec and we'll have to figure out what the code is still [00:24:00] doing.

But maybe there's other ways that is being improved. Conflicting requirements is a fun one because often a dev gets input to a board or like a design or something and then they do their best to understand what needs to be done. And they make an interpretation of this, right?

Simon Maple: Yeah.

And collaboration changes.

Patrick Debois: That kind of matches, indeed. But often there's like conflicting things on how fast you can go to production and then performance requirements and then the business says it needs to be cheap and so, you see having that discussion will be actually also part of a collaborative thing.

Simon Maple: Yeah.

Patrick Debois: Where it's not just oh the technology will solve it. It pushes actually to have the conversation with another product managers and for them with the customers or the business. Yeah, like good devs already do this, but it is gonna be amplified as they break out into this realm as well.

Simon Maple: Number [00:25:00] three, pattern number three is from delivery to discovery.

What does this mean there, Patrick?

Patrick Debois: Yeah, and it doesn't mean we don't have to do delivery.

Simon Maple: Ah, damn, for a moment,

Patrick Debois: But similar to the, implementation to intent, maybe the delivery is already automated, right? We've done a lot of CICD pipelines, so that kind of is more and more a solved problem.

Now, what does a discovery mean? If it's so cheap to generate things, we might generate five different versions of this. So we're discovering which of them is right in the past. We only had time for one and we didn't know that. And if we can generate multiple of them, then we can also have feedback from the customers, the ones they like.

So you become more of a product discovery and even prototype, like faster several different options, which one they like. And so you have that discovery [00:26:00] where in the past you were like heads down in the delivery of one option, and that was bogging us down. And I think that's very strongly as almost like building the right thing instead of building the thing right and that comes again to the product owner and the business and the experimentation but it could also manifest itself into the technology. Hey, we have three tools. Which is the best one? We have three algorithms. Which one should we use?

So also there is a discovery of technology and options we could take in the architecture. We then lead to specifying this into the intent, which eventually leads to becoming the manager of when it's implemented. There's some thought in this that clicks all everything together.

Simon Maple: Yeah, no, absolutely.

And this actually reminds me back to the session that we had with Hannah Fox. One of the areas that she talked about was if when you remove the bottleneck of effectively the slow piece being the [00:27:00] delivery, the coding and, and actually taking that to production, you then realize that actually the bottleneck is more on the PM.

And from that she meant when we can produce everything we want to, the question then is what's the right thing to produce? What's the right thing to deliver? And yeah, she envisioned a future whereby we make thin, small future deliveries, gather that feedback. And it's actually that feedback cycle that needs to be as fast as you can possibly get it so that we can understand that feedback and then iterate onto what our, what our next deliverable is. And that's really a lot of what the discovery is here as well, right? In terms of being able to understand what is the right thing before, before pushing the next piece out.

Patrick Debois: In the past, we had to do feature flagging. Does a customer like A better than B or something like that.

But imagine that the AI is having a conversation with that user and actually changes the code as they're chatting with this, right? So that's also like you can do [00:28:00] discovery in production. You can do your discovery of IDEs or in the technology, so it's definitely in a lot of the areas but hopefully the time that is free by not doing the other thing, we can go more into that realm and there's definitely a bunch of tools that are supporting this new discovery in a good way and that assist that kind of friction to be overcome.

Simon Maple: Yeah, that sounds like a meme there, Patrick. I don't do discovery often, but when I do it in production.

I like that new meme. We'll run with that. Number four. Four out of four. From content to knowledge. This sounds like a very wise one, Patrick. Walk us through this.

Patrick Debois: It also sounds like a little boring one to me. But I'll explain why I think it's, it's there. Imagine everything can be done by someone like a machine.

And we're the managers of the machine. And yes, we have specified what we wanted the intent and we discovered a bunch of things. [00:29:00] What you really want in an, in a company then to keep the competitive advantage is to turn all the things that you learned, the insights in every document and like all the things into knowledge, because that's ultimately your discriminator against all the other ones that you keep that knowledge inside of your company. Now, it could be, we try this for the business, our customers like this, but you can also see this more simplistic, as a developer, you have a code base, a couple of things.

When a new developer comes in, there's a ramp up time of knowledge that they have to learn that new code base. When a developer leaves, there's a ton of knowledge that is in their head that you have to capture. So also those pieces, if you can extract that, and right now a lot of it is almost like somewhere in a wiki gets out there, nobody cares, so if we can nurture those content to keeping that on top of knowledge, [00:30:00] both the humans and the AI will benefit from this because we know the much cleaner your data is, your content, your knowledge actually becomes better. For me, the one that made it click as a category was in the tool, Devin, you have a conversation much like the vibe programming and kind of what do you want and you express the intent and you're, it keeps asking you questions.

Why do you think like, why would you, should we do this and how and all of a sudden it pops up and says, I think this is really important. Should we save this as knowledge? So it's inherently learning from us. Because then the next time it suggests something, it's actually better. And that actually helps us as well because, a new person can come in, take the code base, the code base is turning to lessons using AI. Go nuts, learn. Here's all the context. Here's the historical information. Again, this is a maybe closer to the dev, but in a general sense, this is also [00:31:00] something happening into other parts of the organization and dealing with the knowledge as the ultimate form of kind of value in there.

Simon Maple: Do you feel, this is a, this is one that can go stale as well, whereby, with data. There is data that is correct at a certain point and sometimes incorrect at that same point as well if it's if it's poorly put together is this an area whereby we need to be very careful about the truisms and what's correct, what's not correct, because we can really trip over assumptions in this space.

We need to be careful with that quality of data.

Patrick Debois: Yes, but that's part of that knowledge management is keeping tabs on the quality of the data. Is it outdated?

Simon Maple: Yeah.

Patrick Debois: Like a terminology that we used two years ago and now it means something else. So there's definitely that as well, like a timely piece or historical piece.

The tools have changed. So whatever we do there is irrelevant and we'll have to find it, maybe in a slack channel, we'll have to find it in a [00:32:00] meeting. And this is also a trend that you see in the technology where you have to feed in a lot more context content to actually distill this and keep this up to date and as it is more in that feedback loop, we'll get reminded that it is outdated if we don't get the right answer. So when the manager or the reviewer comes up and okay, okay, why are you saying this? Oh, let's update this. So that's amplifying that pattern as well.

Simon Maple: Yeah, no, they all work together. And that's it's not something which has come together by fluke.

It's many hours of thoughts from yourself and many others. Yeah, just to reiterate, I think, one thing that we'd love certainly is feedback on this. How is this resonating with yourselves? Is this, you looking at this in a similar way? Are there areas that you feel are more important?

Are there parts here or there? Are there patterns here that you feel shouldn't be here, but it should be replaced with something else? We'd love to, we'd love to hear that. And of course, naming's hard Patrick, so let's make sure these these are named correctly so that they are as ,as [00:33:00] clear as possible.

But yeah, we want that feedback. How would we like that feedback, Patrick? What's the best way of the community contributing?

Patrick Debois: Yeah. So we'll we'll be releasing a few blog posts. Like one is the overview and then we go with deeper into each of the kind of patterns. And we love to have you comment on the blog post and share and like that it's visible for everybody.

It doesn't only have to be visible for us. We're doing this like you said, in the open and then we can learn from that. So definitely looking forward to that.

Simon Maple: Yeah, I guess the Discord chat would be a good place as well to have those, have those deeper discussions as well which are maybe a little bit more, a little bit more back and forth.

So make sure you feel free to join the Discord chat and ping out on there so we can we can talk there as well.

Patrick Debois: Yeah, it's great for a deeper chat or conversation instead of us like having comments and ping pong emails.

Simon Maple: Yeah, 50 comment thread. Yeah, absolutely. .Now let's, we've talked a little bit about the, I don't wanna say the practices there, the patterns.

We talked a little bit about people and how [00:34:00] roles and tasks and things like that change. We haven't touched on, on tools just yet. Now, one of the things that fingers crossed we're releasing this week. I know we're recording this last week. So all being well we're, we have released, we're very soon to release a landscape, an AI native dev tools landscape.

And the goal of this is really to categorize the ecosystem to be able to provide a map of where various tools sit so that we can look at the overall ecosystem a little bit more holistically and we need this right, Patrick, because we can't think about this type of a paradigm shift without tools as much as that, driven by lots of different groups, whether it's open source, whether it's vendors, it's something which we need to be able to enforce our ways of thinking to, to actually build those practices those practices out.

Patrick Debois: In the devil's world, a lot of people said, it's not about the tools, it's about the people and the practices [00:35:00] that people do, but without the tools, you can't do it. It is important that we know which of the tools are out there. And that's the catalog gives that clear overview of what is out there because a lot of people don't have the time to look all the time at whatever niche slack or channel to see what's released.

So we're opening up that like for you and that perspective for people of the tooling that is out there. And that's important. And then once we have that catalog, we can talk about the patterns and the practices that you do in those tools on and then relate it to that. So that's why we're releasing both kind of the patterns and the tool catalog, because they help us find the supporting practices that people do.

We tried initially to group all the tools into the practices, but then we figured out a practice is not always related to a specific tool. It is broader, like your manager could be everywhere, discovery could be anywhere. And that's where we maybe went [00:36:00] back to what we currently know as roles.

Hey, you're doing development or a task, right? Because then you can see how that task is changing with AI in there. And that's how we decided to regroup ultimately of what people know right now so they can see what the new tooling brings there and then they can look at the patterns to see which kind of new set of practices that should be doing those tools.

Simon Maple: And it's interesting because this is again one that's changed a couple of times behind the scenes before, before it was released. And I'm sure again it will be changed in future as well, for sure. I'll be amazed if it, if we got it right in the first time around. So it's definitely one of those things where, again everything from naming all the way through to is this tool in the right category or should this tool, is there a new tool that we almost certainly haven't added? That's all amazing feedback that we want to add back in. So community contributions are absolutely paramount here. When we think about maps and [00:37:00] landscapes and ecosystem menus almost essentially, how are these useful for people?

How should someone think about taking value out of this? What are the options?

Patrick Debois: When you look at a map, I think the first thing that people do is try to locate themselves on a map, right? What are we doing? Like, where are we? And it's no different here. Okay, so if you look at the different practices, are we doing this or are we not doing this?

Or like, where should we be going or be expanding? So it gives you. where you are and then were to expand. And the same thing is with the tooling. Maybe right now you only know of GitHub Copilot, which is a good tool. You can build a lot of things around that as well and use other tools to complement that.

So I know it is that the first value that people get is we didn't know that all existed. It's like open, wide opening ,eye opening for them to see oh, it could do all this? We didn't know because if you don't know that it's possible, you [00:38:00] will not start thinking about kind of new patterns and not do the practices.

So that's how I, I think it opens up. Now keeping track of the space is definitely also useful because it's not the map will change and so that, we change the categories or maybe the wording or the patterns. Hopefully not too much, wording will change. And that's okay

in the state we are. And then after that, I hope somebody says hey, I find something that's new. And we, we haven't gotten there, so there's a discovery of what most people think and the things that are out there. Maybe the more fringe things is yeah, I never thought of this, so we're learning and innovating in the sense that somebody else did something new.

And, and that kind of expansion is hopefully what gives us a more complete map ultimately for people to work with.

Simon Maple: Yeah, it's one of those challenges where we talk about a more complete map. We'll never have a complete map. And there will, it's one of those things where [00:39:00] we want to try and avoid stale data, and we want to make sure that the right tools were in the right place. So this is it's important that we do get those contributions. landscape.ainativedev.io is the place to go to, to take a look at that. You'll see the various categories. As you mentioned, categorized by how we think about software development today in terms of coding and testing and so forth.

Yeah, if there's anything there that you feel is incorrect or you want to add feel free to follow the instructions, landscape.ainativedev.io to, to contribute there. It's one of those, AI is one of those spaces where of course there is such a vast number of new startups and things like that every day, the pace is insane, but also many tools do a broad number of things as well. How do you deal with such vendor sprawl in the in the landscape Patrick?

Patrick Debois: Yeah. So our rule right now is to likely, let's say we have 20 tools in a certain [00:40:00] category.

If that explodes somewhere, there must be a differentiator. It can't be otherwise, right? So we'll split that up eventually to a broader kind of area. Now it's not always easy that we found what is the differentiator? I'll give you the example of, okay, today you're an IDE. And then tomorrow you are, you have the ability to do specs.

We already talked about specs. Maybe there's seven different levels you can implement specs or agents and agents could be implemented in seven different kind of variations. So you can't group it by agents because every tool eventually will have agents. Every tool will eventually have specs. Now, we tried to say a couple of rules and one is, it's more like a rule of thumb. If you take away the AI from the product, will it still work? That kind of gives you an idea of is it AI native right? Now, some tools will belong to certain [00:41:00] categories and especially with the move towards a platform who tries to do different things and and you'll see kind of tools being bought by one vendor to become that broader spectrum, much like you saw in the SDLC. And yeah, then you'll maybe have a primary category or a secondary category. But, right now it seems to be a little bit of the exception and we're trying to steer clear and keep them in their own category. But yeah, it is challenging I can tell you that. If categories fails, we always have like keywords and tags for people to do, to find what they need.

I want open source. We can't just say here's the open source one or not, so they can find those just simply with the tag.

Simon Maple: That's really interesting to be able to say, look that here are the categories, but actually we're tagging as well. So that if you click on some of the tags, you'll see those that are just the open source and so forth.

Patrick Debois: Yes, indeed. Yeah.

Simon Maple: We did think originally also about having AI native dev categories. And we mentioned this is thinking about the initial [00:42:00] categories in and around SDLC. Do you think that will change in future, Patrick? Or do you feel like the SDLC, the way of us thinking about different stages in the SDLC will continue beyond the major changes that we see in AI native development.

Patrick Debois: There will be new, more AI native dev categories, although the others are already considered AI native dev, but new categories emerging of things that are so specific or that expand so hard that they become their own ecosystem of tools. And that's likely to happen. Let's say if we do more technical experimentation that's not built in the existing tools, but that might become a category of, you know, just try out seven different coding languages with seven different kind of run times.

And it's probably now expanding of what could happen than it actually could happen. But it's just an example of something that could become its own [00:43:00] category in there. The same thing with knowledge management is something that could become its own category as well.

Simon Maple: Yeah. Yeah. We're looking forward to see how it, it evolves. And of course, as I mentioned before, community contributions are very important here. So feel free to to contribute to both the patterns and also to the landscape.

So Patrick, this has been super exciting. And of course do check out our ainativedev.io, the new site to, to check out both of those on the blog and landscape.ainativedev.io for the landscape map as well. Patrick is wow, we're already running out of time.

So I just want to say, thank you very much for sharing a lot of your work here, and I know this is just the start because I know how much the, the community contributions and discussions really do evolve the thought process here and churn all the thoughts and evolve how the AI native dev landscape should look.

Patrick Debois: Yeah. It's like an ever shifting puzzle, but it's so interesting to try to solve it.

Simon Maple: Yeah. Yeah, absolutely. [00:44:00] Thanks very much, Patrick. And, and yeah, thanks very much for AI native dev. Be sure to subscribe to the podcast feed of your choice as well to stay up to date with all of the latest happenings on the AI Native Dev.

Thanks for tuning in. Bye.

Patrick Debois: Keep the comments coming. Thank you.

Simon Maple: Thanks for tuning in. Join us next time on the AI native Dev brought to you by Tessl.