Ali-Reza Adl-Tabatabai, Founder and CEO at Gitar – Interview Series

Ali-Reza Adl-Tabatabai, Founder and CEO at Gitar, is a veteran engineering leader whose career spans some of the most influential technology companies in Silicon Valley, including Uber, Google, Facebook, Intel, AMD, and IBM. Before launching Gitar in 2023, he served as Senior Director of Engineering at Uber, where he helped lead the company’s developer platform initiatives, following earlier leadership roles at Google overseeing Site Reliability Engineering for products such as Communications, Photos, Social, Cloud, and technical infrastructure.

Earlier in his career, he worked on compiler technologies, virtual machines, parallel computing systems, and hardware optimization at Intel Labs and Facebook’s HipHop VM team, while also teaching advanced compiler design at Stanford University. His decades-long background in programming languages, infrastructure reliability, developer tooling, and large-scale systems architecture has positioned him as a prominent figure in the evolving AI-powered software engineering landscape.

Gitar is focused on a growing problem emerging from the rise of AI-assisted software development: validating and securing the enormous volume of machine-generated code now flowing into enterprise systems. The platform uses AI agents to automate code review, investigate CI/CD pipeline failures, identify bugs and vulnerabilities, recommend fixes, and integrate directly into existing engineering workflows through tools such as GitHub, GitLab, Jenkins, Jira, and Slack. Rather than competing solely in AI code generation, the company is positioning itself around what it describes as “agentic quality gates,” helping engineering teams maintain reliability, security, and operational oversight as software development increasingly shifts toward autonomous and AI-assisted coding workflows.

You’ve led engineering at Uber, Google, and Intel Labs, working on large-scale developer platforms and infrastructure. What specific experiences from that journey led you to found Gitar, and why focus on code validation instead of code generation?

Across Uber, Google, Facebook, and Intel Labs, I worked on developer platforms at very different scales, and the same lesson kept showing up: developer experience is a competitive advantage. Great tools attract and retain the best engineers and let companies move fast. Developers want fast, noise-free tools that keep them in flow and automate the grunt work. But developer tooling is deeply fragmented, and most companies burn enormous engineering resources just stitching a coherent experience together. I saw firsthand how much leverage there is in fixing that.

AI changes the equation by making it possible to automate far more of the developer workflow than before. Code generation is already well covered, but that has only shifted the bottleneck downstream, to validating, refactoring, and maintaining the code we’re now producing at unprecedented volume. That’s where Gitar is focused. As AI writes more code, the scarce resource isn’t generation; it’s the trust, correctness, and maintainability of what gets shipped. Code validation is the part of the workflow that determines whether AI-generated code actually makes it to production safely, and that’s the harder, more valuable problem to solve.

With the rise of AI-generated code, many teams are now dealing with what some call code overload. How significant is this problem inside enterprises today, and where are teams struggling the most?

The shift isn’t in writing code. That part is already moving faster than most teams can absorb. What’s changed is everything that comes after. AI tools are generating a steady stream of pull requests, often faster than teams can review them, which creates pressure in parts of the system that were never designed for this level of output.

Every change still has to pass through validation. Code review. CI. Security checks. Approvals. None of that disappears just because code is generated faster. What used to be a manageable flow has turned into a backlog. Teams are not blocked on ideas or implementation anymore. They are blocked on confidence. Can this ship? Is it safe? Did it break something subtle?

That’s where the friction sits now. Not in creation, but in getting code across the finish line without introducing risk.

The industry has largely focused on generating code faster. Why do you believe validation has been overlooked, and why is it becoming more critical now?

Because the system downstream of code generation hasn’t evolved at the same pace. When output increases, everything downstream gets stressed. Pull requests get larger and more frequent. CI failures start stacking. Review cycles get compressed because no one has the time to go deep on every change.

Quality starts to slip, not because engineers don’t care, but because the volume forces tradeoffs. Platform teams take on more of the burden, handling pipeline issues, triaging failures, and trying to keep things moving. Senior engineers end up acting as coordinators, piecing together logs, diagnosing issues, and deciding what is safe to merge.

Teams face a choice that doesn’t really work either way. Push code through quickly and deal with regressions later, or slow down and protect quality, but accept that velocity drops. That tension is showing up across engineering orgs right now.

Gitar uses AI agents to handle code reviews, testing, and continuous integration (CI) workflows. How do these agents fundamentally differ from traditional static analysis tools and rule-based pipelines?

The difference is not cosmetic. A real agent needs to do more than respond to prompts. It needs to handle multi-step work, plan, use tools, keep track of context, and move tasks forward without constant input.

Most systems don’t meet that bar. They generate outputs, but they don’t manage execution. When these tools are placed inside real workflows, the gaps show up quickly. They don’t reduce complexity. In many cases, they add another layer that someone has to manage.

That’s why the conversation is shifting from “do we have agents” to “what work can actually be handled reliably.”

Trust is a major barrier to automation in software development. How does Gitar ensure that its validation process is reliable enough for teams to depend on?

The pattern that works is simple. Break work into smaller steps. Define clear boundaries. Validate outputs continuously. Keep humans involved where decisions carry risk.

