B (4:13)

So it's a little bit almost the spectrum between a black box service, like you just ask the AI for something and then it does it, and a white or at least a gray box service, which is you. You still ask the AI for something and it still gives it to you, but you understand it better. And maybe you have maybe even some rules and frameworks that you put on it in order to help you achieve a certain level of quality.

C (4:42)

Right, yeah, well, where I still basically maintain the mental model of the application that I'm working on. Whereas in Vibe coding, you can see a lot of people sharing LocalHost 3000, asking people for a review, not understanding that they're working entirely locally. And now let's try to move this into a production and into a server. They're kind of stuck in that regard.

B (5:10)

So when you think more of this gray box or even white box type of AI assisted coding, what have you learned about the process of using AI as an assistant in your own programming that makes it work for you?

C (5:27)

Oh, I'm heavily, heavily involved in the. Not just involved. I'm the ultimate authority and everything regarding architecture and what I want the software to do. So I spend a lot of time planning, breaking down into logical milestones.

A (5:50)

And

C (5:52)

the bigger the software, the more important the software is. I tend to kind of sit next to the, to the AI coding agent and can monitor what it's doing so I can steer it in the right direction if I see that it's going haywire. If it's less of an important software, it's not production grade, it's just for my own use. I may just let it run without me monitoring it, but I am going to be involved in the planning heavily. Maybe it's a character issue of being a control freak, but I find that if I know what's going on in the software, in every bit of it, I don't need to know how to it wrote the syntax specifically, but I need to know how components are being constructed, how different modules of the software are communicating with one another. And ultimately if something breaks, or at least I need to know what the weak points of the software are. If hopefully there aren't any, or there aren't a lot, but I need to know what they are, if there are.

B (7:09)

So if I understand, you're right, you're kind of taking the position of a lead architect, right? Like kind of defining the high level structure of the code, some critical technical decisions, and then you're also taking the role of the technical lead with the AI where you will supervise it in a more or less interactive manner, depending on the risk of the task that it is handling at that time. Is that a way to describe it?

C (7:39)

Yes. So if I have a website and now I'm just at a point where I want to add a button or change the onboarding flow, I don't need to monitor every single thing. It's just a ui, you know, little thing. It's, it's not a big logical restructuring. So I might not monitor it very closely when we get to that point. But definitely when building something that's infrastructure level or more mission critical, I'll definitely be sitting and watching it like a hawk. Yeah, so that's how I work at least.

B (8:18)

And when you think about that, let's start with the architectural like kind of thinking through the problem, breaking it down into logical components, guiding the AI through the building of those. What are some of the approaches, frameworks, strategies, or just simple techniques that you use to make sure that you can keep yourself in that role? Especially because it's February 2026 as we record this, and the AI companies are definitely pushing more towards the autonomous agent type of coding services, not so much the interactive. That would allow you as an architect to kind of fine tune things as they are being developed, et cetera. So how do you keep on top of it? What are the strategies you use for yourself to not necessarily direct everything it does, but to keep true to the architecture you want it to follow?

C (9:15)

Yeah, So I tend to have several steps when I work. First, I need to fully understand, make sure that I understand either the product or the feature or whatever it is that I'm building in all the possible levels you can think of. So that means I need to know how it's related to the business as a whole. What is the business goal? Not just the software related goals, what's the user experience there, how data flows and I'm writing, obviously with the help of AI, a very detailed prd. I usually have like a higher level PRD before that, just to make sure that my idea of what I want to do is clear. And then I have a much lower resolution or higher resolution, depending how you look at it. More detailed anyway, PRD from that prd, usually I break it down into phases. So I need to make sure that the building blocks are there first before I can expand on features. So let's say that I want to build a dictation app. I'm really not going to bother myself with the user experience of how it's going to look on the screen while you're dictating. I'm more interested in let's first make sure that we have something that actually understand what you're saying and transcribes it. Then we can build a whole user flow around it. So that's a prerequisite of everything else that comes later in the software. So once I have these phases, every phase gets its own smaller version of a PRD and an implementation plan. And then essentially I'm just letting the agent follow the implementation plan essentially to the letter in a somewhat autonomous way. So it's not like an interactive where I'm asking it, hey, write this functionality first and let me review it. Write this functionality first, let me review it. It's more of here's the implementation plan. I want you to follow it to the letter and I want you to write tests for everything. And once you're done, and this is a small trick that I've learned, is I'm asking it, what is the confidence level you have that we are 100% aligned with the goals and the implementation plan? Usually it will respond with an apologetic oh, we're only 58% there. And then I ask it to keep iterating until we're 100% there or very close to that. Once it's done, then I'm asking it to usually switch a model. So if I've worked with Opus, which is my favorite for iterative work, it's much more of a co programmer rather than, for example, Codex, which is an excellent model, but it's more of a I got this and it's breaks, communication, goes, do the work and comes back to you. OPUS tends to keep you in the loop of what it's doing. But usually when it's done, then I switch to something like codecs, ask for a full code review, a very scrutinous code review, and feed that feedback back to opus. To make sure that everything is perfect before we move on to the next phase.

