Nizoss

I use a different approach, I enforce TDD using hooks. Think of it this way: You interact with your agent and ask it to implement a feature. Now every change it wants to make will have to be approved by a separate agent. This second agent is spawned using the SDK and can see the pending change, recent session history for context, instructions on how to interpret the information in relation to TDD, and any project custom instructions.

This setup works great especially when you work with multiple agents or sessions in parallel and don’t want to be babysitting TDD. You just know that no TDD shortcuts or violations will be made and can focus on the solution instead. Agents are good at internally justifying shortcuts and lowering what’s good enough as the session goes. You can notice this when you ask them to review their own work compared to when asking a new session to review the changes. The difference is stark.

What’s interesting about the TDD instructions I dogfooded for this is that there is a lot that is implicit about how to interpret operations in terms of TDD violations. For example, earlier versions of the instructions had the validation agent block multi-step refactor changes because there was no guarantee to them that further changes will follow. It would also block changes when a definition is removed while it is still being called. The reasoning is that the code will no longer build and thereby not fulfill the ”refactoring is allowed under green”. Improving the wording and clarifying the process helped from this unwanted false blocks.

If you want to give this approach a try, you’ll find it here. I’m the author and I’m happy to and any further questions: https://github.com/nizos/probity

Good resource and nicely organized. I took the opportunity to apply a couple new things.

I’m working on a project that blocks agents from breaking rules. The rules are enforced through hooks and work across Claude Code, Codex, and GitHub Copilot.

https://github.com/nizos/probity

Exactly! I have said this a couple of times but it was taken literally as in no capital letters or strong language. Glad to see someone else who shares this perspective.

Not throwing shade at anyone here but the thought has definitely crossed my mind that we are recreating SAFe but for agents when looking at some of the orchestration setups out there. I think that it is better to not force the same hierarchical processes that worked for humans in large organizations onto agents and instead look at what they need to give better results and what their failure modes look like.

I fully agree. Also started using husky before expanding further and created my own hooks. I can’t imagine myself using agents today without them, it would require a lot of babysitting.

Sounds interesting, can you elaborate on your thinking? Got me curious.

Exactly! I don’t babysit TDD anymore. I have another agent that does that for me and honestly sometimes catches things I would have missed if I was the babysitting.

Hooks do wonders here. The payload contains a lot of information about the pending action the agent wants to make. Combine that with the most recent n events from the agent’s session history and you have a rich enough context to pass to another agent to validate the action through the SDK.

This way the validation uses the same subscription you’re logged in to, whether you’re using Claude Code, Codex, or Copilot. The validation agent responds with a json format that you can easily parse and return, allowing you to let the action through or block it with direction and guidance. I’m genuinely impressed by how well this works considering how simple it is.

You can find my approach here: https://github.com/nizos/probity

If you’re interested in such deterministic scaffolding/control flow, check out Probity.

I created it to address this exact issue. It is a vendor-neutral ESLint-style policy engine and currently supports Claude Code, Codex, and Copilot.

It uses the agents hooks payloads and session history to enforce the policies. Allowing it to be setup to block commits if a file has been modified since the checks were last run, disallow content or commands using string or regex matching, and enforce TDD without the need of any extra reporter setup and it works with any language.

Feedback welcome: https://github.com/nizos/probity

Creator of TDD Guard here, thanks for the mention!

TDD Guard was built when Claude Code was the only one to offer hooks. Plugins didn't exist and the models were weaker, so the validation context and instructions took more work to get right. This is why it ended up requiring test reporters for different languages.

I have started a new project that does the same TDD enforcement, also through hooks, but without reporters. It works with any test runner, and it is vendor-agnostic, it works with Claude Code, Codex, and GitHub Copilot. The validator also sees recent session history which helps it handle cases like refactoring better.

The TDD instructions are still pretty basic compared to TDD Guard's, which have been dogfooded for a year. One thing I noticed while testing across agents is that some follow TDD a lot better than others, Codex struggled the most with the basic instructions.

Feedback welcome:

https://github.com/nizos/conduct

This is how I would also love to work but not all teams prefer this way. How many are you in your team? Was it easy to switch?

I would love to hear your thoughts on TDD-Guard. An open source plugin I created to enfore Test-Driven Development practices on agents:

https://github.com/nizos/tdd-guard

