Introduction: from architecture to method
After the work on context management and orchestration, I come back to something more concrete: the code itself. I can organize files, trim instructions, isolate agents; in the end, what counts is whether the feature actually does what I wanted to build.
I had a clear constitution and well-maintained instruction files. On paper, it held. In the code, it was something else: the AI generates, interprets, sometimes forgets a constraint, and accumulates. Code isn’t a win in itself. As Software Engineering at Google points out, code is also a maintenance liability. The faster the agent ships, the more duplication, debt, and code smells it can introduce. I needed guardrails, not just better instructions.
At this point, I mostly start putting tools in place to hold quality. Instructions aren’t enough: I need feedback loops, tests, hooks, checks, signals clear enough for the agent to see where things break and fix them while it works.
State of play
By this date, a lot of tools are already part of my daily developer setup. So I end up dropping them into the agent loop too: reusable prompts, commands, project constitution, orchestrator, CI that blocks broken PRs, and the plumbing to generate the right context files for whichever tool is in use.
My work is still development, but it shifts: I spend less time writing the lines myself and more time hardening the environment the agents work in. The subject is no longer to stack better instructions. It’s to make quality verifiable.
When rules become executable
From there, what I’m really after is shortening the loop. The AI generates code, the system answers. If something breaks, I want a clear signal at the right moment so the agent fixes it right away. I move repeatable rules out of the prompt: they become checks the system runs, then sent back to the agent as actionable feedback.
We talk a lot about DX, the Developer Experience built for humans. Here I’m starting to think about the agent’s working experience: short, targeted feedback, readable inside the remaining context. That’s what I call AIX. When I configure a linter, an error message, or a script, I think about the agent that will have to read that output, fix, and try again. If the feedback is clear, it moves on. If it’s vague or too noisy, it spins and repeats the same mistakes.
In practice, the loop isn’t always as clean as the diagram. I write a task, the agent explores, writes code, edits files, then the checks start firing back: lint, types, tests, hooks, CI. With each return, I want to avoid the wall of logs. I want a signal the agent can act on to fix things without flying blind again.
Inside this loop, not all checks play the same role. Some have to be very fast: formatting, a targeted lint, sometimes a typecheck limited to the file or to the modified area. Those can fire often, right after a write. Others look more like small pipelines: they run at the end of a work turn, just before the agent hands control back. They can rerun heavier checks, capture the diff and error state, or even ask another agent to review. In this workflow, the turn shouldn’t end on a “done” if something is still broken. The agent goes back into the loop.
Watch out
Too many hooks recreates the problem I’m trying to avoid. If every action triggers a long return, I might be protecting the frame, but I’m also polluting the context. And a polluted context ends up degrading the output. A good guardrail should return a useful signal, not fill the window with noise.
This isn’t only about lint or tests. I also add custom validations: runtime boundaries, migrations, documentation, context, environment, security. Every project has its blind spots; guardrails make them visible earlier.
The exact list of tools changes from one project to another. The shift stays the same: an important rule doesn’t only live in a prompt. When it can be checked, I get the system to check it.
Update (April 2026)
Since then, my feedback loops have shifted again. I now use more feedback during the writing itself: formatting, targeted lint, sometimes a typecheck or a component validation as soon as a file changes. It’s faster than a full check at commit time or in CI, but it doesn’t replace it. The two levels don’t play the same role.
I also published an old architecture validator as open source: hex-validator. It’s not a tool I’d present as polished today; more of a trace of the exploration at the time. I still use similar techniques, adapted repo by repo. The repo mostly shows the idea: turn certain architecture rules into executable checks.
The AI generates code, but it doesn’t work in a vacuum. It acts inside a stack of context: instruction files, user prompts, files loaded during the task, existing code, comments, documentation, hooks, and checks. My role moves there: keep that stack clean enough for the agent to act without inventing the frame.
So guardrails aren’t a separate layer from context. They’re part of it. They turn a rule, a convention, or an error into an actionable signal. When that stack is well kept, the agent can go much further without me having to take back every decision by hand.