Ep. #87, Augmented Coding Patterns with Lada Kesseler

Jessica "Jess" Kerr: How do you know what your coding assistant is doing?

Lada Kesseler: Right? And when, Right? Because I think there's a lot of things related to that. One of the things is like, what is it in its head? Like, you tell it things and you're like, did it understand me or did it read it? Because agentic systems can pull in things in the context. So I think the thing you were thinking about is the little emojis that I've done.

Jess: That's one of them. But let's start with what you were just saying about when you're using a coding assistant, there's lots of levels or ways to think about what the hell is it doing. Can you describe some of those?

Lada: Right, so first of all, what's in its head?

We're dealing with a black box. And the black box is very silent and m mysterious. So really, first of all, the code, you can open it up and you're like, oh, I understand this, right? It takes some skill, but it's doable. With AI, not so much.

Plus it's like a little bit of mental model going on there that's really hard to see what's inside. Plus its context is also invisible, right? So it read some stuff. You don't necessarily know what it's read because it's also kind of pulling things in.

So that's one aspect, right? What's going on inside that mysterious black box. Another thing is like, what is it doing really? What is it physically doing currently? Like, did it call some tools? Did it look at this file? Did it look at that file? Did it miss anything?

And then the big thing that I see a lot is it is very noisy and it is very fast. And that creates a problem of: How do we keep up with this crazy, noisy talking machine?

Jess: Yeah, you're right. I mean, it's a silent black box and yet it's not silent. It's very verbose.

Lada: Right. It's silent in some ways, but very not silent in some ways. And all of that is tricky. So I have this idea of how you can zoom in and out when you need. And you need a level of noise suppression first and foremost.

You need to not let it overwhelm, because I see so many people just allowing it to spam them, asking them 10 questions and they literally sit down and answer every question.

Jess: Oh my gosh. Yeah, I hate that. I'm like, "no, one question at a time."

Lada: Yes, exactly. That's the core rule that should be everywhere. So that's one. And then like in documents, right? If you let it spam on documents, basically it starts reading pieces of documents and then chopping it up and it does parts of documents. So it read this part but didn't update that part. And like it gets messy so quickly.

Ken Rimple: Yeah.

Lada: So same thing. You can zoom out and be high level and then, whoa, suddenly you could see.

Jess: How do you do that? Do you tell us something?

Lada: Yeah, absolutely. And it was interesting because I started doing this before it was a thing, I think. So I saw it first in tools in June when I saw Claude Code. When you do "/init" in Claude Code, it does create the Claude.md. And with old models especially, it created a beautiful thing.

It was so good because it's like, "okay, here's the parts of the documents or this repo that's important. Here's our things. Do this, don't do that." Very high level, like the gist of the gist. And it's super scannable. I started doing it maybe back in April because my documents started rotting.

You start doing spec driven or I'm not sure if it's spec driven, but I do put things in files a lot. I have this knowledge documents, ground rules, and so on. And as you start progressing your system, this grows and then how do you keep it up with code, right?

Jess: That's true. And we have these AI assistants who are really fast at updating documentations. So we have the potential to keep our documentation up, but we also used it to create a much higher volume of documentation and it doesn't actually go back and update at all.

Lada: Yeah.

Ken: And your cognitive load is high trying to get through all that stuff. Because if you let it do its thing for a while, you end up with so much to go through. And Jess has warned me about this, and she's been right every time. It's like, "delete those stupid files it generated."

Because it's doing a fridge poetry version of that in the context and saying "maybe this."And you're like, "is it. What are you doing?"

Lada: Absolutely.

Delete mercilessly. That's one of the things you do. It's hard because people have this attachment to written documentation, especially stuff not written by them. It's really hard.

Jess: Oh, so we'll delete what we wrote?

Lada: Yeah, we will delete what we wrote most of the time. Although, like, many people don't embrace Git still as they should.

Ken: Yeah it's there. You can go back to it.

Lada: I wrote it. Right? So you can get past it. But if it's somebody else, if they're in the project, that gets really bad. Imagine five of those with very noisy agents in one project.

Jess: Oh, okay.

Lada: It is not sustainable.

Jess: So how do you know what's safe to delete?

Lada: Basically, just my default mode is super zoomed out. So high level. Like, whenever I go, once the sync plays, high level. I have ground rules. So this is like, the rules are always in the context.

Jess: And you keep those really up to date.

Lada: Those are absolutely up to date. I have like 75 lines. And I know every one of those.

Ken: Got it.

Jess: Nice.

Lada: But I also, I have a rule of, in one of those lines is, "be extremely succinct."

Jess: Be extremely succinct.

Lada: Yeah, yeah. So high level, shorts, like, when I go ask questions in the repo, like, I open a new repo and I try to poke at it. I'm like, "give me a architecture on a high level."

And it's so good at that because you can zoom out and you can see now suddenly on high level, then you can poke in and you can zoom in. So we have this semantic zoom now that is like a lens that allows us to go in and out.

Jess: In language?

