
AI Assisted Coding: Agile Meets AI—How to Code Fast Without Breaking Things, With Llewellyn Falco In this BONUS episode we explore the practice of coding with AI—not just the buzzwords, but the real-world experience. Our guest, Llewellyn Falco,...
Loading summary
A
Hey there, Agile adventurer, just a quick question. What if, for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast. Hello everybody. Welcome to a very special series, Coding with AI. And for this bonus episode on Coding with AI, we have with us Llewelyn Falco. Hey, Llewellyn, welcome to the show.
B
Great to be here.
A
So I met Llewelyn quite a few years ago and he's an agile NXP extreme programming expert with over two decades of experience in Java OO design and technical practices like TDD refactoring and continuous delivery. He specializes in coaching, teaching and transforming legacy code through clean code, pet programming, and where possible, MOB programming as well. And he's got a story to tell us about that. Now, before we go into the conversation, let me talk about this series. This series is about bringing you real life stories of how AI is being used by serious and professional software developers. So we're not talking about people who might, and they have all the right to do so, and it's really good. They might use AI to just go. The short weekend project we're talking about, how are we going to use it? Us, the people in the field, the professionals. And our guest, Llewellyn Falco has been learning by doing and exploring the space of AI assisted programming. And that's what this conversation is about for practitioners, by practitioners. So, Llewelyn, let's start at the top because I think there's an interesting contrast here. Vibe coding is all the rage and we want to define it before we go into the details and the stories and so on and help us understand how is Vibe coding different from perhaps other forms of AI assisted coding?
B
Yeah. So first of all, like, I think it's worth pointing out that the world has shifted pretty substantially for me. February. So like how I programmed in January.
A
February 2025.
B
Yeah, 2025. It is August 2025 at this exact moment. And this space moves so quickly that like, I think these dates are relevant. Like, I am sure future me will listen to this podcast and cringe. But things have changed so substantially that we need a word to label a thing that is not like baked, that is currently in motion. And I think vive coding does that. And the shift that occurs when you are programming but not looking at the code to such an extreme extent of what, what this looks like nowadays, you need something to sort of say what this is. And, and the beauty of that is that my limitations are almost completely removed. Right. Like, I am not limited by technologies, I'm not limited by my language, I'm not limited by device or like, I can really move quite seamlessly between things. The danger of that is that you get people who are programming who don't even realize you should be using source control.
A
That's no different from when I started. Right?
B
Right. Yes. It's like that jump when you can move faster. All these little things that we've taken to move safer can become even more important. But sometimes you don't care because you're just moving so fast. You'll hear some of that in some of the stories we talk about today. But you can now program without looking at code. I think when you're in that space, vive coding is the word that we're using to say, hey, we are programming in a way that does not relate to programming.
A
Last year, I think that's a beautiful definition, programming without looking at the code. Because it also brings up some of the critical aspects that we will explore in this episode when it comes to actual practice. The reason why I really like that definition is that it is significantly different from another type of AI assisted coding, which I would call software engineering. With AI, where we are looking at the code, not only are we looking at the code, but we're asking AI to diagram the architecture for us so that we can tell it about the context. And maybe we even design some high level architecture together with the AI. So those are different perspectives.
B
I have done that without looking at the code, which is a, which is an interesting thing. Would you like me to set the context of the story I want to talk about?
A
Go for it.
B
So recently at the Agile 2025 conference occurred in Denver and got contracted by April Jefferson, which if you know her, is just like April is amazing. Probably the world's best online open space facilitator, and I would think maybe the second best in person after Diana Larson. Like, just absolutely amazing. And April also has this gift for. Or she's just really lucky on figuring out where you should put help. Like, if you put your energy into helping this person or this, or, like, really good things are going to happen. Which I don't know how she does that, but, like, it's happened now, like, three or four times where I'm just like, wow. So she calls me up and she's like, hey, we're going to do a hackathon for good alongside the whole conference. And my first thought is, like, I hate hackathons at conferences because it takes you out of the conference and you're just sort of working and, like, why do you go to this place where you can meet all these people and just work? And then she was like, you know, Woody Zul will be there as well, and Steve Koh and. And Paige. And I was like, well, if I'm going to make a mistake, these are the people I'm going to make a mistake with. So I was like, okay, I'm in. And then it turned out Lotta Kessler is also there. I didn't know that at the time, but of the people I want to create something with, especially in AI, Lotta is my top person, right? It's like Lotta and Lars are the two people I know who are doing AI better than I am. And so I was just stoked. And we show up and it starts. So Quinton Cartel is there too, who's the creator of Fast Agile. And so they start with, like. So they have the customer in the room. And the customer in this case are two women, Rachel and Amanda. And Amanda is a psychologist. She works with parents who are at risk of abusing their kids. And she works with the parents and the kids, and she helps them to deal with their kids better. Because I think so much of everything we do in life is like, well, this is the way I learned it, so I will do it. And, like, this is the way I was parented, so that's how I'm going to parent. Or this is the way that I was interviewed, so that's how I'm going to interview. Or this is the way I was managed. So now that's how I'm a manager. And that is, like, so problematic because, like, most interviews are horrible. Most people are not great fare. It's like, most managers are horrible managers. So, like, your role Models that train you are not good.
A
So you have this context, you have the customer in the room. It's a worthwhile endeavor. It's also a hackathon, which you sounded a little bit skeptic of.
B
I'm very skeptical of. And, I mean, I had an absolutely amazing experience just as spoiler work, but I also did not experience the conference. So, like, I'm still mixed at them at conferences, but this experience was so good that I don't care they missed the conference.
A
So what was so good about that experience of. Of coding with a large group of people that were coming in and out throughout the conference and with the help of AI, of course.
B
Of course. Well, okay, so the first. So Amanda, the psychiatrist, she starts by saying, what I really want is there's this technique that we use with parents, and the way it basically works is they watch the parent and the kid interact for five minutes, like playing, and they record a whole bunch of micro reactions, like 60 micro interactions. And then they're like, these are the good ones, these are the bad ones. And. And let's look at teaching you how to do less of the bad and teaching you how to do more of the good. And there's eight interactions that they. They think. And she's like. And we have data that, like, when. When we do these trainings with parents over time, right? So it's like they do training once a week, and then they. The parents go home and practice it with their kids. It is the most effective thing we have to prevent child abuse. And yet a lot of clinicians are not doing it. And the reason they're not doing it is because recording those 60 interactions in five minutes is really hard. And if they compile them, they have to show the parents how they're changing over time. They don't get paid for any of that stuff, and they're not paid very much anyway. So they're overworked, they're underpaid, and this is just too much. So they're not doing it. And they're like, even though we know this is the best thing we have, people are choosing easier things to do. And she's like. And that is really frustrating to me. So right away we're like, oh. Because we had all these ideas like, oh, we can automatically record things. And we saw this. We're like, they just need a calendar. They need, like, one of those little clickers you have in your hand. But, like, where I can have eight hands at once and clicking different things at the. We went through, like, a lot of Exposition as the whole group. And by the end of the day, me and Lada knew exactly what we wanted. We actually broke away. We wrote just a markdown page of here's what we want this to look like. And then we fed that to Claude code. And 15 minutes later, we had a working app on the phone that we handed our phone to Amanda and had her test it. And, like, she was in tears. She was like, you know, for 20 years, I've been trying to make progress on this, and this is the first time I've had hope. Like, I can train. And so, like, that was amazing. And being able to go from idea to minimal vital product in, you know, 15 to 20 minutes, it was an unbelievably short amount of time. Okay, but that's.
A
That's the time it took from knowing what you want until you got it. But of course, there was all of the exposition, the interaction with the customer. Understanding what I want.
B
Yeah, to a. To a. Like, that's not the final. In three days, we released 61 times. So, like, that was not. It wasn't. Oh, I know what I want. But it's like, I know enough of what I want that I can get an MVP out the door and that, like, all this stuff that Lean Startup has espoused for a long time, when you can crank that dial so high, that's amazing. So that was sort of the context that we're working on, and then we are changing things. I'm going to jump around in the story, but I want to jump just a little bit forward to. There is a time where one of the other things that Amanda said and the reason Rachel was in the room. Rachel was a data scientist that works at the Kemp center, and Rachel is responsible for sending the reports to the state for how much the physicians are doing stuff and doing this practice in particular. And those numbers are related to how much funding everybody gets. And she has not sent any data to the state for three years. He's had none to send. Right. And so. So it's also mentioned that it'd be so nice if Rachel actually had some data to send at one point. Part of that data includes, did they ask the parents about the homework? And so we made a screen that said, hey, did you ask about the homework? Because that's the only thing we need is yes. No. Did I ask? And then Rachel came and said, you can't ask that question. And I'm like, what do you mean I can't ask the question? That's the only thing you care about. And she's like, oh, yeah, no, that's the only thing I care about. But if you ask it as a yes, no question, it's called self reporting. And legally that's not something I can use. And I'm like, what? But like, I've. I've dealt with lawyers enough to know that, like, those are arguments. You don't even. Like, you're never gonna.
A
It's in the law. Right? That's it.
B
Exactly. And I'm like, okay, so. So what can I ask? And she's like, you can ask. How many times did they do homework? Or I didn't ask them. And I'm like, okay, but you don't even care. Like, even if it's zero times they did the homework, that's still a yes. And she's like, yeah. And I'm like, okay. Like, it's.
A
It's the law, right?
B
You can't argue with the law. So. So I went to. So we went to Claude and I'm like, I know. We got to swap out this panel where we ask. And Lada was. And Lotta has like a really. Like, I was programming.
A
You're a partner of programming at this point?
B
Yeah, I do a lot of pair programming remotely. And when I program, I was programming with Ilya, who's like Stackistan somewhere out.
A
There or something like that.
B
Yeah, yeah. And he was like, when we pair together, AI works better. And I'm like, it's like there's these very small intuitions that I've developed over really trying to learn AI and I don't even know what they are, but it's like I just make small changes to my words or I flip a question and it's just like those instincts have been trained and at the moment they're good. And I don't know if those instincts will still be good next year. Maybe AI will change to a point that everything I do now is invalid. It's one of the things that keeps me awake at night. It's like, how do I stay current in this thing that is changing so quick? But Lotta's instincts are also really finely tuned in this. And she's like, I don't think it can refactor this. Well, our code has gotten big. We told it like, hey, we want to swap out this panel before you swap it out, refactor the code so the panel is easy to switch. And it did. And then we asked it to switch it. That's without us looking at the code. All we know is the code is big. We have this sense that this is going to be hard to do. We asked it to clean it up and then we asked it to do it. We didn't look really at how it cleaned it up. We just checked, hey, the functionality is still working at this point. We're manual testing. We'll talk about that later. But. So we asked it to do good engineering practices, even though we didn't really understand what it was doing. And that worked. There are multiple times we'd ask it to explain the architecture to us and we just say, okay, yeah, that seems sensible. And then we'd have it do it. Or we'd say, that doesn't seem sensible, like, do something better. But I felt like a manager talking to a programmer at that point more than I felt like a programmer. But I know so, so you can do these better practices even though you're not really seeing what's underneath. And the way that I think about this is, you know, so I mentioned, you know, we do interviews. The way interviews are done to us or we manage the way we're managed, like so much is just like we do the default thing that is popular or was popular to us. And you know, AI is trained on. On people, on stuff. And so it knows a lot, but it has default settings. And those default settings are based on popularity. And a lot of times the default settings are not good. And so a lot of what we do with AI is tell it, let's not do the defaults. You know how to do these other things. And one of those defaults, by the way, is AI is AI is very. It wants to make you happy. It will compliment you, but it will also, it won't tell you something that's disturbing to you. By default it will be agreeable. And we actively tell it. Like we. So we have a cloud MD file which is like the base settings that go in front of everything. And one of the things we say in there is like, tell us things we don't want to hear. Like, help us not to make mistakes. And we also tell it, don't just do the work. It's important that we build a mental model together. Right. And so those are not the defaults. Right? But it is things it knows how to do. And it is like a lot of times, you know, your boss is like, oh, I want you to. I want to hear the truth. But like, then when you tell your boss the truth, you get fired. Like, one of the things here is like, you can tell it the defaults and it will pretty much do them. Like it will believe you. It will trust you.
A
So what you're already kind of describing here is that a good practice for developing with AI is to have almost like a priming document that you give to AI at the start of every session where you tell it what are the rules you want it to follow.
B
If you're using an Agentix system, they almost always have a default always on prompt. Our prompt has stuff like that. It also has stuff like on Mac, there's a terminal command called say, where you can type a terminal command, say and then quotes you. Say whatever you want and then it will voice it. We have it talk to us when there's something important to get our attention. And then the other thing we have is we have a little clover emoji that we ask it to start every conversation with. And what that does is when that clover goes away, we know that our context has gotten too big.
A
Direction. Yeah, right.
B
And we can see it because, oh, emojis gone.
A
Like, that's a great tip, by the way. Everybody pay attention. Just put a specific emoji at the start of every response you get. And when it's gone, it's time to restart the session.
B
And if you're taking your data and putting it into markdown files. So like we have a project markdown file. We had architecture markdown files, a technique that we didn't use for that, but I've been using in the last week. Like I mentioned, this is moving really fast. Is each micro feature I'm making a little markdown file of. Here's how this feature works. Because the data is in that context, not in the. Like it gets put into the context because I asked it to read those files. But I can clear context and start a new context and say, read this file. This is a feature we're working on and that allows me to drop.
A
Tell me a little bit more. How would you go about kind of resetting the session with AI, where the clover is gone, right? Like the emoji that you ask it to use, it's gone and you realize that. So how do you go about resetting the work? Because there's a lot of stuff that has been discussed and decided already and it won't be in all of the context files you were just describing.
B
So if it's important, they're usually in my markdown files. And that happens two ways. Like. So I mentioned, like, we started. Wait, we just wrote the first markdown file. It was really simple. It was sort of maybe 20 lines and not 20 full lines. Like 20 lines. Of bullets and stuff. But then later on. So, like, before we got to that panel where we had to change things, as we were building that up, we were just sort of talking to chat. Now when I say talking, I actually mean talking. We're on Mac, so we're using a program called Super Whisper, which you can download for free. You hit a key combination on your keyboard and you talk, and it goes into wherever your cursor is.
A
And so it transcribes what you're saying.
B
Yeah, yeah. So most of the time, coding now looks like I'm talking to. It's almost like Star Trek, like you're talking to the computer and then a code shows up. And it was good enough that we're in a room of 20 people and everybody sort of talking and it would still pick up our voice and ignore all the background. It was just amazing. We're just talking to it and we're getting the panel to show up. One of our default things we say is like, draw us ASCII diagrams of anything you need to explain. It'll create these little boxes and stuff. Once we get what we want, we're pretty happy. But then we'll say, okay, now can you add it to the feature file and document it and simplify it. We are building as we go this documentation. I actually think that documentation is like the new unit test. And I mean that in a way of like, this is the spec that if I had to lose. If I had to choose between losing my documentation or losing my code, I would keep the docs. I think I could regenerate the code pretty easily with AI, right? With AI, yeah. And I never cared about documentation. I mean, my whole life I've barely cared about documentation.
A
But isn't it. So, like, with AI, the burden of documentation is gone. Right? Because you work through the. You do a very iterative and very fast feedback cycle of describing the feature, getting the feedback, seeing it working, changing things. And then once it's done, you say, okay, now document it here so that we keep it for the future. And that kind of reverses what we used to do way back when, which is first document everything, then write the code.
B
Well, so we'll do both. We might start with the documentation and have it write the code, or then we'll iterate on it and have it update the documentation stuff. Sometimes if I want to add a brand new feature, I'll just put it in the doc and then say, hey, read the doc and add the feature to the code. It goes both ways. But the important Part here is that the documentation is now executable. I can turn it into code that is so valuable, that executional part of the document, because so often you would write documentation in, say, 2000 and nobody would even read it. And if they did, it was very unlikely that it's going to turn into knowledge.
A
So I want to explore one thing, because we're talking about documentation, I think it makes sense because on YouTube videos and people talking about AI, there's a lot of emphasis on the idea that we are now just creating what you and I would call PRDs, product requirements documents. And then the AI is doing the code.
B
We.
A
What you are describing from this story, though, is quite different because even though you are creating requirements and spec documents, you are actually doing that incrementally and iteratively, just like an Agile person would do. But what I hear a lot of people out there promoting is this idea that no, first you write all the requirements down, then you give the requirements to AI. And I, at least from my Agile background, I'll go and say, hey, we've done that in the past. It didn't work with humans. It's unlikely to work with AI either.
B
I mean, that works really, really well. I think if the product has already been designed and is out there in the world and you're like, I want to make a clone of that product, but that's not what we do, right? Like, we. We make new things. And this, this going back to, like, Lean Startup, you know, we made that first product, we got it in our hands, and that was. At the end of the day, what we did is we went to dinner and I was like, okay, we have to fix this, this, and this. The first thing is the order that she wrote it on the board isn't the order she thinks about it. So the buttons are in the wrong order. And that meant she had to look at her phone more, which is exactly what we don't want. We're like, okay, we need her not to look at the phone. So the buttons have to be in the right order and we want haptic feedback. And Lotto is like, can you do haptic feedback on a phone without, you know, without it being a phone app? And so we went to AI and we're like, hey, can we do this? And it did it. And, like, it turns out it doesn't work on an iPhone because iPhone was worried about battery, so they never implemented it. But on an Android, it's like, no problem. So, like, moments later, we have haptic feedback in there, and then the other thing we were like is, okay, we need to know that we have the right version. So we're hosting this on GitHub pages, which we did by saying, this is a GitHub project, please host it on GitHub pages. And it wrote a workflow for us that did that and gave us the URL, which was really nice. Then the other thing we need is we need to work on the laptop, because one of the things they said is a lot of times they have laptops at the lab. And so we did that and we used the number keys and we did all that. So it's like those were the first three things we were like, if we really want this to work, we need that. And then in the morning, the first thing we did is we're like, okay, we have a new version, can we retest? And so she does that, and this time she's using the number keypad. And the way she tests, by the way, she made this video of her interactions with her kid five years ago. Kid was a young kid. And she has this video on YouTube and she watches the video and she records all the micro reactions. And so now she just has her finger on the keypad and so she's fully focused on the video. She used this to train other people. She's probably watched this video like 500 times and she's doing the thing and at the end of it she's like, oh, my God, I just noticed an interaction that I had missed. Right. Because all of her interact, her attention is now on the screen because she can just keyboard.
A
Yeah, yeah.
B
And like at that point I was like, well, it doesn't really matter what we do at this point. We have won. Right, Exactly.
A
That's value, Right?
B
Right, exactly. And so, so much of what we did was like either exploring risk or discovering value, right? So we do something, get it into the hands of the user. And that's never going to change because unless you're building something that's already there.
A
And that's the core of that iterative and incremental aspect of Agile. And that's what I tell people. It's like, no, you don't write the prd. Yeah, you may write a set of features that you wanted to develop, but then you need to show it to.
B
They're going to be wrong, get the.
A
Feedback and then iterate that all the time.
B
Yeah, so.
A
Yeah, go ahead.
B
So there's one other thing that happened here, and this is like. Because I was trying to put together, okay, so one of the very first prompts that we did when we wrote the product. Thing is, we said Write it in TypeScript or JavaScript. And it chose. But we actually didn't even look like three days later. I didn't know if it had chosen TypeScript or JavaScript. Another thing we did is. So I mentioned that versioning, right, we had to put a version number. When you hit the settings, you can see the version number. We needed that to auto increment. Now, AI can do that, but AI is sloppy and it's inconsistent. The first thing we did is we said, okay, write us a shell script that auto increments that number. It wrote that and now I have a repeatable process. But then I was like, but I need it to do it all the time. So I'm like, write us a git hook. So every time I commit it, it auto increments, right? And so it's like it's doing that to create the automated process. But I am taking everything that can be deterministic out.
A
Okay, yeah, that's a good point. Actually. If something needs to be Repeatedly correct so 100% accurate, you need to automate with code.
B
Yeah, yeah. AI can write that code. But don't make AI do repetitive tests. Have it like humans. Right, exactly. And just get everything. But it's like humans, but even worse. For example, we had a thing where we needed to make a new file with a date. We had it write a script that just created the new file with the date at the top because we don't trust it to know today's date. It's not that it can't, it will often get it right. But why even spend the amount of tokens that are needed to do that? Like just remove it. Just remove absolutely everything you can out of its working memory.
A
That is deterministic. Yes, absolutely.
B
Yeah, exactly.
A
Okay, so I have a couple of questions, but of course now we're talking about some practices, like the one that you just did, remove everything from AI that is deterministic, automate that with code, and so on. Like those are all very good practices. But what are some of the anti patterns that you've seen? Perhaps some you've done yourself either from your own experience, others experimenting with AI in their development workflows.
B
So the, I mean, so the biggest anti pattern is you're not committing frequently. Like I really want the ability to drop my context and revert my changes at a moment's notice. Right. And, and so that means like get your stuff into your documents, get your commits in so that at any time I can, I can just shut everything down, start it up again, and I'm good. Or I can roll back and I'm good. That, so that's like the number one thing. The other pattern like this is, okay, so for three days we're releasing 61 times, we're not even looking at the code. What, what does it mean now to be a programmer, right? And because there's definitely things that like, allowed us to be really good makers. And one of them of course, is like, customer in the room. One of them is get it in the hands of the customer. Another one is how I assess risk. And by the way, I'll just tell you, on a personal level, a lot of this was me pissing off people over the course of three days in a fairly small room. I pissed off quite a lot of people. But one of the ways I pissed people off is the customer came with the UX person and they're like, we need you to design this next. This is the most important thing. And I was basically like, no, that's not what I'm going to do. And I like, it's really like, I need a better way of saying this so I don't piss off people because I'm not advocating that. What I am advocating for though is fight for the things that are important, right? And ideally do it nicer and gentler than I do. But a user is really good at knowing if they like something and they're really good at knowing if they don't like something. What they're not good at is knowing how to fix something so that they will like it, right? Like, I can look at a movie and say, that movie sucks, but that doesn't mean I can make a good movie, right? And so a lot of times, like, you have to listen and be like, okay, they don't like this, but how they want you to fix it is not necessarily the right thing. And it doesn't even mean that's the thing you should be fixing right now. And so for us early on, I was like, we need to stop. What we built is good enough if we don't build anything else. When I saw her see that interaction with her kid that she had not seen before, at that point I was like, okay, there's a couple little things, little things I want to tie up here because they're easy wins and I want to get them out of my head. But now I need to switch to the data because there's a whole bunch of unknown risk there. When I was saying, no, I'm not going to build this. What I was trying to do is say, yes, I'm going to build data stuff on Rachel's machine. Which we had gone to lunch with them and asked. And what we were told is they could not put up a server in their system and we could not put out a server not in their system. How do you send data like that? That was pretty hard. And it was HIPAA data, or we were worried about it being HIPAA data because it's about a medical client. And so that is like a ball of lawyers. And what we were able to do is realize what Rachel actually needed was only three yes, no questions and two pieces of data that are possibly HIPAA related. The date and the clinician. Like, the clinic. And. And so, like, when we got it down there, I'm like, well, there's very little here that's dangerous. We can probably get around that. But how do I get data to a place if I can't send data? And she was like, well, you can use OneDrive. And I was like, but then every single psychologist needs to install one drive. Like, I can't. I don't have a mechanism to get it on, like consistent machines like that. And as we were going, I was like, can I send you an email? And she's like, oh, yeah, they let us send email. And I'm like, okay. And then we realized if we send the three yes, no questions, we don't have to send the date or the clinic, because I can figure out the date by when it. Yeah, exactly. And I can figure it out from the email address who sent it. And so I was like, oh, my God. Like, that just solves all our problems. But now I need to send a whole bunch of emails to Rachel's machine. So we do a quick thing with AI to get it to launch an email, which that was pretty easy. And then I'm like, okay, Rachel, do you have your machine here? Now? Rachel's a data scientist, so like, if I can get her basically a comma separated file, she is really happy. And so the first thing we did is we had Rachel there. We had Lotta asking AI questions. We had just a whole group of people. This isn't even mobbing. This is like 15 people screaming at the same time. And so Lotta is like asking, okay, how are. I'm thinking like, well, maybe we can do like a IPOP or IMAP server or a POP server or we can put some credentials somewhere. And Lada just kept saying, give me other suggestions, give me simpler suggestions. And what it gave us was you can just take in Outlook, you can set up an Auto Forward folder, and then you can make a powership script shell that just saves that entire folder to a directory as MSG files. We're like, no passwords. It's just on basically a cron job. It's a Windows schedule task. We were like, I think that can work. Now everyone's yelling and my job is to listen to everybody and then yell louder at Lada so she can. Right? And it was very chaotic, but it was sort of. It felt to me like a whole bunch of people with spears stabbing at like a mastodon. But we did like, we killed the problem. We got it to work and then we stopped and we did 40 minutes of retrospective so that everyone in the group could get to the same page. Because it was like, you know, I'm just picking things from what people are saying and then, you know, yelling louder. And so. So there was a lot, a lot of information going, but there wasn't a lot of synchronicity in that team at that moment. And it took like another 40 minutes of retrospective before we're like, okay, wait. Of course, most of us will not.
A
Most of us will not work in that large group, right? Like, it's probably going to be a pair or a couple of people most.
B
And most of the time as we're working in that model. But that particular problem, we actually, like, we needed a lot of people because we needed a lot of ideas.
A
So moving on from the story because we're getting close to the end here. Llewellyn for those of us who listen to this episode are interested, want to know more? What is a resource could be a book, a video, a paper or a.
B
Tool that you think the first resource is. If you are using AI by going to a website like don't stop going to website, that's fine, but that is not what we are talking about here. Claude is an AI, but Claude code is a cli, like a command line interface to interact with files. Windsurf is like. It looks like Visual Studio code Cursor. If you are using something like Juni, stop. Go get a better tool. Like Juni is not good. There is something called Copilot in Visual Studio. It is decent. It is like what I think of as the lowest level of what you could be doing here. But there's also something called root code. If you're at Copilot, probably you should be at root code. All of these things are usually like $20 a month or somewhere in that Neighborhood, like, pay that money, go experience that. And if you're in something like Windsurf, you can choose which LLM you talk to by far. Like, Claude and GPT5 are the best. Claude is better, I think it's definitely faster. GPT5 is. It feels sluggish is the way I would say it. But try out the different ones and new models drop all the time. Get a sense. Sometimes you just have to go to the other models. Realize it sucks, but now you can hit it with data. This world changes really quickly. But use those, that's the first thing. If you do not have that tooling, you are not doing. You're not doing what you think other people are doing. Like, you need those tools. The tools.
A
You need the right tools for the job.
B
Yeah. And you need tools that can run programs. One of the things that like, almost everyone I know who's, who's doing this has done is they've turned off the safety guards like that. They're just like, if you want to run a program on my system, you can, you don't have to ask me. And that is terrifying. Right? Like it could delete your whole driver, you know.
A
But it has happened, by the way.
B
Yeah, but the thing is, if you give it access to write to your tests and run your tests, it can do anything it wants anyways. There's a certain amount of. If you give it a little bit, you're giving it all anyways. When you do that, what happens is it starts doing these cycles. Claude code is really, really nice. It is a cli and that allows for certain things. And one of the things that allows that, let's say Windsurf doesn't, is so like we made Scott. This is actually Scott from corgibytes, or corgibytes, I guess is sold. But Scott, who started corgibytes, he made this refactoring program and he made a little clot, or not refactoring a testing program. So he made a little CLAUDE prompt that said read my code and write a unit test that increases coverage. It's a fairly simple prompt. It's a little more verbose than that. But your MD file should never be more than 100 lines, period. And this is closer to 20 lines. It's pretty small. Then he made a Python script that said run code coverage. If it's under 80%, call that Claude. Then it writes one test, then the Python script runs the test again to make sure they pass and then commits and then just does a loop of that. So now, we've taken, you know, when I was talking about, like, the. The git hook that's taking deterministic stuff underneath AI out. But here I'm taking the. Scott is taking the deterministic stuff out above AI. And so AI is in the middle. And that's fantastic, right? So there's a whole world that opens up to you when you can automate that stuff. And then the other tool I would 100% recommend is get Super Whisper and try to train yourself to not type as much as possible, like, whenever possible, talk. And one of the things you'll find is when I talk, I talk a lot more than when I type. Right? Like, so, like, we didn't do this during. During the. During the hackathon. I didn't know about this. And I was so focused on testing user value, like, validating that the things we built were what the user actually wanted. But when we got back home, I was like, it'd be nice to have unit tests for this. And so what we did is we made a document called Test Plan, Test Plan md. And then I hit Super Whisper, and I just vomited, like, a sentence of here's the happy path of how you test this code. And then we said, read that and clean it up. And it did. It took, like, that paragraph of vomit and turned it into, like, 20 lines of fairly structured stuff. And I was like, well, that's really nice and accurate, but it's, like, really verbose. And my first indication thought was, like, let's get rid of that, because I don't want to test that. That's verbose. But I was also like, but it's also. It's not. There's nothing. I don't see anything wrong. So what I did is instead, I said, okay, write me the next 10 test cases, but no duplication. Keep them terse. And so the next nine things that showed up were all really nice and small. And it's like, the first one sort of gave enough structure that everything else could be small and light. And we're like, we're pretty happy with that. And then we're like, okay, but this is an app. It's a web app that shows up on the phone. How do I test just a web page? We asked it, give us 10 ideas of how I could test this. One of the things it gave back was Puppeteer. And we're like, that sounds reasonable. He said, okay, write us the test in Puppeteer and write us a shell script to run the test. It did. And now we have Test and That whole process took about 40 minutes. And if I knew that I could have gotten that level of full stack testing in 40 minutes, I would have done it in the three days.
A
Well, that may be.
B
I could do it.
A
Yeah, that would be the next best of all in developing the process. All right.
B
Hey, Llewelyn, the rules are changing all the time.
A
Indeed. Indeed. Thank you very much. It's been a pleasure to have you here. I think you've given us a lot of food for thought and ideas and practical tools and tips and shared your process. We thank you very much for that. So thank you very much for your generosity with your time and your knowledge.
B
Thank you. It's been a really exciting time. If you want to make something, there could not be a better time than now.
A
Take that home, everybody, and apply it. Thank you very much, Llewellyn.
B
Thank you.
A
All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like 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 your product owner courses, 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 all of that AI slop you see everywhere. 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. So if this podcast has helped you 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. It's important. But doing it together, that's next level. I'll see you in the community. Slack. We really hope you liked our show. 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.
Podcast: Scrum Master Toolbox Podcast
Host: Vasco Duarte
Guest: Llewellyn Falco (Agile & XP Expert)
Date: October 7, 2025
This bonus episode delves deep into how professional software developers are leveraging AI to dramatically accelerate coding without sacrificing code quality—or safety. Host Vasco Duarte speaks with Llewellyn Falco, a seasoned Agile and Extreme Programming coach, about his hands-on experience using AI, particularly in high-impact, real-world scenarios like hackathons for social good. They discuss the evolving landscape of "Vibe coding" (programming without looking at code), practical strategies, pitfalls, and the future of Agile in an AI-driven world.
(07:00–16:00)
(15:36–26:00)
(22:53–25:27)
(25:49–30:58)
(30:58–36:00)
(32:22–39:15)
(39:21–46:12)
On the paradigm shift:
“The beauty of that is that my limitations are almost completely removed. I'm not limited by technologies, I'm not limited by my language, I'm not limited by device.” —Llewellyn (03:45)
On AI-fueled speed:
“Being able to go from idea to minimal vital product in 15 to 20 minutes, it was an unbelievably short amount of time.” —Llewellyn (11:57)
On documentation’s new power:
“If I had to choose between losing my documentation or losing my code, I would keep the docs. I think I could regenerate the code pretty easily with AI.” —Llewellyn (23:10)
On feedback-driven development:
“We make new things... So much of what we did was either exploring risk or discovering value. We do something, get it into the hands of the user. That's never going to change.” —Llewellyn (29:13)
On aligning with real risks:
“What I am advocating for though is fight for the things that are important, right? A user is really good at knowing if they like something and they're really good at knowing if they don't. What they're not good at is knowing how to fix it.” —Llewellyn (34:01)
On tool selection:
“If you do not have that tooling, you are not doing what you think other people are doing. Like, you need those tools.” —Llewellyn (41:24)
On the future:
“If you want to make something, there could not be a better time than now.” —Llewellyn (46:39)
This episode provides a candid view into the bleeding edge of software development—where AI is not just a helper but a true collaborator, even a “coding assistant manager.” Llewellyn’s stories and tips demonstrate how Agile values, disciplined collaboration, and careful tool selection drive massive acceleration in real-world impact—without breaking things. The rules, tools, and patterns are changing, but the core Agile lesson remains: learning loops, real feedback, and a relentless focus on delivering value are what unlock the full benefits of AI in tech.
For Agile practitioners, developers, and anyone excited about the future of software, this episode is both a field manual and a call to action: embrace the new tools, adapt your workflows, and iterate faster than ever—with safety, quality, and value always at the center.