Velosyti

When we let an AI agent work alone, and when we don't

Our one rule for AI agents in production code: autonomy depends on how easily a machine can check the work, and how easily we can undo it.

· 3 min read · For founders and IT heads commissioning software

We build most of our software with AI agents now. Not as autocomplete, but as team members that take a ticket, write the code, and hand it on. The question we get asked most is simple: how do you stop them from breaking things?

The answer is one rule. We wrote it on the first page of Foundry, our method for running these projects:

Autonomy is a function of verifiability and reversibility.

In plain words: an agent may work alone only when a machine can check its work, and a revert can undo it. If either is missing, a person steps in.

Two questions per task

Before a ticket goes to an agent, we ask two things.

  1. Can a machine tell if this is right? A failing test that must pass, a type check, a contract that the response must match. If the only check is "a person looks at it and feels fine", the answer is no.
  2. Can we take it back? A code change on a branch can be reverted in seconds. A database migration that drops a column cannot. An email sent to ten thousand customers cannot.

That gives four boxes. Only one of them is "go ahead alone".

The autonomy rule

Where an AI agent may work alone.

Agent works aloneMachine-checkable, easy to undo Agent + human gateCheckable, but can't undo Drafted, then checkedEasy to undo, hard to check Human does itHard to check, can't undo Easy to undoHard to undo CheckableNot checkable

What this looks like on a real project

On a delivery and home services platform for Karaikudi we had four Flutter apps, an admin console and an API to build in about eight weeks. We wrote the OpenAPI contract first. That single file made most tickets checkable: an endpoint either matches the contract or it does not.

Each file has exactly one owning agent. Two agents never edit the same file, so there are no silent overwrites. A Verifier role runs the checks. An Integrator merges. An Operator deploys. And anything touching money, migrations or messages to real people stops at a human gate.

What we got wrong at first

Early on we let agents write their own tests and then pass them. That is marking your own homework. Now the Verifier writes or owns the checks, and the Developer agent cannot change them.

We also learned that "reversible" is often a lie about data. A code revert is instant; the rows it wrote are not. So any ticket that writes to a production table is treated as irreversible, however small.

Why it matters for clients

This is how a small team ships four apps in one season without cutting corners. The speed comes from agents. The safety comes from being strict about where they are allowed to run alone.

References

  1. OpenAPI Initiative
  2. git revert documentation
  3. Human-in-the-loop (Wikipedia)