What BuildIT does
Every claim it makes, it can show you
So this page starts by doing it. Paste code and BuildIT’s own deterministic rules run on the server and cite the line they fired on — the same citation a full review makes, minus the commit, the sandbox and the model.
What it does, stage by stage
You decide which repositories exist and what is worth reading.
- Review on every push, if you want it
- Off until a repository asks, because a review spends your model key. `@buildit pause` quietens one pull request.
- Configured in the repository
- A `.buildit.yml` on your default branch sets profile, path filters and per-path instructions. Never read from a pull request head, and an admin approves each version.
- Skip what your team would never review
- Exclude vendored or generated directories with globs. Dependency manifests are always read, so quietening a folder never turns off the vulnerability scan.
Where it stops
- It never merges
- Every verdict ends with a person deciding. BuildIT has no path to the merge button, by design.
- Access is granted in steps
- Sign-in identifies you. Repository access is a separate choice in GitHub. A model key is requested only when AI analysis starts.
- Source evidence is deleted
- Checked-out code and command output are encrypted, kept for the retention window you set, then deleted — with the deletion confirmed against storage, not assumed.
- A large repository is read selectively
- It fetches the files your pull request changed, your dependency manifests and the documents it cites. If GitHub truncates the file listing, BuildIT says so rather than reviewing part of your code and calling it done.
The honest limit: BuildIT has reviewed 141 pull requests over 7 repositories, 79 of them reaching a blocking or passing verdict. That is a real record and a small one — the next unfamiliar codebase may still find something it handles badly. It refuses rather than guesses, so you will sometimes get no answer instead of a wrong one.