Ali-Reza Adl-Tabatabai, grundare och VD på Gitar – Intervju-serie

Ali-Reza Adl-Tabatabai, grundare och VD på Gitar, är en veteran inom teknikledning med en karriär som spänner över några av de mest inflytelserika teknikföretagen i Silicon Valley, inklusive Uber, Google, Facebook, Intel, AMD och IBM. Innan han lanserade Gitar 2023 tjänstgjorde han som senior direktör för teknik på Uber, där han hjälpte till att leda företagets initiativ för utvecklarplattformar, efter tidigare ledande roller på Google som övervakade Site Reliability Engineering för produkter som Communications, Photos, Social, Cloud och teknisk infrastruktur.

Tidigare i sin karriär arbetade han med kompilatorteknik, virtuella maskiner, parallella datorsystem och hårdvaruoptimering på Intel Labs och Facebooks HipHop VM-team, samtidigt som han undervisade i avancerad kompilatorutformning på Stanford University. Hans decennielånga bakgrund inom programmeringsspråk, infrastruktur tillförlitlighet, utvecklarverktyg och storskalig systemarkitektur har positionerat honom som en framstående figur i den utvecklande AI-drivna programvarutekniklandskapet.

Gitar fokuserar på ett växande problem som uppstår från den ökande användningen av AI-assisterad programvaruutveckling: validering och säkerhet för den enorma mängden maskingenererad kod som nu flödar in i företagssystem. Plattformen använder AI-agenter för att automatisera kodgranskning, undersöka CI/CD-pipelinefel, identifiera buggar och sårbarheter, föreslå korrigeringar och integrera direkt i befintliga tekniska arbetsflöden med hjälp av verktyg som GitHub, GitLab, Jenkins, Jira och Slack. Istället för att enbart tävla inom AI-kodgenerering positionerar sig företaget kring det som beskrivs som “agenter för kvalitetsgränser”, vilket hjälper utvecklingsteam att upprätthålla tillförlitlighet, säkerhet och operativ tillsyn när programvaruutvecklingen alltmer skiftar mot autonoma och AI-assisterade kodningsflöden.

Du har lett teknik på Uber, Google och Intel Labs, och arbetat med storskaliga utvecklarplattformar och infrastruktur. Vilka specifika erfarenheter från den resan ledde dig till att grunda Gitar, och varför fokusera på kodvalidering istället för kodgenerering?

Under min tid på Uber, Google, Facebook och Intel Labs arbetade jag med utvecklarplattformar i olika skalor, och samma lärdom visade sig gång på gång: utvecklarupplevelsen är en konkurrensfördel. Bra verktyg lockar till sig och behåller de bästa ingenjörerna och låter företag röra sig snabbt. Utvecklare vill ha snabba, bullerfria verktyg som håller dem i flöde och automatiserar det tråkiga arbetet. Men utvecklarverktyg är djupt fragmenterade, och de flesta företag bränner enorma tekniska resurser bara för att skapa en sammanhängande upplevelse. Jag såg med egna ögon hur mycket kraft det finns i att lösa det problemet.

AI förändrar ekvationen genom att göra det möjligt att automatisera mycket mer av utvecklararbetsflödet än tidigare. Kodgenerering är redan väl täckt, men det har bara flyttat flaskhalsen nedströms, till validering, refactoring och underhåll av den kod vi nu producerar i en aldrig tidigare skådad volym. Det är där Gitar fokuserar. När AI skriver mer kod är den knappa resursen inte generation; det är förtroende, korrekthet och underhåll av det som skickas. Kodvalidering är den delen av arbetsflödet som avgör om AI-genererad kod faktiskt når produktionen på ett säkert sätt, och det är det svårare och mer värdefulla problemet att lösa.

Med den ökande användningen av AI-genererad kod hanterar många team nu vad vissa kallar kodöverbelastning. Hur betydande är det här problemet inom företag idag, och var kämpar teamen mest?

Skiftet ligger inte i att skriva kod. Den delen rör sig redan snabbare än de flesta team kan absorbera. Vad som har förändrats är allt som kommer efter. AI-verktyg genererar en jämn ström av pull-förfrågningar, ofta snabbare än team kan granska dem, vilket skapar tryck i delar av systemet som aldrig var utformade för den här nivån av utdata.

Varje ändring måste fortfarande passera validering. Kodgranskning. CI. Säkerhetskontroller. Godkännanden. Inget av det försvinner bara för att koden genereras snabbare. Vad som tidigare var en hanterbar flöde har förvandlats till en backlog. Teamen är inte längre blockerade av idéer eller implementering, utan de är blockerade av förtroende. Kan det här ske? Är det säkert? Har det brutit något subtilt?

Det är där friktionen ligger nu. Inte i skapandet, utan i att få koden över mållinjen utan att introducera risk.

Branschen har i stor utsträckning fokuserat på att generera kod snabbare. Varför tror du att validering har försummats, och varför blir det viktigare nu?