Yes! This is something that I also value. Having demo gifs of before and after helps a lot. I have encountered situations where what I thought was a minor finishing clean up had an effect that I didn't anticipate. By including demos in the PR it becomes a kind of guardrail against those situations for me. I also think it is neat and generally helpful for everyone.

If you write your tests the Test-Driven Development way in that they first fail before production changes are introduced, you will be able to trust them a lot more. Especially if they are well-written tests that test behavior or contracts, not implementation details. I find that dependency injection helps a lot with this. I try to avoid mocking and complex dependencies as much as possible. This also allows me to easily refactor the code without having to worry about breaking anything if all the tests still pass.

When it comes to agentic coding. I created an open source tool that enforces those practices. The agent gets blocked by a hook if it tries to do anything that violates those principles. I think it helps a lot if I may say so myself.

https://github.com/nizos/tdd-guard

Edit: I realize now that I misunderstood your comment. I was quick to respond.

This looks really useful! Great work!

If you're on Windows and using vscode, add thiss to keybinds.json

[ { "key": "shift+enter", "command": "workbench.action.terminal.sendSequence", "args": { "text": "\u001b\n" }, "when": "terminalFocus" }, ]

It will allow you to get new lines without any strange output.

And here I am still waiting for some kind of hooks support for ChatGPT/Codex.

Same issue here, dark mode on mobile.

Yeah, this is a no brainer for certain use cases.

Not that I'm aware of. I'll check what possibilities exist with Opencode on their Discord.

That sounds amazing! Thanks for the heads up!

I deliberately picked a vendor-agnostic name. Adding support for other clients mainly means extending IClient:

https://github.com/nizos/tdd-guard/blob/main/src%2Fcontracts...

https://github.com/nizos/tdd-guard/tree/main/src%2Fvalidatio...

I'll take a closer look into adding this support. I'd also welcome a contribution if that's something you would be interested in!

The question is, do other agent platforms support hooks or similar functionality?

Thanks for the TL;DR!

Go support was recently added, and TDD-Guard also works with these frameworks:

JavaScript/TypeScript: Vitest and Jest Python: Pytest PHP: PHPUnit Go: Native go test

Adding a new language or framework just means creating a reporter that outputs test results in a format that TDD-Guard can consume.

I'm not familiar with Opencode. Is there something particular that interests you in it?

Hi HN,

I believe that using guardrails with agentic coding is far more effective than simply using instructions. This plugin demonstrates it using Test-Driven Development.

TDD-Guard can now be used with Go. Other supported languages are: JS/TS, Python, PHP, with dotnet in the works. Next are Ruby and Rust. I'd love community help adding support for more test frameworks and programming languages.

Here's feedback from an early user:

> This plugin is absolutely phenomenal and has become an indispensable part of my toolkit.

> It might sound strange, but I'm moving significantly faster on both new features and refactoring tasks now. The way it works in tandem with my strict ESLint setup is brilliant!I It iterates through issues and consistently produces clean, working code. It's not an exaggeration to say you've completely changed how I think about TDD and AI in my coding process due to this plugin.

Happy to answer questions!

I'm genuinely curious to see what the software quality looks like with this approach. Particularly how it handles complexity as systems grow. Feature development is one thing, going about it in a clean and maintainable way is another.

I've come across several projects that try to replicate agile/scrum/SAFe for agents, and I'm trying to understand the rationale. Since these frameworks largely address human coordination and communication challenges, I'm curious about the benefits of mapping them to AI systems. For instance, what advantages does separating developer and tester provide versus having unified agents that handle both functions?

Same, I manually approve and steer each operation. I don't see how cleaning up and simplifying after the fact is easier or faster.

It's a tough position to be in. I feel that I finally have some expertise worth sharing but at the same time I want to avoid backlash from the community for promoting my own content and projects. At the same time, I really do enjoy reading what others share and think without having to voice my own take. So when I miss the window, I miss the window.

I fail to see how this addresses the issue of poor quality contributions or bloat. I feel that focusing on the real issue would be more productive.

I also use the default one by Anthropic. It's a good start and simple enough to adjust for any needa.

Hi HN,

I have been using Claude Code in production for a couple of months and noticed most content and discussions focus on either flashy demos or complex orchestrations.

This is what I found works best for me and how I actually ship code. Happy to answer questions about any of the approaches and also to learn from how you use it.