[cadamsdotcom]

Some of the ideas here are codified in a simpler way in my TDD framework, CodeLeash (https://codeleash.dev).

The key difference is CodeLeash puts guardrails outside the model, as Claude Code hooks. It can’t forget or skip steps, it gets forced through a process. There are bypasses but they raise alarms that the model is also forced to review.

Putting guardrails outside the model forces deterministic process following. With a sufficiently capable process (TDD is a powerful way to build software) you can really scale up coding agent usage.

[tinodb]

Nice, I had the same idea for a enforced TDD state machine! I wouldn’t tie it to all the other stuff though, but I might try it out.

[cadamsdotcom]

The TDD guard is the most isolated part of the whole thing, you could just take the files involved and ignore the rest. Maybe 6-7 files all referenced from the .claude/settings.json hook config.

Would be glad to see how you go!

[virgilp]

Cool but it is not a framework for working with AI, it is an _opinionated_ framework for building full-stack apps right? As in, I can't use any of it if I'm building, say, a Spark data processing pipeline. Or a ML framework. Or automation software that runs on custom processors.

The idea of "guardrails outside the model" is definitely appealing but I wonder if you can make it generalize well.

[cadamsdotcom]

You’re right of course, the framework is pretty rigidly tied to full stack.

But the underlying idea I think has power - find a process you can codify enforcement of rather than telling models how they should do things.

Spec driven development probably means creating tooling to track how code maps to specs, for example.. and then working out how to manage that as data. Then you can query the data to confirm all mappings between code and specs. That gets you out of the business of nicely and repeatedly asking very expensive and undependable models such queries :)