Ali-Reza Adl-Tabatabai, grundlægger og administrerende direktør i Gitar – Interview-serie

Ali-Reza Adl-Tabatabai, grundlægger og administrerende direktør i Gitar, er en veteran ingeniørleder, hvis karriere omfatter nogle af de mest indflydelsesrige teknologivirksomheder i Silicon Valley, herunder Uber, Google, Facebook, Intel, AMD og IBM. Før han startede Gitar i 2023, fungerede han som senior direktør for ingeniørarbejde i Uber, hvor han hjalp med at lede virksomhedens udviklerplatform-initiativer, efter tidligere ledelsesroller i Google, der overvågede Site Reliability Engineering for produkter som Kommunikation, Fotos, Sociale medier, Cloud og teknisk infrastruktur.

Tidligere i sin karriere arbejdede han med compiler-teknologier, virtuelle maskiner, parallel computing-systemer og hardware-optimering i Intel Labs og Facebooks HipHop VM-team, samtidig med at han underviste i avanceret compiler-design på Stanford University. Hans mangeårig baggrund inden for programmeringssprog, infrastrukturtilgængelighed, udviklerværktøjer og storstile arkitektur har positioneret ham som en fremtrædende skikkelse i det udviklende landskab for AI-drevet software-udvikling.

Gitar fokuserer på et voksende problem, der opstår som følge af den stigende AI-understøttede software-udvikling: validering og sikring af den enorme mængde maskin-genereret kode, der nu strømmer ind i virksomhedssystemer. Platformen bruger AI-agenter til at automatisere kode-gennemgang, undersøge CI/CD-pipeline-fejl, identificere fejl og sårbarheder, anbefale rettelser og integrere direkte i eksisterende ingeniør-arbejdsgange via værktøjer som GitHub, GitLab, Jenkins, Jira og Slack. I stedet for kun at konkurrere i AI-kode-generering, positionerer virksomheden sig omkring, hvad den beskriver som “agentic kvalitetsporte”, der hjælper ingeniørhold med at opretholde pålidelighed, sikkerhed og operationel oversigt, da software-udviklingen i stigende grad skifter mod autonome og AI-understøttede kode-arbejdsgange.

Du har ledet ingeniørarbejde i Uber, Google og Intel Labs, og arbejdet med storstile udvikler-platforme og infrastruktur. Hvad var det specifikke, du oplevede under den rejse, der førte til, at du startede Gitar, og hvorfor fokuserer du på kode-validering i stedet for kode-generering?

På tværs af Uber, Google, Facebook og Intel Labs arbejdede jeg med udvikler-platforme i meget forskellige skalae, og den samme lære dukkede op igen og igen: udvikler-oplevelsen er en konkurrencefordel. De bedste værktøjer tiltrækker og fastholder de bedste ingeniører og giver virksomheder mulighed for at bevæge sig hurtigt. Udviklere ønsker hurtige, støjfri værktøjer, der holder dem i flow og automatiserer det tungeste arbejde. Men udviklerværktøjerne er dybt fragmenterede, og de fleste virksomheder brænder enorme ingeniørressourcer blot på at samle en sammenhængende oplevelse. Jeg så med egne øjne, hvor meget der var at hente ved at løse det problem.

AI ændrer ligningen ved at gøre det muligt at automatisere langt mere af udvikler-arbejdsgangen end før. Kode-generering er allerede godt dækket, men det har kun flyttet flaskenhalen downstream, til validering, refaktorering og vedligeholdelse af koden, som vi nu producerer i en uhørt mængde. Det er her, Gitar fokuserer. Da AI skriver mere kode, er den knappe ressource ikke generering; det er tilliden, korrektheden og vedligeholdeligheden af det, der sendes. Kode-validering er den del af arbejdsgangen, der afgør, om AI-genereret kode faktisk kan sendes sikkert til produktion, og det er det sværere og mere værdifulde problem at løse.

Med opblomstringen af AI-genereret kode har mange hold nu at gøre med, hvad nogen kalder kode-overbelastning. Hvor stor er dette problem inden for virksomheder i dag, og hvor kæmper holdene mest?

Skiftet er ikke i at skrive kode. Den del er allerede i gang med at flytte hurtigere, end de fleste hold kan absorberere. Det, der er ændret, er alt, der kommer herefter. AI-værktøjer genererer en konstant strøm af pull-requests, ofte hurtigere, end hold kan gennemgå dem, hvilket skaber pres i dele af systemet, der ikke var designet til denne niveau af output.

Hver ændring skal stadig gå igennem validering. Kode-gennemgang. CI. Sikkerhedstjek. Godkendelser. Ingen af det forsvinder bare, fordi kode genereres hurtigere. Det, der tidligere var en håndterbar strøm, er blevet til en tilbagestående arbejdsmængde. Hold er ikke blokeret på grund af manglende ideer eller implementering længere. De er blokeret på grund af tillid. Kan dette sendes? Er det sikkert? Har det brudt noget subtilt?

Det er der, friktionen ligger nu. Ikke i skabelse, men i at få koden over målstregen uden at introducere risiko.

