Catch the Bugs Your Code Review Misses - Killian Carlsen-Phelan & Taylor Luttrell-Williams, Sonar
A hands-on walkthrough of Gitar, a code change verification agent, applied to three pull requests in a sample Python ticketing app. It covers catching a bug outside the diff, enforcing a business rule through project configuration, and diagnosing a failing CI test before auto-merging, along with functional validation against Jira, learned conventions, and cross-repo and cross-PR analysis.
Why agent-written code needs a verification layer
AI coding agents write code faster than any team can review it, and the result is a review bottleneck: queues grow, merges sit unattended, and reviewing becomes a chore nobody has time for. Agents also lack the context that matters most: a project’s architecture, its coding standards, and the unwritten business rules that live in a senior engineer’s head or on a wiki page. So production incidents rise with the rate of change. Gitar is presented as a code change verification agent that asks a harder question than whether code is secure, maintainable, or reliable. It asks whether the change is practically correct.
Static analysis such as SonarQube remains essential. It can trace SQL injection across twenty files and functions before it reaches the database. What it cannot do is infer intent, meaning whether the business logic of a change adds up against how the application already behaves. The two layers are complementary, and a fully verified application needs both.
Setting up the workshop repository
The session is entirely browser-based. Participants install Gitar as a GitHub app, then fork the workshop repository into the same organization. The fork must be created with ‘copy the main branch only’ unchecked, because the exercises live on separate branches. GitHub disables workflows on forks by default, so Actions has to be enabled before automated merging and approvals can work. The repository then needs to be connected under configurations and repositories in the Gitar dashboard.
The demo app, Box Office, is a small Python ticketing API for a concert venue. The orders module handles purchases, cancellations, and refunds, and the check-in module handles scanning a QR code for entry. A test suite covers the existing behavior. Opening one pull request per exercise branch, all at once, saves time because Gitar reviews take a few minutes each.
Finding a bug outside the diff
The first pull request adds a ticket transfer feature, so a buyer can send a ticket to a friend. The change includes validation for missing tickets, invalid emails, and voided tickets, and its tests pass with green CI. Gitar’s out-of-the-box review still finds a serious problem: a buyer can refund or void a ticket after giving it away, which silently cancels the friend’s copy. The existing test checked that a voided ticket could not be transferred, but nothing checked the reverse. The defect sits in orders.py, not in the added lines, so a reviewer would only catch it with working knowledge of how cancellations already function.
Fixing it is a single action. Applying the suggested fix, or commenting ‘Gitar fix’, makes Gitar push a new commit that adds the missing validation. It then re-verifies that commit, and it keeps iterating if side effects surface in the workflow. The point is that the complexity of a codebase grows faster than any human can hold it in their head, and reviewers that compare each change against existing functionality become necessary rather than optional.
Encoding business rules as enforceable context
The second pull request adds a $3.50 service fee, so a $50 ticket costs $53.50 at checkout. The hypothetical company has a policy that every price shown to a customer must be the all-in price. That is a product decision, not a correctness bug, which is why it has to be taught explicitly. Two mechanisms do this. A review directory under .gitar holds markdown files with any business context you want to add, and Gitar steers its reviews by it. A rules directory defines conditions that fire actions. For example, when pricing files change, Gitar can list every customer-facing field that was touched so a reviewer can confirm each one is all-in. Rules can go further, such as reading a linked Slack thread from the PR description and checking the code against the discussion that produced it. Gitar flagged the fee against the all-in policy, and this pull request was deliberately left unmerged.
Diagnosing CI failures and auto-merging
Full automation requires two repository settings. Allow auto merge must be enabled, and a branch ruleset targeting the default branch must require the test status check to pass. The third pull request refactors how tickets are scanned so that the scan points to a ticket page URL. The refactor breaks a rule: scanning an already-used ticket a second time returns 200 instead of rejecting it. Gitar reads the CI logs, identifies the failing check, and explains the cause in plain terms.
The presenters called out the familiar loop of reading logs, diagnosing locally, pushing, and waiting through a long pipeline, which burns time and money. Turning on ‘Gitar auto apply’ lets Gitar push fixes without a click for each one, and ‘Gitar auto merge’ merges the pull request once Gitar detects no remaining issues and the pipeline passes. Within a few minutes the pull request iterates to green and merges. Automation is configurable per repository in the dashboard, so teams can choose how much autonomy each codebase gets.
Advanced capabilities
Functional validation checks each pull request against the ticket it claims to implement, which matters because a change can be clean and still incomplete. Jira and Linear are supported, and Slack connects through settings and integrations so that a referenced message can inform a review. A knowledge feature learns team conventions from feedback and from false positives, and that feedback is weighted by reviewer seniority. Each review exposes the rules behind it, where they came from, and why they apply.
Two analyses extend beyond a single pull request. Cross-repo analysis finds changes that merge cleanly on their own but break code in another repository, with no stated limit on how many repositories are analyzed. Cross-PR analysis checks in-flight pull requests against each other, addressing the case where two changes each pass alone yet break production together, a risk that grows with every agent in the stack. Every finding points to the fix, shows where the problem occurs, and explains why it matters.
Questions on context and integrations
An audience question asked whether Gitar could take in context through MCP or custom integrations. The presenters explained that Gitar’s context capabilities review code against material such as architecture guidelines, while the knowledge feature is different: it steers Gitar’s own reviews and fixes based on how the team prefers problems to be fixed, and it stores that preference for future fixes. Details about how knowledge ingestion works were deferred to a follow-up.