The Most Important AI Coding Advice You Haven’t Heard Yet

This article is also published as a video on the Modern Software Engineering Channel

You’ll have heard Dave Farley talking about the benefits of using ATDD – Acceptance Test Driven Development – to specify and control development with agentic AI. Today I’m looking more closely at the inner loop of TDD. Is it a good idea to force the agent to use a strict red – green – refactor for the lowest level of code design? Does code quality improve and is it worth it?

Based on conversations with product owners and business people you outline scenarios and features and examples. This sets you up for success, building the right thing. You also need to build the thing right, which is where the inner loop Test-Driven Development comes in.

Today I’m interviewing an expert TDD practitioner and early adopter of agentic AI – Nizar Selander. Nizar is a software architect and consultant with Factor10. Recently I’ve been talking with quite a few technical coaches about how AI has changed their approach to inner loop TDD, and it seems to me there is a lot of variety and innovation going on. Nizar is one of those innovators.

I asked Nizar to explain why TDD is still important when we’re using agentic AI.

Nizar: “So it’s still important for the same reasons as before. For me personally, it’s about confidence. It gives me the confidence to make changes at a productive pace without losing my sanity.“

Nizar has created a couple of tools to use with agentic AI. I asked him why he created TDD Guard for his coding agent.

Nizar: “So at first, I started by basically giving it instructions, just like everyone does. Follow TDD, do this and that. And it kind of works. But soon enough, the agents start reaching for shortcuts. They’ll skip steps, over-implement, things like that. and I had to go and remind them again over and over. And that’s just not something I wanted to put my time and effort into. So soon enough, I started looking into a way to basically automate this enforcement of the TDD cycle.”

TDD Guard was Nizar’s first solution to force an agent to do proper TDD. He went on to create a follow up tool, Probity, which we’re going to see a demo of in a minute. I asked Nizar to explain why he went on to create it.

Nizar: “TDD Guard worked great, but I kept finding myself policing agents on things that don’t have anything to do with TDD. Things like agents try to disable lint rules instead of fixing the issues, or they would try to commit changes before they run the checks that I want them to check to run. And also, TDD Guard works only with Claude Code, and my teams also used other different agents. So that was the idea behind creating Probity. have it run any rules across different agents. And there were a lot of opportunities that showed up since I’ve created TDD Guard. The ecosystem matured, there are simpler ways to go about things that are much easier, both for me as a maintainer and for the end users.”

I’ve been trying to understand what TDD looks like when we’re coding with an agent. I asked Nizar, and others, to show me a solution to a well known code kata, RPG combat. This is a classic coding challenge. The purpose of this is to show what the TDD process looks like. I’m not really trying to evaluate the actual code that comes out – I’m pretty sure that any coding agent can solve this exercise and all the people I’m talking to are producing good quality code in general. The goal of this exercise is really to understand the coding process. What tools and techniques are people using to write code with agentic AI. 

We have a screen record of the kata. I’ve just picked out a moment where it finishes up the faction story and it moves to the magical object story. It creates a new test case for the healing object on the right here, and then it creates a new file on the left to make that pass. And you can kind of see it doing TDD. It creates another test here on the right, and then a little bit more code appears on the left.

So it’s definitely writing the test first. But then a little bit later on in this sequence, something happens here that I wanted to ask about. Can you explain what’s happening here, Nizar?

Nizar: “Yeah, so it looks like it added a test where it checks that, let’s see, it loses one weapon health each time it is used. So we have our basic setup of the attacker and the target. We also have a sword, which is the magical weapon here. And then we have the attacker attack the target with the sword. And then we assert that the health of the sword is now four. So after writing the test, we also see that the main agent has run the test. Now the main agent is kind of like reasoning out loud and says red, and now we’re going to go to green. We’re going to give it a method use that heals its damage and wears it down. 

And Probity, because it checks all the changes that the main agent is trying to do, it sees the context, the history, the test that was run, and the result. And it will notice this that, hey, this new method that you’re trying to introduce use, It’s not really referenced anywhere, and it’s not really the simplest change you can make to make that test pass. So it flags it as an over-implementation and asks the main agent to do this the correct way, find the simplest way to make the test pass.”

What we see here is Probity has prevented the agent from creating a “use” method that was not called from anywhere.

