B (4:21)

So yeah, so this is interesting because you're saying this is not something you would use to design an end to end solution. So that kind of hints at there maybe being other aspects of AI assisted coding that would help with this end to end solution development. So what are these other approaches and how do they specifically differ from Vibe coding in your own experience?

C (4:50)

Actually automation in the code generation is not a new thing. We used to use like personally my background is Ruby and Rails and that's what we do and the conventional based system, when you have a framework like Rails, there is other frameworks from different technology that use pretty much the same paradigm. They provide you a lot of code generation tools for scaffolding everything. So you don't need to do routine jobs for creating models and controllers and database connections and yada yada. Instead you know that there is like a different strings you pull and the framework gives you the code samples like boilerplates, something that based on the code, accelerators, libraries and a lot of things. So after that, so that the scaffolding was, I think, I don't know, a decade back was a really good thing for engineers to save their time and do automation coding. Then copilots and code assistants happen where you still code and a computer suggests you something so it predicts, first it helps with the syntax, then it helps with the method and understanding of everything that is inside. So you no necessarily need to know exactly how to do method signatures or how to use this particular library because the system will suggest you. So you need to know the vector where you're going. So copilots then they agentic coding where you literally pair program with a machine. And this concept I think describes the best interaction human and computer, like a human and AI. And so vibe coding, it's kind of the thing that takes this agentic way of coding to the next level where you literally no need to write the code, where you simply communicate to the machine with a human language. And the only thing is just like you control it as you would speak with a real human intelligence. So meaning you delegate the whole thing to the computer and then vibe coding kind of covers that. But again it's not a silver bullet and it's not the only one way for providing automation thing. And I believe it's not going to stop with the wipe coding. So I believe it's going to evolve and new things are coming.

B (7:29)

So something, what have you in your own experience, what is the evolution or the several evolutions that you have started working with? Because I know that at the Global Agile Summit you were talking about this concept of TDD 2.0, right? Like using, using AI to kind of supercharge the way you do TDD already. That's just one way. But what are other ways? Have you actually used to go beyond vibe coding and to, to that, let's call it goal or ideal of being able to develop end to end solutions with the help of AI.

C (8:09)

Yeah. So the whole thing of extreme programming is useful. I mean like you can take anything from XP and adopt it for this human to machine interaction. Code review, pair programming, you can do actually the TDD or XDD whatever DDD thing. So you can delegate like the dictionary, the knowledge about the domain and so on and so forth to the model where model can take care of it. But what I would say like I use the most and to make it simple the first but. And that's the evolution of like my own, like my best practices, how I code and how we work with the team. It's transactional model of commits and working around the git. So this transactional models, it's not only the context that you allow the model keep, but that's the way how you interact with your repo and the process, how you commit, how you ask the model to commit. So it's like a semantic way to explain what you want and then how to transactionally store it into the repo so you can roll back it. Not asking the model look into the context, but asking the model look into the repo. So it's more like when you do something commit and it's going to commit first, but for AI we used to do exactly the same for like software software development. When you do like commit first approach, when it's like a very autonomous small commits and very frequent in order to minimize the conflicts between engineers. So when you run like a scrum team of five or seven engineers and you do commits like frequently, the time you spend on merging and on conflict resolving is really shortening. So exactly the same here. When you're working with AI, asking provides something more atomic commits, it delivers more easy for you to kind of guide and navigate it through the process of development.

B (10:19)

What do you mean by transactional models? Are you then talking about that specific approach to how far do you go without committing your approach to rolling back and so on? Is that what you're talking about?

C (10:30)

Yeah, it's a little bit different way of committing. So if like when you commit as a human, you provide title, you provide diff the change, you provide hyperlinks or links to the tickets and reasoning why it was implemented. When you implement this transactional model for the AI, you need to link back this commit to the context. So it needs to understand the reason, not overall why the whole thing was implemented, but why exactly this part of code were accepted and what was the reason and how many iterations.

B (11:06)

Give me an example. So you said as a human, when you commit, you say I fixed this because of this tickets and here's the options we had. And I chose this option, something like this. So how would you do it with the AI then? How would you instruct the AI to handle that commit differently?

C (11:25)

