Sonar’s Killian Carlsen-Phelan and Taylor Luttrell-Williams demonstrate Gitar on a prepared Python ticketing app in this 38-minute AI Engineer workshop.

Review the behavior around the change

  • Their sample app, Box Office, supports purchases, refunds, and ticket check-in.
  • Three prepared pull requests separate missing behavioral coverage, undocumented business requirements, and a failing existing test.
  • Gitar combines the diff with repository context, review instructions, and continuous integration (CI) logs.

A green build misses a refund bug

  • The first change lets a buyer transfer a ticket to a friend; its new tests pass.
  • Existing cancellation code still lets the original buyer refund and void the transferred ticket.
  • Gitar points to orders.py, outside the new diff, and proposes an additional check.
  • Carlsen-Phelan requests a fix, then later returns to show the resulting patch and approval.

Put business rules where the reviewer can read them

  • The second change adds a $3.50 service fee, making a $50 ticket cost $53.50.
  • Box Office’s stated rule requires every customer-facing price to include all fees.
  • Instructions in .gitar/review/ supply that context; .gitar/rules/ can trigger checks when pricing files change.
  • The demo flags a price that violates the rule. This pull request is deliberately left unmerged.

Diagnose, patch, rerun, and control merging

  • The third change refactors check-in and fails an existing test: an already-used ticket can be scanned again.
  • Gitar reads the CI failure and is configured to apply fixes and merge after the required checks pass.
  • GitHub’s auto-merge setting and an active branch ruleset requiring the test check are part of that setup.
  • The presenters move on while the final fix-and-merge cycle is still running; the recording does not establish its completed result.

More context increases the review surface

  • The closing overview covers linked Jira, Linear, and Slack requirements, learned review conventions, and cross-repository analysis.
  • Cross-PR checks target changes that pass separately but conflict when combined; those capabilities receive a brief overview rather than the three-exercise treatment.
  • Choose write and merge permissions per repository, keeping required checks under independent control.

“Every false positive is a token spent and a fix attempt that risks an unintended change.” — Taylor Luttrell-Williams, 9:18

Caveat: these are prepared vendor exercises. Passing their checks establishes the covered behavior; it does not establish general bug-detection accuracy or safe unattended merging.