Working with Agents
Baz Reviewer performs a comprehensive code review of open pull requests in GitHub.
Last updated
Baz Reviewer performs a comprehensive code review of open pull requests in GitHub.
Last updated
Baz now allows organization admins to configure Reviewer workflows, enabling or disabling specific checks to better align with their team’s review process.
How to Configure Workflows:
Navigate to Baz Settings → Preferences
Under Customize Reviewer Workflows, toggle workflows on or off based on your team’s needs
Changes apply to all reviewers in the organization
Additionally, you can also specify paths you would like to exclude using .
Important Notes:
Breaking Changes and CI Errors workflows cannot be disabled, as they highlight critical risks.
Baz Reviewer analyzes extended diffs and leverages the AST of each programming language to identify non-trivial issues, such as:
Highlights addressed and unresolved comments for improved visibility.
Identifies breaking changes to prevent potential disruptions.
Detects typos and overly generic names for clearer, more professional code.
Ensures proper code hygiene by adhering to best practices.
Verifies that tests include meaningful assertions.
Flags type inconsistencies to maintain code integrity and prevent errors.
Recognizes opportunities to rewrite code more concisely for better readability and efficiency.
Reviewer also analyzes every commit to determine if previous feedback has been addressed. For example, it might note, "This comment has been addressed. 🤘" or, if unresolved, "This comment hasn’t been addressed yet. ✋."
Log errors from GitHub Actions are another focus. Baz pinpoints the exact line of failure and provides a concise comment such as, "A failed check needs your attention. 🛠 I’ve attached the log error for your convenience." Breaking changes are flagged with contextual details, including code snippets and descriptions like, "Breaking change identified for API. ⚠️."
Smaller but crucial issues like typos and generic variable names are flagged with suggestions, such as, "Did you mean corrected_name?" or, "Consider changing generic_name to something more descriptive." It also identifies commented-out code, recommending cleanup with comments like, "There is commented-out code in the file(s) X, Y, Z. Consider removing it."
For tests, Baz highlights missing or removed assertions, suggesting improvements like, "Consider adding assertions—currently some cases might be missed." It also flags type change mistakes, directing reviewers to the relevant lines with explanations about the discrepancy. Each of these findings is designed to provide clear, actionable feedback, ensuring reviews are thorough and efficient.
Just like a human reviewer, you can ask follow up questions, request clarifications or even correct Reviewer if you believe it made a mistake. Simply start a chat with any Reviewer finding to start a conversation. Just as any comment, you can select to interact with Reviewer direcrly in GitHub or in Baz.
Reviewer also provides acceptance metrics per workflow to help teams evaluate which categories of suggestions are leading to meaningful code changes. No setup required - metrics are computed automatically from Baz Reviewer’s suggestion issuance and code implementation tracking.
Go to:
Settings > Preferences
Where you’ll see:
A global summary metric: Acceptance across all categories.
Per-workflow metrics.
Definition of “Accepted”
A suggestion is considered accepted only if:
The suggested change is actually implemented in the code diff.
The implementation is matched using AI inspection—not based on UI interaction or manual resolution clicks.
