Talk from AI Engineer World's Fair 2026 examining how AI-generated code increases the volume and size of pull requests, straining CI and code review. Ali-Reza Adl-Tabatabai (co-founder of Gitar, now part of Sonar) presents agentic validation: an agent that reviews PRs with minimal noise, explains CI failures and detects flaky tests, applies fixes until the PR is green, and auto-approves/merges based on configurable rules. Covers a step-by-step trust-building path toward full automation, insights for platform teams and leaders, the underlying architecture (control plane, custom harness, LLM proxy), and combining agents with program analysis in SonarQube. # Channel Presentation Observations — Video: "AI Writes More PRs. Who Validates Them?" ## Explicit Self-Description - The speaker identifies himself and company affiliation: *"I'm Ali and um, I'm one of the founders of guitar.ai AI and previously the CEO up until about a month ago where we were acquired by Sonar and now we are part of Sonar."* - The channel/video context appears to be a **conference talk** rather than a personal channel: it opens with *"Let's get started. Um, good afternoon everyone"* and closes with an invitation to a physical booth — *"come on and visit us at booth number P7 right down the hall there."* ## Intended Audience - **Software engineering leaders and platform teams.** Evidence: - *"it's often times the main focus of your platform organization team or your platform team"* - *"Very very useful for platform teams"* (CI failure categorization) - *"This is extremely useful for leadership teams"* (PR categorization) - Practitioners concerned with CI, code review, and developer productivity — the talk assumes familiarity with CI, flaky tests, taint analysis, and PR workflows without defining them. ## Claimed Scope - The talk frames itself as addressing **code validation in the AI era**: *"you've heard a lot in the past few days about the importance of verification in the age of AI and so today I'm going to focus my talk on code and verifying code."* - Scope includes a product pitch (Guitar/ Sonar's agentic PR validation), technical architecture (*"control plane… agent runtime or harness… an NLM proxy"*), and a forward-looking thesis (*"agents uh doing a gentic validation plus an algorithmic program analysis will give you something that that I think is going to be much better than either alone"*). ## Observable Presentation Patterns - **Vendor talk with product demo framing** — heavily promotional but grounded in a specific engineering pain-point narrative ("costs in your development life cycle are kind of shifting to the right"). - **Trust-building adoption narrative** as a persuasive device: *"over time as they build trust in the system they unlock more levels of automation."* - **Post-acquisition positioning**: repeatedly links the acquired product to the parent brand — *"we're now also shipping uh as part of sonar,"* *"combining guitar with sonar cube."* ## Creator Claims vs. Demonstrated Content - **Claims** (not independently demonstrated): user adoption trajectory, accuracy of reviews, cost savings at *"a fixed PR price,"* improved developer sentiment. - **Demonstrated in the material**: feature descriptions (blocking merges, autofix loops, auto-merge rules, CI failure root-cause summaries) and architectural design choices — described verbally only, with no live walkthrough despite the demo offer at the booth. ## Self-Check All observations trace to quoted transcript passages; no channel-wide conclusions beyond this single conference talk were drawn, and no private motivations inferred. # Delivery Observation Report **Speaker:** Ali (Ali-Reza Adl-Tabatabai, Sonar) **Source:** Transcript only; no timestamps/metadata beyond the title. --- ## 1. Tone & Register - **Conversational-technical.** The delivery reads as a relaxed conference talk, not a formal paper reading. Openings are casual and direct: > "Let's get started. Um, good afternoon everyone. I'm Ali" - **Problem-then-solution structure with an emphatic, persuasive arc.** The speaker repeatedly frames pain in escalating terms before pivoting to the product: > "failures are expensive. They costly. They really slow down your velocity." --- ## 2. Vocabulary & Word Choice - **Heavy use of "expensive" / "cost"** as the dominant framing vocabulary for engineering problems: > "any kind of failure in this phase is very expensive" > "spending a lot of developer infrastructure dollars" > "all runs on very expensive infrastructure" - **"Much better" / "a lot of" as intensifier pairs**, especially in the value-summary section: > "much better quality, much better security... much higher productivity and sentiment" - **Domain shorthand used freely and without definition:** "PRs," "CI," "quality gates," "flaky tests," "outer loop" — assuming an experienced engineering audience. - **Product-name slippage/transcription instability:** "guitar.ai AI" and "guitar" appear throughout (likely a transcription of the actual company name, Greptile-style), alongside "sonar," "sonar cube." The speaker does not spell it out — one observable gap for a mixed audience. --- ## 3. Recurring Phrases & Rhetorical Habits - **"Kind of" as the dominant hedge/filler:** > "this becomes kind of a challenge" > "AI kind of makes the problem even worse" > "your costs... are kind of shifting to the right" > "your choices are kind of tough here" - **"Very" as a near-universal intensifier:** > "plays a very critical part" > "it's really good at catching flaky tests. That's a very popular feature." > "Very very useful for platform teams." - **Rhetorical question as a structural hinge:** > "So, what's the answer here? Of course, it's more AI." > "Now how does this work?" - **Buildup via "So" as a frequent sentence opener** ("So in in almost all software teams...", "So over time...", "So the overall results...") — used to move between slides/ideas. --- ## 4. Teaching & Explanation Habits - **Enumerated feature walkthroughs.** The product section is delivered as a stepwise feature list with explicit sequence markers: > "Well first when you create your PR... And then... And then you can also... And finally, you can automatically approve and merge..." - **Narrating a user journey as the explanation device.** Rather than abstract claims, the speaker teaches via an observed adoption trajectory: > "first they get reviews... so then they give teeth to the agent... then they start using the autofix capabilities... and then where the real interesting leap is..." - **Either/or framing to set up decisions:** > "either you slow down and ask developers to review every PR very carefully or you rubber stamp PRs" - **Three-part architecture explanation:** "There are three interesting pieces here" — control plane, agent harness, LLM proxy — an explicit numbered teaching structure. --- ## 5. Structural Communication Patterns - **Classic conference-talk macro-structure:** context → problem → AI worsening the problem → solution → product features → architecture → value summary → wrap-up → call to action ("come on and visit us at booth number P7"). - **Symmetric problem/solution framing** in the close, mirroring earlier claims: > "AI turns validation into a friction point. And guitar... allows you to automate this step, fully automate PR validation." - **Parallel value bullets** in the results section ("much better quality, much better security... faster delivery times... much higher productivity"). --- ## 6. Isolated Moments (Low Confidence — Not Treated as Patterns) - **Self-deprecating or transitional slips** ("They costly", "in in almost all", "as as you scale") appear as speech disfluencies, common in live delivery; no pattern claimed from a single talk. - **The closing booth call-to-action** ("right down right down the hall there") is the only moment of direct audience-directed logistics — a single occurrence, not established as a habit. --- ## Confidence Notes - Hedge ("kind of"), intensifier ("very"), and rhetorical-question habits are supported by **multiple independent instances** and are treated as stable. - The enumerated and journey-based teaching habits are strongly represented in one contiguous product section; whether they characterize the speaker's teaching across other talks **cannot be confirmed from this single transcript**. # Observation Record: "AI Writes More PRs. Who Validates Them?" — Ali-Reza Adl-Tabatabai (Sonar) ## Speaker Context - **Speaker:** Ali-Reza Adl-Tabatabai, self-identified as a founder of "guitar.ai" (as rendered in the transcript) and former CEO "up until about a month ago," when the company was **acquired by Sonar**. - **Stated talk focus:** Verification of code in the age of AI. > *"You've heard a lot in the past few days about the importance of verification in the age of AI and so today I'm going to focus my talk on code and verifying code."* --- ## Position 1: Centralized Validation Is Critical but Increasingly Problematic **Claim:** Nearly all software teams rely on a centralized validation phase — CI plus code review — which is critical, especially in an AI-driven world. **Stated reasoning — why it matters:** - Enforces **quality gates** centrally (security, compliance, code quality). - Sits on the **critical path** to production ("the faster is always the better"). **Stated reasoning — why it breaks down at scale:** - Longer-running builds and tasks; asynchronous review across sites and geographies slow things down as organizations grow. - Heavy **developer infrastructure spend**: expensive tools and infrastructure that must scale. - Any failure is costly — introducing an **outer loop measured in hours and days**, lost developer time, and disruption to flow state. - Optimization is hard due to **fragmented systems**, bespoke configuration/scripting, and a headcount-constrained platform team. - AI-based fixes are complex, requiring workflow orchestration, asynchronous interactions, team workflows, and tool integrations. --- ## Position 2: AI Makes the Validation Problem Worse **Claim:** AI-generated code increases PR volume and size, shifting costs "to the right" in the development lifecycle. **Stated consequences:** - More code to review; more potential for production failures. - A forced dilemma: > *"Either you slow down and ask developers to review every PR very carefully or you rubber stamp PRs and you risk incidents in production."* - Either path yields "less happy developers, lower sentiment, and much less productivity." --- ## Position 3: The Answer Is Agentic Validation **Claim:** The solution is "more AI" — an **agentic approach to validation**, which is what his company built and now ships as part of Sonar. **Claimed capabilities (as described by the speaker):** - **Review:** Posts issues and inline comments, with a stated goal of a "noise-free" experience; customizable rules, checks, and workflows; optional merge-blocking on unresolved findings. - **CI analysis:** Analyzes CI failures and posts root-cause summaries; described as "really good at catching flaky tests" with automatic retry rules ("a very popular feature"). - **Autofix:** Can fix review issues and CI failures, including looping automatically until all flagged issues are fixed. - **Auto-approve and merge:** Rules define when green PRs are automatically approved and merged. **Claimed adoption trajectory:** Users progressively unlock automation as trust builds — reviews first, then merge-blocking ("give teeth to the agent"), then autofix, then full auto-merge. **Qualification to preserve:** This trajectory is presented as an observed "trend" among their users, not a universal rule. --- ## Position 4: AI Enables New Insights **Claim:** Because every PR is processed by AI, new organizational insights emerge: - **CI failure categorization** (flakiness vs. infrastructure vs. other) — described as "very useful to platform teams." - **PR categorization** (feature work vs. fixes, chores, refactors) — described as "extremely useful for leadership teams." --- ## Position 5: Architecture Claims **Claimed components:** - A **control plane** orchestrating PR workflows. - A **custom agent harness/runtime** handling multi-agent execution, context and memory management, tool calling, and integrations — enabling optimization for "token cost, precision and coverage." - An **LLM proxy** for model routing and failover. **Claimed outcome of the custom harness:** the ability to "guarantee outcomes at a fixed PR price while giving really good quality results." *(This is the speaker's marketing claim, presented without stated evidence in the transcript.)* --- ## Position 6: Agents + Program Analysis **Claim:** Combining agentic validation with **traditional program analysis** (taint analysis, control flow, data flow, software composition analysis) via SonarQube integration offers "much better precision, much better coverage at a really great price point." **Closing claim:** > *"The combination of using agents doing agentic validation plus an algorithmic program analysis will give you something that I think is going to be much better than either alone."* **Qualification:** This final claim is framed tentatively ("I think"), unlike the more assertive product claims earlier. --- ## Claimed Overall Value (as summarized by the speaker) - Better quality and security, "especially with AI generated code." - Faster delivery via full automation to approved/merged PRs. - Higher developer productivity and sentiment; less review grunt work. - More leverage for platform teams. --- ## Notes on Traceability - **All positions above** belong to the single identified speaker, per his self-introduction. - No transcript evidence supports independent verification of performance, adoption, or outcome claims; these are recorded as **speaker assertions**, not established facts. - The transcript renders the company name inconsistently ("guitar.ai"); no curated metadata contradicts or confirms the actual spelling, so it is preserved as expressed. # Attribution Observation: Speaker Roles and Provenance ## Video Identification - **Video ID:** 01a15ca6-ddf4-78f4-8ec1-aeea19c289f1 - **Title (as supplied):** "AI Writes More PRs. Who Validates Them? — Ali-Reza Adl-Tabatabai, Sonar" - **Metadata available:** Title only. No curated speaker list, cited-source list, comment data, or description was supplied. --- ## Speakers and Roles ### Speaker 1: Ali-Reza Adl-Tabatabai (sole identified speaker) - **Identity basis:** Named in the title. Self-introduced in the transcript as "Ali." - **Stated roles in transcript:** - One of the founders of "guitar.ai" (transcribed as such; the product is also referred to as "guitar" throughout) - Previously CEO of that company "up until about a month ago" - States the company was acquired by Sonar, and is now part of Sonar - **Speaking role:** Presenter delivering a conference talk. Opens with "Let's get started" and closes with an invitation to visit a booth. - **Affiliation as stated:** Sonar, per the title, and the speaker's own statement that the company is now part of Sonar. ### Other Voices - **None identified.** The transcript contains a single continuous speaker. No Q&A, panel, or guest segments appear. --- ## Provenance Inventory ### Referenced Sources - **Named external sources:** None. No papers, reports, datasets, or third-party publications are cited. - **Unnamed references:** - "You've heard a lot in the past few days about the importance of verification in the age of AI." This refers to unidentified prior sessions or events. - **Tool references (not sources of claims):** "SonarCube" (transcribed as "sonar cube") is named as a product the speaker's company is integrating with. ### Third-Party Claims - **None attributed to external parties.** Assertions about the industry, such as the claim that AI increases PR volume and size, are presented in the speaker's voice without a named source. - **Speaker-attributed user observations:** The speaker describes trends "in our users," including a progression from reviews to blocking, autofix, and auto-merge. These come from the speaker's own company and are not independently sourced in the transcript. - **Unverified outcome claims:** The speaker states value outcomes (quality, security, delivery time, productivity, sentiment) as results "we're seeing." No measurement method, dataset, or source is given. ### Promotional Segments **The entire presentation is promotional.** Specific flagged segments: - **Product description:** Extended walkthrough of the agentic PR validation product, its features, and its architecture (control plane, agent runtime, LLM proxy). - **Pricing claim:** Reference to "guaranteeing outcomes at a fixed PR price." - **Integration announcement:** Describes the planned combination of the product with SonarCube (transcribed "sonar cube") and program-analysis techniques. - **Call to action:** "Come on and visit us at booth number P7" and an offer of a demo. ### Availability Limits - **Comments:** No comment-availability information was supplied, so it cannot be determined from the record. - **Slides, demos, and visuals:** The transcript references a demo and a product walkthrough, but no visual material was supplied. - **Transcript fidelity:** Product and company names appear inconsistently ("guitar" / "guitar.ai" / "sonar cube"). Names are recorded here as transcribed and should be checked against a primary source before citation. --- ## Summary for Downstream Use - **One speaker:** Ali-Reza Adl-Tabatabai, presenting as a former CEO and founder of the product company, now part of Sonar. - **No external sources or third-party claims** are cited. All claims originate with the speaker or the speaker's company. - **Whole-talk promotion:** Every segment is product promotion, including a booth invitation and a demo offer. - **Missing channels:** No comment data, no visuals, and no curated metadata beyond the title. Let's get started. Um, good afternoon everyone. I'm Ali and um, I'm one of the founders of guitar.ai AI and previously the CEO up until about a month ago where we were acquired by Sonar and now we are part of Sonar and you've heard a lot in the past few days about the importance of verification in the age of AI and so today I'm going to focus my talk on code and verifying code. So in in almost all software teams there is this centralized validation phase that is basically CI plus code review and as you scale your engineering this plays this phase plays a very critical part especially in an AI world. Uh first it enforces all your quality gates centrally. So these are security compliance code quality gates. It's on the critical path of getting your changes into production. So the faster is always the better. But as you scale engineering, this becomes kind of a challenge. As as you have longer running builds and tasks, you have asynchronous team review flows across sides and geographies and things just get slower naturally as you grow. Um, this is also a phase where you end up spending a lot of developer infrastructure dollars. So there's a lot of expensive tools here that need to be integrated and scaled up as you um scale your organization and it all runs on very expensive infrastructure. Uh for these reasons it's often times the main focus of your platform organization team or your platform team. Um but any kind of failure in this phase is very expensive. It introduces failures introduce an outer loop that are typically measured in hours and days. So failures are expensive. They costly. They really slow down your velocity. Uh you lose developer time and that's compounded by disruptions to your flow state. It's also very expensive to optimize. So you've got a lot of fragmented systems that have been integrated together with bespoke configuration and scripting. and you have a usually headcount restricted, constrained platform organization trying to keep it all up and running for you. And trying to address that all with AI is also kind of complex because it requires complex workflow orchestration involving various inter asynchronous interaction, team workflows, integrations across tools and so on. In fact, AI kind of makes the problem even worse. uh you've got a lot of PRs now being generated, more PRs than before uh thanks to AI and bigger PRs uh all of which can have defects and so your costs in your development life cycle are kind of shifting to the right. You have a lot more code to review. You can have potential for a lot more failures in production and and so your choices are kind of tough here. either you slow down and ask developers to review every PR very carefully or you rubber stamp PRs and you risk incidents in production. Either way, you've got less happy developers, lower sentiment, and much less productivity than than you'd expect. So, what's the answer here? Of course, it's more AI. It's uh an agentic approach to validation which is essentially what we built at guitar um that we're now also shipping uh as part of sonar. And basically what we've got here is an agent that fully automates all the validation steps and as outcomes it delivers for you green PRs that are ready to merge or merge automatically. Now how does this work? Well first when you create your PR it reviews your PR and posts issues and inline comments. No surprise there. But our goal has been to really make this experience as noisefree as possible, both in the way we handle the UX as well as posting issues that are real and really matter. You can customize your review with your own rules and you can add your own custom checks and you can trigger your own custom workflow automations. And then you can also configure the system to block merging if there are any unresolved code review findings. It also analyzes CI failures and posts a summary of the root causes of those failures. And in particular, it's really good at catching flaky tests. And you can even set up rules that automatically retry flaky tests if you want. That's a very popular feature. You can also automatically fix any code review issues or any CI failures. Any kind of uh failures that happen in CI, it can fix it for you as well as address any of the issues that it raises. You can either ask it to specifically fix an issue or more interestingly you can set it up to automatically loop until all the fish issues have been fixed in your PR and you have a green PR ready to merge. And finally, you can automatically approve and merge PRs that are green. you can define rules and conditions that control when uh PRs get automatically approved by the agent and merged automatically. So we're seeing actually a very interesting trend in our users. There's a clear trajectory towards fully automated PRs. uh as users use the system and as they build trust in the accuracy of the AI what we see is they work towards full automation first they get reviews and they're happy with they build trust in the accuracy of the reviews they see that these reviews are not only accurate but they're raising really important issues so then they give teeth to the agent by allowing it to start blocking the PRs and then they start using the autofix capabilities to automatically turn PRs green and fix all the issues that were raised by code review or any CI failures that come up. And then where the real interesting leap is beginning to happen now is users setting up rules that define when the agent automatically approves and merges PRs. So over time as they build trust in the system they unlock more levels of automation and with the additional levels of automation and with the trust they're getting more value out of the system. Now because the system processes every single PR using AI it's also able to uncover new types of insights. For example, uh one of the insights that are is very useful to platform teams is a categorization of the top CI failures. Where are you seeing failures in your CI system where your developer is running into failures? Are these flakiness issues that you can that you need to address by improving the reliability of the tests or are there infrastructure issues that you need to address or are there other kinds of failures that they're running into? Very very useful for platform teams. We also have another example of what what else we have in terms of AI enabled insights are categorization of PRs. What exactly is happening across your engineering team in terms of the PRs that are being landed? This is extremely useful for leadership teams. For example, what amount of PRs are going to feature development versus fixing issues, chores, refactors, and so on. Now under the hood, if you look at the system, there's a number of components that constitute guitar. There are three interesting pieces here. One is the control plane that acts as this orchestration layer for handling PR workflows. And then there's an agent runtime or or harness. We built our own harness here that handles multi- aent execution, context management, memory management, um tool calling, all the integrations, etc. And having this having our own agent harness has really allowed us to optimize specifically for the validation use case and it's allowed us to optimize for token cost, precision and coverage of the agent itself. So that allows us to essentially guarantee outcomes at a fixed PR price while giving really good quality results. We also have an NLM proxy that handles the routing across different models as well as things like failover. Now that we're part of Sonar, we've been integrating guitar with sonar cube. There's a ton of opportunity here in combining an agentic approach to validation with program analysis. So combining agents with things like u taint analysis, control flow analysis, data flow analysis, software composition analysis. So all the traditional approaches combined with agents. We think there's a ton of opportunity here and that together you can get much better precision, much better coverage at a really great price point. So the overall results uh the value that we're seeing in in all of this is much better quality, much better security, especially with AI generated code, faster delivery times through all the automation going from PRs straight to approved and merged PRs, much higher productivity and sentiment by developers. So less time spent on actually reviewing code and worrying about what's happening in production with more confidence as well as sentiment because now you much better sentiment now because you have a lot of automation in place and less grunt work. And finally the to the features that we've built for platform teams gives them a lot more leverage to be able to fix issues and to add customizations and see insights in this critical part of the software development life cycle. To wrap up, PR validation is really critical, even more so in AI, but AI turns validation into a friction point. And guitar, what we've built, allows you to automate this step, fully automate PR validation, go from created PRs all the way to merge, completely eliminating this friction and helps you keep up with the rate at which you're generating code from AI. And finally, the combination of using agents uh doing a gentic validation plus an algorithmic program analysis will give you something that that I think is going to be much better than either alone. If you want to talk more and you want to see more, if you'd like to see a demo, come on and visit us at booth number P7 right down right down the hall there. Thank you.