Ali-Reza Adl-Tabatabai, Oprichter en CEO bij Gitar – Interviewreeks

Ali-Reza Adl-Tabatabai, Oprichter en CEO van Gitar, is een ervaren ingenieursleider wiens carrière zich uitstrekt over enkele van de meest invloedrijke technologiebedrijven in Silicon Valley, waaronder Uber, Google, Facebook, Intel, AMD en IBM. Voordat hij Gitar in 2023 lanceerde, was hij Senior Director of Engineering bij Uber, waar hij hielp bij het leiden van de developer-platform-initiatieven van het bedrijf, na eerdere leiderschapsrollen bij Google waar hij verantwoordelijk was voor Site Reliability Engineering voor producten zoals Communications, Photos, Social, Cloud en technische infrastructuur.

Vroeger in zijn carrière werkte hij aan compiler-technologieën, virtuele machines, parallelle computersystemen en hardware-optimalisatie bij Intel Labs en Facebook’s HipHop VM-team, terwijl hij ook geavanceerde compiler-ontwerp gaf aan Stanford University. Zijn decennialange achtergrond in programmeertalen, infrastructuurbetrouwbaarheid, developer-hulpmiddelen en grote-schaal systeemarchitectuur heeft hem gepositioneerd als een prominente figuur in de evoluerende AI-gepowered software-engineering-landschap.

Gitar richt zich op een groeiend probleem dat voortkomt uit de opkomst van AI-geassisteerde software-ontwikkeling: het valideren en beveiligen van de enorme hoeveelheid machine-gegenereerde code die nu in enterprise-systemen stroomt. Het platform gebruikt AI-agents om code-reviews te automatiseren, CI/CD-pipeline-fouten te onderzoeken, bugs en kwetsbaarheden te identificeren, reparaties aan te bevelen en rechtstreeks te integreren in bestaande engineerings-workflows via tools zoals GitHub, GitLab, Jenkins, Jira en Slack. In plaats van alleen te concurreren in AI-code-generatie, positioneert het bedrijf zich rondom wat het “agentic quality gates” noemt, waarmee engineerings-teams helpen om betrouwbaarheid, beveiliging en operationeel toezicht te behouden terwijl software-ontwikkeling steeds meer verschuift naar autonome en AI-geassisteerde coderings-workflows.

U heeft ingenieursleiderschap gehad bij Uber, Google en Intel Labs, waar u werkte aan grote-schaal developer-platforms en infrastructuur. Welke specifieke ervaringen uit die reis hebben u ertoe geleid om Gitar te starten, en waarom richt u zich op code-validatie in plaats van code-generatie?

Over Uber, Google, Facebook en Intel Labs heb ik gewerkt aan developer-platforms op zeer verschillende schalen, en dezelfde les bleef steeds opduiken: developer-ervaring is een concurrentievoordeel. Grote tools trekken en behouden de beste ingenieurs en laten bedrijven snel bewegen. Ontwikkelaars willen snelle, ruisvrije tools die hen in flow houden en het saaie werk automatiseren. Maar developer-hulpmiddelen zijn diep gefragmenteerd, en de meeste bedrijven verbranden enorme ingenieursbronnen alleen al om een coherente ervaring samen te stellen. Ik zag met eigen ogen hoeveel hefboomwerking er zit in het oplossen van dat probleem.

AI verandert de vergelijking door het mogelijk te maken om veel meer van de developer-workflow te automatiseren dan voorheen. Code-generatie is al goed afgedekt, maar dat heeft alleen het knelpunt verderop verplaatst, naar validatie, refactoring en onderhoud van de code die we nu met ongekende snelheid produceren. Dat is waar Gitar zich op richt. Als AI meer code schrijft, is de schaarse resource niet generatie; het is het vertrouwen, de correctheid en de onderhoudbaarheid van wat wordt verzonden. Code-validatie is het deel van de workflow dat bepaalt of AI-gegenereerde code daadwerkelijk veilig in productie komt, en dat is het moeilijkere, waardevollere probleem om op te lossen.

