Ameya Ketkar works on automated refactoring and AI code review, building tools that help engineers change large codebases and evaluate proposed changes. His contributions span research on Java type changes, multi-language code transformation with PolyglotPiranha, and Uber’s collaborative uReview effort. These projects address two connected problems: following the consequences of an edit through a program and producing automated advice that developers can use.
From banking software to Java refactoring
Ketkar studied computer engineering at Mumbai University and worked as a Java developer at Barclays Technology Center India in Pune, contributing to the investment bank’s trade and transaction reporting platform. That experience prompted his interest in tools that improve developers’ effectiveness. He subsequently pursued doctoral research at Oregon State University with Danny Dig, working on static analysis, software refactoring, and empirical software engineering. His historical professional biography records this transition from banking software to developer-tool research.
A central problem in that research was replacing one type with another. Changing a declaration can require corresponding changes to method calls, assignments, parameters, and return values. In his discussion of software-development tools, Ketkar compared this to replacing a central character in a long novel: the consequences extend throughout the text. His research sought to help programmers identify and carry out those connected edits.
With Nikolaos Tsantalis and Dig, Ketkar studied 297,543 type changes across 129 Java projects. Within that corpus, type changes occurred more often than renamings but received less support from development tools. Migrating from an older date API, for example, could require replacing both a formatter and the type of the date it produced. Studying actual project histories exposed the adaptations that an automated refactoring tool would need to handle. His TypeChangeMiner repository accompanies this work.
Ketkar also co-authored IntelliTC, an IntelliJ IDEA plugin that applies Java type-change refactorings using rewrite rules inferred from commit histories. The project explored how developers could encounter that assistance through explicitly requested refactorings, suggested changes, and editor inspections. It connected evidence about how programmers already change code to tools that could help them make similar changes.
Taking refactoring across languages
After completing his PhD in September 2021, Ketkar joined Uber’s programming-languages research group. He later became a founding engineer at Gitar, where his 2024 professional biography describes work on multi-language program analysis and refactoring; the presenters’ introductory slides identify his founding-engineer role. By his 2026 AI Engineer appearance, he was again affiliated with Uber and contributing to uReview.
PolyglotPiranha, developed at Uber with Daniel Ramos, Lazaro Clapp, Raj Barik, and Murali Krishna Ramanathan, extended code transformation across programming languages. A company may need the same conceptual cleanup in several languages, while conventional transformation tools require separate implementations for each. The team’s code-transformation language connects rewrite rules into a graph: each rule specifies an edit, and the connections determine which rule runs next and where it applies. This structure expresses cascading changes without requiring a complete compiler-based tool for every task.
Retiring a feature flag provides a concrete example. A transformation can replace a flag check with its known value, simplify the resulting condition, and remove code that can no longer execute. Those are successive steps in one cleanup, rather than unrelated text replacements. PolyglotPiranha supported cleanup and migration across Uber’s Java, Kotlin, Swift, and Go code.
Building automated code review with uReview
With uReview, Ketkar contributes alongside Will Bond and other Uber engineers to automated review of proposed changes. In their joint account of the system, the team describes routing requests from GitHub, Phabricator, and agent workflows to reviewers with different cost and performance characteristics. Post-processing rates, categorizes, filters, and deduplicates their comments so developers receive actionable findings rather than an accumulation of overlapping suggestions.
Making reviews useful through feedback and team rules
Developer feedback: The team’s evaluation work asks whether those findings help developers. Early cost tracking, satisfaction surveys, and support feedback gave limited insight into individual reviews. Classifying developers’ replies helped identify recurring mistakes and frustrating comments. Tracking the addressal rate—whether developers acted on a review comment—added a measure of practical usefulness. These signals serve different purposes: sentiment captures a developer’s response, while addressal records action. Neither alone establishes that a comment is correct.
Agent trajectories: Inspecting agent trajectories, including tool calls and execution paths, helped the team understand how a reviewer reached its result and where it spent unnecessary effort. That information supported runtime tuning and guidance about what agents should avoid doing within a limited review window. The team also found that confident model output needed grounding in each team’s conventions, style guides, and known failure patterns.
Team-specific review rules: uReview supports single-file logic checks, deeper multi-file reviews, AI linters for systematic issues, and custom agents that can use team knowledge bases and previous pull requests. Its customizations sit near the code and connect to Uber’s ownership model, allowing teams to maintain their own review rules. Routing determines which reviewers and models apply to a change; sentiment, addressal data, and trajectory information return to the teams maintaining those rules. A skill generated from earlier pull-request reviews can be easy to write. Running it repeatedly with useful results at an acceptable cost requires evaluation and revision.
uReview’s reported quality and cost results
In the 2026 presentation, Bond and Ketkar reported roughly 25,000 uReview comments per week, feedback on about 10% of comments, an overall addressal rate of approximately 67%, and action on nearly three quarters of high-severity findings. They also reported a 60% cost reduction relative to a naive implementation. These were team-reported results for the system described in the talk. Uber’s August 2026 engineering account also names Ketkar among the core contributors to its Software Factory efforts and describes evaluating uReview’s quality and cost against benchmarks drawn from real work.
Will Bond and Ameya Ketkar explain how Uber routes code changes through multiple reviewers, filters their output, learns from developer behavior, and lets hundreds of teams maintain local rules without giving up platform-wide consistency.
uReview separates review surfaces from generators, then rates, categorizes, filters, and deduplicates candidate comments before delivering them.
Useful observability combines what developers say, what they change, and how the agent produced its finding: sentiment, addressal rate, and agent trajectories answer different questions.
Team-owned review rules need ownership integration, nearby configuration, deterministic routing, and feedback to their authors. Writing a skill was easier than operating it consistently and cheaply at scale.
Uber reports around 25,000 comments per week, a 67% addressal rate, and 60% lower cost than a naive implementation. Addressal measures developer behavior, while the reported 70% quality and accuracy improvement lacks enough methodology to reproduce.
Agent-facing reviews need greater accuracy because a bad comment can induce repeated changes and reversals. As agents assume more detailed work, the speakers propose moving human review toward architecture, domain expertise, and product judgment.
▶ Watch ↗