Right. So for example, when you're providing the, let's say the next step in implementation for agentic coding or vibe coding and you ask a model to implement login form. So you say like I want to be able as a user, I want to be able to log in, I need to provide my email and a password. Then if the password is correct, then I should be redirected to my profile, whatever. I have a button to log in, I have the button forgot password, whatever is expected. Then this is a straightforward way to implement the thing and you ask the model to do that. Then as part of your prompt is you ask the model to commit this code to implement it as a transaction, that should be applied to the code base and this transaction should include the fast forward thing. So when everything is good and you specify the guardrails, run the test, figure out the design, do proper planning, do code review and then how to roll it back. So if you fail, what do you need to do to roll back the changes? So if you fail, if you get for example, the bad feedback from the driver, or if you get the bad feedback from the other agent, that is saying no, no, no, no, no, it's not working. It should work differently. You need to like the model needs to use the rollback scenario to get itself back to the zero point, to the beginning point of this transaction. Re implement it but not lose. It's like code review, right? So you implement the code, you push the changes. Somebody from your team saying huh, that's good one, but think about different approach. And then you re implement it, but you keep the context. That that was one approach I've tested, now I'm doing another one. I don't know if it explains, but yeah.

B (13:17)

So what you're basically saying is that while as humans we naturally keep context when we do a transaction, you know, a git commit with some information, whatever, the AI will not necessarily do that because the way it manages context is outside our control. So we can design prompts so that we force it to have a specific control, sorry, context during that transaction. And the transaction here means you have an idea, you explain the idea, you make the changes, you commit the changes.

C (13:52)

And the rules, how to validate it with two directions. The positive scenario, which is straightforward, commit and take the next task. And the negative scenario, rollback, rollback.

B (14:04)

Why did you choose to call it a rollback rather than just iterate or something like that? Because I hear you say rollback as if it meant kind of going back to the previous known good state in the repository, of course, without losing the context. Is that what you mean?

C (14:20)

Yes, exactly. That's the way how this commit first works and how the thing actually used to be. In a traditional way of development, there is two ways for structuring your commits. It's the branches and trees where every feature branch goes in parallel with the whole thing and then you merge it back, kind of gathering together the all results from the team. Or the very linear way where you building atomic commit where each commit represents the feature and each commit is independent, can independently be enabled or disabled. Kind of like a feature commit to.

B (15:08)

Master is what some people call it.

C (15:10)

You commit directly to master. You don't like, you do not allow agentic code or like the real human to do this feature branch temporarily until the whole feature complete. So you force it to commit it directly to master. And in this situation, every commit that you have, it's an independent part of the code that you can kind of turn on or turn off. And that's why you need to have a rollback.

B (15:35)

Yeah, exactly. So basically what we're saying is given the current situation of AIs and your own experience, it's actually much better to just restart with the context that you have than to actually try to change something that did not iterate more and more.

C (15:53)

Exactly.

B (15:53)

And because it's potentially depending on how big the change is and we of course want to focus on smaller changes potentially because the changes are so small, this process is so quick that actually there's no loss for the rollback. Right. Because of course the opposite would be to have a large change, say a couple of hours, two, three hours of work and then rolling back. And that would mean you need to do another two, three hours of work. Right. So I guess you're also implicitly talking about by design working in very small increments with the AI.

C (16:27)

Right. And keep it linear and a very like atomic and independent. I would say it's if we use notation like the names from the old practices. So it's commit first and trunk based development. So we commit faster and we try to keep the context inside of the commits and we try to minimize branching. Instead we are merging master as fast as we can deliver something. Okay.

B (16:58)

And when I hear you say we try to keep the context inside the commits, this also sounds to me and I want to hear your thoughts that we acknowledge that context, managing context and keeping context is one of the weak points of today's coding agents. Therefore we need to be very mindful in how we manage that context for the agent.

C (17:19)

Right? Yes. Yeah. So actually picking up a particular commit, meaning you can read from the context that was stored like before you committing, you dumping there the current state of the, of the system if you need to get it back. So you read it from, from the commit and you need to make it kind of AI friendly. So it's no longer explanation of a engineer. I've added this thing because, you know, I needed that for that reason. So you kind of, you know, stuck.

B (17:55)

There almost like make sure that the commit message includes the prompt sequence that you used to generate the commit.

C (18:03)

Yeah. And instructions how to roll back. Wow.

B (18:07)