Met de opkomst van AI-gegenereerde code hebben veel teams nu te maken met wat sommigen “code-overload” noemen. Hoe significant is dit probleem binnen ondernemingen vandaag, en waar worstelen teams het meest?

De verschuiving ligt niet in het schrijven van code. Dat deel verplaatst zich al sneller dan de meeste teams kunnen absorberen. Wat veranderd is, is alles wat daarna komt. AI-hulpmiddelen genereren een constante stroom van pull-requests, vaak sneller dan teams ze kunnen beoordelen, wat druk creëert in delen van het systeem die nooit voor dit niveau van output zijn ontworpen.

Elke wijziging moet nog steeds door validatie gaan. Code-review. CI. Beveiligingscontroles. Goedkeuringen. Niets van dat verdwijnt alleen omdat code sneller wordt gegenereerd. Wat eerder een beheersbare stroom was, is veranderd in een achterstand. Teams zijn niet geblokkeerd door ideeën of implementatie meer. Ze zijn geblokkeerd door vertrouwen. Kan dit verzonden worden? Is het veilig? Heeft het iets subtiele gebroken?

Dat is waar de wrijving nu zit. Niet in creatie, maar in het krijgen van code over de finishlijn zonder risico’s in te voeren.

De industrie heeft zich voornamelijk gericht op het sneller genereren van code. Waarom denkt u dat validatie over het hoofd is gezien, en waarom wordt het nu kritieker?

Omdat het systeem stroomafwaarts van code-generatie niet in hetzelfde tempo is geëvolueerd. Wanneer de output toeneemt, wordt alles stroomafwaarts gestrest. Pull-requests worden groter en vaker. CI-fouten beginnen te stapelen. Review-cycli worden samengeperst omdat niemand de tijd heeft om diep in elke wijziging te duiken.

Kwaliteit begint te glijden, niet omdat ingenieurs het niet kunnen schelen, maar omdat het volume compromissen afdwingt. Platform-teams nemen meer van de last op zich, omgaan met pipeline-problemen, triageren van fouten en proberen dingen in beweging te houden. Senior-ingenieurs eindigen als coördinatoren, die logbestanden in elkaar zetten, problemen diagnosticeren en beslissen wat veilig is om te mergen.

Teams staan voor een keuze die niet echt werkt op beide manieren. Code snel doorvoeren en later met regressies omgaan, of vertragen en kwaliteit beschermen, maar accepteren dat de snelheid daalt. Die spanning komt nu overal in engineerings-organisaties naar voren.

Gitar gebruikt AI-agents om code-reviews, tests en continue integratie (CI) workflows af te handelen. Hoe verschillen deze agents wezenlijk van traditionele statische analyse-hulpmiddelen en regel-gebaseerde pipelines?

Het verschil is niet cosmetisch. Een echte agent moet meer doen dan alleen op prompts reageren. Het moet multi-stap-werk afhandelen, plannen, tools gebruiken, context bijhouden en taken vooruit helpen zonder constante input.

De meeste systemen voldoen niet aan die standaard. Ze genereren outputs, maar ze beheren geen uitvoering. Wanneer deze tools in echte workflows worden geplaatst, worden de lacunes snel zichtbaar. Ze verminderen de complexiteit niet. In veel gevallen voegen ze een extra laag toe die iemand moet beheren.

Dat is waarom het gesprek verschuift van “hebben we agents” naar “welk werk kan eigenlijk betrouwbaar worden afgehandeld.”

Vertrouwen is een grote barrière voor automatisering in software-ontwikkeling. Hoe zorgt Gitar ervoor dat het validatieproces betrouwbaar genoeg is voor teams om erop te vertrouwen?

Het patroon dat werkt is eenvoudig. Werk breekt in kleinere stappen. Definieer duidelijke grenzen. Valideer outputs continu. Houd mensen betrokken waar beslissingen risico’s met zich meebrengen.

Agents kunnen code reviewen en problemen naar boven brengen die gemakkelijk over het hoofd gezien kunnen worden op grote schaal. Ze kunnen CI-fouten analyseren, gerelateerde fouten groeperen en naar een waarschijnlijke oorzaak wijzen. Ze kunnen reparaties aanbevelen en, in sommige gevallen, deze in een gecontroleerde omgeving toepassen.

