AI coding agents changed a basic equation in software development: teams can now generate far more code without adding more engineers. At Tinder, PRs entering review nearly doubled while changed lines entering review grew 3.3×. Active reviewers grew only 27%, review load per reviewer rose 69%, and the month-end review backlog nearly doubled. PRs got larger, too: median changed lines per PR rose from 36 to 102, while the number of available reviewers stayed largely the same. That did not just make review slower. It made review worse. PRs became larger and harder to understand. High-priority work competed with everything else in the queue. The engineers with the most relevant context were not always included. On Android, validating a change often still requires a reviewer to check out the branch, build the app, and manually reproduce the relevant state. Agent-generated work also made it less clear who was ultimately accountable when something went wrong. The obvious response is to add an AI code reviewer. That can help, but reviewing a diff is only one part of the problem. A code-review system also determines what gets attention first, who has the right context, how behavior is validated, and who is responsible for the outcome. In this talk, we’ll share how we are rethinking that system. Some changes happen before a PR is opened: giving agents access to ticket context, architectural decisions, and repository-specific standards; splitting large changes into smaller stacked PRs; and catching obvious issues before requesting human attention. Other changes reshape the review itself: prioritizing PRs using risk and business context, finding reviewers with the right domain knowledge, varying approval requirements based on the change, and making Android behavior easier to verify with automated screenshots, videos, and ready-to-run builds. We’ll also cover what should remain human, including architectural judgment, product intent, accountability, and the mentoring that has traditionally happened through code review. Attendees will learn how to: Recognize when code review has become their team’s delivery bottleneck. Prioritize review work using risk, business urgency, and domain expertise. Give agents the context needed to produce smaller, more reviewable changes. Make Android behavior easier to validate without rebuilding every change locally. Decide which parts of review can be delegated and which still require an accountable human.