Tell me, how did you discover that approach? Because I mean, first of all it sounds very specific. It also sounds that is grounded in experience. So you probably went through problems where not having that became a problem. Right. So how did you discover that idea of keeping the context in the commit?

C (18:25)

So we used to do a lot of trunk based development ourself. So after sometimes kind of shifting from GitHub Flow or Git Flow where team works in parallel on parallel branches and maintaining those feature branches, doing merges and preparing release trains. Somewhere we kind of come up to the idea that it might not be that efficient on a larger scale and running like a mono repo with a very linear history and like a very linear approach of the commits might be more beneficial for rapid development. And in order to maintain that, we used to use our own set of rules for how to code review, how to commit, how to roll back, how to merge conflicts, and so on and so forth. So actually it's not something new that we discover, it is set of rules that we use for ourselves. Like engineer to engineer communication. Like before you commit, here is the checklist that you need to follow. Here is the instruction how to shape the commit message. Here is the links how to get at minimum like two thumbs up from your peers, how to do code review and if there is any discussion what to do later on with this discussion. So we're not losing, for example, if you're committing something and there is, you know, 10 people spend a couple of days discussing what's the best way to implement this feature. When you merge, that's very valuable information. You shouldn't lose it. You shouldn't throw away the discussion like okay, it's done, forget about it. And after some iteration everybody lost the concept.

B (20:08)

Basically what you're saying is that this is a hard earned wisdom from massive software development endeavors where you have multiple people developing in parallel and then you somehow need to recover the context of why was this change done right. And that is still valuable when you work with AI, because AI itself also needs to be able to kind of restart that particular context if you somehow.

C (20:34)

As a junior engineer. So that's, that's the similarity we used to do. So we use that for people to more quickly pick up with the whole team paced. So if you treat AI as a junior engineer in this Exactly. Situation, it's very easy to come up with. Ah, okay. Maybe we just use the old traditions how we onboard, you know, juniors to the team and let's actually a good point.

B (20:59)

So what we're talking about here is like finding what are good software engineering practices and keeping them when working with AI. We just had an episode yesterday with David Dahl who was talking exactly about the same thing. He developed this aid or augmented AI development framework that basically kind of structures that interaction with the agents. And you also did that when it comes to tdd, right? Like you at the Global Agile Summit, you were talking about TDD 2.0. So how AI can help you actually be better and use better TDD. So describe that high level for us because people can go and watch the talk for the details, but describe set the context for us because I think there's a couple of things that we want to explore.

C (21:46)

Yeah. So TDD and frameworks that allow you to do test first and it's a good way to keep requirements and the only thing is missing that if you want to make those requirements executable, it sounds like a prompt. And the idea for TDD 2.0 was what if we combine the way how we test and do acceptance for any particular feature, how we make it executable for AI and if one agent implement the code and another agent can pick up the test scenario and iterate on the code until it passes. And the main idea was that you do not allow AI to write this prompt. So that's human responsibility to create those prompts for TDD. And then you can be kind of confident that the implementation part is going to be safe. It could take a lot of time for iterating until it's right, but if you keep it as a guardrail it works.

B (22:48)

So this is very good because one of the things we want to explore here is what are some of the anti patterns? And implicitly in this exposition of TDD 2.0 is the idea that humans need to be very careful about what is the outcome they want. So the tests and then once that is clear and it's even executable, you can then give the code writing to AI because you will for sure get what you need to get because the tests are there to validate that. Is that how you would describe it?

C (23:23)

Yes. So I think the anti patterns you like at least you need to set proper expectation. And the way how do you verify the results? And that's still even if you wipe code, even if you don't want to touch the code at all like saying like just do it. I'm not interested in kind of looking under the hood. You still need to validate it. And the validation or verification could be with the bare eyes you watch. Yeah, you play with it or something else. Right. So in any case you need to accept it somehow. So I think writing AI agentic coding, vibe coding, whatever coding without proper verification and properly set expectation what you want to get as a result, that's the main mistake. Otherwise you just, if there's no, you know, if there's no goal to implement something, you just want to have fun and you know, it's like a Friday night you, you have nothing to do, you go wipe coding for whatever, that's, that's perfect. But if you, if you need to do for like, for some reason, then I think the, the verification mechanism, it's, that's the must. And what I would say else is that my first rule of thumb is if you need to write a code in the test, I would never allow AI to write the test, so I would do it by myself. Still, it can write the code. The second one, I would never allow AI to invent the architecture. So if I have no idea how.

