Docs
View as MarkdownEdit on GitHub

Introduction

Why Bastion exists, and the one idea you need to hold in your head.

The problem

Agents write most of the code on a growing number of teams. When they are fully unlocked, output volume looks more like engineers x 100 than x 1. Two things stop teams from unlocking that:

  • Human diff review does not scale. Asking a 5-person team to review their agents’ output is like asking 5 people in a 500-person org to review the other 495. You cannot fix that by trying harder.
  • Without review, codebases rot. Things go fine until they do not, and then you have a ball of mud nobody can work in.

The usual shape of agentic review hands the whole diff to one reviewer that checks everything and writes comments designed for a person to act on. As you ask one generic reviewer to check more things, its recall on any single one degrades. A one-item checklist agent works; at ten items it is weaker; at a hundred it fails.

The core idea

In Bastion, a reviewer is a focused fitness function (an automated check that continuously asserts one property holds as the system evolves), and review is the author agent’s loop taken to its conclusion.

An authoring agent already loops against the compiler, the linter, and the tests. Bastion adds loops whose oracle is another agent, one that encodes judgment a compiler or a test cannot. The whole system follows from five principles:

  1. One concern per reviewer. Single-responsibility reviewers stay at high recall and confidence. The unit of the system is the reviewer, not the review. You cover more ground by adding narrow reviewers, never by broadening one. A cross-cutting property like tenant isolation or migration safety is not special; it is just another reviewer whose single concern is that property.
  2. Reviewers run in the author’s own loop, not only in CI. The repository’s reviewers run locally (fast, pre-PR) and in CI (authoritative), so CI usually confirms a green local loop. The two can differ when CI feeds reviewers the PR’s description and discussion that a default local run lacks, and a purely local run can also include your personal user-level reviewers, which CI never runs (see Authoring reviewers).
  3. Humans sit at the policy layer. The goal is not human-out-of-the-loop. It is to move the human from reviewing diffs to authoring, curating, and governing reviewers, plus triaging escapes (bugs that slipped through a review that should have caught them). Your interface becomes the reviewer registry, not the diff.
  4. Aligned agents can still inadvertently game the system. Bastion tolerates this and makes it visible and easy to correct by adjusting reviewers, rather than trying to make gaming impossible (which would give up the benefits of agentic development entirely).
  5. Reviewers converge through use. Ship a reviewer that is good enough, then improve it from the escapes you actually hit, rather than trying to design a perfect one up front. The escape-to-improvement loop is where that happens.

The mental model

Picture the way a good team did code review before agents:

An author opens a PR. A reviewer reads it, leaves feedback (some blocking, some optional) and withholds approval until satisfied. The author addresses the blocking items (by changing the code, or by convincing the reviewer the code is already right) and requests re-review. Repeat until approved.

Bastion brings that process to the agent era. The reviewers play the colleague’s role, their verdicts are the feedback, and the author agent resolves the blocking items and re-runs. The human is still in charge, but of the reviewers, not of every line.

What Bastion is not

Two non-guarantees are deliberate. Keep them in mind before you adopt it:

  • No guarantee of correctness. Bastion does not prove your code is free of bugs or vulnerabilities. It is code review without the human in the small loop; a reviewer is only as good as its model and its prompt.
  • No guarantee the right thing is being built. Catching “this is the wrong thing to build” was never review’s job. By PR time that ship has sailed; it is a design-time question. Keep humans in the design loop.

Bastion is also not an adversarial security boundary. It is the agent-era equivalent of team code review for aligned contributors: a speed bump and a set of good defaults that keep earnest actors on the rails, not a defense against a determined malicious one. The practical consequences for you, and how to govern within these limits, show up in Governance.

Next: Getting started -> install the CLI and run your first review.