Branchen har primært fokuseret på at generere kode hurtigere. Hvorfor tror du, validering er blevet overset, og hvorfor bliver det mere kritisk nu?

Fordi systemet downstream fra kode-generering ikke er udviklet i samme takt. Når output øges, bliver alt downstream belastet. Pull-requests bliver større og hyppigere. CI-fejl begynder at stable sig. Gennemgangscykler bliver komprimeret, fordi ingen har tid til at gå dybt ind i hver ændring.

Kvalitet begynder at glide, ikke fordi ingeniører ikke bekymrer sig, men fordi mængden tvinger til kompromiser. Platformhold tager på sig mere af byrden, håndterer pipeline-problemer, triagerer fejl og forsøger at holde tingene i gang. Senior-ingeniører ender med at fungere som koordinatorer, der samler logfiler, diagnosticerer problemer og beslutter, hvad der er sikkert at samle.

Hold står over for et valg, der ikke virker i nogen af delene. Skyd kode igennem hurtigt og håndter regressioner senere, eller langsommeligt og beskyt kvalitet, men accepter, at hastigheden falder. Den spænding viser sig over hele ingeniør-organisationer lige nu.

Gitar bruger AI-agenter til at håndtere kode-gennemgang, test og CI-arbejdsgange. Hvordan adskiller disse agenter sig fundamentalt fra traditionelle statiske analyseværktøjer og regel-baserede pipelines?

Forskellen er ikke kosmetisk. Et rigtigt agent skal kunne mere end blot reagere på prompte. Det skal kunne håndtere multi-trin-arbejde, planlægge, bruge værktøjer, holde styr på kontekst og flytte opgaver fremad uden konstant input.

De fleste systemer opfylder ikke den standard. De genererer output, men de håndterer ikke udførelse. Når disse værktøjer placeres inden for rigtige arbejdsgange, viser hullerne sig hurtigt. De reducerer ikke kompleksiteten. I mange tilfælde tilføjer de en ekstra lag, som nogen skal håndtere.

Det er derfor, samtalen skifter fra “har vi agenter” til “hvad kan arbejde faktisk håndteres pålideligt”.

Tillid er en stor barriere for automatisering i software-udvikling. Hvordan sikrer Gitar, at valideringsprocessen er pålidelig nok til, at hold kan stole på den?

Mønsteret, der virker, er simpelt. Del arbejdet op i mindre trin. Definer klare grænser. Valider output kontinuerligt. Hold mennesker involveret, hvor beslutninger medfører risiko.

Agenter kan gennemgå kode og fremhæve problemer, der er lette at overse på stor skala. De kan analysere CI-fejl, gruppere relaterede fejl og pege på en sandsynlig rodårsag. De kan foreslå rettelser og i nogle tilfælde anvende dem på en kontrolleret måde.

Dette reducerer mængden af manuel triage, ingeniører skal udføre. Det fjerner ikke ingeniører fra løkken, men det ændrer, hvor de bruger tid. De fleste systemer opererer med checkpoints, ikke fuld uafhængighed.

Dit platform tillader hold at oprette deres egne agenter. Hvor vigtig er tilpasning for virksomhedsadoption, og hvad er nogle af de mest interessante brugsområder, du ser?

Tilpasning er afgørende for virksomhedsadoption. Hvert platformhold bruger betydelige ressourcer på at tilpasse CI til virksomhedens specifikke behov, og dette har traditionelt krævet specialskrevne scripts, konfiguration, værktøjsintegrationer, logprocessorer og resten af det duct tape, der holder moderne udvikler-infrastruktur sammen.

Gitar kollapser det arbejde. Platformhold kan skrive brugerdefinerede kontroller ved hjælp af naturlige sprog-prompte, der tillader dem at validere ting, der er svære eller umulige med traditionel program-analyse, f.eks. flagge bruger-orienterede streng, der er tvetydige til oversættelse, eller validere opdateringer til AGENTS.md-filer. De kan også automatisere brugerdefinerede arbejdsgange på toppen af pull-requests: link PR’er til Jira-problemer, åbne følg-op-billetter for uløste gennemgangskommentarer, automatisere genprøvning af ustabile tests eller tilføje brugerdefinerede til-gør-liste til PR-summer.

De mest interessante brugsområder tenderer til at være dem, vi ikke havde forventet. Hold kender deres kodebaser og deres smertepunkter bedre end nogen leverandør gør, så når du giver dem en primitiv, der omdanner “vi ønsker, CI kunne bare kontrollere X” til en 10-linjes prompt, begynder de straks at automatisere ting, vi aldrig ville have bygget som standard. Det er præcis, hvad vi ønsker.

Moderne ingeniørhold afhænger af et komplekst sæt af værktøjer som GitHub, GitLab og Jira. Hvor vigtig er det for Gitar at integrere i eksisterende arbejdsgange i stedet for at forsøge at erstatte dem?

Adoption afhænger af at møde udviklere, hvor de allerede er. Ingenting ønsker en ny overflade at lære, en ny dashboard at tjekke eller mere kontekst-skiftning mellem værktøjer. De ønsker, at deres eksisterende arbejdsgange bliver hurtigere og mere stille. Så dyb integration med GitHub, GitLab, Jira og resten af stacken er ikke et nice-to-have for os; det er den samlede strategi.