Lada: In language and in code, in anything, any text. And then you can zoom in by asking more questions, especially if there's more context there. So in repo, it can actually go far deeper because there's depths there. In a document that's just written on one level of abstraction, you don't have that.

So you'd have to either guess or pull in stuff that doesn't exist. Right? So yeah, and I use this all the time and it's super, super helpful. And I think this is something, I still find ways to use it. I think I'm progressing to level two. Because you can also do it in tests. Because if you think about--

You're trying to keep up with AI and it writes a lot of code and writes a lot of tests. How do you know what it did if you're not looking very closely? One way is to write tests on a high level of abstraction.

So you can do it several ways. Again, you can do approval tests, zoom out. And approval tests can be images or it can be structured text in a way that's super scannable. That's one of them at least. And then you can also do custom assertions a nd all of that. Make it easy to for yourself to follow the agent by zooming out.

Jess: So it looks like BDD, like Behavior Driven Design tests.

Lada: I think BDD are super powerful and you want them on the level outside the agent is what I keep coming to. The agent shouldn't touch them.

Jess: Oh, okay.

Lada: On some stage. On some stage.

Jess: But in BDD you say "given condition in natural language, when something happens in natural language, then expectation in natural language."

And the hard part of BDD historically has been implementing all those steps because you kind of hard code, "okay, when I say then the cart should be empty, here's the code version of that."

But the agent can implement those steps, right?

Lada: Absolutely, yeah. And you can go Gherkin if you'd like. You're describing. You can also do approval tests. So like me and Llewellyn Falco have a talk about better testing with approval tests.

Jess: And approval tests, that's where you have like a snapshot, right?

Lada: Yeah, it's like a golden standard. So basically it produces something. You're like, "yes, it looks good to me, check mark."

And then now it's a golden start. And whenever you run the tests, if it produces that, we don't even say anything. We say everything is good and if it's bad it shows the diff. So now it's immediately quickly you can see what's wrong.

Jess: Yeah, if it's different. Or sometimes I want it to make a change. And I'm using those approval tests to confirm to myself that it made the change I wanted.

Ken: And to be clear here, these tests, you write them. You write the tests. You don't let the LLM generate the tests.

Jess: Well, not with approval tests. With approval tests.

Ken: Well, I'm saying like the specs, so to speak.

Jess: Okay.

Ken: What I'm saying is like, let's take the BDD side of things, right? You would want to assert everything in the "given when then" language. You want to think at a high enough level so that you can understand what it's trying to test.

So that when it goes crazy ham on your code and breaks the test, you could say, "hey, rebuild these based on the same specification I gave you earlier because you screwed up and it's not running and I want you to fix what you did. And I understand a high level of abstraction. So now do what I want to do at a high level of abstraction."

Right? Is that basically what you're saying? Sorta?

Lada: Sorta. So again, Llewellyn Falco. So he has a very, very good way to do this. This is how he approaches TDD. He's like, "here's a feature. Write me first. All the tests, single lines of English. Every test is a single line of English, no more than that."

And I think that forces it to get the-- So this is where you zoomed out to the level that you get the gist of the stuff that you care about. And it's very scannable, extremely scannable. I can quickly see the list and they're like, did it miss something?

The next thing I would do immediately is look at this level of test, look at the task, and look what you just produced. Double check yourself. Did you miss something? Find issues with that?

This is a pattern I use. I call it feedback flip. It's basically immediate feedback from the agent. Surprisingly, it works with the same agent, which kind of blows my mind. And I'm like, why? And I think I have ideas, but it's interesting.

Jess: So Lada, tell us who you are and how you got to know so much about AI assisted coding.

Lada: Yeah, so I'm a software developer. I would call myself probably a crafter. So I love extreme programming, I love TDD refactoring and have been tending for legacy code for a while. But I also like writing good stuff from scratch very much. Probably my preference. We don't always get to do that. Right?

And so this year I've been, and I've been skeptical about AI for like maybe a year and a half. Pretty skeptical because it didn't seem very useful. But suddenly I found myself on a project where I didn't have any front end developers and I was like, "can I do this to the AI in the thing that I don't know? In angular?"

And I kind of did. And then I was like, okay, now I'm paying attention. So I've been exploring it since, because like, I think people say "hide, not hive." But like my last year is not anything like the previous 15 years in this career.

I'm exploring it like mad. And I was just super curious. It's just super interesting and trying to understand what we're dealing with. I care deeply about how to do good things with it, how to do this well, especially how to produce software that lasts and doesn't break on us and cause issues and breaks trust of our customers.

Ken: My ears perked up because it's front end that you're generating because that's always a complex beast. Like everyone says that front end development's easy until they do it. And then you realize it's a moving sludge pile of crazy numbers of APIs that change before you sit down the next morning for coffee. You're like, why is this thing broken?

Lada: Smells like AI. Yeah, Perfect.

Ken: Yeah, they fit together like ice cream and something else. Something I won't say. Yes. Anyway, so what were your first halting steps in getting this black box to give you something that you could use? And when did you do the aha moment and say, oh, wait a second, now I'm productive with this?

