Guardrails for coding agents

Last Tuesday, I watched a Claude Code session attempt to delete 42 files in a single terminal command because it misunderstood a directory structure. It was a routine cleanup task that I had assigned while I was finishing breakfast with my son, Jupiter. If I hadn't been watching the terminal output, a significant portion of a project’s history would have vanished in a millisecond. That moment reinforced a lesson I have been internalizing as I build out the systems for my studio: instructions are not the same thing as guardrails.

When we talk about agents, we often get caught up in the "reasoning" capabilities of the models. We spend hours refining system prompts, telling the machine to "be careful," "verify before deleting," or "always run tests first." But prose is probabilistic. No matter how many adjectives you use to describe caution, an LLM is still a statistical engine. In a production environment where you are the sole owner and operator, relying on a model's "judgment" to follow a prompt is a bet with a high downside.

The fragility of prose

The primary mistake I see builders make is treating the system prompt as a legal contract. It isn't. It is a set of suggestions that the model interprets through the lens of its training data. If the model determines that the most likely next token in a sequence is a destructive command, it will execute it—even if your prompt explicitly told it not to.

This is why "soft" guardrails fail. A soft guardrail is an instruction like "Never push to the main branch." A hard guardrail is a branch protection rule in GitHub that physically prevents the push from happening, regardless of who or what tries to initiate it. In my work with agentic engineering, I have moved away from asking the agent to be safe and toward building an environment where it is impossible for the agent to be dangerous.

The goal is to move the "safety" logic out of the LLM and into the operating system. This creates a deterministic environment. If a command violates a rule, the system kills the process before it touches the disk. This isn't about limiting the agent's creativity; it is about protecting the studio's assets.

Hard hooks over soft suggestions

The most effective way to constrain a coding agent is through deterministic hooks—scripts or binaries that sit between the agent and the shell. I use a series of wrapper scripts for common destructive commands like rm, git push, and npm publish.

For example, when an agent attempts to run a delete command, the wrapper script intercepts the request. It checks the target path against a "protected" list. If the agent tries to delete the .git folder or the src/main directory, the script returns a standard error message and logs the attempt. The agent receives the error just as it would from a normal system failure, and it is forced to "reason" its way around the constraint.

This approach changes the dynamic from "I hope the AI follows my rules" to "The system enforces my rules." It allows me to step away from the screen for a moment to help Brittany with something around the house without worrying that a hallucination will wipe out a week of work. We use these same patterns in the Army National Guard for logistics and safety—you don't rely on a soldier's memory when you can build a physical gate.

Tiered permissions and the sandbox

One of the benefits of running a one-person studio is that I am the only one with the keys to the kingdom. When I bring an agent into that environment, I treat it like a junior contractor who is only allowed to work in a specific room.

I implement tiered permissions based on the task at hand. If an agent is tasked with refactoring CSS, it does not need write access to the database configuration files. I use filesystem-level permissions to "jail" the agent process into specific subdirectories. If it tries to move outside those bounds, the OS denies the request.

This sandbox approach is essential for scaling. As I manage multiple brands—Inky, Pregnancy Power Hour, and The F1 Formula—the complexity of the systems grows. I cannot keep every detail of every codebase in my head at all times. By setting up these "safe zones," I can delegate high-volume coding tasks to agents with the confidence that they cannot cause cross-project contamination.

Handling the rejection

A common question is how the agent reacts when it hits a hard guardrail. In my experience, agents handle deterministic errors better than vague instructions. When a shell hook returns a "Permission Denied" or "Protected Path" error, the model typically recognizes the boundary immediately. It often apologizes and seeks an alternative route that complies with the system's rules.

This feedback loop is where the real work happens. Instead of me having to police the agent, the environment polices the agent. This frees me up to focus on the high-level architecture and the creative direction of the product. The agent becomes a tool that operates within a defined space, much like a CNC machine or a 3D printer. It has a high degree of autonomy, but it is physically limited by the rails it sits on.

The owner’s peace of mind

Building software today is fundamentally different than it was five years ago. The cost of generating code has dropped toward zero, but the cost of maintaining and protecting that code remains high. As an owner, my primary job is risk management. I want to move fast, but I refuse to move so fast that I break the foundation of what I am building.

I think of these guardrails like the structures I learned to appreciate during my years as a jazz guitarist. You have the chord progression and the time signature—those are the hard rules. Within those rules, you have total freedom to improvise. Without the structure, the music becomes noise. Without guardrails, agentic development becomes a liability.

The transition from a "prompt-based" safety model to a "system-based" safety model is what allows a single operator to run a portfolio of products. It moves the burden of vigilance from the human to the machine. Reliability in a one-person studio isn't about how smart the agent is, but how little damage it's allowed to do when it's wrong.