# Is Autonomous AI Coding Safe?

**Short answer.** Autonomous AI coding is as safe as the gates bounding it,
and no safer. Letting an agent loop unattended is only defensible when the
loop has a hard iteration cap, a spend ceiling, a guard against destructive
commands, and — critically — stops the instant any one of those checks
fails, instead of continuing to retry or running to a fixed finish line
regardless of what happened along the way.

## Where unattended loops actually go wrong

The realistic failure modes are not "the AI writes malicious code." They
are mundane and much more common: a fix-the-test loop that never converges
and burns hours of runtime, a retry sequence that quietly spends far more
than intended, or one destructive command executed with nobody watching.
None of these require the model to be adversarial — they only require
nothing external to be checking.

## How Maistik Forge bounds an autonomous run

[`forge run`](/harness/autonomous-run) executes an agent loop repeatedly and
stops it the moment an enforced gate opens, escalating to a human instead
of retrying forever. Its safety posture is explicit:

| Property | Behavior |
|---|---|
| Default | Dry run — without `--yes` it prints the plan and executes nothing |
| Iteration cap | `--max-iterations`, default 5, hard ceiling 50 |
| Already-open gate | Refuses to start — zero executor invocations |
| Gate opens mid-run | Stops immediately, names the gate, exits non-zero |
| Gate check errors | Stops — an unreadable gate is never assumed closed |
| Iterations exhausted | Stops and escalates — finishing the cap is not success |

Only one outcome is a clean exit: the executor itself signalling it is
done. Every other ending escalates to a human. Forge itself has no model and
cannot write code — it orchestrates an executor supplied via `--cmd` and
enforces gates between iterations, which is also why `forge run` is the one
place Forge deliberately steps outside its usual configurator-only role.

## Questions people actually ask

### What stops the loop from just hitting the iteration cap and calling that success?

Nothing treats exhausting the cap as success. Forge explicitly escalates —
"finishing the cap is not success" — and prints `escalate: a human should
review before continuing` rather than exiting cleanly.

### Can an autonomous run bypass the guardrails gate or the spend budget?

No — `forge run` checks the same enforced gates between iterations as a
manually driven session. An already-open gate refuses to even start the
loop, and a gate that opens mid-run stops it immediately. See [the
enforcement doctrine](/harness/overview) for the full set of controls it
respects.