B (3:40)

Yeah, outside of the training set, of course.

C (3:43)

Exactly. And I remember doing this, the test in the beginning and I saw the AI couldn't do it. Maybe the first message kind of get the hang of it. But then when I, then I started to ask it, like, let's play, now it's your turn. And then it's maybe followed the rule, beginning, yes, maybe two turns. And then it kind of faltered. But as I remember distinctly with ChatGPT 3.5, I did this test again and then I could see that now we can play for an hour. And then it hit me like, boom. Now we have entered a new kind of era. This is going to be a new industrial revolution almost. Because now I have computer is playing with me and I haven't coded it up at all. I've just told it the business logic, so to speak, and it can follow along. That to me was very magical. So then my next test I remember I did because I want to see is this going to work for actually making a workflow out of this? Because I could see the potential.

B (5:04)

By workflow you mean like software development, right?

C (5:07)

Yeah, exactly, exactly. Like can this, like in the projects I'm doing at work, can this. Because I had like, I could see the vision kind of slowly manifesting, like maybe this could be like a collaborator, like someone just sitting besides me all the time, but who never gets annoyed at my questions. And you know.

B (5:33)

The perfect pair programmer, right?

C (5:35)

Yeah, exactly, the perfect pair programmer. And I remember the second test that I did was I created a really, really stupid function, the most stupid function ever, and I asked it to create unit tests for this function and I made it stupid because again, I didn't want it to be in the training data.

B (6:01)

By stupid do you mean unexpected, Very simple.

C (6:05)

Yeah, not like bug ridden or something, but something that was very, very weird and maybe not difficult to read. Or let's see, it should take one object that has these three fields and then a number and then an array filled with this. And then when I give it the word apple pie, the output, like it should do something with all those parameters, you know.

B (6:40)

Okay, okay, okay, yeah, yeah.

C (6:42)

Something odd that.

B (6:44)

Very odd indeed.

C (6:45)

I know no developer would never do this, you know, so I could feel sure that it's just not reading from some memory, you know. And then when I saw it's actually writing unit test, that made sense for this function, like both happy and sad paths. Then I was like running over to a colleague and was like, holy shit, look at this. Because I remember he was always like, oh, it's just a parrot. It just.

B (7:16)

So you were kind of expressing your skepticism and giving it challenges on purpose to make it fail. And then the surprise is it didn't fail.

C (7:26)

Yeah, exactly. Because I had this vision. I actually didn't think it would work, but I had this vision of this actually helping me out with development, like maybe doing boring stuff. I don't want to do scaffolding or things like that.

B (7:45)

We'll come back to that. Because I think AI is probably not very good at doing the boring stuff. But we'll come back to that in a second.

C (7:52)

Yeah. So after those two tests, I actually like. One of my first blog posts actually was this was before, I think nobody has ever actually coined this term, but AI driven development. So that's like within the a, in another place. And I have a blog post about that. It's like a proto version of this framework that I've done now, but there I in there. I also made a little video of. Of how I used AI to create for me a function that. What's it called? You know, when you switch the letters around and it becomes another sensible.

B (8:43)

You mean just, just. I know what you mean. Just changing the position of the letters and creating another valid word or phrase.

C (8:52)

Exactly. And you can do it with very long ones. And I used then I could see already here we need some way to guide the AI towards the right solutions. And I love this practice of test driven development. So I used to test driven development with the AI, who I knew could now play with me because I have done this test with it. So then we just go back and forth. We create the test first, then we create the implementation, then we refactor. We go in this cycle and in the end, in that video, you can see it all works like the tests all go green and the function works as well. That to me was a magical time because then I know.

B (9:42)

How do you differentiate your approach, which you just related to us, how you developed, how you got there. How do you differentiate your approach from vibe coding, which is kind of the word that everybody's using. So how is aid or augmented AI development different from vibe coding?

C (9:59)

