This post is about the origin of the framework and the core idea behind it: moving "correctness" from something we expect an agent to infer into something the environment can continuously verify.
Origin
I am a solo builder. I created this framework to solve my own needs - to automate development work without compromising on quality.
I started using it as an internal tool some time ago. I build enterprise software for organizations that use IoT technologies to improve operations and generate business value. A number of those customers saw me work with this setup during meetings and workshops and asked about applying it in their IT departments. That is the origin story of this initiative.
The offering may sound similar to things others are describing. What distinguishes it is that I use this setup daily to build production solutions that manage physical and virtual infrastructure. I know it works, because it is how the work is done.
Human at the end of the cycle
I think the real prerequisite for that is making as much of the acceptance criteria as possible machine-verifiable. Tests, types, security checks, and policies give the agent something humans often rely on implicitly: an external definition of what "correct" means that survives context compression, model changes, and long execution chains.
The more of that definition we can encode into the system, the less autonomy has to depend on the agent remembering what it was supposed to do. In that sense, reliable agentic development may be less about making agents smarter and more about making the environment around them harder to misunderstand.
Automated feedback instead of hope
That is precisely the design principle I apply: use production-proven analysis tools to provide automated feedback to AI agents.
The alternative is to hope that agents "figure everything out." The problem with hope is that it does not scale, does not reproduce, and does not leave evidence. Instead, when a check fails, the agent receives a specific prompt containing the concrete output of the analysis tools — the failed test, the type error, the scanner finding. Remediation is targeted rather than speculative.
What this buys you
- An external definition of correctness. The spec of "done" lives in the environment, not in the conversation.
- Autonomy that does not depend on memory. Long execution chains do not degrade the definition of correct, because it is re-verified at every step.
- Verifiable evidence. Every verdict comes with the tool output that produced it, so humans at the end of the cycle review evidence instead of reading summaries.
That is the origin story of this initiative. Any feedback is much appreciated!