Dit vermindert de hoeveelheid handmatige triage die ingenieurs moeten doen. Het verwijdert ingenieurs niet uit de lus, maar verandert waar ze hun tijd besteden. De meeste systemen werken met checkpoints, niet met complete onafhankelijkheid.

Uw platform staat teams toe om hun eigen agents te maken. Hoe belangrijk is aanpassing voor ondernemingsadoptie, en wat zijn enkele van de meest interessante use-cases die u ziet?

Aanpassing is essentieel voor ondernemingsadoptie. Elk platform-team besteedt aanzienlijke middelen aan het aanpassen van CI aan de specifieke behoeften van hun bedrijf, en dit heeft traditioneel maatwerk-scripts, configuratie, tool-integraties, log-processors en de rest van de duct-tape vereist die de moderne dev-infrastructuur bijeenhoudt.

Gitar reduceert die inspanning. Platform-teams kunnen aangepaste controles schrijven met behulp van natuurlijke-taal-prompts, waardoor ze dingen kunnen valideren die moeilijk of onmogelijk zijn met traditionele programma-analyse, zoals het markeren van gebruikersgerichte strings die voor vertaling vaag zijn, of het valideren van updates voor AGENTS.md-bestanden. Ze kunnen ook aangepaste workflows automatiseren bovenop pull-requests: koppelen van PR’s aan Jira-problemen, openen van follow-up-tickets voor onopgeloste review-opmerkingen, automatisch opnieuw proberen van flaky-tests, of toevoegen van aangepaste to-do-lijsten aan PR-samenvattingen.

De meest interessante use-cases zijn meestal die waar we niet aan hadden gedacht. Teams kennen hun codebases en hun pijn punten beter dan enige leverancier, dus wanneer je hen een primitief geeft dat “we wensen dat CI X zou controleren” omzet in een 10-regel-prompt, beginnen ze onmiddellijk dingen te automatiseren die we nooit standaard zouden hebben gebouwd. Dat is precies wat we willen.

Moderne engineerings-teams vertrouwen op een complexe stapel tools zoals GitHub, GitLab en Jira. Hoe belangrijk is het voor Gitar om te integreren in bestaande workflows in plaats van ze te proberen te vervangen?

Adoptie hangt af van het ontmoeten van ontwikkelaars waar ze al zijn. Ingenieurs willen geen extra oppervlak leren, geen extra dashboard controleren of meer context-switching tussen tools. Ze willen dat hun bestaande workflows sneller en stiller worden. Dus integreren met GitHub, GitLab, Jira en de rest van de stapel is voor ons geen nice-to-have; het is de hele strategie.

Maar onze ambitie gaat verder dan integratie. We proberen deze tools niet te vervangen, en we proberen er niet alleen in te pluggen. We automatiseren de workflows die eroverheen lopen. De PR-review, het koppelen van tickets, de follow-up-taken, de flaky-test-retries, alles moet automatisch gebeuren, op de achtergrond. En we gaan verder: een agent bewerkt de PR rechtstreeks om code-review-feedback te adresseren en CI-fouten te repareren, en uiteindelijk afhandelt goedkeuring en merge voor wijzigingen die voldoen aan het beleid van het team. De rol van de ontwikkelaar verschuift van het besturen van elke stap naar het instellen van intentie, het beoordelen van resultaten en het afhandelen van uitzonderingen.

De eindtoestand is geen nieuw hulpmiddel waar ontwikkelaars inloggen. Het zijn de bestaande hulpmiddelen die meer zelf doen, zodat ontwikkelaars zich kunnen concentreren op het werk dat daadwerkelijk hun oordeel vereist.

U hebt gesuggereerd dat menselijke code-reviews uiteindelijk de uitzondering in plaats van de regel kunnen worden. Wat moet er gebeuren om organisaties te laten voelen dat ze zich comfortabel voelen bij die verschuiving?