Yeah, exactly. So that early approach, now I have this new framework that to me it's like When I've done it right like now, I thought about it a lot and I've made the diagrams and everything for it now. It's like much more formal and structured actually, because Markus Hammerberg, that you mentioned at the beginning, my, my awesome colleague here, he, he, I showed him this workflow I have just in a few screenshots and he said, oh, we should formalize this. This is really cool. And then that now two months later, here I am with this framework augmented.

B (10:41)

He already tell you to write the book because that's what he will do next. He's done that before.

C (10:47)

I heard you published two of his books, right?

B (10:50)

One of his books, yeah, the book about a hospital in Indonesia which almost went bankrupt twice and he helped save the story. It's a great book and I'll put the link to that in the show notes.

C (11:04)

Oh, it's not the development. Nope.

B (11:06)

That was something he wrote before.

C (11:08)

Oh, beautiful. I didn't know that.

B (11:12)

All right, so coming back to this.

C (11:13)

AI augmented development, I will ask you a question now. So this, I see it as a spectrum and on the one far extreme you have Vibe coding, and on the other far extreme you have AID or some framework like that. And what is this spectrum then? The spectrum is, I think, how much you are aware of the code itself when you make something. So Vibe coding for me has a very strict definition. The definition is, I think, also in line with Andrej Karpathi's definition. He made this definition up when you don't even care about the code at all, you only care about the results. So if you do a front end app, you don't even look or care to look or oftentimes can't even understand the code. And you don't care. You only care about the results that pops up on the screen. But you know there's something happening in the background, but you don't care. That's to me is Vibe coding. So that comes then in contrast to other ways of using AI as a developer on this spectrum and to me my AID framework is on the very like the furthest away from Vibe coding because it's actually like it's for professional developers. You need to know your things to do this right. I even have like two of the fundamental developer principles for AID is first is don't abandon your brain. And the second, I remember that that was precious.

B (13:09)

I really like that.

C (13:11)

And the second is incremental steps. So the first one there, don't abandon your brain. It's. That's the opposite of Vibe coding, right? If you think about the brain as understanding the code itself. So does that kind of answer the question?

B (13:32)

Yeah. So you're basically saying that there's a spectrum and we're kind of discovering what that spectrum is. And there's vibe coding on one side of the spectrum. So you don't really care what the code looks like if it's performing or whatever. And then there's another side of the spectrum that goes more towards a structured approach that is, and these were your words applied by professional software developers. And in aid or augmented AI development, you give it specific practices. And one of the things that I really appreciated because not even developers who don't use AI use these practices are TDD or Test Driven Development and BDD Behavior Driven Development, which is basically writing acceptance tests rather than just the unit tests that TDD gives us. So why did you do that? Why did you make that conscious choice of bringing TDD and BDD to a framework that is supposed to take less work? I mean, I'm using air quotes here because that's not really the case. But it actually takes more work, it's just faster, which is developing code with AI compared to Vibe coding. So basically you're adding stuff on top of Vibe coding and that stuff that you're adding, don't abandon your brain, like understand what the code does, but also work through it in very small steps through the TTD cycle. Basically. Why did you come to that realization that. Wait a minute, TTD really is important here?

C (15:07)

Yeah. So I can answer this question in so many ways, but I guess I will answer it in. So you said we build on top of Vibe coding. The way I see this is that's how many AI driven development frameworks these days work. They start with AI and then they try to tack on like software engineering best practices after. And this is a hill I will personally die on. I think that is totally wrong. You should start with like software engineering wisdom and then only add AI where it's actually appropriate. I think this is super, super important and the entire foundation of this framework. So in a way you can. Sometimes when I think about aid, it's almost like I'm teasing or almost manipulating developers to start to use good, normal software engineering practices. But I have it in this shiny AI box that feels very exciting and new. And it is very exciting new. We can talk about like all the ways I actually use AI to augment us, but at the core we have like software engineering fundamental wisdom and we start with that. And I can just mention one thing that happens when you don't do that. That I saw the other day. There is another framework from GitHub called Speckit. Have you heard about it?