För att systemet nedströms från kodgenerering inte har utvecklats i samma takt. När utdata ökar blir allt nedströms ansträngt. Pull-förfrågningar blir större och mer frekventa. CI-fel börjar staplas. Granskningscykler blir komprimerade eftersom ingen har tid att gå djupt på varje ändring.

Kvalitet börjar glida, inte för att ingenjörerna inte bryr sig, utan för att volymen tvingar till avvägningar. Plattformsteam tar på sig mer av bördan, hanterar pipelineproblem, triagerar fel och försöker hålla allt i rörelse. Senioringenjörer slutar agera som samordnare, sätter ihop loggar, diagnostiserar problem och bestämmer vad som är säkert att slå samman.

Teamen står inför ett val som inte fungerar riktigt på något sätt. Antingen trycker de på koden snabbt och hanterar återställningar senare, eller så saktar de ner och skyddar kvaliteten, men accepterar att hastigheten minskar. Den spänningen visas upp över hela tekniska organisationer just nu.

Gitar använder AI-agenter för att hantera kodgranskning, testning och kontinuerlig integration (CI) arbetsflöden. Hur skiljer sig dessa agenter fundamentalt från traditionella statiska analysverktyg och regelbaserade pipelines?

Skillnaden är inte kosmetisk. Ett riktigt agenter måste göra mer än att svara på uppmaningar. Det måste hantera flerstegsarbete, planera, använda verktyg, hålla reda på sammanhang och flytta uppgifter framåt utan konstant inmatning.

De flesta system uppfyller inte den här standarden. De genererar utdata, men de hanterar inte utförandet. När dessa verktyg placeras i riktiga arbetsflöden visas luckorna snabbt. De minskar inte komplexiteten. I många fall lägger de till ett extra lager som någon måste hantera.

Det är därför samtalet skiftar från “har vi agenter” till “vilket arbete kan faktiskt hanteras pålitligt”.

Förtroende är en stor barriär för automatisering i programvaruutveckling. Hur säkerställer Gitar att dess valideringsprocess är tillräckligt pålitlig för team att lita på?

Mönstret som fungerar är enkelt. Bryt arbetet ner i mindre steg. Definiera tydliga gränser. Validera utdata kontinuerligt. Håll människor involverade där beslut bär risk.

Agenter kan granska kod och yta problem som är lätta att missa i stor skala. De kan analysera CI-fel, gruppera relaterade fel och peka på en trolig rotorsak. De kan föreslå korrigeringar och, i vissa fall, applicera dem på ett kontrollerat sätt.

Detta minskar mängden manuell triage som ingenjörer måste göra. Det tar inte bort ingenjörerna från loopen, men det ändrar var de spenderar sin tid. De flesta system opererar med kontroller, inte fullständig oberoende.

Din plattform tillåter team att skapa sina egna agenter. Hur viktigt är anpassning för företagsadoption, och vad är några av de mest intressanta användningsfallen du ser?

Anpassning är avgörande för företagsadoption. Varje plattformsteam spenderar betydande resurser på att anpassa CI till företagets specifika behov, och detta har traditionellt krävt skräddarsydda skript, konfiguration, verktygsintegrationer, loggbearbetare och resten av tejpen som håller modern utvecklarinfrastruktur samman.

Gitar kollapsar det arbetet. Plattformsteam kan skriva anpassade kontroller med hjälp av naturligt språkliga uppmaningar, vilket låter dem validera saker som är svåra eller omöjliga med traditionell programanalys, till exempel flagga användarvända strängar som är tvetydiga för översättning, eller validera uppdateringar av AGENTS.md-filer. De kan också automatisera anpassade arbetsflöden ovanpå pull-förfrågningar: länka PR till Jira-problem, öppna uppföljningsbiljetter för olösta granskningskommentarer, automatiskt omförsöka fluktuerande tester eller lägga till anpassade att-göra-listor till PR-sammanfattningar.

De mest intressanta användningsfallen tenderar att vara de vi inte förutsett. Teamen känner till sina kodbas och sina smärtproblem bättre än någon leverantör gör, så när du ger dem en primitiv som förvandlar “vi önskar att CI kunde bara kontrollera X” till en 10-radersuppmaning, börjar de omedelbart automatisera saker som vi aldrig skulle ha byggt som standard. Det är exakt vad vi vill.

Modern utvecklingsteam förlitar sig på en komplex uppsättning verktyg som GitHub, GitLab och Jira. Hur viktigt är det för Gitar att integrera i befintliga arbetsflöden snarare än att försöka ersätta dem?

Adoption beror på att möta utvecklare där de redan är. Ingenjörer vill inte en ny yta att lära sig, en ny instrumentpanel att kontrollera eller mer kontextväxling mellan verktyg. De vill att sina befintliga arbetsflöden ska bli snabbare och tystare. Så att integrera djupt med GitHub, GitLab, Jira och resten av stacken är inte ett trevligt att ha för oss; det är hela strategin.