Vertrouwen wordt opgebouwd in fasen, niet in één keer. Organisaties moeten met hun eigen code zien dat AI de bugs en kwetsbaarheden kan vinden die er echt toe doen en hun aangepaste regels met precisie en hoge dekking kunnen afdwingen. Vanaf dat moment is de weg naar autonome merging een natuurlijke progressie door vier niveaus van toenemend vertrouwen.

Het eerste niveau is detectie. Teams bouwen vertrouwen op dat agents echte problemen vinden met een lage vals-positieve rate. Zodra dat vertrouwen is gevestigd, laten ze de AI automatisch PR’s blokkeren wanneer het kritieke problemen vindt.

Het tweede niveau is reparatie. De AI vindt niet alleen problemen, maar lost ze ook op, waardoor de PR wordt ontgrendeld en CI groen wordt zonder menselijke tussenkomst. Vertrouwen hier betekent dat de agent problemen en CI-fouten precies kan oplossen zonder dingen te breken.

Het derde niveau is goedkeuring. Zodra teams zien dat agents betrouwbaar PR’s groen maken, laten ze de AI PR’s goedkeuren onder voorwaarden die ze definiëren. Het geven van organisaties expliciete controle over de voorwaarden voor auto-goedkeuring is wat deze stap veilig in plaats van roekeloos maakt.

Het vierde niveau is merge. De AI landt de wijziging, opnieuw onder voorwaarden die het team comfortabel vindt. Deze stap heeft zijn eigen standaard: de agent moet merge-conflicten precies oplossen, zonder regressies in te voeren of main te breken. Dat is belangrijker dan mensen beseffen, omdat de frequentie van conflicten toeneemt met commit-doorvoer, en doorvoer explodeert terwijl AI meer code genereert. Grote monorepos voelen dit al; iedereen anders is er zo.

De verschuiving naar AI als de standaard reviewer is geen enkele sprong van vertrouwen. Het is een ladder, en organisaties klimmen die ladder tree voor tree als het bewijs zich ophoopt.

Terwijl AI meer van het coderingsproces overneemt, hoe ziet u de rol van senior-ingenieurs evolueren in de komende jaren?

Senior-ingenieurs zijn al aan het verschuiven naar coördinatierollen, logbestanden samenstellen, problemen diagnosticeren en beslissen wat veilig is om te mergen. Dat is geen rol die iemand gepland had. Het is een reactie op het systeem dat onder druk breekt.

Terwijl agents meer van het repetitieve validatiewerk overnemen, blijven ingenieurs in de lus, maar verplaatsen ze zich hoger in de stapel. Ze besteden minder tijd aan handmatige triage en meer tijd aan het nemen van beslissingen over wat moet worden verzonden en waarom.

Gitar heeft onlangs 9 miljoen dollar opgehaald om het platform te schalen. Wat zijn uw top-prioriteiten voor dat kapitaal, en wat ziet succes eruit over de komende 12 tot 18 maanden?

Het kapitaal gaat naar twee prioriteiten. De eerste is go-to-market: we schalen onze ondernemingsbeweging en investeren in developer-bewustzijn, zodat de teams die baat zouden hebben bij Gitar, eigenlijk weten dat we bestaan. De tweede is product: we blijven bouwen aan onze visie van volledig autonome code-validatie en -kwaliteit, wat diepere agent-capaciteiten, bredere workflow-dekking en nauwere integratie met de tools die ontwikkelaars al gebruiken, betekent.

Succes over de komende 12 tot 18 maanden ziet eruit als een significante basis van ondernemingsklanten die Gitar uitvoeren over hun codebases, een developer-gemeenschap die ons erkent als de standaard voor AI-gedreven code-validatie, en duidelijk bewijs dat onze agents meer van de review-, reparatie- en merge-werkzaamheden autonoom uitvoeren over tijd. Als we op koers zijn, is het gesprek over een jaar niet of AI code kan valideren, maar hoeveel van de validatie-pipeline een team heeft overgedragen aan agents. Dank u voor het geweldige interview, lezers die meer willen leren, moeten Gitar bezoeken.