B (16:58)

Yes. Give us just the 30 second summary of what Speckit is about because I think that's important here.

C (17:05)

Speckit is just like aid, a way to structure instead of just saying to the AI I have this idea and telling it about it in an unstructured way and then say build it and please make no mistakes. You know, that's what most people do these days. Like developers have realized this is not a good way to go about it. So how do we do this? And some people have started to realize that maybe we need to be more. Our instructions to the AI needs to be more formal and they don't realize often that this has been done already with BDD and stuff like that. So they invent it again. Anyway, that's what I think Speckit is doing. They have more formal specifications, what they should do that the AI can then take and do a better job at building the thing. So that is Speckit. And the funny thing I want to mention is that I saw they added a new feature last week and this is what happens when you start with AI and try to tack on wisdom later. And the new feature they added was they have removed the testing. Now Speckit don't do testing at all unless you ask it. And that was like, oh, a new feature.

B (18:38)

I want to hear your thoughts on this because I've looked into Speckit and bmad, which are other frameworks, some more complex. And Speckit specifically looks to me as an over engineered process centric view created by a large company by people who've never developed software themselves. Because Speckit sounds to me like just a bunch of specification steps which ultimately that's the goal, will produce the neat specification for the AI to implement. Of course AI is building the spec. So there's another problem. How do you test that the spec is, is actually about what you want it to be and it isn't about software development. It just feels like an overkill. So how would you contrast Speckit and aid?

C (19:29)

It's so much to say here. I actually have this big table like this of all the things that other frameworks do that it doesn't do one thing like just take one of them. When yeah, first they vibe code the specs like kind of unstructured. They just like oh, make specs. And they don't realize like this is a whole world of structure. Like this is not just oh, specs is the. If you Have a spec. That's it. No, like there's a taxonomy to specifications. And I think behavior driven development have solved this in the best way possible already. So for me, I always with this framework, want to stand on the shoulder of giants and work on top of what has already been done. So that's what I think they don't do. They wipe code, some specs, and then what happens is that they make a task list. There's another of these framework called Taskmaster that does this as well. What a task list is, is a markdown file, like a normal text file. And then you have a checkbox and then what the AI should do. And the AI makes this list and the big problem about this, and then it goes through and it develops some stuff and checks it off. It actually changes the text file. It's pretty cool. So it adds a little check mark and then it goes through and it looks great. Right? This looks like a really structured way of doing development, but it actually comes with a lot of like down the line, this is, this is going to bite everybody in the censored world. Because, for example, what if you want to change something in the future, then you have to manually go through this checkbox and test that everything still works. Yeah, because this, yeah, because this is just a text file. And also when the AI decides to check the box, that means this is the definition of done, completed. Right. But how is the AI taking that decision? It's totally like ad hoc code is written.

B (22:17)

Right. It's like going Back to the 1980s, I wrote the code.

C (22:21)

Yeah, exactly. And it's like, I'm done. But what does that done to you mean? Nobody has any idea. So it's totally like.

B (22:31)

That's actually a very good point. Like, I am done is something that, for example, Scrum has put a lot of effort into. Right. Like it created the definition of done. And then we have to discuss internally, what does it mean, what kind of steps do we go through, how do we validate it? But in Spec Kit and other frameworks, there is no definition of done. The aid can just randomly decide that it's done. And what I really like about aiade, the framework that you've created is this idea that you start. So even before you use AI, you already have the prerequisites. You call it product discovery and specification. And this is something that I don't see any of the other AI frameworks, or at least speckit, bmath and some others that I've looked into, I don't see them cover because you actually separate that. You said, no, no, no, no. I don't start before. Somebody already did the product discovery and specification phase. Why did you make that choice? Why did you explicitly say that before you start using aid, you must have done product discovery and specification?

C (23:38)

Yeah, that's a perfect question. I don't know if you do you know Dave Farley? Yes.

B (23:45)