Lada: Yeah. So that was that moment that basically changed my mind about AI. So I was basically doing a backend for, I was writing an agent. Now I figured out how to do RAG and how to do the backend part of what I needed to do. And then suddenly I have no front end. What do I do? And this was pre-agentic. That was in November. Agentic barely started. So last year.

Jess: November of 2024?

Lada: Yeah, November of 2024. And I was a bit late to the party. So Anthropic had a feature that released earlier that's called Projects. And the difference between the browser and the projects is you can upload files there.

So you can have a little folder with context that you upload and if you combine it with a tool that allows you to grab a piece of code and just concatenate it into a giant string, you basically have a way to quickly give your agent, which is still locked in the browser, all your contacts or a big chunk of your project, and then suddenly that agent that was really, really useless before can tell you how to add an Angular page.

And I'm doing things step by step, always very slowly, so I'm like, can you create me an empty Angular page? And it does. And I look at the code and I have to paste it still. Right? So it's pre-agentic, so I have to grab the code and paste it, but it works.

And then I'm like, can you add a thing here to this? Can you add a text to this thing? And so on. And I built the whole thing and I got compliments for my design skills.

Ken: It's doing something right.

Lada: Yeah. And that's not the first one. Since then I've been pretty much agnostic of the technical stack. And it's crazy.

Ken: Yeah. Because you could do React, you could do Vue. I've just done two mobile apps and iOS and Android with it. I'm like, darn, now I, or Claude and I, are mobile developers suddenly. But we can get things done.

Lana: Precisely.

Jess: And sometimes the best design is following patterns.

Ken: Yep.

Jess: And it's good at that.

Ken: It's really good at that.

Lada: And because we know how to write software well, you can still guide an agent. Right? So I find that all my skills that I built before, like, if I get myself into something unpleasant, I can get myself out and I know when to start. So, you know the hilarious moments where agents, some people show screenshots of what they do to their agents and they get the agents so desperate that they delete themselves from their computers.

Jess: Aww. I guess it's better than kicking puppies.

Ken: They must be bad bosses in real life, right? Like, I would think that if you're that mean to an LLM, okay, it's not real, but, oh boy.

Lada: You don't even need to be mean to an LLM. The only thing you need to do is vibe code and continue vibe coding. It will just do it for you.

Ken: That's true.

Jess: Oh, because they get ashamed of themselves.

Lada:

They basically are running into the same problem as a group of completely clueless developers who don't know how to do anything good in code other than just produce code. They don't have design skills, testing skills, any of that. They don't know when to apply it. Imagine that at speed. And that's where the agent arrives.

Ken: Yes. You get in this loop, by the way. I find that I get in this circular loop when that happens, where you know it's time to give up and nuke things and start again, when every question you ask it when it's screwing up, it gives you a version of what it did wrong last time that it thinks you forgot about.

You're like, "No, I've seen this before. Three questions ago. And you did it six questions ago. And we're in a loop and I quit, we're done."

Lada: Actually, that's actually a pattern that Ivett Ordog added. That's absolutely a thing that you can think about as a good marker of start again. You're in the corner.

And the way to start again easier. Like you will save yourself a lot of brain cells if you actually have safe points in between. Right? Don't just do a giant, "write me a Twitter." That's a recipe for disaster. At some point you're going to run into a wall. That's a guarantee.

But if you do, "okay, write my page, then do this" and you save all the stuff in the files. So like you save the intermediate what you ask it to do and then it makes it so powerful because you can also spin five of them and do it in Verl.

Jess: You mean save the instructions?

Lada: Mhm.

Jess: Save the plan. Obviously the code is in files.

Lada: Yeah. Right. So like, "here's a feature file. This is what we're trying to implement. Here's a to do." Like we have a group of files, now because they're saved and there's a save point after that, so you committed, now you can, first of all, start so easily. And so I call it knowledge checkpoint. You have a knowledge checkpoint. You saved the piece.

Instead of going and telling AI, which is basically like a fleeting context that closes and is rotting in front of you so quickly, you saved it and now you can reuse it. So you can start a different context immediately. And you can also parallelize it. Like you can do like 10 agents that do the same thing and try it out. And you can steal feature from different branches. So it's kind of mad.

Jess: Nice. So you have a collection of these patterns, right?

Lada: Yeah, I do.

Ken: Tell us more.

Lada: So the idea was basically very simple. Somebody asked me how I code with AI and I was starting thinking about it and it was so hard to get this communicated to anyone. And everybody I've talked to, so every developer who is really, really good at generic coding is like, "I don't know how to communicate this thing. I have so many intuitions. But I just stare at my computer and the agent does a lot of things and where do you start?"

So my goal was to do a talk because Jacqueline Lee from Calgary Software Crafters asked me to do a talk and I started thinking about it. My goal was to teach somebody the things that I learned this year, exploring like crazy.

And as we distilled the idea, so Jacqueline helped me, Llewellyn Falco helped me a lot with figuring out what is even in my head. They were like, "oh, you have patterns in your head. You have very many little things. They kind of build on each other and they're bite sized, each of them, but together they can be combined and you can arrange them and think through them."

