The agent that wrote it shouldn't verify it

AI coding agents are powerful and unpredictable. The choice most teams face is bad: babysit every step, or wake up to a 50-file diff nobody trusts. Two OSS projects take the same bet — that orchestration and independent verification beat self-review — and ship it in very different shapes.

zeroshot

Summary. zeroshot is a CLI that runs AI-driven code changes through separated executor and verifier agents.

• Tagline from the repo: "The agent that wrote the code shouldn't be the one that says it works."

• Installs as an npm global: npm install -g @the-open-engine/zeroshot, then zeroshot.

• Requires Node ≥ 22 and one supported model provider.

• Guided setup detects installed providers, picks a default, and configures git worktree isolation for fresh repositories.

• Linux and macOS today; Windows is deferred per the README.

The design choice worth pausing on: worktree isolation. The executor works in one worktree, the verifier reads the diff independently. There's no shared context that lets the writer smuggle its assumptions into the reviewer.

Use case. Any workflow where an agent produces code changes that a human would otherwise have to review from scratch.

• Imagine a cost-governance repo where an agent proposes Terraform edits to right-size instance families across accounts. With zeroshot, one agent produces the diff; a second, without the executor's chain-of-thought, verifies against the plan output and the module's tests before a human sees it.

• Imagine an on-call task: an agent patches a Kubernetes resource-request drift issue flagged by OpenCost. Executor writes the patch; verifier confirms it actually reduces requests and doesn't touch limits it wasn't supposed to.

• No direct FinOps mapping in the repo itself — this is general-purpose executor/verifier orchestration. But every agent-generated infra PR is a FinOps risk surface, and independent verification is cheaper than a bad merge.

The premise is the interesting part. Self-review from LLM agents is theatre; the same context that produced the bug produces the "looks good to me." Splitting the roles is the smallest architectural change that fixes it.

fabro

Summary. fabro is an open-source workflow orchestration platform for AI coding agents, framed by the maintainers as "the open source dark software factory for expert engineers."

• Contributors include brynary and swerner by commit count.

• Process is defined as a graph. Agents execute the nodes. Humans intervene at chosen points, not every step.

• Installs into an existing agent runtime. With Claude Code: curl -fsSL https://fabro.sh/install.md | claude. With Codex: codex.

• Positioning from the README: "You either babysit every step or review a 50-file diff you don't trust. Fabro gives you a middle path."

Where zeroshot is a two-role pipeline, fabro is a graph. You declare the process — plan, implement, test, review, deploy — and pick which edges require a human hand on the wheel. The unit of trust is the node, not the whole run.

Use case. Multi-step engineering workflows where fully-autonomous is too risky and fully-manual is too slow.

• Imagine a monthly cost-reduction sweep across a monorepo: (1) query OpenCost for the top 20 over-provisioned workloads, (2) generate PRs adjusting requests/limits, (3) run the test suite, (4) require human approval before opening PRs against production namespaces. As a fabro graph, the human gate lives on exactly one edge.

• Imagine a Reserved-Instance-vs-Savings-Plan rebalance task where an agent drafts the Terraform, another simulates the plan, and a human only reviews the delta against the current commitment portfolio.

• No direct FinOps tooling in the repo. But agent-driven infra changes are precisely the workflows where blind automation burns money and blind manual review misses drift.

Worth calling out that fabro and zeroshot are not competitors so much as different levels of the stack. fabro orchestrates the whole graph. zeroshot enforces the invariant on a single node: writer ≠ reviewer. You could run a zeroshot-style verification step inside a fabro node and lose nothing.

The pattern underneath both

Both projects reject the two-mode default of current agent tooling — full autopilot or full babysitter. The shared assumption:

• Self-review by the same agent is not review.

• Human attention is scarce and should be placed by design, not by default.

• Isolation (worktrees, graph nodes) is what makes agent output auditable.

For FinOps and platform teams, the practical read: any workflow where an agent touches infra-as-code, budgets, autoscaler settings, or commitment purchases needs a verifier that didn't write the change. Whether that verifier is another LLM in a separate worktree or a human at a specific graph node is a policy choice, not an architectural one.

One decision this week

Pick the workflow where an agent-generated diff last surprised you. If it was a single-shot code change, try zeroshot and see whether an independent verifier catches what self-review missed. If it was a multi-step pipeline, model it as a fabro graph and mark exactly one edge as human-gated. If either tool saves you a bad merge or an overprovisioned quarter, sponsor the fabro maintainers — brynary and swerner are doing the work.