We'll put the link to his YouTube channel on the show. Notes.

C (23:51)

Like, if there is one person that is responsible for almost most of the things I've done in aid, like when I say I want to stand on the shoulders of giants, that's one of the giants. There are also other giants like maybe KEMPEC or the people who created BDD and so on. Yeah, yeah, exactly, exactly. So he has. I took a course of his some time ago and he has this great illustration of the product journey and he goes. The product journey goes like this. It starts with a vague wish. You know, the customer has an idea in his or her head, it's totally unstructured. Then the consultancy or the company who they want to build this with, the customer, they start to structure this in some way and they. Farley, he conceptualizes this as going from a vague wish to a story to an example, to executable specifications, then to code and tests and then working software. So that's the full journey of a product that I totally agree with and I have adopted in aid. I want to be totally like shout out to this man. Because without this man, this framework would be totally different. I think he does everything right. Basically almost everything. I have something, but let's not talk about that. So the AID framework is. It starts at the executable specification, code and test and working software part, like the later stage of that journey. And it wants to have some specifications to plug in in the beginning. I am doing, currently working on AID for specifications as well. But that is intentionally a totally separate project I'm working on. I call it the Dream Encoder. And my design, like the way I want to design aid is I want to be very high level. So I don't want to stand in the way of how teams want to organize their specifications and things or how they want to write their code or do their architecture. I want to be very high level. So this Dream Encoder framework, it will also, it will help you to do this step that BMAD or Speckit or all these other frameworks. They do. But I've intentionally decoupled it from the execution of the.

B (26:51)

From the coding part. So you have an AI framework that you're developing for the product discovery and specification part. And then you have aid, which is specifically for the programming part.

C (27:03)

They should not know about each other. Like, AID works totally standalone. That's my vision for it.

B (27:11)

For me, this is interesting because one of the things that I really find AI is powerful for is helping to develop concepts and ideas. I find it that it is very unreliable for things that must always work. So we were talking about that early on in our conversation, the boring stuff. And one of the things that I learned from Llewellyn Falco, who was on our first series of AI assisted coding interviews, is that you should always automate the boring stuff. And what he meant by that is you shouldn't allow AI to. To even think about the boring stuff. You should create little scripts that do the boring stuff, but they do it reliably, 100% reliably, because scripts are deterministic, while AI is not deterministic. So how do you stand on that?

C (28:02)

Boring. But how does it define boring stuff?

B (28:05)

So anything that needs to be done more than twice.

C (28:09)

Okay.

B (28:10)

Because what I find is that AI seems to me to be a perfect fit for things like creating new ideas, developing existing ideas, formatting and structuring unstructured ideas. I think that works brilliantly because we are expressing our humanity by projecting our understanding onto the text that AI produces. But when it comes to coding, like, for example, one of the things that you use in AID is let's write the test first, then do the implementation. Because if we write the test, I don't care if the implementation has a small bug, we will find it. Yeah, right. But if we say, oh, no, no, no, the implementation is the boring stuff. That's what Vibe coding basically says, right? Implementation is the boring stuff. Then you want to give it to AI, forget about it, never touch it, and then just. It kind of magically works. Sometimes it does, sometimes it doesn't. So that's what I think. I think AI is really good at doing exactly the things that we think we were the ones doing it. And AI is really bad at doing the things that we think we would offload to AI. And the DDD cycle, I think, is a great example, because we write the tests with AI, then we can let it write the implementation. We don't need to worry about it, because the tests are the encoded write behavior that is 100% reliably repeatable. Right. The test itself is 100% reliable repeatable. So you can leave the rest to AI. So how do you think about this kind of distinction between the boring stuff, the stuff we can offload to AI, versus the stuff we should have control over.

C (29:50)