B (12:56)

Two things that come to my mind, of course. First of all, this separation of creating the PRD and even different levels of PRDs depending on how you face the development, then handing those over to the model. That's one perspective that I wanted to explore. Because one of the things that we as a community have learned in software development is that iteration is how we develop great software. We don't usually develop great software in one go, but. But from what you're saying, you have two types of iterations going. You have the iteration that you use to build the PRD which has different levels of granularity, as you said, starting with the generic and then so on. So you iterate there, as I understand it, with the model. And then once the model is picking up that PRD that you are happy with, you still iterate. But you called it alignment, right? Like when you were describing, you asked it, are you aligned with this? And then it does whatever magic to figure out the 58% alignment percentage. And then you force the model to iterate until there's so called alignment as you describe it. Do you see those as two types of iterative software development or how would you describe that?

C (14:15)

Yeah, they're both iterative processes. Both is focused on a different thing. I do have to admit that while we're developing and I'm starting to see the product, I may change the PRD and say, oh, if you're already doing that, why not also do that? It's just, you know, or if that

B (14:35)

doesn't look right, let's try this approach instead.

C (14:38)

That could also happen. But yeah, it is an iterative process. And also once the code review is completed, I also have another step where is. It's like, okay, look at everything that you've wrote. And I want code optimization phase. So let's reuse component. I don't want anything to be written twice. Let's see if. Let's go to the database once instead of four times. Just because you need four types of objects. Just try to use a join query or whatever it is. Let's optimize it and try to minimize the CPU and memory and resource load in general. But that usually comes at the very least, the very final step. Let's make sure that everything is working according to the plan. And now let's try to optimize the code to make it smaller, more maintainable. Also force it to. So I brought a lot of my kind of past coding experience and regiment to the AI coding. So I force it to use inline comments to explain large blocks. I force it to use doc strings because it's a lot easier for the programmer or the next AI agents that will review the code to understand what the function is doing, not just from a code based perspective, but from specifically that block in the code. So to understand what it's doing and to understand what it was supposed to be doing. So that's also something that I'm asking it to add to the docstring, sort of a reference to the implementation plan. So not only will the next AI know what the software is doing now, the code reviewer will be able to know what it was supposed to be doing and make sure that there is alignment.

B (16:36)

So one of the things that strikes me from this latest description is this idea of distributing the context to the right spot, if you will. Right. Like have the context in the prd, high level, mid level, low level, detailed prd, then have the context within the functions, the modules or the code blocks.

C (17:00)

It's not really the context, it's more of kind of inline comment. This is where we're reaching the database. The reason is when we did it in other function, it caused slowness. So there's kind of hints of why some decisions were made. And the reference. So the doc string is very simple. What parameters are in, what parameters are out. But there's also a reference. This is in reference to the implementation plan in file XYZ md.

B (17:33)

Yeah, and the reason why I mentioned context, of course I'm using context as the word that is used to describe the information the AI takes into account when doing its job. So not context as we would use it, but context as in AI uses it like the context window. And the reason why I mentioned this is because in my experience, AI coding agents are extremely good at repeating the same mistakes reliably, right? Like rewriting the same script 20 times just because you've asked a similar prompt to before and they never really went and checked. Was there a script that did this already? And it seems to me, and I don't know if that's why you use it, but it seems to me that this approach of sprinkling the context with the code will help the next round. Whether it's the same or a different agent, it doesn't matter, but it will help the next round that goes through the code not to repeat the same mistakes. I imagine you, you might have some notes in those contextualized comments. Do not call this function because or don't use this structure of query for the database because or something like that. I don't know if that's what you do, but that's the idea.

C (18:44)