Men vores ambition går videre end integration. Vi forsøger ikke at erstatte disse værktøjer, og vi forsøger ikke bare at plugge ind i dem. Vi automatiserer arbejdsgangene, der kører på tværs af dem. PR-gennemgangen, billet-lænkningen, følg-op-opgaverne, genprøvningen af ustabile tests, alt det skal ske autonomt, i baggrunden. Og vi skyder videre: en agent redigerer PR direkte for at håndtere kode-gennemgangsfeedback og fikse CI-fejl, og håndterer til sidst godkendelse og samling for ændringer, der opfylder holdets politikker. Udviklerens rolle skifter fra at køre hver trin til at angive hensigt, gennemgå resultater og håndtere undtagelser.

Endestaten er ikke et nyt værktøj, udviklere logger ind i. Det er de eksisterende værktøjer, der gør mere på egen hånd, så udviklere kan blive fokuseret på arbejdet, der faktisk kræver deres dømmekraft.

Du har foreslået, at menneskelig kode-gennemgang kunne blive undtagelsen snarere end reglen. Hvad skal ske, før organisationer føler sig komfortable med den skift?

Tillid bygges op i stadier, ikke på én gang. Organisationer skal se, med deres egen kode, at AI kan finde fejl og sårbarheder, der faktisk betyder noget, og gennemtvinge deres brugerdefinerede regler med præcision og høj dækning. Fra derfra er vejen til autonom samling en naturlig progression gennem fire niveauer af øgende tillid.

Det første niveau er detektion. Hold bygger tillid til, at agenter finder virkelige problemer med en lav falsk-positiv rate. Når den tillid er etableret, lader de AI automatisk blokere PR’er, når det finder kritiske fejl.

Det andet niveau er reparation. AI’et fikser ikke blot problemer, men fikser dem, afblokerer PR’en og gør CI grønt uden menneskelig indgriben. Tillid her betyder, at agenten kan løse problemer og CI-fejl præcist, uden at bryde noget.

Det tredje niveau er godkendelse. Når hold ser agenter pålideligt gøre PR’er grønne, lader de AI godkende PR’er under regler, de definerer. At give organisationer eksplisit kontrol over betingelserne for automatisk godkendelse er, hvad der gør dette trin føles sikkert snarere end uforsigtigt.

Det fjerde niveau er samling. AI’et lander ændringen, igen under betingelser, holdet er komfortabelt med. Det trin har sin egen bar: agenten skal løse samling-konflikter præcist, uden at introducere regressioner eller bryde main. Det betyder mere, end folk forstår, fordi konflikt-hyppighed stiger med commit-gennemstrømning, og gennemstrømning eksploderer, da AI genererer mere kode. Store monorepos føler allerede dette; alle andre er på vej til det.

Skiftet til AI som standard-gennemgang er ikke et enkelt spring af tillid. Det er en stige, og organisationer klatrer op én trin ad gangen, efterhånden som beviserne akkumuleres.

Hvor ser du rollen udvikle sig for senior-ingeniører over de næste par år, da AI tager over mere af kodningsprocessen?

Senior-ingeniører skifter allerede til koordinationsroller, hvor de samler logfiler, diagnosticerer problemer og beslutter, hvad der er sikkert at samle. Det er ikke en rol, nogen havde planlagt. Det er en reaktion på, at systemet bryder sammen under belastning.

Da agenter tager over mere af det repetitive valideringsarbejde, forbliver ingeniører i løkken, men flytter sig opad i stakken. De bruger mindre tid på manuel triage og mere tid på at træffe beslutninger om, hvad der skal sendes, og hvorfor.

Gitar har nyligt samlet 9 millioner dollars for at skala-platformen. Hvad er dine top-prioriteter for den kapital, og hvad ser succes ud til over de næste 12 til 18 måneder?

Kapitalen går til to prioriteringer. Den første er go-to-market: vi skal skala vores virksomhedsbevægelse og investere i udvikler-bevidsthed, så hold, der kunne have gavn af Gitar, faktisk ved, vi eksisterer. Den anden er produkt: vi fortsætter med at bygge mod vores vision om fuldt autonom kode-validering og kvalitet, hvilket betyder dybere agent-funktioner, bredere arbejdsgangs-dækning og tættere integration med de værktøjer, udviklere allerede bruger.

Succes over de næste 12 til 18 måneder ligner en betydelig basis af virksomheds-kunder, der kører Gitar på tværs af deres kodebaser, en udvikler-samfund, der anerkender os som standarden for AI-drevet kode-validering, og klart bevis for, at vores agenter gør mere af gennemgangs-, reparation- og samlingsarbejdet autonomt over tid. Hvis vi er på sporet, er samtalen om et år ikke, om AI kan validerer kode, men hvor meget af validerings-pipeline-en et hold har overdraget til agenter. Tak for det gode interview, læsere, der ønsker at lære mere, skal besøge Gitar.