Using Gitar to Verify Pull Requests Beyond the Diff

Taylor Luttrell-Williams introduces herself and Killian Carlsen-Phelan as developer-content engineers at Sonar. Their workshop demonstrates Gitar, a code-change verification agent, using a sample ticketing project and three pull requests. The claims about the tool’s capabilities come from its vendor’s presentation.

The workshop uses a 14-day trial and a dedicated GitHub repository. The presenters say the exercises run in a browser and require a GitHub account and the Gitar app. They plan to start with an out-of-the-box review, add project-specific instructions, and then demonstrate CI failure analysis.

Luttrell-Williams frames the problem as a verification bottleneck. Coding agents can generate changes quickly, but teams still need to determine whether the resulting code is secure, maintainable, reliable and correct for the intended business behavior. She says fixed-size review teams can struggle as the queue of changes grows.

She argues that agents may lack project-specific context and can miss existing architecture or coding conventions. Her concern is that faster production can produce more incidents if teams do not verify the result. These are the presenter’s claims; the workshop does not provide an independent incident-rate analysis.

Luttrell-Williams describes Gitar as a change-verification agent that reviews pull requests, diagnoses CI failures and can suggest or apply fixes. She says users can choose their level of automation and review involvement. She also claims that the product is tuned to reduce false positives and can provide analytics.

According to the presentation, context can include the pull-request diff and discussion, CI logs, and project-specific instructions. A review is triggered when a pull request is opened; findings and suggested changes are posted back to the request. Automated fixing and merging are optional settings, not inherent guarantees of correctness.

Carlsen-Phelan takes over the hands-on demonstration. He says participants should install the Gitar GitHub app and fork the workshop repository into the organization where the app is installed. He emphasizes unchecking “copy the main branch only,” because the exercises use several branches.

He then enables GitHub Actions in the fork and checks that the repository appears in the Gitar configuration. These settings are part of the demonstration: Actions and later merge permissions determine which automated checks and actions are available in that repository.

The sample application, Box Office, is a small Python ticketing API. Carlsen-Phelan describes orders.py for purchasing and cancelling tickets and checkin.py for admitting attendees by QR code. The repository also contains tests, which run whenever a pull request is opened.

He opens pull requests for the three exercise branches against his fork, allowing reviews to run while he explains the scenarios. He cautions participants to choose their own fork as the base repository rather than accidentally opening the requests against the upstream project.

The first pull request adds the ability to transfer a ticket to a friend. It includes basic validation for missing tickets, invalid email addresses and voided tickets, as well as tests. At the point shown, the tests and CI workflow are green.

Carlsen-Phelan contrasts static analysis with a contextual review. He says static analysis can trace certain security issues, while the demonstrated agent also considers descriptions, intended behavior and existing code. He presents the approaches as complementary; this example does not prove that either approach catches every defect.

Gitar posts a finding: a buyer can transfer a ticket and then cancel the original order, invalidating the recipient’s ticket. The missing case is the reverse of an existing test that prevents transferring a ticket already voided. The relevant cancellation logic is in the existing orders.py file, outside the immediate change being reviewed.

The presenter explains why a reviewer looking only at the new diff could miss the interaction. Understanding the risk also requires knowing how the existing cancellation path works. He uses the example to illustrate why broader context matters as changes and codebases grow.

To request remediation, he shows the “apply fix” control or a Gitar fix comment. He says the agent adds a commit and rechecks the change. Later in the demonstration he shows the proposed correction in orders.py, where an additional check has been added; the workshop does not establish that every automatic fix will be correct.

The second pull request adds a $3.50 service fee per ticket. A $50 ticket would therefore cost $53.50 at checkout. The fictional business has an additional rule: every price shown to a customer must already include mandatory fees, so a technically functioning calculation can still violate the product requirement.

Carlsen-Phelan shows two project configuration locations, .gitar/review and .gitar/rules. Review instructions can supply project context, while a rule can define a condition and an action. In the example, changes to pricing files trigger a check of customer-facing prices against the all-in rule.

He describes another possible rule: when a pull-request description contains a Slack link, an integration could use the conversation as review context. That is a product capability he describes, not an action performed by the reader of this article. Teams would need to configure whatever integrations and permissions they intend to use.

The demonstrated review lists pricing fields and indicates which prices include the fee. It flags that the event-facing price is not all-in. Carlsen-Phelan notes that this is a business-rule mismatch rather than necessarily a syntax or type error. He leaves the second exercise unmerged.

The third exercise demonstrates optional automation around a pull request that changes ticket scanning. The presenter enables GitHub auto-merge and configures a branch rule requiring status checks to pass. The workshop repository’s instructions contain the setup details for participants who want to reproduce the exercise.

The pull request has a failing test: a ticket that has already been scanned can be accepted again after the refactor. The review identifies the failed CI check and describes the missing protection. Carlsen-Phelan uses it to illustrate how an agent can inspect failure information instead of relying only on the diff.

He posts commands to enable auto-apply and auto-merge for this demonstration. He explains that auto-apply permits additional fix commits, and auto-merge is intended to act once the configured pipeline passes and the agent has no remaining findings. These actions depend on repository settings and the checks actually configured.

The presenter says Gitar will continue iterating and that automation can also be configured selectively by repository in its dashboard. During the recording, the tool is still working when he moves on; his explanation of the intended final merge should not be mistaken for an on-screen observation that the merge has already completed.

Luttrell-Williams returns to describe advanced capabilities beyond the main exercise. She says functional validation can compare a change with an associated Jira ticket and that integrations can bring in context from tools including Jira, Linear and Slack, when configured.

She describes a knowledge feature intended to learn conventions and use reviewer feedback, including feedback on false positives. She says reviewer seniority affects weighting and that the interface shows where review rules came from. These are product descriptions from the presenters, not independently tested results.

The presenters distinguish cross-repository analysis, which looks for a change that can break code in another repository, from cross-PR analysis, which examines in-flight requests that may pass individually but interact badly together. They show a dashboard with findings and information about why a finding matters.

In the closing questions, the presenters say Gitar can use MCP and other integrations for context. They distinguish project context from knowledge used to steer future review suggestions, and one presenter says he would need to follow up on the exact details of knowledge ingestion.