Yeah, that's exactly what I do. And recently we've actually released the skill that we're using internally. And this is the mental model as I mentioned. I think in the previous call that we had in the old, good old days, you used to have a mental model of the software. As a developer you knew what's going on. And what I'm asking now is as the AI writing the software, I wanted to keep a file that's literally called Mental model MD that has everything related to the software, why decisions were made, if there's a non obvious solution that we're using, why this solution was chosen. So whenever we want to develop a new feature or fix a bug, instead of the agent start speculating on what could be the cause or just blindly scanning the entire code base, it can go to that Mendel model file which usually has a lot of description and some sort of. The agent builds it itself. So it's never a constant structure but usually also have some sort of knowledge base graph type of a higher level knowledge based graph of the software as a JSON snippet inside that doc. So this relates to this, this kind of connects to that. So instead of blindly searching around the code what might be the cause of the issue or how I need to develop a new feature, it just goes to that mental model and learns a lot about the process. So every time and I use it with hooks, so every time there's a pre compact before we lose context, I want you to update that mental model with new learnings so it keeps it fresh essentially.

B (20:44)

Yeah, absolutely. That's a great tip. Now of course there's a lot of things that you have learned work but I'm sure you have seen also a lot of things that don't work. So what are some of the anti patterns you've seen either from your own experience or. Or from talking to others about how not to use AI in a development workflow?

C (21:06)

Okay. Everything that I'm about to say is just how I'm not using AI. Okay, so it's not a recommendation to anyone's workflow. But one of the things that I've noticed that I do quite differently from even a lot of people on our team is I only use one MCP which is context 7 for example. This is the only one that I'm using and anything else that I need to use I'm just instructing it to use the CLI. So if you need Stripe, if you need GitHub, if you need whatever, just use the CLI. And it just uses a lot less context. Maybe if they were designed differently and have kind of their own registry of MCP that's not part of the context, maybe that would have helped. But as of now, it just takes way too much context. I don't want. And that's the most precious resource that we have as AI users. So that's one thing that I don't use. We have maybe a handful of skills that I'm using, maybe six or seven skills that I'm using for how I want to do qa, how I want to do the mental model, how I want to. I want, how I wanted to do testing, stuff like that. But another anti pattern for me is that I never go into plan mode. I just talk to the AI. And the reason why I'm not using plan mode is because I find it limiting. The plan mode works, seems to work that the intended use was, I'm going to vibe code an idea, let the AI plan it, and then I either approve it or give it some notes. And the way that I do planning is a long and iterative process. So essentially I just start with a prompt, like, I want to discuss this idea. Do not start coding until we have everything planned out and I give you the go ahead. And yeah, so that works great for me. Once I'm happy, then.

B (23:35)

So it's a little bit like you are applying the same idea of vibe coding or AI assisted coding, but to the understanding and decomposition of the problem that you're tackling.

C (23:48)

Yeah, you can say that. You can say that that's what I'm doing. And even, by the way, even when we're done with the planning part and we're going back to coding and I want to hypothesize something, so the prompt will probably end with something like, what do you think? So it knows that it's discussion time and not coding time. So it stops coding. And yeah, so that's. For me, I would say the anti patterns. Probably another anti pattern that emerges from this discussion, as you can probably guess, is that I don't let the AI be the architect. Maybe with Opus 5.5 I will. But I need to know what's going on in the software. If this is. Again, this is not a toy. I'm not developing a toy. The software that I'm working on is production grade. It's mission critical. Companies are relying on that. I can't not have a full mental model of what's going on there.

B (24:53)

This actually reminds me that the way that the current AI models work is that they have a lot of training data which allow them to learn certain sequence of tokens. And what you just said about not outsourcing or delegating architecture to the AI model reminds me that actually we don't have a lot of architecture training material. We need to create that kind of training material before an AI is even ready to be performant at that level. And I'm guessing that the AI companies out there are probably working on that, especially those who are focusing on the software development market niche, if you will. But it's hard for me. I mean, even within our community, we don't really have a language of architecture. Many have tried, we have UML and we have simple modeling languages and all kinds of different attempts. But I don't think we have a solid language like we do for programming, which has their own grammar and so on. I don't think we have a solid language that has been widely used by the industry to define architecture in function of problems to be solved.

C (26:10)

I'm not sure we will have, because it's essentially the way that your thinking applied to programming and decision making. I think that I told you about this in a previous call. I used to volunteer at my daughter's high school to teach computers like 10 years ago or something like that. And for the first two months I didn't let anyone use a computer. I just wanted everything pen to paper as flowcharts. I want them to understand how the software works and understand the different components without bothering themselves with how do I write this. And with AI, it's even more so. Not as important the syntax, but it's more important that you know how the software should be structured. So that's why I think that we're not going to really see a language for planning, but it's going to remain in the realm of processes rather than a language.