And now I basically have a talk that has a walkthrough of these patterns.

Ken: That's really cool.

Jess: And a repo.

Lada: And a repo, yeah. Thanks to Ivett. Also Ivett helped to make the website because I just wrote it as markdown and she was like, "oh no, we should make it a website."

Jess: It's GitHub.com/lexler/augmented-coding-patterns, right?

Lada: Yeah. With dashes in between.

Jess: Yes.

Lada: There's also lexler.github.io/augmented-coding-patterns/. So thank you for finding it.

Jess: And we will put that link in the show notes.

Ken: Yeah, for sure.

Jess: Some of these patterns help you know what the agent is doing, right. Like this one that tells you what files it's been reading in. Tell us about that one.

Lada: Yeah. So I call it context marker. And the idea is basically whenever you try to figure out what is in the context, you can make it a little bit more visible by just adding a few things. So I have a ground rule. So this is like in my plotted D file that says basically always start replies to me with a starter emoji and starter emoji is formed as a variable "starter_emoji"and my starter emoji is, I don't know, lucky clover this time of year. And then I can do basically in the process file.

Jess: What's the process file?

Lada: Right. So if you're unfamiliar with process files, you probably want to listen to Llewellyn Falco's talk on process files, which we should also link. The process file is basically you can think about it as code as text. So text as code. It's hard to say which one.

So basically it's a file that describes how an agent can do something. For example, here's my TDD process. It's process file. When you start TDD'ing, write me tests as English, high-level English and show it to me. Then one by one, start with implementing each test. Make sure that this and that and so on.

Jess: Oh, so it's almost like a system prompt for a particular circumstance.

Lada: Yeah, exactly. Or like a task. And it often follows the steps. So it is a little bit more deterministic because it's basically a to-do and to-dos are magical with AI because I think they focus on and allow them to do things in steps.

Jess: Okay, so you've got your starter emoji and whenever it talks to you, it shows you that, right?

Lada: Yes.

Jess: I've started using this, mine is a carrot.

Lada: Carrot. That's hilarious.

Ken: The stick is right behind you.

Jess: Because Jessica "Kerr."

Ken: Ooh!

Lada: I love it. Can I see it sometime?

Ken: That's why you do that.

Lada: All right, so there's that. And then you can basically, in my TDD process, I'm like, when you are in red phase or green phase, I have a little green plant that it shows me. So green and then in red there's a circle or a no thing. And then in the refactor there's like a loop thing and I see immediately which phase of TDD it's in.

Jess: Right. Oh, so this is making its verbose output scannable.

Lada: Yeah, exactly. Very quickly.

Ken: That's a great idea.

Lada: Thank you. And there's things. So what else do I use it? I sometimes put markers in individual instructions. For example, I have instruction of my agent needs to be proactive and warn me if I'm about to mess up or if there's something wrong. And I ask it to also display exclamation point emoji in there. So I see quickly. So when I see that emoji, I know that instruction fired.

And that's good to know because it's really good to know when you have a Claude.md file for your agent, ground rules.

If those ground rules are not followed, they're noise. And the problem with noise with AI is it's not just noise, it's also harmful because it takes focus away from the agent. So it's making you less efficient.

So that's one of the ways. Another way to use this kind of thing is like, I think you saw my Chewbacca, Jessica. So somebody was saying that they split up their giant Claude.md because apparently there's a limit to how big you could make it. And they split it into a bunch of files and they're like, "oh, now they're lazy loaded."

And I know that they might not be because I've kind of tested before. So like, did it test? And here's how you can test. You can go. So the main Claude.md is pointing to, say, a file that's called map.md. Did the agent read that Map.md when you open the new window? Y ou put something like, "say, 'Chewbacca' when you see this, when you read this" and you open the thing, you open the window and you see Chewbacca. Guess what? It's not lazy loaded. Right? So this little tricks help us build intuitions.

Jess: Oh, so that's the part where you don't want it to read all those files when it first starts up, you just want it to have access to them later, and it is.

Lada: Precisely. But it's good to know how it's working for real underneath, right?

Jess: Yes.

Lada: So now you can maybe you can out prompt this. Maybe now you can be like, don't read it now, read it when you need it. And see immediately, did it work?

Jess: Yeah.

Ken: Okay. Yeah.

Jess: This is a kind of live observability of like in human joint activity, you want to be sure you have enough common ground, which is, I know that you know this and you know that I know this. And that common ground is established by these files that you've actually curated and they're up to date. And the pattern of starter emoji and "say this when you read this" file, gives you an awareness of what that AI knows, of what knowledge you do have in common or don't.

Lada: Yeah, yeah.

Jess: And that increases the interpredictability. Well, at least your predictability of it, which helps with the joint activity.

Lada: Yeah, I think so. So the idea of like putting a word there was. This is where I kind of got the idea initially, right? So somebody was like, "call me this name when you read this" at the ground rules.