Yeah, this is a. This is a really interesting point and one that I have thought a lot about. And when I took Dave Farley's course, I remember we kind of shared the same idea, that if you just had the specifications correct, then that is the truth. And then in a perfect world, AIs can do whatever they want with the code. Because if the specification is good, that means it's done, because that is the definition of done. And you need an executable specification. You just have a test list. The opposite of having a test list is having an actual test that tested. But it becomes a little bit. It becomes trickier. Like, that is a really good vision, but it becomes tricky. And it became, I think, tricky even for him because he has lots of courses on tdd, but he has also courses on acceptance tests. And he calls this ATDD Acceptance Test Driven Development. And what we talked about right now, I think is Acceptance Test Driven Development. That is the mindset you have there. You just have the specifications and that is just like the BDD Gherkin style. And then you transform that into executable specifications using what Farley calls his four layer model, which I really love and have in aid as well. We can talk about that maybe later. And then if you just have this, then you could essentially just have the AI go crazy behind the scenes, do whatever you want. We don't have to care because we know our specifications are correct. Like that is the definition of don't. But he also has many courses on tdd. And this is actually a completely different thing than Acceptance Test Driven Development because it's a totally different workflow there. And I talked to him actually about this and he clarified. He clarified it for me in a way that I actually put in the article as well. And he said the two kinds of tests answer different questions. Tdd, which is unit tests, often integration tests as well, sometimes is my code technically correct? You use TDD when you're actually developing the software. But then acceptance test, that answers the question of is my system releasable after this change, is it up to the businesses? Like, I'm happy with this.

B (33:18)

So one of the things that I'm thinking when you describe that is that of course in practice, TDD and ATTDD or bdd, so acceptance Test Driven Development or Behavior Driven Development, they are really just steps in a spectrum of tests, right? Like we usually say, TDD is a design practice, right? Like not a Test practice, a design practice. While ATTDD or BTT is more, as you said, a high level, can we release this? Does it do what it needs to do? Kind of thing. But of course, you know, in practice, even though we might use different technologies, gherkin for one unit, frameworks for others, they are still one step in that spectrum, right?

C (34:01)

Yes. So after I thought about this a really long time, I realized and I think this is also what Dave thinks. Like you need both of these practices to develop production grade software because TDD makes the code good. And you know, when you refactor in the TDD step, like in that step, you actually put all the 50 or 60 years of software engineering wisdom goes in there to make the code good. And remember, this is not vibe coding. So we care about the code here. Like maybe in 20 years we can only do ATTDD because it will be good enough at all these things. But right now, and I'm using AI every day, so I, I see a lot of hype post on X about developers will become extinct. But I can see that these people don't actually write code because every time I prompt an AI and it writes code for me, there is often at least one or two or three mistakes that will cause catastrophic mistakes down the line and make the software impossible to change. Because Dave Farley also says good software is software that is possible to change easily. So that's the way I see things. You do TDD to actually develop the code and you do it in a way that makes it easy to change over time, maintainable. But then you also have outside.

B (35:53)

Or.

C (35:53)

You have acceptance test to actually test that the software is not just technically correct but is actually performing according to what the business or the client wants. Exactly.

B (36:08)

All right, so we need to change direction now and look a little bit to the future. David, when you look at AI assisted coding or augmented AI development as you call it, what are the trends that you see and how do you think this approach will develop in the future?

C (36:26)