Agents can review code and surface issues that are easy to miss at scale. They can analyze CI failures, group related errors, and point to a likely root cause. They can suggest fixes and, in some cases, apply them in a controlled way.

This reduces the amount of manual triage engineers have to do. It doesn’t remove engineers from the loop, but it changes where they spend time. Most systems operate with checkpoints, not complete independence.

Your platform allows teams to create their own agents. How important is customization for enterprise adoption, and what are some of the most interesting use cases you’re seeing?

Customization is essential for enterprise adoption. Every platform team spends significant resources tailoring CI to their company’s specific needs, and this has traditionally required bespoke scripts, configuration, tool integrations, log processors, and the rest of the duct tape that holds modern dev infrastructure together.

Gitar collapses that work. Platform teams can write custom checks using natural-language prompts, which lets them validate things that are difficult or impossible with traditional program analysis, for example, flagging user-facing strings that are ambiguous for translation, or validating updates to AGENTS.md files. They can also automate custom workflows on top of pull requests: linking PRs to Jira issues, opening follow-up tickets for unresolved review comments, automatically retrying flaky tests, or appending custom to-do lists to PR summaries.

The most interesting use cases tend to be ones we didn’t anticipate. Teams know their codebases and their pain points better than any vendor does, so when you give them a primitive that turns “we wish CI could just check X” into a 10-line prompt, they immediately start automating things we’d never have built by default. That’s exactly what we want.

Modern engineering teams rely on a complex stack of tools like GitHub, GitLab, and Jira. How important is it for Gitar to integrate into existing workflows rather than trying to replace them?

Adoption depends on meeting developers where they already are. Engineers don’t want another surface to learn, another dashboard to check, or more context-switching between tools. They want their existing workflows to get faster and quieter. So integrating deeply with GitHub, GitLab, Jira, and the rest of the stack isn’t a nice-to-have for us; it’s the whole strategy.

But our ambition goes further than integration. We’re not trying to replace these tools, and we’re not just trying to plug into them either. We’re automating the workflows that run across them. The PR review, the ticket linking, the follow-up tasks, the flaky test retries, all of it should happen autonomously, in the background. And we’re pushing further: an agent edits the PR directly to address code review feedback and fix CI failures, and ultimately handles approval and merge for changes that meet the team’s policies. The developer’s role shifts from driving each step to setting intent, reviewing outcomes, and handling exceptions.

The end state isn’t a new tool developers log into. It’s the existing tools doing more on their own, so developers can stay focused on the work that actually requires their judgment.

You’ve suggested that human code reviews could eventually become the exception rather than the rule. What needs to happen for organizations to feel comfortable with that shift?

Trust gets built in stages, not all at once. Organizations need to see, with their own code, that AI can find the bugs and vulnerabilities that actually matter and enforce their custom rules with precision and high coverage. From there, the path to autonomous merging is a natural progression through four levels of increasing trust.

The first level is detection. Teams build confidence that agents find real issues with a low false-positive rate. Once that confidence is established, they let the AI automatically block PRs when it finds critical issues.

The second level is remediation. The AI doesn’t just flag problems, it fixes them, unblocking the PR and turning CI green without human intervention. Trust here means the agent can resolve issues and CI failures precisely, without breaking things.

The third level is approval. Once teams see agents reliably turn PRs green, they let the AI approve PRs under rules they define. Giving organizations explicit control over the conditions for auto-approval is what makes this step feel safe rather than reckless.

The fourth level is merge. The AI lands the change, again under conditions the team is comfortable with. This step has its own bar: the agent has to resolve merge conflicts precisely, without introducing regressions or breaking main. That matters more than people realize, because conflict frequency goes up with commit throughput, and throughput is exploding as AI generates more code. Large monorepos already feel this; everyone else is about to.

The shift to AI as the default reviewer isn’t a single leap of faith. It’s a ladder, and organizations climb it one rung at a time as the evidence accumulates.

As AI takes on more of the coding process, how do you see the role of senior engineers evolving over the next few years?

Senior engineers are already shifting into coordination roles, piecing together logs, diagnosing issues, and deciding what is safe to merge. That’s not a role anyone planned for. It’s a reaction to the system breaking under load.

As agents take on more of the repetitive validation work, engineers stay in the loop but move higher up the stack. They spend less time on manual triage and more time making decisions about what should ship and why.

Gitar recently raised $9 million to scale the platform. What are your top priorities for that capital, and what does success look like over the next 12 to 18 months?

The capital goes toward two priorities. The first is go-to-market: we’re scaling our enterprise motion and investing in developer awareness so the teams who’d benefit from Gitar actually know we exist. The second is product: we’re continuing to build toward our vision of fully autonomous code validation and quality, which means deeper agent capabilities, broader workflow coverage, and tighter integration with the tools developers already use.

Success over the next 12 to 18 months looks like a meaningful base of enterprise customers running Gitar across their codebases, a developer community that recognizes us as the default for AI-driven code validation, and clear evidence that our agents are doing more of the review, remediation, and merge work autonomously over time. If we’re on track, the conversation a year from now isn’t whether AI can validate code, it’s how much of the validation pipeline a team has handed over to agents.

Thank you for the great interview, readers who wish to learn more should visit Gitar.