And I thought that name was-- So I immediately made a funny name. It was funny for the first five minutes and then it got really annoying. And then I'm like, "instead, I want to see emojis."

And emojis are nice because now you can have emoji profile. So I can also stack my emojis. So the way I do this is like my golden standard rules of like, how to do hexagonal architecture is a hexagon emoji, for example. And now I see my ground rules with the clover and then a hexagon. Now I know that it read both.

There's a difference in how different agents handle contexts and sometimes what happens when the context gets too long. Right. So for Windsurf, for example, I had, like, three emojis in there, and when I saw one of them disappear, I'm like, okay, this part got out of the context, and I can see it immediately because it's just not there in the three things and so scannable.

Jess: Oh that's great. So you can see stuff, enter the context and leave it?

Lada: Yeah, yeah, yeah.

Jess: "It forgot about this because it's not showing me a tree."

Lada: Yeah, yeah. And it's not 100%, but if you don't see it, it's definitely not there. If it sees it, there's also a question, does it pay attention to it? It's not the same thing. Because it may not have enough focus.

Jess: Ken, what were you going to say?

Ken: I'm just blown over. I really love that I have a new site I'm going to spend a lot of time on because I am in that early journeyman, putting the tools on the table and going, I wish I had this screwdriver mode of Claude and making lots of dumb mistakes. And I feel like, just like, when patterns came out for coding, it was a great thing to reference to start realizing there's predictable ways of doing things that you can use and take advantage of. So I love this. I'm just thrilled.

Lada: I'm also trying to be like, "how do we do it in a way that's not fleeting?" And I'm starting from the problems, so I'm starting to think, what is this thing in front of us? I try to understand it and, like, so there's things about it that are important.

So, like that black box that I described. And the fact that it's biased to be compliant, but also there's, like, the fact that it can't learn. So now we have to build the context for it, because it can't learn and we need to restart. The only thing we can do is restart or add to it.

Ken: That's a great point.

Jess: Or it learns really fast all at once at the beginning when it starts the conversation and then promptly forgets it at the end. Well, except it doesn't even forget it. You just start it over and it's a new person.

Lada: Yeah, yeah. And that's another problem. But that problem is actually a limited focus. So what you described is basically, you told it so much that you overloaded it and it doesn't work well. And this is very interesting because I've ran into-- I saw really good. And some people, I think haven't seen really good. So when you focus the agent. And so I had these productivity rules.

Jess: Oh. Like you've seen it do really well?

Lada: Yes, yes. And this is on narrow focus.

A narrow, very focused agent that only does one thing is magical.

And I only saw it because I basically had a main Claude Code where they code with everything. And then I had a little committer and they all have one block of rules, basically ground rules that they reference and they had those productivity rules in there. "Warn me if there's any issues, tell me if I'm about to make mistakes, don't push back against problems. Ask questions," all of that.

And my main agent, like I was waiting for this to hit and it never did. But suddenly my committer started doing that and I almost dropped out of my chair when I saw it for the first time. Seriously.

Jess: How did you know it was the committer? Does it have its own starter emoji?

Lada: No, no, no. My world looks like this. I have basically right now a terminal. I used to be on iTerm2 for a while. Now it's Ghostty. And basically it's just blocks of windows I've opened there. Right?

So I have Claude Code, that's my main Claude Code on the left and just piece of screen is that. But then another piece of screen, usually a smaller one, is a committer. So I open two Claude Codes in the terminal at least. Right?

And the committer, the only thing I do in this committer window, it has its own instructions. Like "you're a commuter, only commit, do this, do that."

Jess: Okay. So it's not a sub agent, it's that you are giving a different agent an instruction here.

Lada: Different agent. In the same repo.

Ken: Single purpose?

Lada: Single purpose. Yeah. And suddenly that single purpose one started to notify me about things. It's like you're about to commit this node modules. Did you mean to do that?

Jess: Nice.

Lada: And seriously, this was so surprising. And because I have those productivity rules and because I didn't overload it and "do this, do that, and think" like some people like agents have so much focus, like 7,000 plus minus 2 or something. I think it's not the case actually. I think it's still 7000 plus minus two.

Jess: Nice.

Lada: Yeah. So this is an example that limited focus is an example of another kind of blocker that is really good to know. Then you can actually do something about it.

Ken: So one of the things that I keep running into, because I don't do these things the way you're doing them, is that working with the AI to get things done is such a variable box. It could take two hours or three weeks.

Lada: Absolutely.

Ken: But you're giving it these little targeted prompts that say because, "you're a committer or because you're working on page design, you will know everything about, like focus on CSS and whatever style stuff is, but don't focus on the serious code, focus on the UI layout." And you're narrowing the black box's purview, its reach.

Lada: Absolutely.

Ken: Oh, that's really brilliant.

Lada: I think you have to, because--

This thing cannot manage complexity, it doesn't manage complexity now. I don't know, we may need to just build a better tool. So you have to, naturally. If you don't manage complexity, nothing will. And then complexity will grow and kill you because it kills you very quickly. You know how quickly you can code yourself into a corner, even as one developer without AI.