Nizar: “Exactly. That’s something that agents tend to be happy about, especially in more complex situations where the test seams aren’t as clear. They get a bit lazy and reach for tests that really don’t give you the confidence you need. So I used to do this manually. I would just follow whatever the main agent is doing, and I would flag and ask it to undo things, change this and that. But it was tedious, and I just didn’t enjoy it. And I’m really glad that now I have a tool that does this mostly for me. So I don’t have to police the TDD cycle itself.“

I think this is very cool, being able to see the agent doing TDD properly. This seems like a lot of trouble to go to though. I asked Nizar to explain why that is so important.

Nizar: “The thing is, it all boils down to confidence. If I know that someone after me might try to refactor or make a change, but there’s something important for the functionality to work as intended, and it’s not covered by a test or something to communicate to the next developer that this is crucial. I feel like I really lose the whole thing that I’m leaning against that allows me and my teams to develop in a productive way. All of a sudden, you start to see bugs, unexpected behaviour, things are not documented. I feel like strict TDD gives me that [confidence] automatically. I’m making sure that every test fails before an implementation. You know that it can fail. You know it’s a test you can rely on. And then by making sure that you always have the simplest change to make it pass. It protects you against over-engineering or unnecessary complexity or things that might mislead other people in the future. It just keeps the code clean, concise, tidy, easy to work with. And yeah, I just can’t be thankful enough for TDD to be honest. It keeps me sane. “

I like that – TDD keeps you sane!

What we’ve seen in this demo, and I think is very common, is that the agent is writing all the code, Nizar is not writing code by hand any more. I asked him if he still reads all the code the agent writes?

Nizar: “I like to have control over exactly everything that happens. So in the beginning, I would actually run one agent, and I would just watch it. And I would step in as soon as I notice something is not ideal. So yeah, I still read all the changes. I discuss them with my colleagues. I still feel that it’s mine. I don’t feel that it’s code that I just borrowed from somewhere because I’m involved in forming it, shaping it. I feel responsible for it and I’m also proud of it.”

“I was not comfortable with letting agents and LLMs write code for me. I cannot let that go, but I think me understanding is critical. I just, and I think it’s also an important bridge, basically between the agents and the real world, because I’m in meetings with stakeholders, customers, the team. I hear pain points, feedback, I know some history of the project. There’s a lot of things that just aren’t apparent in the code itself. So as much as I would like to make the context rich for the agents so they can work more on their own, there’s a lot that they just can’t infer from the code alone. And I have to be in that loop. And I think it would be difficult for me to do an effective job at being in that loop and being in charge without also having the mental model. It’s, I think it’s central here.”

This is a important point – Nizar is very clear he reads and understands the code the agent is writing for him. Enforcing this TDD process with a tool gives him more of a supervisor role. He told me he normally has four of these agents working at once, supervising them all. 

One thing I was concerned about though – was the cost of this approach. I asked Nizar to explain the costs.

Nizar: “Yeah, so it does cost tokens. Even though I like to use the latest model on a high effort, I noticed that all the validation requests were actually getting routed dynamically, depending on how complex they are. But the vast majority were being routed to very simple, small models that were actually very cheap. So I understand that maybe if you are on a limited plan or a budget, this might not be the ideal way to work. For me, it’s not an issue. The issue really is that it just takes longer, but I’m also fine with that. I would rather pay upfront than later. So I would say the time is more really of something that you would notice.”

It could be a good investment – some time and tokens in exchange for confidence in your design. I asked Nizar for his best advice for anyone wanting to improve the quality of the code they write with agentic AI.

Nizar: “I would say it’s the same old advice that everyone has been giving for years, which I’ve also learned and found the value of it, whether using agents or not. It’s try to test behaviour, not implementation shape. And this is so that your tests survive refactors. They allow it to give you the confidence to actually make changes, and you don’t have to keep rewriting tests. And it’s not about coverage, really. It’s about confidence. Do those tests give you the confidence to ship without you having to manually doubt everything and want to keep checking things yourself.”

This is all excellent advice. And if people would like to try out Probity, where can they get it?

Nizar: “It’s on my GitHub. And it’s still an early project, and I would happily receive any feedback and ways to improve it. I think this space is developing very quickly. There’s a lot of great ideas. And to anyone who basically has a hunch, generally speaking, has a crazy idea, they’re a bit unsure, just go for it. and you really never know where that takes you.”

Conclusions

Many thanks to Nizar for creating this tool and explaining a little bit about it. He also has another article about it on Factor10’s blog. This is a fascinating insight into one approach to using agentic AI to get good results for your design, and confidence in the code and tests.

Happy Coding!