B (25:14)

Do you do that today? How do you guide AI through the architecture? It's not only through tests, right? Because there are many architectures that could pass the test. So how do you do it today?

C (25:27)

Again, for us it's easy because if we do a Ruby on Rails, there's a lot of conventions, so the architecture and the patterns are built in inside of the framework. And choosing the proper. Like, if I know the task and I know it should be API based, or it should be monolith based, or it should be microservices based, I kind of set the, when I do like the planning steps for AI, I set those architectural view for the agent encoding. Like I need an API. Here is the description of the API, here is the guardrails, here is the validation steps, how I want to make sure it works. And again I explain which tools and libraries, which patterns. Again, if I have, I need to use plus because we have a lot of scaffolding and then like the, from the previous ages, the code generation samples what we usually use and it's not an anti pattern, but it's a pattern and if you do not follow, then it becomes of course like an anti pattern. So if the structure is linear and if scaffolding and the very stupid linear code generator can implement the feature. For example, if we use library for authentication and this library generates you the whole interface for authorization, authentication, profile management, user creation, yada yada, like you don't care. It's just you click the button, generate new user, it generates you everything like the database records, like mailers, all the procedures then you should use. Like AI should reuse those very stupid code generators from the framework instead of implementing it with its own flow. So that's the expectation you set. If there is a code generator available, use code generator first and then refactor it by yourself.

B (27:27)

Can you write these rules in the Cloud MD or Agents MD file or how do you give those rules? Because you're saying when I'm Going through the planning steps for the AI. Are you doing that on your own? Are you working with an AI agent to create that set of rules? Do you already have a template? How do you go about it?

C (27:46)

Yeah, we used to do a lot, of course, now we, a couple of months back, more than a half year back, we shifted to cloth code before the planning steps were available. We used the text files for each step and each iteration to set the proper context. Now we are building the API endpoint. Here we are building the user interface here we are building whatever and you put the specific conditions for. For the user interface, we're going to use this library and this library has a number of code generators. We're going to use those code generators first and then refactor it. So nowadays AI can help you to do proper planning. And it's still the same instruction for every step, but it's a little bit easy because you don't need to store your own MD files for prompts and conditions to validate.

B (28:46)

Yeah, it does it itself. So one thing that you were saying that I picked up on, that I want to explore a little bit more, is that you have these files per iteration. And I guess by per iteration you mean like a set of features, right? Like, you know, user management or whatever. Is that something you still use as a pattern that you have a specific description of what each iteration is going to do?

C (29:10)

It works for the boilerplates mostly. When we do, like, for example, if we implement another API for mobile game, or if we implement another API for whatever simple application for 10, 15 screens, we know exactly the structure, we know exactly the architecture. It's very well described from the previous. Like if the coefficient of repeating repetition. Yeah, yeah, is high, then yeah, you just copy it from the, from the previous boilerplates and the end result will be Most likely like 90% complete. So you do a little bit of polishing and you.

B (29:53)

Yeah, and that's actually a very good tip, right? Like, if you've done this a similar project before, you can just take the instructions. You can even ask the AI to generate the instructions for you, and then you can just review it and polish it and give it to the next project and then you can use that as kind of a frame. And what I hear you say, and I want to check that with you, what I hear you say is that the developer becomes more of a code reviewer and architect role rather than a programmer role, and that the AI takes more the responsibility of actually writing the code with your instructions. And then what we do is make sure the tests pass, make sure that the code follows the architecture and guide it when there are things that are unclear.

C (30:41)

I think the similarity is the following. When you write on that scale, it's not a gigantic project. It's not like an enterprise system that you need to build couple of years with the team of 20 people. So if you're building something, we usually separate it for the MVP stage or a rapid prototype. And usually architects or CTO or a really senior people deliver draft, like a draft version of the code. It works, it explains the logic, it behaves properly. But there is a lot of work, like there is a lot of boring work that when the prototype is complete, then you give it to the next level, to the team, so they do the whole polishing. So in this situation, I think it works great when you pair as an architect or like a really senior engineer who can implement it by himself. But instead, and in order to save time, it, it do the pair programming with AI. And AI kind of ships this, this the draft rapid prototype when it's complete and you need to push it to the next stage of like the polishing thing. The way of using agentic code is different. So you cannot plan all the high level thing. Instead you're running more iteratively, you do more testing, you do more kind of like a user's feedback there. So I would say it's like two different strategies. How to do MVP when you need to run faster and ship something to give it to the end user. So they play that's architect copiloting with the AI. When you send it to the next stage of stabilization and polishing for the team, then you run in parallel. It should be front end engineers doing something, backend engineers doing something, mobile developers doing something. And they use their own approach how they would implement this particular feature. So it's kind of like a drill down to the level of.