Ken: I'm good at that too. Yeah.

Lada: So am I.

Ken: But that makes a lot of sense. So one of the things I was thinking about when I'm hearing this is there was this book many years ago called Refactoring Your Wetware. It was by Andy Hunt. So his whole point was your cerebral cortex can't keep everything in memory. So you externalize by putting in things in mind maps and other things to kind of like have an external cortex. With the LLMs, you're basically giving it an external cortex to work with. So when it dies, the next weird thing that comes back and look at that same cortex can catch up.

Jess: Because it dies as soon as its context gets overloaded and it starts being annoying and you get in that loop and you say, slash, clear and that one's dead. And then you hire another one and then it reads all the documentation and bam, it's ready to go.

Ken: And let me finish that too, because, I mean, yes, the problem I have is when I'm doing an investigation about something. Oh, this ticks me off so much. I'm doing an investigation about something really complex and I have a certain amount of knowledge that's amassed to help me solve the problem, but it starts running out of context and I'm angry.

So if I kill it, it loses that. Unless I tell it, "spend some time, write this out."Which I do. "Spend some time, write out what you've learned so far." I just haven't gotten the mechanics right to say like, "please do that, but be focused."

Lada: What you described just now was a part of the hell as well. It's called Can I Extract Knowledge? So you put a lot of energy into this context. So that's fleeting and ephemeral. Immediately as you did, basically get it out into a file, into a safe space, now you have a thing you can point at and it's going to take you a second. Versus reiteration of the same thing.

Ken: Yeah.

Jess: That piece of knowledge is going to get out of date.

Lada: It might. Yeah, it might. So you need to figure out how to keep it up and the way you keep it up--

Jess: Or delete it.

Lada: Or delete it. Oh God, yes, delete it, please.

Ken: Especially with something during refactoring that doesn't matter anymore. Get rid of it.

Lada: And thing is, with AI, the dead stuff is out there to get you because-- So the agent finds it. It's like, oh, I found the place where in code. Right. I found the page that you're trying to fix. Let me fix everything about it.

And this is one of the ways it gets itself in the loop. I've been there. That code is deadly. It's deadly with AI.

Jess: Uh oh. Because anything incorrect or out of date in the context is not only spending focus on something useless, but it's actively directing it towards something wrong.

Ken: It's a text-based foot gun. It is different than the last 30-some years of coding for me too. It's a totally different world. You're absolutely right.

Lada: Kind of crazy. Yeah.

Ken: See, I just did the AI thing too. I just told you you were absolutely right.

Jess: Oh no. It's entering at lexicon.

Lada: I need therapy. Seriously.

Jess: We need some sort of reverse therapy where someone tells us we're wrong.

Ken: "Whenever you say that, Claude say I'm absolutely wrong." Yeah, that'd be great.

Lada: That's pretty easy to do as a hook actually, I think.

Jess: Oh yeah, as a hook also. "Tell me when I'm wrong. No, tell me more."

Lada: Just yesterday I was thinking about, I noticed telling my Claude that it's right. And then I'm like, "no!"

Ken: So here's my question for both of you. How have you complained to Claude when it's done something wrong to you and you want to fix it?

Jess: Slash clear.

Ken: Yeah. You just quit right away without trying to get it to fix itself. Right?

Jess: I'm like, we're out.

Ken: Because I've actually said no, no, no, no. Which is stupid. And it just leads you down the path and it gets worse from here.

Jess: Because that wrong stuff that it said is in its context.

Ken: Yes. It's in memory now. And it's just going to hurt you further.

Lada: Yeah, I guess I sometimes escape, escape and roll back, pretend if it doesn't exist and roll the dice again.

Jess: Escape, Escape. Do you like back up the conversation?

Lada: Mhm. So I go to previous message, basically.

Ken: Oh, that's a good idea. Yeah.

Jess: I've heard of people who like go in and edit its own thinking.

Lada: No way. I guess you can write a tool like that pretty easily. Yeah.

Jess: Lada, you were talking about the little starter emojis and stuff like that give you an immediate connection to what is it doing right now. But that's not persistent. On the other end of that, when you hook up OpenTelemetry to Claude Code, for instance, it will output logs and metrics about what it's doing to, well, I send it to Honeycomb, of course.

And those are persistent and it's really useful for like, "how much was I spending," but it doesn't have the full level of detail and it doesn't have a trace. It doesn't like walk you through a conversation of "What did it do?"

Lada: Mm.

Jess: So I leave that on. But yeah, the OpenTelemetry output doesn't help me use it better so far anyway.

Lada: Yeah, it's very entertaining though, like, especially when you like when I started coding with Claude Code, my friend also has created a dashboard in Honeycomb.

Jess: Nice.

Lada: And then we've been like, "oh, look at how much usage we had." It was just fun. And also like, "oh, there is the new model." We knew immediately.

Jess: Ah. Right. Which model it used?

Lada: Yeah. And cost also. Yeah.

Jess: I was going to ask you what you were wondering about when you said something about how could you make this knowledge of what it's doing less ephemeral.

