- Ali-Reza Adl-Tabatabai argued that AI-written code moves the bottleneck to review and testing, where teams must slow down or approve changes without real scrutiny.
- He sells a tool that automates this checking, so his proposed fix is a vendor's view, and the talk gave no data on incident rates.
Ali-Reza Adl-Tabatabai argued that AI coding tools do not remove the bottleneck in software delivery. They move it. He helped found Gitar, a company since folded into Sonar, and he was a guest on the AI Engineer show. In his telling, the slow point becomes checking code: human review and automated testing, known as CI. Teams then face a hard choice, and he warned that approving changes without checking them risks incidents in production.
What was said
Adl-Tabatabai started with the pull request, or PR: a proposed code change that waits for review before it joins the product. AI, he said, increases both how many arrive and how big they are. In his words: "You've got a lot of PRs now being generated, more PRs than before, thanks to AI, and bigger PRs, all of which can have defects."
He said this pushes cost later in the process, because "your costs in your development lifecycle are kind of shifting to the right." More code needs review, and more can fail in production. That leaves two options. Developers can slow down and read every change closely. Or they can approve changes without real scrutiny and risk incidents. Either way, he said, developers are less happy and less productive than expected.
He also noted that CI was already slow and costly. Many companies run fragmented tools joined by custom scripts, kept alive by small platform teams. His answer is an AI agent that reviews changes, explains test failures, spots flaky tests (tests that fail at random), fixes problems, and merges changes under rules the team sets. He said users unlock more automation as they build trust.
Why it matters
Our reading: faster code generation does not mean faster delivery. If review and CI capacity stay flat, the extra output has to go somewhere. Adl-Tabatabai's point is that it often goes into production with thinner checks.
For engineering leaders, that suggests measuring more than output. Ask how review load has changed since AI tools arrived, and whether reviewers still have time to read what they approve. Rubber-stamping is rarely a policy. It tends to happen by default when queues grow. Buyers of software can ask vendors how changes get checked before release.
The other side
Adl-Tabatabai sells a product in this area, and the talk ended with an invitation to visit his company's booth. His fix is, in his words, "more AI," which raises the question of who checks the checker. He said trust builds over time, which implies early use needs close human oversight.
He also gave an opinion, not a measurement, that agents combined with traditional program analysis would beat either alone. The excerpts give no figures on how many more PRs AI produces, or how often rubber-stamping leads to incidents. The argument is a vendor's reasoning, not tested evidence.
Written by the WebPulse Newsroom with AI assistance, and checked by our editorial review: every quotation was verified against the recording's transcript. How we use AI.
The conversation this talking point comes from
- AI Engineer: AI Writes More PRs. Who Validates Them? — Ali-Reza Adl-Tabatabai, Sonar (2026-10-09)