B (27:19)

Yeah, absolutely. And a lot of judgment based on the specifics of the problem to be solved. So when you look at the way AI assisted coding is being used right now by yourself, your team and others out there, what are the trends you see? Where do you think this approach is going to in the near future?

C (27:38)

I think that we're probably going to see the death of the ide.

B (27:45)

I'd vote for that.

C (27:47)

Yeah, I think those days are over. These days I'm still using the ide, but it's more of. It's rarely for editing. It's just a viewer Right. As a viewer. Exactly. And for a viewer, I don't need a full fledged ide. So I think that the approach that software like Conductor is doing, I think they've done an amazing work in how they structure this software. You have chat panes and you work with different work trees and you have a file viewer and you have your terminal. I think that's probably how the future software development tools would look like. Probably with a test suite attached to it or something. Just something a bit more advanced. But that's the direction that we're going towards.

B (28:44)

And the name of the editor or the Conductor. All right, I will put the link in the show notes.

C (28:50)

Yeah, I'll send you the link. There was also a new tool that I found literally over the weekend. I still don't remember the name. Oh yeah, it's by augment code. It's called Intent. So it's a similar approach. Personally, I think that something like this, that it's really good, it's really well structured, very similar to approach, at least to Conductor, but it also includes more advanced stuff like an integrated web browser and File Viewer, File Explorer, Knowledge File Viewer and Diff Viewer. So it's very complex. One thing that kind of prevents me from fully using it is that it's yet another subscription. And I much rather just just leverage my existing Cloud Max and OpenAI Max to use these tools instead of paying for yet another tool. But something like that that would be able to connect directly to APIs would be amazing.

B (30:12)

What do you think of the idea? This is something I've been toying with in the. In terms of developing my own approach to AI assisted coding. This idea that one of the critical and most important jobs we do as developers using AI is to keep the context, the mental model, as you called it, the understanding of the architecture always front and center and making sure that the model doesn't deviate from that unless we want it to. Right. And what do you think of tools that would automate a lot of that work? Right. Like, so a lot of what you said, which is creating the PRD and so on, is a way for us to kind of, kind of guardrail the way the development goes on when we are using the AI models. Are you aware of or have you seen anyone playing with the idea of kind of either a parallel model or just as part of the way you develop the system, you create an internal database or even an MCP to use an interface that would act as the, let's call it the stand in for us when the model is doing long term development, let's say a few hours

C (31:28)

of development so far. I'm not aware of anything like that, to be honest. I'm playing around with the writing. My own coding agent that's actually using stock model or set of the art models like Opus and Codex. But it's guarding context with its life. So it's far from production ready. And I'm not even using it in 99% of the time that I'm coding. It's more of an experimental project. But I think that someone will end up building something like this. I think the companies that doing the closest to something like this is factory with their droids, which is my favorite AI coding agent with the same model. I can't tell you the number of times that I started something with CLAUDE code and had to switch to factory to clean up after it. Something with the way they're guarding context, they're doing better compression. It's a lot better. Just the fact that you're starting a new session with a code base that it had never seen before and you ask question somehow it needs to do a lot less exploring to answer. Whereas CLAUDE code by its design is more than exploratory animal. It just goes for kind of a journey to try to figure out what the code is doing. And it's almost like every time it starts from scratch. So I think that at the end of the day, what we're going to end up seeing is less of a process, but more of a better harness and larger context windows. So if you imagine, let's say that we're two years into the future and you have a 5 million context window and your code base is still 2003-000003-00000 token context. It's just nothing for the model to just keep everything in memory and remember everything. It will also make a lot of the RAG applications obsolete. A lot, not most. Some of them has huge amounts of data to work that they'll still require chunking and better retrieval. But for most small code bases and 200, 300,000 tokens is not that small, that's still a large code base. So I think it's going to be solved in in that way with larger context windows, better models and better harnesses. I think we're a year away at most.

B (34:31)

The way these things develop, we never know. But we will be here to watch this and talk about it. Ran, it's been a pleasure. What about if people want to know more about you and the work that you're doing, where should they go?

C (34:45)

Definitely X that's where most active. So my account is x.com rusi a r o u double s I I'll send you the link as well. Yeah, that's where I'm most active.

B (34:59)

Absolutely. We'll put the link to that in the show notes as well, as well as all of the references that we just discussed. Ran, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.

C (35:10)

Thank you very much for having me. It's always a pleasure.

A (35:15)

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

B (36:15)

all of that AI slop you see everywhere.

A (36:17)

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 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.

B (37:05)

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.