A question with no good answer
Somewhere in your codebase there is a function that moves money. A few files away there is a generated API client that nobody has read since the day it was generated. If you let an AI agent loose on that repository, the tool treats both files the same way: editable.
Ask the vendors how they handle this and you get process answers. The agent is careful. There’s a review step. You can always reject the diff. All true, and all beside the point, because the question was never “will a human look at the output?” It was: before the agent typed anything, what told it that one of those files is radioactive and the other is disposable?
In most tools, nothing does. In Sapilon, the codebase itself does. Every file (and where it’s
useful, every region within a file) carries one of three ownership tags: //!AUTO, //!SAFE,
or //!DEV.
The three zones
//!AUTO: the AI owns it. This is code where “the AI changed it” is the normal, expected
state: generated API clients, type definitions, scaffolding, standard CRUD screens, list pages
built from proven patterns. The agent creates, modifies, and regenerates this code without asking
anyone. Requiring human sign-off here would be theater; the blast radius is small and the pattern
is known. A meaningful share of a typical business application lives comfortably in this zone.
//!SAFE: the AI proposes, a human approves. The bulk of real application logic: business
rules, integrations, anything with behavior worth arguing about. The agent works here freely, but
its output arrives as a proposal: a diff, the reasoning behind it, and an approval step that a
person has to take before anything lands. You still get the speed of an agent doing the work.
What you give up is the possibility of a change you never saw.
//!DEV: humans only. Payment flows, auth internals, permission checks, migrations with
irreversible side effects. The agent can read this code, and should: an agent that can’t see
your auth model will write worse code everywhere else. But it does not write here, and it does not
propose changes here. Not “asks extra nicely first.” Does not.
If you’ve read our piece on agents and autopilot, you’ll recognize the shape: this is the flight envelope, written down where the automation can’t miss it.
Why the tag lives in the code
We could have made this a settings page. A list of protected paths in some dashboard, a policy document in the wiki. We didn’t, for three reasons.
The first is enforcement. A policy describes what should happen; a tag in the file is what the
tooling checks, mechanically, on every single change, the way a linter checks a style rule.
There is a real difference between “we told the AI to be careful with payments” and “the AI
structurally cannot write to payments/,” and the difference shows up on the day something goes
wrong.
The second is that humans read code too. A //!DEV marker at the top of a file tells the engineer
opening it exactly how much scrutiny its history deserves, and tells the new hire which parts of
the system the team considers load-bearing. The zones turn out to be useful documentation even
before an agent enters the picture.
The third is survival. Configuration lives in a vendor’s database and dies with your subscription. The zone tags live in plain Git, in code you own, so they survive tool changes, model upgrades, and staff turnover. Whatever agent works on this codebase in three years will find the same boundaries in the same place.
Zones move as the project does
Ownership is not a one-time decision. Early in a project, a freshly scaffolded module can sit in
//!AUTO because there’s nothing downstream of it to break. Six months later, once real invoices
depend on it, promoting it to //!SAFE is a one-line change. And the tag’s Git history now
records when the team’s trust in automation changed, and for which code. Demotion happens too:
hand-written code that stabilizes into pure boilerplate can be handed back to the agent.
That’s the practical answer to “how much should we trust AI with our code?” Not a philosophy but a dial, per module, adjusted as evidence comes in.
Zones decide access. Observability covers the rest.
One thing ownership zones deliberately do not do is make AI work invisible where it’s allowed.
Every action the agent takes, in //!AUTO just as much as in //!SAFE, is logged, rendered as
a diff, and reversible, and automated review runs on generated changes before they count as done.
The zones control what may be touched; the audit trail shows what actually was. You need both,
because “the AI was allowed to do it” and “we can see what it did” answer different questions
from your auditor.
Where this fits
Ownership zones are one piece of a larger position: that software is a lifecycle, not a prompt, and that a codebase an AI will work in for years needs its rules of engagement written into the code itself. To see how the zones operate across a real project, alongside review, environments, and the audit trail, start with the AI governance page.