Lada: Right. I think this is where I think we need a tool. I'm about to write something like that on my own. Because it feels like we need something observing what it's doing. I think that means maybe another LLM that keeps just everything what's going on and then you give it tasks and it abstracts, zooms out and maybe saves it somewhere.

So I almost want a high level, "here's what's going on in this stage." I can give you an example. It's not code related. It's weird.

Jess: Great.

Lada: Yeah. So me and Peter Koffler are doing something kind of crazy. So we are teaching AI to play Zork. Zork is a game from the 80s.

Jess: Oh yeah. Microsoft just open sourced it, right?

Lada: Yeah, yeah, exactly. Exactly. Cool. You saw it. So we're like, what does it even mean? Right? So here we're approaching something like what does it mean for us? So we're trying lots of crazy different things.

And one of the things that we saw is like, "okay, we're letting it run around. Maybe we built it an MCP and it's doing things." How do we know what it's up to? First thing would be nice to have a map. So can we build it a map? And then map is not enough because other things happened. Right. So what things happen? What do we care about?

Well, what items did it find? Or was there doors? And then there's keys and maybe we won't remember that there was a door and there's a key and we want it to remember. So it feels like we're kind of running into the same thing. We need views, high level views, something keeping track of what's going on and maybe recording that somewhere. And I maybe want a file or some kind of narration.

Jess: I always want to put it in a trace. Of course.

Lada: Yeah, a trace will be lovely. So we're kind of discovering that we need this and it feels extremely applicable to code because in code, " what happened?" What is the current goal that we're trying to do? What are the things we tried? Why did we decide something else? So all those kind of views. And it feels like we need those kind of summarizers to be able to keep up with it.

Jess: Oh yeah, that's a good point. Because I can run open hands agent and I can instrument that and I can get a trace of, "what did I say? What did it do? What tool did it call? What did it get back from that?" But you have a great point that on top of that, and maybe referencing that actually, a summary trace that's like conceptual that an agent could.

An agent could even go look at the original trace and say "okay, what actually was it doing here?" And make an interpretation and a narrative.

Lada: Precisely. Yeah. I almost want to write a re-prompter like this because I want to be like. I want at any point to kill the context and be able to reprompt immediately without doing it myself. So something keeping up with what's going on and then this is the next thing.

Jess: What do you mean re-prompt?

Lada: So I told AI what to do, I prompted it. Right? It does a thing and something happened here. At some point, if I clean the context completely, if I kill it, I need to start again or I need to continue. How do I continue? So this ability to continue Is we are at this point. This is what happened. This is what is needed next. Do that. This is kind of a re-prompting, like continuation of prompt.

Jess: Is it like resume in Claude Code?

Lada: It's not resume. Right. It's like what happens when you resume. So you open a new window, for example, or when you press start. Resume is basically continuation of the conversation.

Jess: Right. It's just pick up where you left off.

Lada: Yeah, yeah. I'm talking about kill the conversation, start a new one. And you were in the middle of things.

Jess: Oh, so like, this is like the, write a note for yourself for why did I go downstairs?

Lada: Yeah. But I want it at a fingertip every time. Every time. "This is what I was about to do next. This is what is needed next. How do I get this?" And I think it's doable. I think you can do it probably with local LLMs.

Jess: Okay.

Ken: When you said you were having it solve Zork it just like all-- By the way, my favorite thing when I was a kid was to play the text adventure games, because that was my age group. So I had all the Infocom adventures. But this is the same thing as saving your game and then coming back and restoring the game from a save point.

This is the same concept as like this, catch up. You know, do me a favor, catch up for me. Checkpoint for me. Catch up and move forward.

Jess: That's interesting because whenever people say, like, if you could have a superpower, what would it be? I always say saving my game. Because if I could make a save point right here, go try something. Be like, crap, I wish I had gotten up earlier and go back, then I could do so much. If I could actually learn from my mistakes and do something about it.

Lada: I love it.

Jess: But with our help, the agents have that. Right?

Lada: Yeah.

Jess: We are the administers of their superpower.

Lada: Absolutely. So I have several patterns about that. And I have several things I use as deliberately. Right? Because this is ability to try something.

So many people are like, oh, AI is really good at prototyping. And the way they think about prototyping is greenfield. Completely greenfield. Right? The first project. But it's not limited to that. There's several things you can do. Like, for example, the creator of Claude Code basically describes how he prototyped the to-do list feature. He created 20 prototypes in two days. All of them were tested by users.

Jess: Wow. So like live prototypes. Okay.

Ken: Wow.

Lada: Yeah.

Try all things is what you can do. Right? Try everything on a very local, small scale. And now you're so powerful because you're getting knowledge about your domain, about what's good, about what users prefer. This is actually using AI for good instead of just crazily producing code that is bad at crazy scale.

Jess: And that is a feedback loop that you wouldn't have if you couldn't generate the code super quickly.

Lada: That's true, that's true. And maybe it's a throwaway code, but that's fine. We learn. We can learn because we can try so many things. It's nuts.

