Pachinko Coding—What They Don't Tell You About Building Apps with Large Language Models | Alan Cyment

Summary

---

Summary – Scrum Master Toolbox Podcast: Pachinko Coding—What They Don't Tell You About Building Apps with Large Language Models

Guest: Alan Cyment
Host: Vasco Duarte
Date: October 8, 2025

---

Episode Overview

This episode dives deep into the practical realities—both thrilling and frustrating—of coding with Large Language Models (LLMs), as experienced by veteran agile consultant and certified Scrum trainer Alan Cyment. The conversation explores the promise and peril of "AI-assisted coding," the addictive loops developers face, and how abstraction levels are shifting in software creation. The episode is candid, quirky, and insightful, rich with analogies (from Thermomix kitchen gadgets to Japanese pachinko slot machines) and tips for mastering this revolutionary workflow.

---

Key Discussion Points & Insights

1. Defining AI-Assisted/Vibe Coding

• AI-assisted coding vs. traditional coding: Alan describes "vibe coding" (sometimes called AI-assisted coding) as largely relying on an LLM to output code, bypassing deep rational engagement with the software’s details (02:30).
• He likens its promise to a kitchen Thermomix: you just add ingredients, follow instructions, and supposedly get a gourmet meal—no real skills needed. But early experiences left him “disappointed,” with code that often didn’t even compile (03:20–04:14).

“Thermomix coding is here...And I kept becoming disappointed.”
— Alan, [04:06]

---

2. The "Pachinko Coding" Cycle: Addictive but Risky

The Gambling/Slot Machine Analogy

• Alan coins the term “pachinko coding,” referencing addictive slot machines in Japan (pachinko parlors), to describe the endless loop of trying, copying and pasting errors, modifying prompts, and hoping that “this time it will work” (10:10).
• The cycle induced a rush of dopamine—followed by frequent disappointment and wasted money and time.

“It was like a TDD cycle, but more of an addiction cycle...This time it's going to work. I know this time it's going to work.”
— Alan, [07:03]

The Price of Hope

• Sometimes he’d spend up to $20 a day chasing solutions, which could actually be cheaper through hiring a human developer for small tasks (13:19–15:09).

---

3. Hits and Misses: When LLMs Work and When They Don’t

Breakthrough Moments

• On rare occasions, LLMs surprised him with dramatic productivity gains. Alan recounts successfully building an ecommerce integration in a single day, far faster than he could have learned from scratch (16:19).
• He echoes Martin Fowler and the “English as the new programming language” abstraction, suggesting LLMs might herald a new modeling tier: moving from punchcards → assembler → high-level code → English prompts as the next abstraction (17:47–19:05).

“English is the new level of abstraction. So first we had punching cards...And now we could think in terms of real variables and then object orientation came...So each one of those was a new level of abstraction that allowed us to forget about thinking so much at that low level allowed us to think about bigger things.”
— Alan, [17:47]

Failures and Frustration

• LLMs frequently overcomplicate things, especially with UI-related code (CSS, events). Alan joked it was like letting a “Roomba try to paint your room”—often a mess (11:42).
• When using more expensive models, there was no guarantee of better results (11:37).

Adapting Practice: From Rage to “Mecha” Coding

• Alan introduces “Mecha coding”—where the developer is like a pilot in an exoskeleton: more powerful than ever, but still responsible for direction and quality (19:05).
• Viewing LLMs as a “function,” not a person, helps manage frustration; expecting brilliance leads to "rage coding". Instead, he treats the LLM as an extrapolation machine—good at what it’s seen before, unreliable otherwise (22:03).

---

4. Strategies That Work with LLMs

Agile-Inspired Micro-Steps

• Small, well-defined steps yield best results—embracing TDD and YAGNI (“You Ain’t Gonna Need It”) principles (24:30, 37:47).
• Prompt LLMs to suggest options and clarify pros and cons before coding, using the model as a conversational consultant (28:11).

