Ali-Reza Adl-Tabatabai, grunnlegger og CEO i Gitar – Intervju-serie

Ali-Reza Adl-Tabatabai, grunnlegger og CEO i Gitar, er en veteran ingeniørleder hvis karriere omfatter noen av de mest innflytelsesrike teknologiselskapene i Silicon Valley, inkludert Uber, Google, Facebook, Intel, AMD og IBM. Før han lanserte Gitar i 2023, var han senior direktør for ingeniørvirksomhet i Uber, der han hjalp til å lede selskapets initiativer for utviklerplattformer, etter tidligere lederroller i Google som overvåket Site Reliability Engineering for produkter som Kommunikasjon, Fotos, Sosiale medier, Sky og teknisk infrastruktur.

Tidligere i sin karriere arbeidet han med kompilatorteknologi, virtuelle maskiner, parallell databehandlingssystemer og maskinoptimering i Intel Labs og Facebooks HipHop VM-team, samt underviste i avansert kompilatordesign ved Stanford University. Hans mangeårige bakgrunn i programmeringsspråk, infrastrukturtilgjengelighet, utviklerverktøy og stor skala systemarkitektur har posisjonert ham som en fremtredende skikkelse i det utviklende AI-drevne programvareingeniørlandskapet.

Gitar fokuserer på et voksende problem som oppstår fra økningen av AI-assistert programvareutvikling: validering og sikring av den enorme mengden maskin-generert kode som nå strømmer inn i bedriftssystemer. Plattformen bruker AI-agenter til å automatisere kodegjennomgang, undersøke CI/CD-pipelinefeil, identifisere feil og sårbarheter, anbefale fikseringer og integrere direkte i eksisterende ingeniørarbeidsflyter via verktøy som GitHub, GitLab, Jenkins, Jira og Slack. I stedet for å kun konkurrere i AI-kodegenerering, stiller selskapet seg rundt det de beskriver som “agente kvalitetsporter”, og hjelper ingeniørteamene med å opprettholde pålitelighet, sikkerhet og operasjonell tilsyn når programvareutviklingen stadig skifter mot autonom og AI-assistert kodearbeidsflyt.

Du har ledet ingeniørarbeid i Uber, Google og Intel Labs, og arbeidet med stor skala utviklerplattformer og infrastruktur. Hvilke spesifikke erfaringer fra denne reisen ledet deg til å grunnlegge Gitar, og hvorfor fokusere på kodevalidering i stedet for kodegenerering?

Over Uber, Google, Facebook og Intel Labs arbeidet jeg med utviklerplattformer i svært forskjellige skalaer, og den samme lærepenheten dukket opp: utvikleropplevelsen er en konkurransefordel. Flotte verktøy tiltrekker og beholder de beste ingeniører og lar selskaper flytte raskt. Utviklere ønsker rask, støysvake verktøy som holder dem i flyt og automatiserer det tungrodda arbeidet. Men utviklerverktøy er dypere fragmentert, og de fleste selskaper brenner enorme ingeniørmidler bare for å sy sammen en sammenhengende opplevelse. Jeg så førstehånds hvordan mye gevinst det er å fikse det.

AI endrer ligningen ved å gjøre det mulig å automatisere langt mer av utviklerarbeidsflyten enn tidligere. Kodegenerering er allerede godt dekket, men det har bare flyttet flaskenhalen nedover, til validering, refaktorering og vedlikehold av koden vi nå produserer i en utenforliggende volum. Det er der Gitar fokuserer. Når AI skriver mer kode, er den knappe ressursen ikke generering; det er tillit, riktighet og vedlikehold av hva som faktisk kommer til produksjon trygt, og det er det vanskeligere og mer verdifulle problemet å løse.

Med økningen av AI-generert kode, har mange team nå å gjøre med hva noen kaller kodeoverbelastning. Hvor signifikant er dette problemet innen bedrifter i dag, og hvor strømmer teamene mest?

Skiftet er ikke i å skrive kode. Den delen er allerede i ferd med å flytte raskere enn de fleste team kan absorbere. Hva som har endret seg, er alt som kommer etter. AI-verktøy genererer en jevn strøm av pull-forespørsler, ofte raskere enn team kan gjennomgå dem, noe som skaper trykk i deler av systemet som aldri var designet for dette nivået av utgang.

Hver endring må fortsatt gå gjennom validering. Kodegjennomgang. CI. Sikkerhetssjekker. Godkjenninger. Ingen av det forsvinner bare fordi kode genereres raskere. Hva som tidligere var en håndterbar strøm, har blitt til en baklog. Team er ikke blokkert på ideer eller implementering lenger. De er blokkert på tillit. Kan dette skippe? Er det trygt? Brøt det noe subtilt?

Det er der friksjonen sitter nå. Ikke i skapelse, men i å få kode over målstreken uten å introdusere risiko.

Bransjen har i stor grad fokusert på å generere kode raskere. Hvorfor tror du validering har blitt oversett, og hvorfor blir det viktigere nå?