Jess: Yeah. The output of the code, the desired result is the learning, not production. Yeah. That externalization of what I was about to do is something I need to do a lot. And then if you have the AI do it, I guess you get a save point.

Lada: Yeah, that's pretty much what I do as well. So with "try everything" and so on, one of the crazy things you can do with AI is also you don't know what you don't know and you can quickly get it to tell you what you don't know. Right?

So just by asking. And also, I really like the idea of seeing all paths. So, instead of taking all paths, you can make it show you all paths. I call it reverse direction.

Basically, one way to do this is it asks you, hey, what technologies do you want to use for this project? And you're like, well, what would you recommend given this task? And it shows you things and this is where you start thinking. You don't think at the first step, what technology is doing. You look at it, what it showed you and it gives you ideas.

And the more you see ideas, the more you get ideas. And because AI can generate ideas, I think it creates at scale and also so much the breadth. Right. It read the whole Internet. It doesn't remember the whole Internet, but it has a lot of ideas you haven't seen. So you can now show it to yourself and get more ideas.

Jess: Nice. And this is in contrast to. You're absolutely right. There's a trick here of not knowing things too early because as soon as you sound confident, it's going to reinforce that.

Lada: Yeah, that's right. Absolutely. It's got a latch onto it. And yeah, so that's a trap, actually. You can answer-inject it.

Jess: Answer injection. Nice.

Lada: Yeah. Limiting your answer with your question. I actually see it a lot. I've done it myself more than once.

Jess: You see it what?

Lada: I see people limiting themselves with basically the breadth of output, by the way they Ask questions.

Ken: Oh, okay.

Jess: And you have your instruction in there, "Please tell me if I'm like going to make a mistake."

Lada: And yeah, but that's not enough in this case because you're like. So one example on Hack For Good, which is like a hackathon we're at with Llewellyn, Woody and a few other people who are amazing, wonderful, this summer is--

So we're trying to do process emails from somebody's computer and we don't need anything complicated. But the way somebody prompted it was basically, hey, we need emails from computer. And the answers can be API, it can be server, it can be something else. Guess what answers it gave us. Suggestions?

API and something else. What it didn't give us is the thing we actually ended up using because I pushed it to say, what thing can be simpler than that? Give me the simplest answer you can think of.

And then it was like, "oh, you can just write a local script." And that was enough. And that was actually this kind of stuff is a difference between you getting things done and not. And sometimes in this case we, in three days , we solved two of their problems and got them funding.

Jess: Wow.

Lada: Yeah.

Jess: That was at Agile 2025, right?

Lada: Yeah.

Jess: Way back at the beginning, you said something about feedback loops. It was testing. It was about writing the test so that Claude can check its own work. I heard a great quote the other day. It was, "ask not what Claude code can generate for you, but what feedback loop you can generate for Claude Code." This was Willem van den Ende.

Lada: That's awesome.

Jess: Yeah, yeah. And of course we love feedback loops. That's why we're in observability. The more ways you can give it to know whether it's succeeding, the more it can do.

Lada: Yes.

Jess: And the more it can do with less supervision.

Lada: Yes, exactly. Exactly. Yeah. I think you're touching upon a thing that's also important. Like the agent also needs visibility. Right. Basically we're trying to be like, this is a little thing and you give it a little wish and you give it everything that it needs for that wish. And if you give it like small enough and all the information it needs, or you let it see things, then it does much better than without that.

Jess: Observability for the agent and of the agent.

Lada: I think your talk was great about MCPs, right? Where you point out that agents are also suddenly our clients too. And I love that.

Jess: Yay. Okay, we need to wrap up. Is there anything that you want to say or point people to?

Lada: I guess if you want to learn more about patterns or if you want to boost yourself in coding with agentic AI, you can watch my talk.

And there's going to be another one that I just did on AI Native DevCon. There'll be a recording soon, like in a week or so.

Jess: Nice.

Lada: Yeah, it has a little bit more that I missed in the first version. And you can go to the website or follow me on LinkedIn.

Ken: Wonderful.

Jess: Great. And we'll link to your LinkedIn. You're Lada Kesseler. Ken, is there anything else we should do before we wrap up?

Ken: No, I think that's it. But I just want to thank you because this is really fascinating and I think there's great stuff that you have here to mine and learn from.

So I know I'll be better at it once I read this stuff and follow along and try some of these techniques because I tend to do it more intuitively, which is going to burn you every time. You think, "I'm just going to vibe with it." Don't vibe with it.

Jess: That works after you figure out the patterns.

Ken: Right? Yeah, I think you're right.

Lada: I think that's also how you learn. Right? So what you described about vibe coding, like, that's what I did. Right? I had no idea what I'm doing.

Ken: It's a journey you're taking because you haven't talked to a thing like this. I haven't talked to a thing like this since Zork. I mean, seriously.

Lada: Yeah.

Jess: Lana, thank you so much. It's been great having you.

Lada: Thanks so much for having me. I appreciate the invitation.

Ken: Thank you.