Yes, I think there are two ways of thinking about this kind of AI driven workflows and I think people will need to choose one of these. And the first one is, this is kind of whenever you hear about or read about AI for coding, this is usually what you hear. And that is, oh, our AI can now code for over 30 hours straight without stopping. When I hear that, I get very, very, very afraid because you fall asleep and the next morning the code is done. Maybe the tests are green, but what has it done in there? Remember, when I work Today, every time I make a little prompt, it makes two or three mistakes that cause technical tech debt down the line. Imagine everything it does for 30 hours. This system will not work, I think. But this is the way. Like if you look at the blog post, this is. They want to have these agents in the cloud and they are working autonomously when you get your coffee or when you sleep or when you cook dinner for kids or stuff like that. So that is not what I want with aid. I want to be the stark contrast. And instead of doing that, I want to do the opposite. I want to work in extremely small increments and always look at what it does and always steer it towards my goals, which is the specifications. And you can like if I go speaking to your question, what is the future of this? In my approach, when you go really small in 10 years going with this approach, it will still be really, really cool because the I envision and this is already happening when I'm developing at home with aid. Sometimes I just say yes, go yes, yes, yes, yes, no, yes. You know, I don't have to type anything. Like today, the code is maybe 96% of all my code is written by AI with aid. But in the and oftentimes right now I have to maybe guide it because it forgets the instructions like the TDD workflow. Often it skips from red directly to or green directly to the next red. It doesn't go as I tell it to refactor. In the future, the small steps will be so short that you can just maybe have earpiece and with your voice you can just sit like this and it's like, yes, no, yes, refactor that no. This a really cool future to me. But compare that to the. I call it the prompt and pray approach. You tell it just do this for me and make no mistakes. And then it comes back after two hours and it's just chaos.

B (40:16)

I totally see that. So what you're saying is that there's these two trends, right? Like there's this one trend which is more towards the vibe coating magic agents in the cloud will magically create what you need. And then there's this other approach, which is the one that you prefer, which is that AI will get much better and it will be able to do this much smaller steps, more incremental development that you can just confirm, evaluate and confirm quickly, making you faster with the help of AI. And I guess that's why you call it augmented AI development. Last question.

C (40:53)

Fast feedback, small increments. And that is also in line with the DORA reports, if you know about those, they say that teams that work really well, they work in small increments, small batches, they do everything like that. Fast feedback loops. I believe that is the way.

B (41:12)

Before we go, is there a resource? Could be a book, a video, a course, whatever that you think people should look into if they are more interested in. In learning about AID and other aspects of AI augmented development.

C (41:25)

Yeah, like the first thing I think developers should do is to learn the fundamentals. They should just skip AI altogether and learn about BDD and tdd. Just best practice. But when you know that, then you can look into a framework maybe like mine. And I have released this article on dev to. It's called AID Augmented AI Development. It's very dense with information, but it has everything you need. But for anyone who wants to maybe get a more slow start, I have last week created onboarding, like more gentle onboarding flow, which is like you can go. It's like a little like a game. You go through like seven levels at your own pace. It's more friendly, introduces you to TDD in a more gentle way. And that is in the repo for aid. If you go to docs and then onboarding, we'll put the link in the show notes. Yeah, perfect.

B (42:35)

Absolutely. All right, David, we're about to end, but before we go, where can people find out more about you and the work that you're doing?

C (42:42)

Yeah, I think right now I'm doing so much with this so they can go to the aid repo. Otherwise you have me in LinkedIn and I would love to connect them. As you can hear, I really passionate about speaking about all this. So if you want to reach out and talk about it, I'm be super happy. Absolutely.

B (43:02)

Well, the link to all of those will be in the show notes, also to David's LinkedIn page. So yeah, reach out and strike up a conversation. We have so much to learn as a community in how to use these tools. David, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.

C (43:18)

Thank you so much for inviting me. Thank you.

A (43:23)

All right, I hope you liked this episode. But before you hit next episode, here's the deal.

B (43:29)

This podcast is powered by people like.

A (43:31)

You, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, summit keynotes, live workshops, E courses, deep dive interviews, books, and if you're into no Estimates. We got the pioneers of no estimates in those deep dive interviews as well. Agile Business intelligence, creating product visions, coaching.

B (44:09)

Your product owner courses.

A (44:11)

You name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of.

B (44:23)

All of that AI slop you see everywhere.

A (44:26)

And of course, without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together.

B (44:39)

So if this podcast has helped you.

A (44:42)

Before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great.

B (45:07)

It's important.

A (45:09)

But doing it together, that's next level.

B (45:12)

I'll see you in the community. Slack.

A (45:16)

We really hope you liked our show.

B (45:18)

And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.