Fordi systemet nedstrøms av kodegenerering ikke har utviklet seg i samme takt. Når utgang øker, blir alt nedstrøms belastet. Pull-forespørsler blir større og hyppigere. CI-feil begynner å stable seg. Gjennomgangssykluser blir komprimert fordi ingen har tid til å gå dypt på hver endring.

Kvalitet begynner å gli, ikke fordi ingeniører ikke bryr seg, men fordi volumet tvinger kompromisser. Plattformteam tar på seg mer av byrden, håndterer pipelineproblemer, triagerer feil og prøver å holde ting i gang. Senioringeniører ender opp med å fungere som koordinatorer, setter sammen logger, diagnostiserer problemer og bestemmer hva som er trygt å slå sammen.

Team står overfor et valg som ikke virkelig fungerer på noen måte. Skyv kode gjennom raskt og håndter regresser senere, eller sakke ned og beskytte kvalitet, men aksepter at hastigheten synker. Den spenningen viser seg over ingeniørorganisasjoner nå.

Gitar bruker AI-agenter til å håndtere kodegjennomgang, testing og CI-arbeidsflyt. Hvor fundamentalt forskjellige er disse agentene fra tradisjonelle statiske analyseverktøy og regelbaserte pipeline?

Forskjellen er ikke kosmetisk. En ekte agent må gjøre mer enn å reagere på forespørsler. Den må håndtere flertrinnsarbeid, planlegge, bruke verktøy, holde styr på kontekst og flytte oppgaver fremover uten konstant innputt.

De fleste systemer møter ikke denne standarden. De genererer utgang, men de håndterer ikke eksekvering. Når disse verktøyene plasseres inn i virkelige arbeidsflyter, viser gapene seg raskt. De reduserer ikke kompleksiteten. I mange tilfeller legger de til en annen lag som noen må håndtere.

Det er derfor samtalen skifter fra “har vi agenter” til “hva arbeid kan faktisk håndteres pålitelig”.

Tillit er en stor barriere for automatisering i programvareutvikling. Hvorfor sikrer Gitar at valideringsprosessen er pålitelig nok for team å stole på?

Mønsteret som fungerer er enkelt. Del arbeidet inn i mindre trinn. Definer tydelige grenser. Valider utgang kontinuerlig. Hold mennesker involvert der beslutninger innebærer risiko.

Agenter kan gjennomgå kode og fremheve problemer som er lett å overse i skala. De kan analysere CI-feil, gruppere relaterte feil og peke på en sannsynlig rotårsak. De kan foreslå fikseringer og, i noen tilfeller, anvende dem på en kontrollert måte.

Dette reduserer mengden manuell triage ingeniører må gjøre. Det fjerner ikke ingeniører fra løkken, men det endrer hvor de bruker tid. De fleste systemer opererer med kontrollpunkter, ikke fullstendig uavhengighet.

Ditt plattform tillater team å lage sine egne agenter. Hvor viktig er tilpasning for bedriftsadoptsjon, og hva er noen av de mest interessante bruksområdene du ser?

Tilpasning er essensiell for bedriftsadoptsjon. Hvert plattformteam bruker betydelige ressurser på å tilpasse CI til selskapets spesifikke behov, og dette har tradisjonelt krevd skreddersydde skript, konfigurasjon, verktøyintegrering, log-prosessorer og resten av duct-tape som holder moderne utvikler-infrastruktur sammen.

Gitar kollapser dette arbeidet. Plattformteam kan skrive egne sjekker ved hjelp av naturligspråklig forespørsler, som lar dem valider ting som er vanskelige eller umulige med tradisjonell programanalyse, for eksempel å flagge bruker-orienterte strenger som er tvetydige for oversettelse, eller valider oppdateringer til AGENTS.md-filer. De kan også automatisere egne arbeidsflyter på toppen av pull-forespørsler: lenke PR-er til Jira-problemer, åpne oppfølgingsbilletter for uløste gjennomgangskommentarer, automatisk gjenta ustabile tester eller legge til egne gjøremålslister til PR-sammendrag.

De mest interessante bruksområdene tenderer å være de vi ikke forventet. Team kjenner sine kodebasier og sine smerteområder bedre enn noen leverandør gjør, så når du gir dem en primitiv som gjør “vi ønsker CI kunne bare sjekke X” til en 10-linjers forespørsel, begynner de umiddelbart å automatisere ting vi aldri ville bygget som standard. Det er nettopp hva vi ønsker.

Moderne ingeniørteam avhenger av en kompleks stabel med verktøy som GitHub, GitLab og Jira. Hvor viktig er det for Gitar å integrere i eksisterende arbeidsflyter i stedet for å prøve å erstatte dem?

Adopsjon avhenger av å møte utviklere der de allerede er. Ingeniører ønsker ikke en annen overflate å lære, en annen dashboard å sjekke eller mer kontekstskiftning mellom verktøy. De ønsker at eksisterende arbeidsflyter skal bli raskere og mer stille. Så å integrere dypt med GitHub, GitLab, Jira og resten av stabelen er ikke et hyggelig å ha for oss; det er hele strategien.

