Systems · Forge
PreviewAutonomous development needs contracts, not vibes.
Your team can now generate more change in a day than it can honestly review in a week, and the word “completed” has stopped meaning anything. Governed software delivery is the way out that does not require trusting the agent: a goal becomes a scoped work packet, agents build in isolation, a different model family attacks the change before a human spends a minute on it, proof gates decide what is promoted, and a person approves what ships.
Five multiple-choice questions. A person replies within one business hour.
The problem
The agent wrote the change in four minutes. Now who reads it?
Coding agents crossed the line from suggesting to doing. Nothing about your team’s capacity to read a diff moved with them.
The failure mode is specific, and it is not incompetence. The agent finishes, the tests are green, the status says done — and done means the process finished, not that the change is correct. Green tests are evidence about the tests. A suite that stubs the exact seam that is broken will pass forever, and it will pass faster every time you add agents.
Meanwhile that agent has a shell, your credentials and a branch. The blast radius of a confident mistake is the whole repository. A coding agent deleted a production database during a code freeze, and the write-up read like every incident of this class: nothing was disabled, nothing was sandboxed, and the agent believed it was helping.
Source: Fortune, 23 July 2025, on the Replit production-database deletion.
The mechanism
Five contracts, in order.
Each one is a thing the agent cannot talk its way past, because none of them are instructions to the agent. They are conditions on the work.
- 01
The packet, not the prompt
Before an agent runs, the work is written down: the goal, the paths it owns, the paths it may not touch, the proof gates that decide the outcome, and the documents that govern the decision. An agent that wanders outside its owned paths has broken a contract, which is a thing you can see rather than a thing you argue about.
- 02
Build in isolation
Each packet gets its own working tree. Agents running in parallel cannot overwrite one another, and a packet that fails is thrown away without touching anything else. Nothing lands on the trunk because an agent said it was finished.
- 03
A different model family attacks it
The reviewer is never the builder, and on supported runs it is not the builder’s model vendor either. Its brief is to refute the change: find the case the builder did not test, the permission the fixture quietly granted itself, the seam the test suite stubs out. It votes, with the evidence attached.
- 04
Proof gates, not opinions
Promotion is decided by gates that actually run — the full consuming test suite, the type check, the hygiene check on the working tree. The verdict is the exit code, not a summary of the exit code. A gate that cannot run is blocked, never passed.
- 05
A person approves what ships
Promotion to the trunk carries a risk tier, and that tier needs a named human. The record keeps the commit, which gates ran, both votes and who approved. Six months later that record is the answer to “why is this in the build”.
Proof
We are the customer.
This is the one page on this site where the proof is not a promise. VertixOS is built this way. The agents that ship our platform run under the same packets, the same gates and the same approvals described above, and the record is a commit history rather than a slide.
The number that matters is the third one. In more than half of our recorded review rounds, the independent reviewer surfaced a real defect after every automated test in the pipeline had already gone green. Not a style note, not a preference — a defect that would have shipped.
One of them is worth telling in full, because it is the argument for the whole design. A review by a different model family found that a high-risk approval gate could be satisfied by a voice confirmation — an agent could, in effect, approve itself by speaking. Every test was green. It was caught before release, and the gate was closed before that code left our own workspace.
That is what we mean by contracts rather than vibes. The builder was confident, the suite agreed with the builder, and the only thing standing between that and production was an independent checker whose job was to disagree.
What these numbers do not say
- It is our own workload. One engineering monorepo, one operator. It is not a customer deployment and it is not a controlled study.
- Some rounds were same-family. Roughly seven of the twenty-nine had a reviewer from the same model vendor as the builder. They are flagged as such in our own ledgers, and they are counted in the total above rather than quietly removed from it.
- We publish no improvement percentage. You will not find a number here claiming cross-family review catches some percentage more than single-model review. Earning that number requires a controlled benchmark, we have not run it, and a figure we cannot defend is worth less than the sentence above it.
Where this actually is
Forge runs on our repository. Not yours, yet.
If you came here to point this at your own repository this quarter, read this paragraph before the rest. Everything above is true on our own monorepo and nowhere else: the packets, the gates, the cross-family review, the approvals and the 214 promotions are all that one codebase. That is what the Preview badge is admitting to.
Running it against a customer repository is design-partner work, and the reason is isolation. Today a packet is isolated by scope — its own working tree, its own owned paths, gates that must pass before anything is promoted. That is the right control on a machine your own team already trusts. Pointing agents at someone else’s codebase calls for isolation of a different kind, with hard limits on what a process can reach and where it can send data. That work is specified and on the plan. It is not shipped, and selling it as though it were is exactly the thing this page argues against.
One more limit, stated plainly: agent definitions are versioned and pinned on our own lanes, and a promotion is reversible because it is pinned to the commit that passed. A customer-facing surface for drafting, publishing and rolling back agent definitions is in preview rather than shipped.
Watch one of your own goals go through it
Design partnerScoped to the codebase and the team
Your engineers in the room, one real goal: the packet written in front of them, the isolated build, the independent review, the gates, the promotion decision. You keep the packet format and the gate definitions whether or not you continue. The tooling is real and in daily use; running it against your repository is the design-partner part, and it is scoped in writing before anything starts.
Straight answers
The questions an engineering lead asks.
Agent speed is easy. Agent-written code you can defend is not.
Start with the measurement. You get an honest read on which of your work an agent could take, which of it still needs a person, and what would have to be true before you would let an agent near the trunk.
Five multiple-choice questions. A person replies within one business hour.
Preview: proven on our own repository. Customer repositories are design partner.