B (32:51)

That's a very good heuristic. Definitely there are different goals and for different goals we use the tool differently. We're almost at the end. But I did want to ask you, Sergey, when you've got already quite a lot of experience with using AI assisted coding, you've been developing your own approach and thinking through this. How do you see it evolving if you push the movie forward, let's say six months, because perhaps in a year it's going to be totally different, but if you push the movie forward a little bit, just enough to unveil what might be next, coming next, how does it look like in the near future?

C (33:30)

So I Think nothing is going to change. So the model is getting better and better. The context window is growing more and more. The AI agentic coding is going to be more robust, more reliable, but to some extent human. At this, even like at this stage, human is a bottleneck. So because human needs to write it, human needs to provide domain knowledge, needs to provide business requirements. So AI cannot build you a software that will, you know, will create a business for you. You cannot say like, hey, code me the mobile application. I want to be rich, I want to like earn $1 million next month. So like go and code it and then publish it somewhere. So you still need to guide it. It's a great tool. But what I see for the next six months or even like a year, it's going to get more frameworks, it's going to get more patterns, specifically architectural patterns. So how to properly build the code. So now agentic coding is getting as, and I've seen that many times already when you're hiring somebody for a position like a software engineer. Now there is a line understanding of Argentine coding. So now being a software engineer and trying to get a new job, it's going to be like the mandatory requirement for you to understand how to use AI for coding. So it's not enough to just be a good engineer. So you also need to know how to use those things. And there is no standards at the moment. So I believe it's going to bring new frameworks which will incorporate all the best models and the way how to implement standardized things like how to build mobile application, how to build web application, how to refactor legacy code, and so on and so forth. And it will bring more high level patterns and approaches, how to do and how to build it from scratch, how to maintain, how to evolve the code and so on and so forth. So I think we are reaching the good performance level of AI models. And now we need to kind of guide it to the proper, like to make it efficiently, like it's a great tool. Now we need to understand how to make it efficiently.

B (36:02)

Yeah, absolutely. And frameworks are already emerging. We have Speckit, bmad and yesterday's episode with David was about his own framework called augmented AI development. So definitely I can see that happening already. That's been great. Sergey, is there a resource, a video, a course, a book that you would point people to if they want to explore AI assisted coding even further?

C (36:31)

You know the best way for getting all the news and resources, as you said, I also ask AI to kind of once a week, twice a month, you gather the trending things. For those who as myself coming from the Ruby world, there is one guy called Obi Fernandez. I can send you links later on. He recently published a book called Patterns of Application development using AI. It's focused for Ruby and Rails application mostly but overall it brings the high level view for how software engineers specifically for web development, let's put it that way, how software engineers in web development can utilize AI and which patterns that they can develop for themselves to be efficient with their day to day tasks.

B (37:25)

We'll put the link to that book and to Obi's work and in the show notes it's great to to see that the patterns word continues to develop and be used in the software engineering because that's how we learn. We learn through sharing these patterns. Yeah, Sergey, how about you? What if people want to contact you, get in touch with you know more about cyberchiser? Where should they go?

C (37:50)

I do, I do Twitter or x still and LinkedIn. I think those two social networks that I can and I keep using pretty frequently. So for Twitter mostly kind of events and my schedule, where I do, where I Travel and for LinkedIn it mostly some trending stuff that is happening in AI, some researchers, case studies that I personally publish or republish as part of the company. So yeah, so I think those are.

B (38:28)

The best ways everybody out there reach out. This is something we're all exploring as a community. AI assisted coding. Sergey, thank you very much for your generosity with your time and your knowledge.

C (38:40)

Vasko, that was pleasure.

A (38:46)

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.

B (40:35)

I'll see you in the community. Slack.

A (40:38)

We really hope you liked our show.

B (40:40)

And if you did, why not rate.

A (40:42)

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.