# Agentic Coding: Ground Rules, Skills, and Refinement Loops

**Podcast:** The AI Native Dev - from Copilot today to AI Native Software Development tomorrow
**Published:** 2026-08-25

## Transcript

Whatever AI produces should be good from the first try and never the case.
So how do you get to quality?
You're fine.
This thing is only good at doing one thing at a time.
You have to almost give it permission to disagree and fight that in your rules.
Hey, tell me honest things.
Don't lie to me.
Don't try to please me.
When I started doing that, I noticed that I was like, ooh, it's less nice to me.
I call it like a centrifuge.
So basically the idea is like, you spin an AI so fast and stupid comes out.
The AI Native Dev is a podcast for developers and engineering leads at the cutting edge of AI and agentic coding.
Join your hosts, Guy Pagiani, and me, Simon Maple, every week as we chat with the most exciting voices in AI and tackle the biggest questions facing developers today.
This is the AI Native Dev.
Yesterday, you were writing code.
Today, you're prompting agents.
Tomorrow, you'll be running a software factory.
Argentic coding is moving fast enough to give anyone whiplash.
This June, AI DevCon London sold out.
Hundreds of developers, engineering leads and VPs packed in to hear speakers from Anthropic, OpenAI, Netlify and GitHub cut through the hype and get to what actually works.
This November, we're bringing it back to New York.
Bigger, bolder and full of people actually building the Argentic future.
Three days of real talks, real tools, real answers, whether you're directing the agents, building the loops themselves, leading the teams or setting the strategy.
Our early bird pricing ends on September 30th, so make sure you lock in your place before prices increase.
As a podcast listener, you can get 15% off your ticket using promo code POD15.
We have so much planned and we can't wait to have you join us in New York.
Hello and welcome to another episode of the AI Native Dev and we are shooting here on location in San Francisco.
We actually wanted to have a session with Lada Kessler a number of times actually and we tried to schedule it a number of times and then we bumped into each other in San Francisco at...
AI engineer in San Francisco.
And so we thought, hey, why don't we just do this in person?
So welcome to the podcast, Lada.
How are you?
I'm doing great.
Thank you so much for having me.
Oh, it's an absolute pleasure.
Now, Lada, you are working as a principal engineer at Logic 2020, right?
Tell us a little bit about that.
Yeah, basically, I'm working at a contracting company.
It's kind of a niche one.
Nowadays, we're all over the US and I get to go do a lot of various things.
Right now, I'm trying to do everything in my power to make sure that they are about EA.
Yeah, amazing.
And you, of course, gave a session at AI Native Dev.
Which one was that?
That was in New York last year, wasn't it?
In November last year.
really loved by all of our attendees.
You got some super high scores.
I remember I was chatting with Patrick afterwards and he was like, we have to get Larder back.
We have to get Larder back.
So yeah, we'll see what we can do for this year.
But it's wonderful to have you on the podcast.
And by the way, we are, today is the 1st of July.
It's currently 10 a.m., just gone 10 past 10 in San Francisco.
And England are playing live and they're playing so poorly.
It's actually 1-0 to Congo DR right now.
They're playing so poorly.
Let's not watch the second half here.
Let's have a podcast.
That'll be more interesting.
But we'll keep you up to date on scores as we go.
We're still watching them.
Well, we have the kind of score there, but we're not watching the game.
That would be rude.
That would be rude.
So tell us a little bit about your involvement with AI.
How are you using AI today in your day-to-day or your hobby work?
Pretty much completely at this point.
Not just software development.
So I do pretty much everything with AI or the majority of things I do with AI.
So it starts with code, obviously.
And then I do a lot of code that the systems I code have potentially some agents in there as well, but not always.
What I'm actually passionate about is figuring out how to get the coding bit.
And I find that oftentimes when you're actually working with a coding agent, you also get much better intuition to how to write authentic systems.
So I think it's very, very much linked.
But then things I do on top of that are like, so I do a lot of note taking with AI, but like I used to be very disorganized and like Obsidian and things like that didn't work for me very well.
But now I have basically a folder where I have a drop folder where I have my notes and it has a system of organizing things for me.
So I'm like, hey.
process today's notes and goes on like, okay, ask me some questions sometimes or like organize it.
And so now I'm like, oh, so well organized.
I like that.
I've totally just built this for myself as well.
So I actually connected it with Slack, my granola notes.
I've completely opened up now.
It knows everything about me and it tells me what to do.
And it's like, you know, what should I do today and things like that.
So it's good to see it's not just me.
So far, I'm restricting it from.
accessing my email.
I'm trying very hard not to go this way because I know its temptation is there.
I even allow it to write some of my emails, but I haven't yet got to the stage where I'm comfortable with it sending at all.
And when it does write my emails, I tell it what I want to write and it just words it for me.
And then I go into that and kind of like adapt.
But it's curious the path that we're all on here and how much we're relying on this to almost be our...
We initially focus on the code that we review very heavily and we're probably going to see exactly the same levels of validation and verification in the way that we present ourselves as well.
So if I write an email, that's me talking to someone else and they're expecting that email to come from me.
And so I want that to be validated to make sure it's not just AI slot that's being sent.
Otherwise, it's giving me a bad reputation by me sending shocking content to someone else.
for me to expect someone else to read some AI slot that I've generated.
That's very rude.
So let's talk a little bit more about that because by default, agents aren't always the best at nailing something that we want.
So how much does the enablement of agents matter?
Basically, I think about it as AI comes with defaults that are not very helpful and you kind of have to adjust them.
in your systems.
So one way to do this is basically, so they all have like this thing that I call ground rules.
Basically, this is your cloud MD or something like that.
And you can basically define, here's my, here's the thing that's most important for me.
Like you need to be careful to not just put everything in your history and your TDD process and you like everything else in there because it also has to, not enough memory, right?
And your ground rules there, when you talk about your ground rules, how much of that is specific to the project versus almost like more your organization or your preferred way of development that you can just share across all your projects?
All right.
So I have both levels, right?
So first of all, my big one that is applied to everything, this is like the ground rules that are fighting the most problematic things that I see across all the AIs, no matter when they are.
on several things.
So, for example, if you think about, like, so we're dealing with a black box.
We don't know what's inside.
There's a mental model of some sort in there.
When you talk to it, it understands something, but it's completely invisible.
You don't know what's going on.
And it's also, like, trained.
on purpose to please you, right?
So what I have a lot in my ground rules is like, hey, you actually, like, you have to almost give it permission to disagree and fight that in your rules.
So that's what I do.
One of the things is like, hey, tell me honest things.
Like, don't lie to me.
Don't try to please me.
Does it follow those?
Because it almost feels like that's a little bit like prompt engineering, right?
It's much better.
So when I started doing that, I noticed that I was like, ooh.
it's less nice to me.
It feels less nice.
Like this initial like it's actually being like, oh, you're so great and so on.
Like I have allergies to this too.
Like I think I have, I need therapy for this at this point.
But like I noticed the job.
It was substantial.
And now it's actually like before the latest opuses, it was pretty great.
Nowadays it also like tells me that it's being honest, which is really annoying.
It's like honestly speaking, like, oh my God, stop doing this.
So, yeah, and then I have productivity rules, and productivity rules are basically, hey, if you notice some problem, tell me now, and don't actually commit to the thing I said.
And so those are like checkpoints?
Or does it naturally do that as part of everything?
So two folds, right?
So first of all, it's in my ground rules.
This is basic, like, here's our contract.
Here's how we work with LADA.
And also I have to reinforce it, or I have to do checklists when I do the work on time.
I kind of feel like I need both layers.
Depending on the size of context, the second thing helps a lot as well.
And where do you put all that?
Did you mention you put that in your ClaudeMD?
Yeah, the basic ground rules are in ClaudeMD in the user level for everything.
But like my ClaudeMD, I know every line there.
It's 72 lines, and I'm very careful about how much stuff in there.
And then unlike system prompts, it feels like Antropic just puts a lot of things in the system prompts.
It's a bit, yeah, not great.
But yeah, I also have things on like I slash commands when we're just in vogue in time.
I sometimes have some things on the project level, but I'm careful what I put there again.
And I'm more like, here's a menu of what you have.
And then here's a way you discover more.
It's more skill-like, right?
Something like that.
And it's more of a progressive disclosure.
In terms of skills, what kind of skills do you feel like you rely on most heavily in your day-to-day engineering?
TDD, I think, is the best one.
So why is TDD not?
TDD is presumably a one-liner in your ClaudeMD, and then...
No.
Oh, it isn't?
No, it's a scale right now.
It's a scale.
It used to be a slash command.
So many people are saying, oh, TDD doesn't work with AI.
And when asked, how are you holding it?
And they're like, oh, we just tell it to TDD, and it doesn't, because it doesn't work, right?
What works really well is what...
What I have is basically a process.
Hey, do this, do this, then do this, and do this.
And basically, how I got to it is I basically TDD'd with it for a session.
And then I was like, hey, record everything we just did.
So I micromanaged it at first and then record everything they had.
Now I have it outside.
Now I say, hey, clear session.
Let's TDD.
And I watch everything where it messes up, and I correct.
So you ask it to TDD?
I asked the TDD.
Okay, so I was expecting a one-liner in your ClaudeMD that says make sure you always do follow the TDD rules and then a skill that explains the TDD rules.
But if you're explicitly invoking it to do TDD, you're kind of in control.
No, it's a little bit of both.
So I have like, basically, I have some rules about code, but not too much in my main thing.
Mostly like, I like simple things.
If you can...
do things more simply, prefer that.
We prefer that to hockey solutions and stuff like that.
But with TDD, basically, I have a skill, right?
And the skill basically has this little front matter at the top, right?
And that's the thing, actually, that's written for the agent, for it to know when to invoke it.
And the whole point is, like, unlike the old MCPs that just, you know, shopped all the instructions for itself in your context and just garbaged it completely, you have just this little thing over there.
And then the agent sees this and is like, oh.
I have a TDD skill.
I'm supposed to do it every time I write code.
Oh, so basically I have that.
And that's what makes it automatically do TDD.
That's right.
That's the activation, right?
And that's the bit, I think the description is the piece that most developers, when they look at a description, they think it's almost like, that's for humans.
Yes, and it's absolutely not for humans.
Yeah, they will write a very lightweight description.
And they completely mess up how that skill then gets activated.
Exactly.
So that's how the agent...
determines whether it should use that skill or not.
Exactly.
And when you have many, many skills, it's also there to help the agent decide.
And if they're very generic, then they're going to overlap so, so much.
The agent's got no chance.
Precisely, precisely.
That's why I have like a skill factory basically that focuses on that explicitly because I find that entropic default one doesn't work very well.
And I see like many lines of in front matter.
It produces like all this kind of stuff.
It feels like it's not good.
So I basically have like a, one of the processes in the Skill Factory is like, hey, iterate over this and in this context, like this is what it's supposed to be like and try many times and like go into that direction.
Is it good enough?
And then it shows it to you and it's usually much better than the defaults.
Nice.
So it's just an iterative way of making sure it's concise.
I call a thing into a file.
So basically this is a refinement loop.
This is just super powerful.
So the process goes like this.
You basically have a goal, some goal with AI.
It doesn't matter what.
Then you have it take one step towards the destination you want.
Just one step, which is really important.
And then you commit or you put it into a file.
So, for example, I actually write with AI.
And I'm a bit scared to say that because so many people are making a point to say that they are not writing with AI.
Because I think it's expected that whatever you produce at this point is, first of all, not your voice and slop.
When you say write, like author?
Like, write something.
I don't know, like, things for conferences, for example.
Like, a little blob for myself.
I would write with the AI.
And the end result is much better, but, like, it's so much my work.
There's so much more my work there.
But, like, the way I get to that is, like, hey, here's a thing, drafty things, thoughts, like, maybe something.
I don't like this.
I quite like this.
Go iterate.
Go think into a file.
I call it go meditate.
Yeah.
And basically, it writes the first iteration into a file.
And I say, stop.
Read it back.
here's the goal still.
Is it good enough or is it something to tweak?
Write it back and so on.
So I have like seven, it goes on like, I call it like a centrifuge.
So basically that is like, you spin an eye so fast and stupid comes out.
Yeah, I love it, love it.
Yeah, that's really interesting.
And I think actually, I do exactly the same from the point of view.
I use it to write a lot.
And I feel guilty as well when I'm like, you know, if I send this to someone, do I need to DLLMify the text so that it feels like someone thinks I wrote it myself?
you know, it's the guidance that we add in and the direction that we add in and the reading it and telling it, no, this is wrong, that's right.
That's what is the important piece rather than the fact that we're writing every single word or not.
I think there's an amount of us as humans that need to kind of like get over that mental barrier of that.
I think a lot of people, if they say they're not doing any of that with AI, they're probably lying to themselves a little bit more in terms of...
Maybe.
Maybe they're trying to make a point of not doing that for real.
Perhaps.
And maybe that's a good thing.
I think there's just like this...
this expectation that I see a lot of people having, which is like whatever AI produces should be good from the first try and never the case.
It's just never the case.
So let's stop expecting that.
So how do you get to quality?
You refine.
So this kind of processes of refining it together with human input, a lot of steering.
So I have basically a lot of centrifuge and, okay, I don't quite like this.
This doesn't sound quite right.
Go meditate again.
And so on.
And after like five loops of that, I'm at a place where it actually sounds much more like me than I would have done myself, I think.
I can hear in Tom's head right now, he's thinking, how do I put Simon into a centrifuge right now to get the stupid out of him?
But that's another question.
But let's talk a little bit about, in order to get the best out of AI, it's super important to understand the problems.
Right.
Understanding the problems and working around those problems or circumventing those problems will help us get that better solution.
So let's think more about coding now.
What would you say are the most common problems in and around coding agents that we should understand better so that we can actually produce a better output?
I think there's twofold.
So I think...
So going a little bit back to what we discussed about the problems with AI.
So there's some problems with AI.
And I found that there's some problems with mental expectations of people around how AI is supposed to work.
So a lot of things I see right now, especially new people, when they come into it, they're like, oh, there's ground rules.
I'm just going to put everything I care about there.
So let's just put my TDD process.
Let's just put all my...
best practices and do this and make sure not to screw up and make no mistakes and do this.
So the thing is that that thing doesn't work this way in practice.
Like I'm not training models.
So I actually am getting more and more curious about how they work internally.
But it feels like they have a concept of attention.
And that's probably the biggest thing that I see people not understanding.
So even like yesterday, that was an interesting.
Interesting, really, really good talk from HumanLayer.
Two talks from HumanLayer.
I really like them both.
And one of the things that I was disagreeing with was that the person was like, Dax, not the person.
He was like, AI, if AI knew how to write good code, it would have done it.
And I think that's so wrong.
Because what I see a lot is basically, so people are trying to say, hey, write me, do this task for me, first of all, this is a task, and also uphold my standards.
And they add a lot of things on top here.
So in my experience, that doesn't work.
And I think why it doesn't work is because this thing is only good at doing one thing at a time.
So you can't expect to just enforce your standards like this way.
So what you do instead, that works amazingly well.
And he was basically, he is something that he knows so much about this, right?
But he's like, if AI knew how to code, write good code, it would have done it.
Thing is, if you go and ask AI after it read something to find all the problems with it, it will.
And if you go into different directions, you can get so much better reports about what's wrong.
And you get it to fix it there.
But you don't do it in one go.
You do it in many goes.
This resonates so, so much.
It actually reminds me that this week we actually launched Tesla Agent.
And I'll mention this for one reason that there's a cool, really cool thing that I love called Verifies in Tesla Agent.
And you can use Tesla Agent to kind of like kick off code reviews.
We have a basic, well not a basic, it's a reasonable code review in there as well.
And so you can use it to kick off your code review.
Now, in your code review, you might have 100 things that you're trying to check for.
And if you say go and do a code review, it'll do a reasonable job.
Superficial.
Yeah, exactly.
If you look through every single piece, you might think, oh, actually, you didn't do this.
Whereas if I was to say to an agent, just do that, it will do it and it will do it well.
Now, a verifier is very interesting because it takes a very specific thing and sometimes triggers deterministically on various files.
I can't get a front end file to do this on or whatever.
And it will say, did you, you know, can you check, can you verify that you're adhering to these standards?
And maybe it even points to the standards in the skill.
And it will go back and it will do that.
And when you have each of those verifiers that are all doing that, you actually get a far, far better result.
faster as well because it's the verifiers are like I say deterministically triggered and they run very short kind of like processes.
Really, really interesting that.
really backs up what you're kind of saying.
That's like very similar experiences.
I think I'm going in a similar direction with friends.
Like we're doing something similar.
So we have deterministic triggers that detect some code smells like long method or dead code.
Then it triggers something and then that thing can be pluggable.
So it can be like, hey, plug an agent to that to be like, hey, here's a prompt to do this for long methods.
Here's a long method.
Let's make it better.
And here's how recipes.
So one focused.
do this or it may be invoking a linter or a formatter even right so i'm trying to do as much automation there as was possible as well yeah and focus i think is something on what you said yeah absolutely yeah let's now maybe turn more practical uh and if we think about um you know various um kind of methods of of writing software um before ai as well this was potentially a problem, we would, you know, even by myself at times, would just think, oh yeah, I know what I'm doing here.
And I just write, just knock out as many lines of code and, you know, say, here's the app.
I didn't even need to think about it.
And sometimes that works.
Now with agents, we can do that like that.
We can do it very, very fast and just say, this is what I want.
Just go and do it.
But in larger systems, maybe we need to think about that a little bit more.
Maybe we need to plan it and architect it.
And I know you do a little bit of architecture in your role as well.
You play with architecture as well as engineering.
So what's the right process as an engineer to approach a larger, more complex task?
Do we just go to the agent and do like a...
you know, rapidly developed application first, prototype then do architecture, should we whiteboard first?
What's the approach you use?
It depends so much on what's going on, right?
And how much I understand the problem is the biggest thing here, the biggest variety of what I would actually do.
So for established projects, I would usually go talk to AI and like prototype things together.
So there's a whole prototyping session before.
And then I tend to...
In plan mode thinking together or just like knocking an app out and learning through...
It's a lot of back and forth and I asked it to produce me artifacts.
So like I really like HTML right now.
So it produced me HTML artifacts and I can comment on each individual one and then I can send all that feedback to the agent and it's much easier.
It's like a whiteboard a little bit.
So more and more like I want this whiteboard.
with agent and I'm trying to build one as well but like that works pretty well on the established thing or things that I understand.
I also have another process entirely for the things I don't understand because I find sometimes like oh we're trying to do this thing neither the person I'm doing it with nor me have a good understanding of the problem space yet.
So let's not even just go coding at all because like when if you start coding you're like over committing to a specific path just this one and you're blind to the other varieties and you're like you're so focused on solutioning early on that you like forget about like what are you actually trying to do and maybe there's a better solution over here maybe it's a completely different solution that wants to come out but you're not looking at the problem yet so I see so many people looking at the jumping into solutioning before thinking through the problem So one thing I do with some people that was pretty fun is like I call it basically like a sketch prototype.
I don't know, it's marked down.
Basically, I take my code and I replace it with an agent.
In no way put it into production, please, ever.
But basically, this is for very draft.
So basically, and the code is instructions in a file.
So my whole system is markdown file plus agent and the agent goes through processes and I get to experience the user experience from that and I learn so much.
So basically then I actually commit to code or like go into some different directions.
So that's been working pretty well in some cases.
You're essentially the user trying to understand how a user would go through that and then from that.
And the agent basically can be standing for code, for any code whatsoever, if you want to.
But it won't be deterministic, it won't be good, but I don't need good at this point.
So it's almost like you're mocking the code, you're mocking with an agent.
Yeah, it's like a pretend, it's like your paper prototypes used to do, but it's much faster and much easier.
Yeah, very interesting.
And when, obviously, from an architecture point of view...
A lot of people talk about, and myself included, talk about how developers are kind of more going to be driving teams of agents and moving more into the kind of, I guess, the architecture style role.
Why can't an AI do good architecture?
So it might, on a scope of like one specific task, do a pretty good job.
But what I find is like, there's two problems, right?
First of all, oftentimes we're not able to keep up with it, right?
So the question is like, many people are doing different things, but many people don't read code.
And many people, are, I think, finding a vacuum in their heads.
Like, where there used to be a problem and solution space, there's now nothing.
But I know that if you just let something happen, it will probably degrade, you know?
We live in the universe where entropy is a thing.
AI kind of does a decent job maybe if you do the iteration on one task, but then it can't hold everything in his brain.
It can't do all the things all at once, right?
We discussed, right?
So maybe you can iterate and like, I haven't figured this out with AI definitely, but maybe you can like run several iteration loops and think about this, think about that on this level.
And you have to do it on different levels of architecture, right?
And you can't just do it on one.
Yeah.
Yeah, even like on this scope, it's too much.
So it's a problem of complexity management, I think, quite a lot.
And also like holding this mental model.
And I don't know who holds this mental model right now.
So I kind of have to.
And do you see that long term, short term?
Like how?
I know it's really hard to actually.
It's a tough question because it's impossible to really guess.
what's going to happen in three months.
But I'll ask anyway, because I can do that as a host.
How close do you feel we are to AI actually being able to do a good enough job, which is the danger, right?
Because as soon as it can do a good enough job, 80% of the time, it'll try it and do it.
All right.
I have no idea about timescales and what will happen.
It feels like we're building a system that builds other systems right now.
Yes.
Yeah.
It very much goes.
And it feels so tempting and it feels so interesting right now.
It's like the most interesting problem out there, I think, at least for me, to build that system.
And like, can I bake my engineering practices into that system so it does all this stuff for me?
So I actually build things, but on a high level, I think that was an allure that people were trying to get to for a long time.
I think it actually might be reachable.
I don't know if it's reachable.
So there's some problems that I think aren't solved right now.
Will they be solved?
Maybe.
Especially if we find something else that works much better and can actually learn as we go.
If you're enjoying the podcast and want us to continue to bring you the very best content, please do us a favour and hit that subscribe button.
It really does make a difference and lets us continue to improve the quality of our guests and build an even better product for you.
All right, back to the episode.
So a quick game update.
Harry Kane just scored in the 75th minute.
So it's one all.
England still have a chance.
Go England.
Let's get back to practical matters.
Let's talk about maybe some other tips of what you think developers should be doing, could be doing, that they tend not to naturally do in their agentic coding.
Right.
I think what I see a lot of people are...
I think it sounds like a conversation.
You're having a conversation, so you kind of behave like a conversation.
So it asks a question and you're like, oh yeah, sure, let me answer you, AI.
And I feel like many people are not thinking high level and like, hey, you don't have to actually go where it asks you to go.
You actually can steer quite a lot.
So I call it reverse direction.
You basically decide, like, you're the decider here.
You don't have to uphold.
And also, you don't like something that the AI does.
Like, it gives you a list of, like, 10 questions, and some people sit there and answer every one of them.
This is so painful.
Don't.
Like, one at once, or HTML with all the files, much, much easier.
So it's kind of steering.
Another thing I see people not doing is, like, using it almost like an instrument of vision, I find.
Because, like, what I do with it a lot is...
I was just at a craft conference and Goiko Adjic, I hope I didn't murder his name horribly just now, but he has an amazing talk and one of the points that he was making, it's much easier to complain than to explain what you want.
So like seeing something helps you understand what you want and it's just much easier.
So like have it show you something and then it's...
much easier to see what you're not like.
You get more ideas.
You can borrow different ideas, combine them, and you can go into a different direction entirely by just doing that.
And a lot of it is like, I think about it as like, imagine I'm at a crossroad with many, many, many, many paths before me.
Right now they're invisible to me, but AI can make them visible to me at zero cost.
Show me all alternatives that are in front of me.
One thing that I really like is like, When you have a choice that you have to make, give me a choice.
Like, choose yourself.
Show me with a little emoji.
Like, I have a star emoji.
This is a chosen option very succinctly.
And then choose me the paths that are not taken.
Yeah.
Very nice.
I was doing it for a long time kind of manually, but then Arlo Belshi showed me this trick that he's doing it on one move.
So basically, this is like four patterns at least applied all together.
And then I can basically like, oh, this is the decisions before me.
I want this one.
No, no, AI, you're actually wrong.
This one is good because blah, and so on.
So I can go into that direction now.
And I actually broadened my horizon, what I don't know before me.
Looked into that briefly.
No, not good.
Go there.
It's very similar to kind of like, we're doing a lot right now thinking about, sorry to bring it back to Tesla Agent, but in Tesla Agent, we have this change risk.
And the key is it will determine, or it will try to determine whether a change is high enough risk.
to be to be raised to say hey this needs human review or whether it can is good enough to do LLM review and I think it's it kind of like makes me think about you know we use LLM as a judge for a lot of things and it's it's it's almost as it builds it might be nice to essentially say hey this is a this is an important decision that I think you need to make versus this is an important decision that I need you to know that I have made and you just need to kind of like look through it, check it over and just say, yeah, I'm fine with it.
It then avoids that almost needless at times, you know, back and forth and that too much interaction.
Yeah, exactly.
So I run into this a lot as well.
So like a lot of my conversation have started to seem like the same thing, right?
So what I have like a default, right?
So like my default technology stack is this.
Let's just do all of that every time.
Let's not just decide it every time.
Right.
And also like when you say AI review versus human, you like, why not both?
Right.
So absolutely get AI to spin all the stupid out and then do human and make sure that the AI positions it in a way that's easy for human to follow because it's not easy right now.
So in that case, is there almost like an...
feel an overload of review?
Yeah, absolutely.
Or do you almost feel like it's...
I don't let myself to go there, right?
I don't let it.
So what I do is basically, there's two folds.
I think it's important to be able to answer a question.
To me, it's important.
Does my system work, right?
And for that, first of all, I have tests.
I have tests on tool levels.
I have BDD tests.
I have TDD tests, right?
TDD tests are for agent.
This is a cross-check against reality.
So this is not letting it go too far from reality.
It also is helping in...
First of all, it produces pretty good code, surprisingly.
So, like, I would love to go there a little bit further about that.
And then it also...
It also makes sure my tests are not...
completely horrible because like when you have AI write tests, a big danger, like I trust my AI with my tests even less than I trust it with my code.
Right.
Because I absolutely would cheat and lie and do horrible things there.
Yes.
And common tests, which is like a crime scene, like it should be punished by something bad.
Yeah.
So, okay, I have this TDD stuff.
This is for agent mostly and for code quality and so on and check against reality.
And then I have VDD tests that are about, does my system work?
Right.
And I want them high level.
I don't want them, like, I don't even want them on Cucumber level because Cucumber feels too detailed for me.
So what I do a lot is, like, I write BDD level tests.
I basically write, like, a little whiteboard-y domain language.
So, like, how do I think about this problem?
Make it extremely scannable so I can look at my tests.
Are they complete?
Like, and I see things like...
Depends on the domain, but if I do API, I see here's my API, here's what happened, that's what API returned, for example.
And it's all a bunch of tests like this.
Or if it's more visual, it's a game.
So if somebody made this move, this is what happened.
So I want to see that, and I want to make sure that this is not something that agent can edit very easily.
But this internal stuff, he can edit as much as it can.
And your BDD style test, does it use a similar...
Gherkin style approach to...
No, I use approval tests pretty much.
Is it deterministic?
No, absolutely.
100%.
So even when you read it, you can rely that those tests aren't going to be...
Online to me.
Absolutely.
That's crucial, right?
Yeah.
That's crucial.
I use approval tests for that, basically.
This is a good technique to know for legacy code if you're trying to pin the...
behavior, you basically can be like, hey, what does this thing return when I do this?
And it outputs, and you say, oh yeah, it looks good.
This is a golden standard.
So approval test, you approve this.
There's a little bit of risk to that.
You need to be careful what you're approving.
But basically, you can pin your whole system, and then you can refactor inside.
That's one of the ways to use this.
And I use approval testing for this kind of BDD-level test as well.
It's very easy to define the many languages there.
Yeah, amazing.
We've covered the low level.
Really nice practical tips there for engineers to listen to and follow.
Let's take it one step higher now.
Let's talk a little bit about patterns and maybe kind of like a little bit more about your environment to how you actually build.
So software factories.
First of all, what's your thoughts on software factories?
Is it a destination for you?
Do you believe it's a destination?
And I guess if you do, where are you on that journey right now to becoming a software factory?
Worker.
I'm not to be a worker.
I'm to be like an architect.
I'm a software factory architect.
When I said factory, I thought, oh, a factory worker.
It's like a software factory worker.
Developers.
Yeah, the agents are the software factory workers.
Exactly, exactly.
Well, yeah, I don't know, actually.
So I think, so we're building the system that builds other systems.
Does it work like a software factory like we see today?
I don't think so.
But I think we're trying to figure it out.
What I don't like in many approaches that I see right now is they're kind of a little bit of throw-eye at AI.
So basically, like, let's create agents to create more agents to create more agents and so on.
Or let's create agents, let's make agents write skills to write skills and, like, all of that craziness.
And what I see a lot is, like, it degrades so badly.
Like, the output is just completely garbage, and there's a lot of it, and there's a bunch of noise.
So I don't know how people are not, I'm not drowning in garbage in those.
Maybe I'm just not.
like doing a try, I haven't tried to be fair.
I've tried a little bit of this approach, like I tried like the Cloudflow, right?
And in the problem that I tried many other, so I have like a default problem that gives agents like, hey, new model, try this.
And I see the result.
And it's nice because I have a constant that I compare things against.
And the Cloudflow, in my experience, did the worst job of them all.
Ah, really?
Yes, at the time.
Maybe I wasn't holding it right.
But so I see the problem of like, if you have the building blocks that you're relying on that are not actually doing the thing you think they should be doing, why do you think the whole system works?
How?
So there's a level of autonomy here, I guess, which is the key, whereby...
do you leave the factory to kind of like build and almost maintain itself?
Or do you allow the factory to kind of make suggestions whereby everything or the most important pieces need to be validated and verified by a human to say, yeah, this is actually a good move or this is the direction I want it to go in.
So there's probably, you know, levels of self-building factory versus, I guess, you architecting the factory to build code.
I have no idea, actually.
So I'm really curious about this.
I overheard somebody talking about their factory from Gastown, I think.
Oh, Steve, you're going to.
Gas City.
Yeah.
No, no, no.
Somebody from Gas City.
And it was interesting.
So I absolutely jumped into the conversation and asked, like, hey.
Tell me in practice how you're actually working.
How do you deal with this?
How do you deal with that?
It was very interesting because actually a lot of things he said was kind of matching my experience with refactoring.
So I have my refactoring process that I just point out things and they go in a good direction for me.
And so a lot of that made sense.
So I'm super curious about factories.
What I'm trying to do myself, and I think I will believe in factory that I build myself while it actually, like with my standards.
But what I'm trying to do is I'm trying to get to the building block that I can trust.
So this is where my refactoring process comes in.
Can I have a refactoring process?
I can point at a piece of code, several files perhaps, and it will just go away, does a good job, I come back to good code.
And I have that now.
So that's nice.
And I'm trying to kind of, can I do this for extracting the knowledge?
So right now if I ask AI to save something into a file, it oftentimes does a very bad job at it.
Like too much noise or over...
like focuses on something that's not important in a broader context and all that.
How do we get it to extract knowledge?
So I'm playing a lot of that stuff.
So kind of trying to build those building blocks and then maybe I can construct them into something automated that I can actually trust.
But I need such level of verification here and I want to automate as much stuff needs to be code as possible here, I think.
So that's where I'm at.
I'm not there.
I'm dissatisfied with my process.
It works pretty well for what I'm doing, but I'm constantly dissatisfied and I'm looking for more.
That's why I'm the conference.
I think that's the key though, right?
It's about knowing you're dissatisfied where you want to improve and then over time, it's a gradual.
I think people who think they can just switch into a software factory.
They will drown in garbage.
They're living a dream.
It's not a good dream, I think.
Yeah, it's a nightmare.
Sorry, they're living a nightmare.
They're dreaming about how fast they can grow.
It's about, and I think in order to gain that trust over time as well, it's about gradual.
increments and improvements.
That's why Dex Horty's talk yesterday was so interesting, because he was like, hey, we tried this factory thing for half a year, it doesn't freaking work.
Now we're going back to this.
And I want to listen to those people.
Yeah, yeah.
The people who have tried, the people who have got experiences.
Talking of factories, there's also, have you had a guy called Harry Kane?
Say it again?
Harry Kane?
Say the whole thing.
Harry Kane.
Patrick Dubois in the background is laughing right now.
But Harry Kane is a gold factory, and he's just put...
England 2-1 up against Congo DR.
So I think we like him very much.
We like him very much.
He's an amazing person.
I can't believe I'm so excited.
I thought this was gonna be a five nil walk over.
But you know, everyone's a potential banana skin.
But let's talk about your tooling and workflows.
terminals, IDEs?
How do you like to...
No, no, no.
No IDEs.
So, like, I started very early on with agents.
And, like, basically I was a month late to the party.
So, like, November when this started, I started in December.
And I was in Winsurf.
And immediately I was unhappy because I was, I'm in love with IntelliJ, or I used to be in love with IntelliJ.
Refactoring tools, unprecedented, like, there's just nothing compares in the industry, right?
And I can do crazy things with this.
And then I have this windsurf thing with Agent, where Agent lives, right?
So now I have to switch between this and this constantly.
And I'm like, no, I just want to be in the project.
I just want to talk to you.
Why am I locked into this thing?
So as soon as Cloud Code became a real thing, which to me happened in May last year.
I switched and never looked back.
So console only, pretty much.
I just barely look at files sometimes.
And I use IDE basically as a text editor.
Do you feel more disconnected from the code as a result?
Or do you still kind of look back at it?
It depends.
It's a trust thing as well, right?
Absolutely.
And it's trust because it depends on the level of risk, right?
So what are you dealing with?
I'm right now not in the, you know...
the gory and the bad.
I'm actually very much greenfieldy.
A lot of prototyping, a lot of other things.
If I was in the brown field, I would behave very differently, I think.
How would I behave?
I don't know.
I think I would automate the heck out of that.
I would make sure my test suit is something that's really, really good, that is super fast, right?
And this is where the skills come in.
My value is there, right?
Teach the agent to do the test suit that is just like this.
And then probably then I can actually go a little bit higher level maybe.
But still I would be much closer to the code.
Right now I don't need to do that.
So I don't.
Awesome.
We're coming close to wrapping up.
We have about, I'd say, five minutes of injury time before the final whistle.
So before the final whistle, let's wrap up by asking, I guess, when we talk about where you are experimenting next.
What are the things that, you know, when you leave the conference, you're going to be super excited to try to play with and explore?
I'm super interested in so many things.
And there's only one me, unfortunately.
But you need to use more agents to explore and be your brain.
Yeah, totally.
Yeah.
So, yeah, I'm definitely the bottleneck.
I'm feeling it.
like acutely.
But yeah, one of the things I really want to understand is how people are doing loops and how I'm doing, like how do I do loops better?
Because I'm doing loops a lot, but like I think I'm doing it differently than people are doing.
So I'm very curious to just be exposed to a lot of like different ways of doing things and trying them out.
Another thing that's been on the radar for a long time is like this event sourcing and event modeling.
So I took a class from Martin Dilger a little while back and I unfortunately didn't, didn't have time to actually try it out.
But it had a promise of something that was...
His process is pretty great.
So it feels like it solves a problem of keeping up in the complexity management all at once.
So it's very interesting.
There's some trade-offs on top of that.
But basically what he's doing is he's doing event modeling, which means he thinks through the process and he writes these little diagrams of what's happening.
And then...
Each one is like the slices.
So basically this piece of behavior does that.
And then he generates the code for them.
Slices are completely isolated, which means there's a lot of duplicated code, but it doesn't matter because it never overlaps.
Not ever.
Right.
And then what does it matter that you created like two objects person?
Yeah.
If it doesn't overlap ever.
I'm not sure how it works in practice.
I'm a little bit worried.
about some things, plus like events, so he does events sourcing, which is basically don't collapse your state, right?
You have events for everything, then you can unwrap and you can do so many things there.
So then you have views basically for everything that UI needs, which is kind of constructed aggregation views and also very many of those.
So this is like very many of those, which looks like code duplication worries me, but I want to try it.
and see because he seems to be very happy and I think he's solved basically from what he says it feels like that solves a lot of problems so I'm going to try it out as well.
Sounds good and great things for our audience to listen to as well and try out.
Lada, this has been wonderful.
Thank you very much.
I'm so glad we managed to do this in person.
Thank you so much for sharing all your insights and your ways of working with our audience.
It's been a pleasure chatting.
Very much appreciate it.
Thanks so much.
I'm so happy that England won.
I know.
Full time is almost upon us all.
So that's great.
Thank you so much.
Fantastic.
Thank you.
Wonderful.
I hope you enjoyed that conversation.
Really lovely insights.
And tune in to the next episode soon.
Bye for now.
The AI Native Dev is brought to you by TESL, the package manager for skills and context.
Your hosts are Guy Pajani and me, Simon Maple.
Our producer is Tom Dowler.
The AI Native Dev is not just a podcast, it's a community.
And we host monthly meetups at the TESL offices in central London.
Visit tesl.io forward slash community to learn more.
And I hope to see you there.