Purpose-Built Prompts and Process Hygiene

• Provide context with “conventions” Markdown files, set clear process standards (like always running integration tests, checking for errors, and refactoring for readability).
• Explicitly ask the LLM to “take two steps back and rethink,” especially when stuck. This can reset overcomplicated solutions ([30:14–33:42]).

“I wrote some, the prompt was something like take two steps back and rethink the whole way in which you are trying to develop this and try to develop this the simplest possible, most native basic yakni way of turning on checkboxes...And it worked.”
— Alan, [31:42]

Be Realistic About LLM Weaknesses

• LLMs are better on some tech stacks than others (React Native/Flutter = “brittle”; Svelte = “solid” in his experience, [37:47–40:14]).
• Success correlates with the LLM’s exposure to the relevant tech stack in its training data.

---

5. Case Study: Building a Custom Birthday Reminder App

Alan describes building a “birthday and gift reminder” app:

• Past attempts (pre-LLM) failed due to complex integration/setup.
• With the LLM (“mecha coding”), he delivered a working version in under a day—without knowing Swift—by letting the AI explain options, and iterating incrementally (24:55–29:05).
• He overcame major bugs by prompting the LLM to reset and rethink, eventually achieving a robust result.

---

6. Notable Quotes and Memorable Moments

• On Addictive Loops:
  “I felt like a servant…I was sort of like serving the machine by telling it, okay, this is wrong.”
  — Alan, [06:24]

• On Finding Joy in Success:
  "The moment the pachinko machine said I won and I had won...when it did work…it was, I really felt that something…perhaps this could be a new level of abstraction."
  — Alan, [16:19]

• On Realistic Use:
  "I don't think this approach would ever work for enterprise grade software...For that kind of things, I think it can work."
  — Alan, [34:35]

• On LLMs as Bad Programmers: "If you start to treat it like a person, it drives you crazy because it's so wise and so stupid at the same time."
  — Alan, [22:03]

---

7. Practical Tips for Effective LLM Coding

• Go small: Embrace micro-commits and smallest-viable requests.
• TDD/Integration: Incorporate continuous testing as part of the conversational prompt.
• Prompt discipline: Provide the LLM with comprehensive prompts outlining context and process standards.
• Refactor in steps: Always ask AI to suggest refactorings or simplifications.
• Leverage LLM as a consultant, not just a code generator: Query for tradeoffs, options, and explanations.
• Acknowledge tech-stack limitations: Know the LLM will perform unevenly depending on training data for your stack.
• Don’t expect LLMs to replace human craftsmanship: Use them to accelerate prototyping and tackle accidental complexity, not to architect enterprise-grade solutions blindly.

---

8. Recommended Resources

• Paul Hammond (LinkedIn): Inspirational for crafting comprehensive LLM prompts (40:56).
  “I learned…the step that mostly helped me was reading and watching a guy called Paul Hammond on LinkedIn…his style and his insistence…on doing small steps that helped me.”
• Kent Beck: Mentioned for “augmented coding,” but Alan found Paul Hammond’s approaches more practical ([40:56]).

---

Timestamps for Important Segments

• [02:30] – Definitions: “Vibe coding”/Thermomix coding
• [07:03] – Addictive “Pachinko” coding loop
• [10:10] – Coining “Pachinko coding”
• [13:19] – Spending $20/day; rivaling human outsourcing cost
• [16:19] – First breakthrough: the pachinko “win” moment
• [17:47] – LLMs as a new level of abstraction
• [24:30] – “Mecha” coding and process hygiene
• [28:11] – Using LLM as consultant for options/tradeoffs
• [33:42] – Resetting and getting unstuck via prompts
• [34:35] – LLMs not (yet) for enterprise-grade software
• [37:47] – Small steps, TDD, integration, and CI
• [40:56] – Resource: Paul Hammond’s prompting strategies

---

Conclusion

