It is gated. It is stricter than a PR.

Every push to main runs through an automated policy pipeline before it lands. If your code violates a security rule, breaks a test, uses a banned dependency, or fails any check the organization has defined — the push is rejected. The code does not land. Full stop.

This is not less strict than a PR. It is more strict. A PR gate depends on a human reviewer who may be stressed, rushed, or doing you a favour on a Friday afternoon. Under pressure, PRs get rubber-stamped — "LGTM, ship it." Everyone who has worked in a team knows this happens. A policy gate cannot be rubber-stamped. It runs the same checks every time, regardless of who is pushing, what day it is, or how urgently someone needs the change to land.

What the research actually says

We need to be precise here, because this is where credibility lives.

The Accelerate research does not say peer review is harmful. The opposite: DORA endorses peer-review-based approval and contrasts it favourably against external approval. The negative finding is specifically about approval by people external to the team — change-advisory boards, senior managers, formal sign-off queues — which correlates with low performance and shows no evidence of lowering change-fail rates.

A pull request is a form of peer review. DORA endorses peer review. So the research does not support "PRs are bad." What it supports is: remove the blocking gate (external approval, heavyweight process), keep the review in another form. That is exactly what gittan does.

We killed the gate. We kept the review — as pair programming, post-commit review, and an asynchronous architecture advisory that compiles findings into a team report. The review happens. It just does not sit between "code is ready" and "code is shipped."

The structural problem with diffs

Set the research aside. There is a structural argument that needs no study.

A PR operates at the wrong granularity. A diff shows you lines in a file. It does not show you whether the change belongs in this service, whether the abstraction is right, whether it creates a maintenance burden in six months. Those things live in the relationship between the change and the whole system — not in the diff. The format is limited to the line level, and the things that break production live above it.

A PR with 50 lines might get a real review. A PR with 500 lines gets skimmed. Review effectiveness drops as the size increases. But the PR workflow incentivizes batching — creating a branch, opening a PR, waiting for CI, waiting for review is expensive, so developers accumulate changes to amortize the overhead. The reviews that matter most are the ones least likely to be thorough.

The bet: AI is shifting the economics

This part is our own position, not a research finding — we are explicit about the difference.

As more line-level code is AI-generated, the marginal value of line-by-line human review falls. The lines are usually correct. The syntax is fine. What matters is structure: does this change belong here? Is this the right abstraction? Does the data flow make sense across the system?

We built for where review is heading, given how AI changes the economics today. Human judgment is worth most on structure and direction — not on reading diffs. The shift is already visible, and it favours a model where line-level checks are automated and humans review at a higher altitude.

Ownership, not committees

A human backstop downstream lets the developer externalize quality — "ship it, the reviewer will catch it." Remove the backstop and the bar at write-time rises, because there is no one left to hand incomplete work to. You do not push code that is "probably fine." You push code that is ready — tested, clean, passing every policy. This is an incentive argument: how people behave around safety nets.

The objection: if automated gates and static analysis sit downstream, have you not just swapped a human backstop for a machine one? The distinction matters. A human approver vouches — "LGTM" is co-ownership, the reviewer goes on record, responsibility is shared. A gate measures — it reports pass or fail and vouches for nothing. It hands the result back to you, and the fix is still yours. A gate does not recreate the responsibility-shift that a PR does, because it never says "I approve this." It says "this passed these checks. You own the rest."

This is also what makes AI-assisted development first-class. When the gate is policy and tests rather than a human queue, an individual — or an individual working with an AI — can take a change from idea to passing-and-shipped without waiting on social process. The model assumes capable people owning their output, not a committee.

Humans promoted, not replaced

We did not replace humans with automation. We moved each kind of review to whoever does it best.

Line-level review — is this line correct, is there a null check, is the syntax right — is mechanical work. It scales terribly when a human does it, and it was never the human's strength. That goes to the automated gate: policy checks, tests, AI analysis.

Architecture, structure, right-tooling — does this fit the system, is the team heading in the right direction, is this the right trade-off — that is lifted to team level as human review at a higher altitude, where judgment and ownership live. The architecture advisory compiles findings into a team report. The team discusses it in their own cadence. The human is not deleted. The human is promoted — off rubber-stamping diffs (a job nobody wants) onto the level where a senior engineer adds something irreplaceable.

This is also a recruiting argument. gittan offers engineers the chance to stop being a review machine and own the system instead.

What it costs

Honesty about the trade-off: this model depends on developers who own their output. If a team uses PR review as a backstop for incomplete work, the transition is cultural, not just tooling. The gated push catches rule violations — it does not catch the subtle design decision that breaks no rule.

The answer is batch size. In trunk-based development with small, frequent commits, a bad design decision is a small change that is cheap to revert. The architecture advisory catches patterns over time and surfaces them as recommendations. The combination — small batches, automated policy, advisory review — is a different safety net from a PR, grounded in reversibility rather than pre-approval. We wrote a separate page explaining why we believe it is the right trade-off.

What happens under the hood

The gate does more than run the pipeline. It handles the edge cases that come from gating a distributed operation on a centralized check.

• ‣ Stale-ref detection. Before running the pipeline, the gate checks whether the branch tip has moved since you started pushing. If someone else landed a push in the meantime, your push is rejected immediately — no waiting two minutes for a pipeline that would fail at the ref update anyway. You get a clear message: the branch has moved, pull and push again.
• ‣ Result caching. If the same commit SHA already passed on the same branch (e.g. you are retrying after a network error or a concurrent-push conflict), the gate skips the entire pipeline and accepts the push instantly. Your terminal shows "pipeline skipped (already passed)" instead of re-running the same checks.
• ‣ Fail-open on infrastructure failure. The gate is designed for availability over consistency. If the pipeline times out (10 minutes), or the commit bundle cannot be staged for the runner, the push is accepted with a prominent warning banner. Your code lands unverified. This is a deliberate trade-off: blocking all pushes because CI infrastructure is down causes more damage than accepting one unverified push. The bypass is audit-logged — repo, branch, SHA, reason, and timestamp — so the team can re-verify after the infrastructure recovers.

Compliance

Some regulated environments require documented review as policy. DORA notes that peer-review approval can satisfy segregation-of-duties requirements when captured in the platform. gittan's pipeline sign-off is exactly this mechanism — a review step that is recorded, auditable, and enforced by code. It is not a workaround for the DORA-endorsed model. It is the model.