Vibe coding needs a floor: Why AI agents need guardrails
11.06 2026, 8 minutes read time
TL; DR: In the article How I built an AI agent system to run my side projects, Fortytwo COO Remi Vandemir wrote about how he made a little fleet of AI agents that run his side projects.
The natural next question is: Would he recommend that you copy it?
- Vibe coding needs a floor: Why AI agents need guardrails
- Should you build your own Agent system?
- The part I did not vibe code: infrastructure, security, and governance
- The same AI model behaves differently on a better engineering floor
- Good vibe coding happens inside constraints
- Let the agent stop: why “no change” should be a valid outcome
- Human judgment still owns risk, taste, and the merge button
- The boring layer wins: Guardrails make agentic development useful
Should you build your own Agent system?
The answer is yes, with conditions, and those conditions are all about laying down safe foundations. Agents need a solid floor that supports safety and guardrails, because they do not have those safety mechanisms built in.
This is the part most demos skip. They show the satisfying moment where an agent opens a PR, fixes a bug, or builds a feature, but they rarely show what sits underneath, making it all work: identity and access control, permissions, network boundaries, model governance, secrets handling, tests, CI, and the operational plumbing that decides whether autonomous work is useful and safe or dangerous and reckless.
My setup works because the agents run in a contained layer. They can move quickly because there are places they cannot go, actions they cannot take, and gates they cannot bypass.
The part I did not vibe code: infrastructure, security, and governance
Everything in the personal layer is vibe-coded: the portal, the mission runner, the glue around the vault, the proposal queue, the dashboards, the launchd jobs, and the small details that make the system feel alive. I am comfortable doing that because I am working in the application layer, where mistakes are contained and reversible.
The layer underneath is different. Fortytwo has people who are experts on infrastructure, and they built a proper landing zone in Azure. It is a hardened base: identity and auth, network boundaries, storage, backups, and governed LLM access through Microsoft Foundry. The models the agents call sit inside a controlled path instead of behind a loose API key in an environment file.
I had experts help me set mine up correctly so I didn’t have to improvise the security model, nor did I have to pretend it was my area. That matters because the more autonomy you give a system, the more boring its foundation needs to be. Boring means inspectable, governed, and built around failure modes that are known before the agent finds them for you.
The first question is not “can the agent code?”, it is “where can it go?”
When people talk about autonomous agents, they often focus on capability. Can it write code? Can it reason through a bug? Can it make a plan? Can it use tools? Those questions matter, but they are not the first questions I would ask.
I would start with the boundaries. Can the agent reach production? Can it access secrets? Can it mutate real user data? Can it call models outside a governed path? Can it merge without review? Can it bypass CI? Can it keep running when the output is clearly bad? Can it spend money without a hard stop? Can it write somewhere you do not inspect?
The answers shape the system more than a prompt ever can. A capable agent in a loose environment is a liability, while a capable agent in a contained environment becomes useful. The difference is all about the shape of the room you put the agent in.
In my setup, the agents can open PRs, but they cannot decide that their PRs should merge. They can propose ideas, but they cannot decide that those ideas should ship. They can inspect failures, but they cannot silently rewrite the operating model around them. These boundaries makes the system function without drifting and without acting in counterproductive ways.
The same AI model behaves differently on a better engineering floor
This is the part I keep coming back to: the same model can feel wildly different depending on the environment.
Point it at a project with unclear boundaries, weak tests, no shared components, secrets in the wrong places, and no reliable deploy gate, and it will produce work that looks plausible but costs more to trust than to write.
Point it at a project with strong primitives, typed contracts, a test suite that fails loudly, a design system, and a clear review path, and it can produce a diff I can read in a few minutes.
The model is the same, but the floor is different.
That is why I am skeptical of broad claims about whether agents are good or bad at development. The answer depends on the substrate. A messy system gives them room to make messy work, while a disciplined system gives them less room to drift.
Good vibe coding happens inside constraints
This is also the reason why “vibe coding” can mean very different things.
At its worst, it means asking a model to improvise across every layer of the stack and hoping the output holds together.
At its best, it means moving quickly in a constrained layer where the important decisions have already been made, the dangerous paths are closed, and the feedback loops are fast. I am comfortable with the second version, and have very little patience for the first.
Let the agent stop: why “no change” should be a valid outcome
One of the most important changes I made to my own setup was teaching the Improver to skip work.
The first version always came back with a PR, because that was the instruction, and the problem with that instruction is that there is always something to do. There is always another test to add, another dependency to nudge, or another small refactor to justify. If the success condition is “produce a diff,” the system will produce motion whether or not the motion matters, and that is exactly how autonomous workflows rot, filling your review queue with work that is technically defensible and strategically irrelevant.
“No candidate worth shipping” has to be made a first-class outcome. A skipped run can be a good result, a security mission that finds nothing obvious is a good result, a refactor mission that declines to touch a stable part of the codebase is also a good result. The agent needs permission and instruction to stop, and the surrounding system needs to treat stopping as information rather than failure.
Human judgment still owns risk, taste, and the merge button
There are many things I am happy to delegate to my agent system, like drafting a plan, inspecting a failure, proposing a fix, writing a test, refactoring a small component, opening a PR, summarizing a run, generating an objection, or suggesting a feature. Those are bounded tasks, and they produce artifacts I can inspect.
What I do not delegate, is the decision about what is worth building, the risk call or the merge of a PR. All in all, I do not delegate taste. It may change in small, specific places over time, but the general rule has held up well: agents help me generate options, while I own the judgment around those options.
The more expensive a mistake would be, the tighter the boundary should be. That sounds obvious, but it is easy to forget once the system starts working. A useful agent invites you to trust it a little more every time. Sometimes that is fine, and sometimes that is exactly when the guardrail matters.
A practical checklist before letting AI agents run unattended
Before letting agents run unattended in a project, I would want clear answers to a practical set of questions. This list may seem like bureaucracy, but in this case bureaucracy is all about setting up the boring foundations that make unattended work useful.
The boring layer wins: Guardrails make agentic development useful
The side-project fleet looks fun from the outside because of the visible parts: the portal, the PRs, the proposals, the morning brief, and the agents with names that seemingly do the work.
But in reality, it is the boring parts that makes it work without derailing underneath the hood: the secured landing zone, the governed model access, tight permissions, typed contracts, test runs, CI, review, the design system, logs, kill switches, and skip conditions.
Vibe coding benefits from traditional engineering discipline, and does not really work without it The faster the application layer moves, the more stable the layer underneath needs to be.
My agents can run a night shift because the building has locks, walls, alarms, and a front desk, and that is how I can wake up to useful work having been done.