Alan’s honest, witty account of “pachinko coding” serves as both a warning and a roadmap for developers plunging into LLM-based workflows. The magic happens when practitioners combine agile thinking (micro-steps, constant feedback, refactoring) and new prompting best practices—treating the LLM as a powerful but unpredictable exoskeleton. While the full promise of “Thermomix coding” remains elusive, Alan’s experiments illuminate a path where English truly could become the next programming language—when paired with discipline, agility, and a pragmatic eye for tradeoffs.

---

Connect with Alan:

• LinkedIn: Alan Cyment
• Web: simmon.com (most content in Spanish)

---

End of summary.

Transcript

[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 one more episode on this week of Coding with AI. And joining us today from Buenos Aires is Alan Simmont. Hey Alan, welcome to the show.

[B]

Hey Vasco, thanks for inviting me.

[A]

Absolutely. For you to know Alan a little bit, he's a consultant, a trainer and a facilitator based in Buenos Aires, specializing in organization, organizational fluency, agile leadership and software development cultures. He's also a certified Scrum trainer with deep experience across Latin America and Europe. And he blends agile coaching with theater based learning to help leaders and teams transform. And today we're exploring the practice of coding with AI. Not just the buzzwords, but real life experience that our guest Alan has been learning by doing and exploring. Some people call this vibe coding. I tend to call it AI assisted coding because vibe coding may have other connotations, but I don't actually know what that means for you. So let's start with your perspective and your definitions. Alan, how do you define vibe coding or AI assisted coding? And how is it different from other types of coding with AI?

[B]

So my understanding is that the original definition of bytecoding is that even, even if you know how to code, you use an, an LLM, an AI tool to create code for you and you don't really get to think about the code or even to read about it. It's like you're just like mere user, so you don't have to think. All right? And that I think it's included in the word vibing, that it's not your thoughts, your brain actually doing rational thinking, but it's just your feelings. When I First, I mean, before even the coinage of Vive coding, when I first read about the promises of the. Of code creation by the original chatgpt, the instant metaphor that came to my mind and it really actually landed after I heard Vive coding and I said, it's not about vibes was. I don't know, at least here in Argentina, has become very fashionable. I think it's a European brand. But there's a machine called Thermomix that it's supposed to like, cook like a cook, I mean, with quotes for you, without you knowing how to cook. You just have to load the recipe, bring the ingredients, put them, press the right button, wait, and you'll have gourmet meal made for you after a given time. So I said with some fear, because I was a developer for a long time and I mean, so it was a bit fearsome, but at the same time very enticing. Thermomix coding is here. So first thing I did was just try and say, okay, make me. And I made that description of a big application and it was a whole disaster. I mean, it didn't even compile, didn't even build. And I'm talking chatgpt, I think it was three or whatever the first really known version was. So at the beginning was very, very, very disappointing. Of course, companies received huge influx of money and they invested and they made their models better with each new generation. The promise of the Thermomix coating, I kept buying into it, into the promise, kept trying it, and I kept becoming disappointed. And what I realized is that I started entering into this and this was before agentic coding, before cursor or cloud code exploded. I found myself asking things to the. At the moment it was chatgpt, I think, and a bit of Claude copying and pasting into my ide, which I think was VS Code, trying to run it and seeing either a compile error or that the results were not what I wanted. So either capturing a screenshot or capturing the console output and putting it back. First of all, I felt like a.

[A]

Servant, like you were serving the machine instead of it serving you. Right, yes.

[B]

And it reminded me of a very interesting line of the book. I remember the name of the book, but in which I think, yeah, I think it's from Harari. Yeah, I think it's the famous book by Harari where he says that in the end we didn't like conquer the potato, the potato conquered us. It's like we ended up being slaves of the grain, let's say, and of some vegetables. So I was sort of like serving the machine by telling it, okay, this is wrong. I mean, here, it says it's wrong here. Well, as soon as some MCP and agentic stuff came up, that silly pickup code, copy pasting, right, Copy pasting was done automatically. I mean, I knew that was going to be made. I mean, technically it was very, very silly. But again, I mean, so the cycles became faster and the cycles I realized internally that they were. It was like a TDD cycle, but more of an addiction cycle. So it's like, this time it's going to work. I know this time it's going to work. And I pressed Enter and I read the message and I paid a lot of attention to what the text of the messages, the text of the AI was saying. And it was always reassuring and saying, this time I fixed it, this time I found it and this time. So I really believed it and I said, oh, at last. And I tried and it didn't work.

[A]

So you're kind of in this loop of trying something, copy pasting the error message, trying something again, copy pasting the error message. And you were doing this at the time with a code editor. So it's not CLAUDE code or Windsurf or Cursor or any of those that kind of do that cycle on their own already. Right.

[B]

But anyway, when I started using the agentic ones, mostly ADIR and cloud code, those are the two ones that I mostly use cli, I use some client I never wanted to try Cursor. I didn't like the business model either in general. The one that I used for, for a longer time and it was open source, so that I like that more was ader. Of course I had to pay for every token. And lately I've been using cloudcard a lot more because I'm, I'm profiting from VC money being poured. So it's, it's subsidized tokens that I'm using right now.

[A]

Meaning you're still spending the money, it's just not your money anymore.

[B]

Yeah, I mean, I mean I feel, I feel a bit guilty because I know too many trees are being cut down because of this, but if I don't use it, someone else is going to use that. So it's like it's crazy subsidies that I'm using right now.

[A]

When we were talking, you talk about this addictive cycle, you even had a name for it, this addictive cycle that, okay, now it's going to work and then you paste in the error and. And then the same problem happens what was the name you used for that?

[B]

So I instantly, what came to my mind at that moment were the slots machine. And I remember a trip to Japan and seeing all the pachinko stores or places with people like, absolutely, like living.

[A]

There almost as robots serving the machine, right?

[B]

Yes, yes, yes. And this happened when I was using Aether and Ather tells you after every round because it's a bit authentic. So I was not doing that much copy and pasting at the moment. It was capturing on itself some of the output. But I did have to initiate every round anyway. Anyway, after every round it said I solved it and it didn't and it said how much I paid for it. So the cost of the tokens were. And I was using Deep Seq at the moment, so it was really, really cheap. It was like every round was a couple of cents. But sometimes I say, okay, now I'm going to really use my money wisely and I'm going to use this. I know I was Gemini or Claude and I paid, I remember, for one round, two and a half dollars. And I said, okay, this time it's going to work. And it didn't.

[A]

So the more expensive models were not necessarily any better than the cheaper models.

[B]

No, no, no. I mean, I started to understand some of the places where the models get lost more easily. Visual things like CSS or in general, anything having to do with UI and events associated. I mean, all the event cycle alongside the ui, all that stuff and all the, a lot of infrastructure stuff, configurations, and it got into this like, wormhole. And then when I decided to finally check on the code, the code was horribly complicated, complex. You know where I felt at the moment is that as if I had asked my Roomba to paint my room. And then when I, when I entered the room, it was a whole disaster. I didn't know what I mean. The only thing I could do was paint it white myself again because it was a whole disaster and I had paid for it. But what I found myself, even though I believe I don't have in general addictive behaviors in life, I found myself going back to this belief that this time it was going to be Thermomix.

[A]

It's almost like it was activating your reward centers in the brain and you couldn't just stop it because you thought, okay, but if I look at the code, it's going to take me so much time. I need to get it to work, I will get it to work. And then you would just continue in that cycle. And of course, most of the Time it wouldn't work. And I remember when we were in prep that you told me that you ended up spending what, 20 plus dollars a day at some point.

[B]

At some point I did. And it was not just the money. It was the feeling of, maybe it's my psyche, but the feeling of disappointment because it's the whole cycle of unfulfilled promise. Right. It's like you enter the pachinko place and you picture yourself leaving a million, a lot of money, and okay, maybe you only lost 20 bucks. It's not that bad. You're not poor, but you are not rich.

[A]

This is interesting because I've done my own coding projects and I've often used developers on platforms like Upwork or Fiverr or something like that. And I've paid less than that to a human developer on those platforms to develop a complex system that was actually a fork from an open source, already existing, very large system and so on. So when you think about $20 a day, we already know you can get a human who knows what they are doing doing that for you and guaranteeing that when it comes back, it works.

[B]

Yeah, because in, because, I mean, I got good stories. I mean, there's part of the story that has a good ending.

[A]

Okay, so let's tease that so everybody, the good ending is coming. And I'm actually going to ask a question before that though, Alan. So we're in the middle of this addictive pachinko coding cycle. And by the way, that's a great definition for vibe coding. I think it's a sexier definition. I would much rather do pachinko coding than vibe coding. It sounds so much more fun. But of course you started evolving your approach and your understanding of how it works. As you said just a moment ago, you started learning where it gets lost and perhaps also how to avoid it. We'll go and check that in a second. Can you share a moment or a project when you first felt that, okay, this really is going to change how everybody codes in the future? What was that moment and what was the insight that you got at that moment?

[B]

I think basically the moment the pachinko machine said I won and I had won. I mean, I mean, from time to time it did work and I, and it did create. I mean, I, I hadn't been able to successfully connect to an E Commerce on my own. I mean, I hadn't done productive coding in 20 years. And I found myself in one day having developed things that I probably wouldn't have been able to even read the whole documentation in that time. So when it did work it was, I really felt that something that Martin Fowler recently quoted from someone saying that perhaps this could be a new level of abstraction.

[A]

Translate that for us. What do you mean when you think about coding with AI? What do you mean when you say it? Perhaps it could be another level of.

[B]

English is the new level of abstraction. So first we had punching cards, then we, and, and we had to think. We. I, I wasn't even born right, but we had to think in terms of bits and the bits, turning the bits on and off. Then assembler came in and that was a new level of abstraction. And now we could think about moving things or adding things in between registers. And then the first real languages came in and we could think in terms of real variables and then object orientation came and we could think in terms of events and messages. So each one of those was a new level of abstraction that allowed us to forget about thinking so much. I mean at that low level allowed us to think about bigger things because we had abstractions that summarize bigger concepts.

[A]

Which is by the way how languages are developed. Meaning human languages, not coding language. I mean languages as an entity that exists in the human world.

[B]

And so abstractions are our way of dividing and conquer mentally. So first after reading all the buzzword about the new development language is English. Forget about software programming languages and my disappointing experience with pachinko coding. My first thought was ah, no, I mean you still will never work. No, it will never work. I think it's like in my current experience. So I've started developing a couple more things after my. So my first project was this, my personal webpage with little part of E commerce to sell some online training. But then I started developing. I said why not try to develop some products that I want to exist or some forks of some open source projects that I want them to exist and they are not there. So just as an example, something I, I call it myself when it works. I call it Mecca coding Mecha as in or exoskeleton. I think it comes from the world of manga. I know it from the Legos that I buy my kid because many are called mech or Mecha. So it's those robots where you need a person or a Lego. I mean like thinking being to be in control. But you are like inside the robot and the robot gives you powers like strength or weapons or speed that you wouldn't have on your own. But you are, you have to control it okay, and you don't control it like with remote Control, you're inside it. So it's like expanding your possibilities. But you need to be proficient in the use.

[A]

I mean in like piloting a fighter aircraft. Right. It gives you superpowers, but you really need to be very good at it.

[B]

I mean, yeah, I mean I. You have to learn before doing that. So what I coded in, I call it Mecha coded in a day or less than a day. Because that's another interesting thing that happens now with agentic coding is that it's sort of provoke but it makes it very tempting to multitask.

[A]

Yeah. Because you're waiting, right. You give it an order and then you're waiting for it to do the work, come up with a potential solution.

[B]

Yes. And now that I have developed after reading some examples and developing more of an understanding of how to make it work better. So with longer or having this CloudMD or conventions MDs which are like pre prepared prompts where you give it some idea of some basic hygienic ways of working so that you should always run integration tests after every change and always make sure that it linked in and there are no typing errors. And of course, I mean, and stuff like don't forget, I mean look for several refactoring opportunities. Refactoring to me means making the code more readable. Making the code. So it's like I explicitly go over all that even though sometimes it forgets about it and I need to remind it. I found it's when I started before coming up with the pachinko coding. I call it rage coding because it felt like working like a drunken PhD with amnesia. It was crazy. So if you start to treat it like a person, it drives you crazy because it's not so it really enrages you because it's so wise and so stupid at the same time. If you start seeing it as a person, if you see it as a function, then it's being extrapolated and that sometimes the extrapolations are just wrong because that's what extrapolations are. Then I think at least I begin to calm down.

[A]

Okay, but let's. I think this is a great point. So you were developing something which you were able to in the end develop in one day. And you did that because over time you had learned this different rules. So explain what you developed and what were the rules that finally organized kind of shepherd did the LLM into being productive for you.

[B]

So the product, the software in itself, it's, it's something that I need. Personally, I, I tend to forget birthdays of Course, I got an iPhone and Android has it. I mean, there's birthday reminders everywhere. I mean, the problem is that because they were synced automatically with my former Facebook accounts, in my calendar, I have the birthdays of people I don't even know. I got thousands of birthdays and there's no easy way. So I used to have a reminder in my iPhone to tell me every day there's a birthday. And I ended up remember telling my wife, remember that guy that we once met up? Today's his birthday. And she said, I don't care. And I said, I don't either. So I needed just a simple basic birthday reminder where I could choose which birthdays to be reminded of and what I had thought. And I had thought about this for a long time. There's some people that I really want to say hi that day, and sometimes even if I read that it's their birthday, I forget. So I would like a pestering mode to keep asking me, did you say hi? And for some very special people, I really would like to have a reminder. The pestering reminder of buy a gift. Because when the day comes.

[A]

Yeah, a few days before, even a week before. Right?

[B]

Yeah. Because that day I say, oh, I would have loved to bought this guy a gift, but I forgot and it's too late now. And even if I. Because I could be reminded a couple of days before, but usually I just say, okay, yeah, yeah, I know, I know. I will buy it. So just a simple birthday and gift buying reminder with pestering mode. Like, have you bought it? Not yet. Okay. I was like. Like a snooze of buying. Very simple thing. I tried to do it once using React Native. I couldn't even. I mean, it took me half a day to try and find a library that could connect to the birthday contacts to read the contacts. And I couldn't even create before LLM time, like a cli. Nothing now in one day. And I honestly didn't even read a Swift tutorial yet. And I know I can learn Swift. I got the application running and I'm interested into understanding. And I can say that I've taken architectural decisions even though I'm not proficient in Swift or in iOS architecture.

[A]

So basically, you developed an application that you really wanted to have without ever looking at the code, making decisions without understanding the consequence of those decisions. But with the help of an LLM.

[B]

Yes, but. No, but in a way, this is what I begin to buy into the abstraction metaphor, because I know I have an understanding and I've made some Technical decisions I kept. One of the things that I learned is that I need to ask for options and I, and I tell it. I need to explicitly tell the LLM, give me the options, don't code and explain me the pros and cons of each of the options. So for instance, I want to store, I need to store the birthdays locally. Give me at least three options to store this locally and tell me the pros and cons so I don't have to get into the details of actually.

[A]

How the LLM can be even a consultant.

[B]

Yes, it's. It's a friend was talking about, someone was talking about. It's like you talk to the help to the manual. It becomes more of a conversational manual and it allows you to go past a bit of the accidental complexity. You know the difference, I love the difference between inherent and accidental complexity. So the inherent complexity is what the real complexity of making an application that reminds your birthdays, which is not big. And then you have all the accidental complexities which are like the details of the unnecessary complexity that are brought about by the bad UX of software development languages. Nobody thinks about UX for developers. All the overhead of setting up environments and all that stuff.

[A]

We used to call it yak shaving.

[B]

Oh yeah, I had forgotten about that. Yes. So by asking. So by making it very explicit that I want to use tdd, that I asking very small things, so taking even asking for very small steps and then and making it explicit that I don't want it to code it just yet, continuously asking for refactoring ideas or opportunities. So even though I don't know the exact syntax of Swift, whether it uses quotes here or parentheses there or brackets there, I have decided things like names of methods or renaming because I have done that in 10 other languages and now I don't need to know the details of this. And then there was a moment in which I wanted to have like checkboxes for each of the. When I was importing or whether I wanted this contact to be reminded of gifts, of saying hi of merely of the date. And the checkboxes were working like crazily. I mean I. When I click, when I tapped on it, it turned off and it. So it was doing weird stuff. So I took a screenshot, I started with some pachinko and I started to get a bit enraged and I said okay, fixed it and it didn't work again and then again and it was like five times. And I said okay, I really need to get to understand what is going on Here because what I think is this is the birth of reminder application for me. It's not worth my time to try and understand it and I don't think I need and I want to understand the deeper inner workings of Swift. I mean I don't want my career to be based on developing iOS applications. So I don't want to. I would feel like a waste of time in my case for this language. So what I said and it worked was you might be over. This is a very simple thing, you might be over complicating it. Like I wrote some, the prompt was something like take two steps back and rethink the whole way in which you are trying to develop this and try to develop this the simplest possible, most native basic yakni way of turning on checkboxes. And it's a yes, you are right. I was over complicating it. I have no idea what it did. I have no idea. But basically I think what it what it internally in my mind what it did was I brought a new Roomba and I said, I gave it the white paint and I said the previous Roomba just did things wrong. Just paint everything white and think about it again. So this new round, it might work. And it worked.

[A]

So one of the things that you're kind of describing here is that at first you thought that in order to program with LLM you needed to know somewhat what was going on a little bit about Swift, as you said. But then later on when you thought that this isn't working, you said, okay, I need to take a step back and accept that I'm not going to learn Swift, I'm just going to tell it, this isn't working, take a step back, make it simpler and do it again. And that worked. And for me, what that suggests is that for coding, well with LLMs it actually pays off to take that level of abstraction. Right. Like so that you're not worrying about renaming methods like you said, or detailed refactoring solutions. But you're just saying I want this done. Make it simple. Right. Like Yagni.

[B]

Yeah. Yes. And ask for very small things. And oh by the way, if this was going to be, I don't know, I don't think this approach would ever work for enterprise grade software. Okay. Like bigger stuff. If I'm talking as more birth of reminder application for that kind of things, I think it can work. So far I have been using it for some other stuff like for my clients and for processing. A lot of my clients use Jira or Azure DevOps even though I don't like those tools, there's some interesting information there. I have been developing even without understanding much what was going on there with Python, even though I do. I do code in Python and I understand it, but I haven't had the need to really understand it. Very unique. Like small comments that import like the query JIRA and give me a JSON then with. With the PBIS or work items, then another small one. I wanted to. For instance, I was, I was, I was. I was thinking whether to use Monte Carlo simulations or not for a team. So I said okay. I came up with an idea while I was on the bus. Why don't. And I told the team about it and they were very skeptical. So I thought why don't I take the historical data of this team from Jira the use JIRA and I make a retroactive simulation of what Monte Carlo would have said and compare it to the actual forecast they made. And when I first tried it with the Thermomix like okay, bring me everything. I come back in two hours and they will be ready. It was like no. As if it would have cooked something brown and tasteless and it didn't compile. But when I took an approach of more unique yakney small things of okay, let's just bring me the work items for this team after a few iterations.

[A]

So you're almost like you are being the agile coach or in this case the coding coach for the machine. You're telling it these are the best practices. We do it in small steps now do only this step kind of the slice that you're interested in. What are some of the other practices that you have experienced as being productive as helping you to benefit from this coding with AI?

[B]

Oh, let me go over them. So for Unix like one purpose applications or that's one in general TDD Yagni oh and running integration code all the time. Perhaps if I would have said myself a CI so reminding the agent that he or she it's its own CI and that it should never let any kind of error appear because it starts bleeding right then. Well, there's another story that I didn't tell you and this brings me to a theory that perhaps this works very differently in different text stacks. So I'm developing. I started to develop an elearning because I again myself I don't like. I want to. I want to sell E learning and I don't like the elearning platforms that I see so I want to try do an MVP of an elearning application that has the way that I want to do it. So I first tried to do it with React Native and it was so brittle, it kept breaking, breaking, breaking, breaking, breaking. Then I tried with Flutter and it kept breaking, breaking, breaking. And then I said, perhaps the way I'm using the cloth is wrong, something might be wrong. And when I tried with svelte and doing it all web, I know the technology, the stack in itself is simpler, but it became way more solid, way more stable, even though I was following the same prompting practices. And what I think is that maybe the LLM just has less information, is less proficient in certain tech stacks than in others. And I have read about that. So I don't know, perhaps if I have to work with C or. I mean, I haven't tried it with all tech stacks, it's more stupid. I don't know.

[A]

That's actually a very good point because we need to assume that all of these LLMs were trained based on publicly available code. And knowing what kind of code is available will help us also define what kind of tech stack it understands better. Because of course it has more exposure in the training data for that. So, Alan, we're getting close to the end and I know that you have so many more stories. This could be another long episode just with the amazing stories you have to share. But what is the resource like? Could be a book, a video, a paper, a tool that you think, okay, if you're really interested in coding with AI, this is a resource you must know about.

[B]

I don't. Yeah, the. I mean, I learned that. I think the step that mostly helped me was reading and watching a guy called Paul Hammond on LinkedIn, even though I didn't end up following. But I took from him the idea of having a very comprehensive prompt that would give the LLM like a whole idea of my perspective on developing like very comprehensive. Because I had read some prompts by Ken Beck, who is apparently been doing a lot of. He calls his augmented coding what I call mecha coding. But his prompt was too light in my experience. I used it and it didn't help me. So it's not that Paul Hammond's prompt worked for me, but his style and his insistence, I think was his on doing small steps that helped me. I haven't found either a book or anything like that, by the way.

[A]

Small steps work with human coders as well. Small steps are the core of the TTD cycle.

[B]

Because my only fear is that this is all confirmation bias by we agile people. Because it might be, and maybe there's another way of making LLMs work well with big steps. But at least we agile people and people with experience in agile coding are. The conclusion that I see other people reaching and myself is that, oh no, agile is so dead that the only way of making LLMs work is by making them use agility. So who's that?

[A]

That's a beautiful way to end. Alan, it's been pleasure. Thank you for being here with us. If people want to connect with you, hear more about your experiences, maybe ask a few questions, where could they go?

[B]

Right now it's all LinkedIn. I. Yeah, I want to do some X and other social platforms as well. My webpage is simmon.com but most of my work is in Spanish. Most of my consulting and training, I do it in Spanish. But yeah, let's just connect on LinkedIn. Absolutely.

[A]

We'll put the link on the show notes. So make sure you get in touch with Alan and learn together as a community, because that's what we need to do. Alan, it's been a pleasure. Thank you for your generosity with your time and your knowledge.

[B]

Thank you, Vasco. Thank you so much. Have a good one.

[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 talk, 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 [e-mail] membership because listening is great, it's important, but doing it together, that's next level. I'll see you in the community.

[B]

Slack.

[A]

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.

[B]

Sam.