TO BUILD A FIRE

GitLab Transcend: Life After Code · Track A — Start Fresh · Assisted Autonomy

Tagline

AI made code cheap. Human attention is scarce. TO BUILD A FIRE routes review effort where it matters — with evidence, explicit policy, and a receipt for every decision.

The problem

Two lines can change an access boundary. Thousands of generated lines may not.

As coding agents accelerate software development, teams can produce more changes than humans can carefully review. But review capacity remains finite, and diff size is a poor measure of where that capacity should go.

A generated file with ten thousand lines may be mechanically reproducible. A two-line authorization change may quietly grant access to users who should never have it.

Traditional review workflows put both changes into the same queue. Adding another AI reviewer often compounds the problem: more summaries, more findings, more comments, and another layer of output for humans to evaluate.

The bottleneck is no longer just understanding code.

It's allocating human judgment to the changes that actually require it.

That is the problem TO BUILD A FIRE solves.

What it does

TO BUILD A FIRE is an evidence-driven attention router for merge requests. It directs finite human review capacity toward consequential uncertainty, explains why attention is needed, and preserves an auditable record of how each decision was reached.

The system follows a deliberately separated chain of responsibility:

Agents produce observations. Verification produces bounded evidence. Policy routes attention. Humans resolve what remains consequential and uncertain.

A Change Mapper agent reads the merge request and identifies candidate observations, affected areas, and claims that may require verification.

An Evidence Engine collects and structures deterministic checks, scanner results, ownership information, and other bounded evidence. Each result is tied to what it actually establishes — not to a general assertion that the change is safe.

A Falsifier agent challenges claims by proposing counterexamples. Its findings remain candidates for examination, never authoritative verdicts.

A deterministic, versioned Review Package carries claims, evidence, provenance, source locations, and policy decisions between components.

Finally, the Attention Router applies explicit policy and assigns one of three explainable routes:

  • COVERED_BY_EVIDENCE — the declared claims have the evidence required by policy.
  • TARGETED_REVIEW — specific consequential claims remain unresolved, with precise locations and evidence gaps.
  • DEEP_REVIEW — the change requires broader human examination because its impact, contradictions, or uncertainty cannot be resolved through a narrow review.

These are attention routes, not automated merge approvals.

The reviewer receives the relevant claims, the supporting evidence, the unresolved questions, and the estimated review effort — rather than another unstructured stream of AI opinions.

The system never decides that a change is safe. It makes the remaining human work visible, specific, and actionable.

A working demonstration

The demonstration includes a deliberately seeded authorization change: an access-control function is modified to allow every authenticated user.

The change is small. Its consequences are not.

GitLab CI runs a bounded authorization-invariant check against the change. The check reports a failure.

The pipeline itself still passes, because it successfully completed its responsibility: producing the evidence package.

The pipeline passed. The authorization claim did not.

TO BUILD A FIRE preserves that distinction instead of collapsing both outcomes into a green or red status.

The resulting Review Package keeps the authorization claim unresolved, identifies the missing evidence, and routes the change to TARGETED_REVIEW.

In the live Review Package Explorer, the reviewer can inspect the claim, its evidence state, and the reason attention is required.

The demonstration also shows how a GitLab Duo Change Mapper assessment enters the workflow under human control.

The agent reads the merge request and proposes observations. Before anything is posted back, a human approval checkpoint is required. The agent does not approve or merge changes autonomously.

A separate integration job links the approved assessment to the Review Package only when the project, merge request, and exact head commit match.

The demonstrated result is linked — for the same commit.

This preserves an essential boundary: an assessment of yesterday's code cannot silently become evidence for today's revision.

How it's built

The deterministic routing core is implemented in Python. Its policy is explicit and versioned, and each routing decision produces a SHA-256-addressed receipt.

Given the same evidence and policy, the router produces the same result. Agent-generated observations cannot override the deterministic decision boundary.

GitLab CI/CD provides the evidence-producing pipeline, including SAST scanning, deterministic contract checks, and a bounded authorization-invariant test against a seeded control. Evidence is associated with the exact merge request head commit.

GitLab Duo Agent Platform powers the Change Mapper workflow. Candidate observations are separated from verified evidence, and posting an assessment requires human approval.

The assessment-linking mechanism checks project identity, merge request identity, and exact revision before connecting agent output to the Review Package.

The Review Package Explorer is a browser-only interface built with vanilla HTML, CSS, and JavaScript. It supports English and Spanish, light and dark themes, and local inspection of Review Packages without uploading their contents.

The live application is deployed on Google Cloud Run, served through NGINX, with deployment infrastructure using GitLab CI/CD and Workload Identity Federation (OIDC).

The architecture combines agent assistance, bounded verification, deterministic policy, cryptographic receipts, and explicit human authority boundaries.

The result is not another AI code reviewer. It is a system for deciding where review attention belongs, what evidence supports that decision, and what remains for a person to resolve.

Try it live

Live Review Package Explorer

https://tbaf-review-explorer-zxmd2hmaaa-uc.a.run.app/

Click Try example report to inspect the Review Package, its unresolved authorization claim, the evidence state, and the attention route.

The interface also supports opening Review Packages locally, directly in the browser.

GitLab hackathon repository

https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/1688368/showcase

GitHub public mirror

https://github.com/annatchijova/to-build-a-fire

Full slide deck

https://tbaf-review-explorer-zxmd2hmaaa-uc.a.run.app/assets/slides.pdf

The source code, architecture, technical documentation, evaluation materials, and demonstration resources are available through the project repositories.

What's next

TO BUILD A FIRE is designed as four complete, connected product levels, each useful independently and each preserving the evidence and authority boundaries required by the next.

Level 1 — One change, end to end. Follow a change through the post-code lifecycle, connecting verification, security, packaging, release, deployment, monitoring, and governance with explicit human checkpoints.

Level 2 — Team-wide attention scheduling. Allocate a shared review budget across open merge requests. Make review demand, available capacity, prioritization, and work left uncovered visible rather than pretending every change can receive equal attention.

Level 3 — Approved repair and re-evaluation. Carry an approved fix through fresh verification, review, release, and monitoring, preserving the relationship between the original finding, the repair, and its resulting evidence.

Level 4 — Repository portfolio intelligence. Apply compatible, explainable policies across related projects, account for cross-repository dependencies, and make review decisions traceable at portfolio scale.

The long-term objective is not to replace software engineers with autonomous reviewers.

It is to make human review capacity an explicit, evidence-driven resource throughout the software lifecycle — from a single merge request to an entire portfolio.

Built with

Python · GitLab CI/CD · GitLab Duo Agent Platform · GitLab SAST · Google Cloud Run · Workload Identity Federation (OIDC) · NGINX · HTML · CSS · JavaScript


AI made code cheap. Human attention is scarce.

TO BUILD A FIRE makes every review route explainable, every evidence boundary visible, and every consequential decision accountable.

Not another reviewer. A better way to decide what deserves review.

Built With

Share this project:

Updates

Submission history