More generated code moves the bottleneck to review
When code becomes cheaper to produce, reviewer attention becomes the scarce resource.
An agent can produce a plausible multi-file diff faster than a reviewer can reconstruct its assumptions. If every pull request arrives with missing tests, misplaced files, stale conventions, or unexplained risk, generation speed simply creates a larger queue.
The first review pass should be mechanical and local: did the work use relevant context, did behavior changes receive proportionate tests, did the diff expose a likely credential, and did it violate a mandatory rule? Those questions should be answered before a teammate spends time on naming, architecture, and product judgment.
Review the actual local change
A useful pre-review sees committed, staged, unstaged, and safe untracked work—not only the last commit.
Agent sessions often leave work across several git states. Reviewing only a pushed branch can miss the file the developer is about to commit or the untracked route that changes the feature. Brief assembles a bounded local diff and keeps secret-like content out of output where possible.
The review should be tied to the same task used before coding. That lets Brief look for a matching context receipt instead of rewarding context gathered after implementation. A missing receipt is evidence about the workflow, not proof that the code is wrong.
Keep findings honest about certainty
Deterministic risks can block; semantic judgments should usually begin as advisory findings.
A likely private key in a diff has a different evidence level from “this abstraction feels wrong.” Treating both as hard failures teaches teams to ignore the tool. Brief reserves stronger treatment for checks with reliable evidence and for rules an owner has explicitly approved as mandatory.
This separation also preserves the reviewer’s role. A local tool can verify that a required test is absent. It cannot know whether a product tradeoff is acceptable unless the team has written that decision down and scoped it to the affected path.
- Block on narrow, deterministic, high-risk evidence
- Warn when context or test evidence is incomplete
- Name the source rule behind every policy finding
- Leave taste and tradeoffs for a person unless policy is explicit
Review-ready requires behavior and policy proof
A review-ready change combines behavior proof, policy proof, and a concise account of remaining risk.
Green tests matter, but they are only as good as their coverage. A page may build while its mobile layout clips. A migration may lint while its row-level policy is wrong. The validation plan should match the type of claim: runtime tests for behavior, browser evidence for layout, database checks for data boundaries, and diff review for team rules.
The final handoff should not claim checks that were skipped or infer that a screenshot proves semantics. Brief stores the commands and verdict with the handoff, creating a compact trail a human can audit before merging.
- Match the task to context gathered before editing
- Inspect committed, staged, unstaged, and safe untracked changes
- Run checks that prove each behavior, layout, or data claim
- Record skipped checks and unresolved risk in the handoff
- Send product and architecture tradeoffs to a human reviewer
Common questions
Questions worth asking next
Can Brief replace human code review?
No. It removes predictable review chores and surfaces repo-specific evidence so a human can focus on architecture, product intent, and tradeoffs.
Does Brief use an LLM to judge every diff?
The implemented local reviewer focuses on deterministic evidence and repository rules. It does not present an LLM's opinion as a guaranteed semantic review.