Men vårt ambisjonsnivå går videre enn integrasjon. Vi prøver ikke å erstatte disse verktøyene, og vi prøver ikke bare å plugge inn i dem heller. Vi automatiserer arbeidsflytene som kjører over dem. PR-gjennomgangen, billettlenkingen, oppfølgingsoppgavene, flaky test-gjentakelser, alt dette bør skje autonomt, i bakgrunnen. Og vi skyver videre: en agent redigerer PR direkte for å håndtere kodegjennomgangsfeedback og fikse CI-feil, og til slutt håndterer godkjenning og slå sammen for endringer som møter teamets politikker. Utviklerens rolle skifter fra å drive hver enkelt trinn til å sette intensjon, gjennomgå resultater og håndtere unntak.

Sluttilstanden er ikke et nytt verktøy utviklere logger inn i. Det er de eksisterende verktøyene som gjør mer på egen hånd, så utviklere kan holde fokus på arbeidet som faktisk krever deres dømmekraft.

Du har foreslått at menneskelig kodegjennomgang kunne bli unntaket snarere enn regelen. Hva må skje for at organisasjoner skal føle seg komfortable med den skiftet?

Tillit bygges i stadier, ikke alt på en gang. Organisasjoner må se, med sin egen kode, at AI kan finne feil og sårbarheter som faktisk teller og påtvinge deres egne regler med presisjon og høy dekning. Derfra er veien til autonom sammenslåing en naturlig progresjon gjennom fire nivåer av økende tillit.

Det første nivået er deteksjon. Team bygger tillit til at agenter finner virkelige problemer med en lav falsk positiv rate. Når denne tilliten er etablert, lar de AI automatisk blokkere PR-er når den finner kritiske problemer.

Det andre nivået er remediering. AI-en fikser ikke bare problemer, men fikser dem også, blokkerer PR-en og gjør CI grønt uten menneskelig inngripen. Tillit her betyr at agenten kan løse problemer og CI-feil nøyaktig, uten å bryte ting.

Det tredje nivået er godkjenning. Når team ser agenter pålitelig gjøre PR-er grønne, lar de AI godkjenne PR-er under regler de definerer. Å gi organisasjonene eksplisitt kontroll over betingelsene for auto-godkjenning er hva gjør dette steget føles trygt snarere enn uforsiktig.

Det fjerde nivået er sammenslåing. AI-en lander endringen, igjen under betingelser teamet er komfortable med. Dette steget har sin egen standard: agenten må løse sammenslåingskonflikter nøyaktig, uten å introdusere regresser eller bryte hoved. Det betyr mer enn folk realiserer, fordi konfliktfrekvensen øker med commit-gjennomstrømming, og gjennomstrømming eksploderer når AI genererer mer kode. Store monorepo føler dette allerede; alle andre er på vei til å.

Skiftet til AI som standard gjennomgang er ikke et enkelt sprang av tro. Det er en stige, og organisasjoner klatrer den ett trinn av gangen når bevisene akkumuleres.

Når AI tar på seg mer av kodeprosessen, hvordan ser du på at rollen til senioringeniører utvikler seg de neste årene?

Senioringeniører er allerede i ferd med å skifte til koordineringsroller, setter sammen logger, diagnostiserer problemer og bestemmer hva som er trygt å slå sammen. Det er ikke en rolle noen planla for. Det er en reaksjon på systemet som bryter under belastning.

Når agenter tar på seg mer av det repetitive valideringsarbeidet, holder ingeniører seg i løkken, men flytter høyere opp i stakken. De bruker mindre tid på manuell triage og mer tid på å gjøre beslutninger om hva som bør skippe og hvorfor.

Gitar har nylig samlet inn 9 millioner for å skalle plattformen. Hva er dine topprioriteter for denne kapitalen, og hva ser suksess ut som de neste 12 til 18 månedene?

Kapitalen går mot to prioriteringer. Den første er go-to-market: vi skal skalle bedriftsbevegelsen og investere i utviklerbevissthet så teamene som ville dra nytte av Gitar faktisk vet vi eksisterer. Den andre er produkt: vi fortsetter å bygge mot vår visjon om fullt autonom kodevalidering og kvalitet, som betyr dypere agentkapasiteter, bredere arbeidsflytdekning og tettere integrasjon med verktøyene utviklere allerede bruker.

Suksess de neste 12 til 18 månedene ser ut som en betydelig base av bedriftskunder som kjører Gitar over sine kodebasier, en utviklerfellesskap som anerkjenner oss som standarden for AI-drevet kodevalidering, og klart bevis på at våre agenter gjør mer av gjennomgangs-, remedierings- og sammenslåingsarbeidet autonomt over tid. Hvis vi er på spor, er samtalen om et år ikke om AI kan validerer kode, men hvor mye av valideringspipelinen et team har overført til agenter.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Gitar.