Men vår ambition går längre än integration. Vi försöker inte ersätta dessa verktyg, och vi försöker inte bara ansluta till dem heller. Vi automatiserar arbetsflödena som körs över dem. PR-granskning, biljettlänkning, uppföljningsuppgifter, fluktuerande testomförsök, allt detta bör hända autonomt, i bakgrunden. Och vi trycker vidare: en agent redigerar PR direkt för att hantera kodgranskningsfeedback och åtgärda CI-fel, och hanterar slutligen godkännande och sammanslagning för ändringar som uppfyller teamets policys. Utvecklarens roll skiftar från att driva varje steg till att ange avsikt, granska resultat och hantera undantag.

Slutläget är inte ett nytt verktyg som utvecklare loggar in i. Det är de befintliga verktygen som gör mer på egen hand, så att utvecklare kan stanna fokuserade på det arbete som faktiskt kräver deras omdöme.

Du har föreslagit att mänskliga kodgranskningar kan bli undantaget snarare än regeln. Vad behöver hända för att organisationer ska känna sig bekväma med den skiftningen?

Förtroende byggs i etapper, inte allt på en gång. Organisationer behöver se, med sin egen kod, att AI kan hitta buggar och sårbarheter som faktiskt betyder något och upprätthålla sina anpassade regler med precision och hög täckning. Från där är vägen till autonom sammanslagning en naturlig progression genom fyra nivåer av ökande förtroende.

Den första nivån är upptäckt. Teamen bygger förtroende för att agenter hittar riktiga problem med en låg falsk positiv frekvens. När det förtroendet är etablerat låter de AI automatiskt blockera PR när det hittar kritiska problem.

Den andra nivån är åtgärd. AI:t fixar inte bara problem, utan också åtgärdar dem, avblockerar PR och vänder CI grönt utan mänskligt ingripande. Förtroende här betyder att agenten kan lösa problem och CI-fel exakt, utan att bryta saker.

Den tredje nivån är godkännande. När team ser agenter tillförlitligt vända PR gröna låter de AI godkänna PR under regler de definierar. Att ge organisationer explicit kontroll över villkoren för auto-godkännande är vad som gör det steget känns säkert snarare än vårdslöst.

Den fjärde nivån är sammanslagning. AI:t landar ändringen, igen under villkor som teamet är bekvämt med. Det steget har sin egen bar: agenten måste lösa sammanslagningskonflikter exakt, utan att införa återställningar eller bryta huvud. Det betyder mer än vad man tror, eftersom konfliktfrekvensen ökar med commit-genomströmning, och genomströmning exploderar när AI genererar mer kod. Stora monorepos känner redan av det; alla andra är på väg att göra det.

Skiftet till AI som standardgranskare är inte ett enda språng av förtroende. Det är en stege, och organisationer klättrar den ett steg i taget när bevisen ackumuleras.

När AI tar på sig mer av kodningsprocessen, hur ser du att rollen för senioringenjörer utvecklas under de kommande åren?

Senioringenjörer skiftar redan till samordningsroller, sätter ihop loggar, diagnostiserar problem och bestämmer vad som är säkert att slå samman. Det är inte en roll som någon planerade för. Det är en reaktion på att systemet bryter under belastning.

När agenter tar på sig mer av det repetitiva valideringsarbetet förblir ingenjörerna i loopen, men flyttar högre upp i stacken. De spenderar mindre tid på manuell triage och mer tid på att fatta beslut om vad som ska skeppas och varför.

Gitar nyligen höjde 9 miljoner dollar för att skala plattformen. Vad är dina topprioriteringar för den här kapitalen, och vad ser framgång ut som under de kommande 12 till 18 månaderna?

Kapitalet går mot två prioriteringar. Den första är marknadsföring: vi skalar vår företagsrörelse och investerar i utvecklarmedvetenhet så att teamen som skulle dra nytta av Gitar faktiskt vet att vi existerar. Den andra är produkt: vi fortsätter att bygga mot vår vision om fullt autonom kodvalidering och kvalitet, vilket innebär djupare agentförmågor, bredare arbetsflödes täckning och tätare integration med de verktyg utvecklare redan använder.

Framgång under de kommande 12 till 18 månaderna ser ut som en meningsfull bas av företagskunder som kör Gitar över hela sina kodbas, en utvecklarsamling som erkänner oss som standarden för AI-driven kodvalidering, och tydliga bevis på att våra agenter gör mer av gransknings-, åtgärds- och sammanslagningsarbetet autonomt över tid. Om vi är på rätt spår är samtalet om ett år inte om AI kan validera kod, utan hur mycket av valideringspipelinen ett team har överlåtit till agenter.

Tack för den underbara intervjun, läsare som vill lära sig mer bör besöka Gitar.