Ali-Reza Adl-Tabatabai, zakladatel a CEO společnosti Gitar – rozhovor

Ali-Reza Adl-Tabatabai, zakladatel a CEO společnosti Gitar, je zkušený lídr v oblasti inženýrství, jehož kariéra zahrnuje některé z nejvlivnějších technologických společností v Silicon Valley, včetně Uber, Google, Facebook, Intel, AMD a IBM. Předtím, než založil Gitar v roce 2023, působil jako senior ředitel inženýrství ve společnosti Uber, kde pomáhal vést iniciativy vývojářské platformy, a dříve vedl týmy v Google, kde odpovídal za Site Reliability Engineering pro produkty, jako jsou Communications, Photos, Social, Cloud a technická infrastruktura.

V ranější fázi své kariéry pracoval na technologiích kompilátorů, virtuálních strojů, paralelních výpočetních systémech a optimalizaci hardwaru v Intel Labs a týmu HipHop VM ve Facebooku, a zároveň učil pokročilý design kompilátorů na Stanford University. Jeho dlouholetá zkušenost v oblasti programovacích jazyků, infrastruktury, nástrojů pro vývojáře a architektury velkých systémů jej ustanovila jako prominentní osobnost v oblasti softwarového inženýrství poháněného umělou inteligencí.

Gitar se zaměřuje na rostoucí problém, který vyplývá z růstu softwarového vývoje asistovaného umělou inteligencí: validaci a zabezpečení enormního objemu kódu generovaného stroji, který nyní proudí do podnikových systémů. Platforma využívá agentů umělé inteligence k automatizaci kontrol kódu, vyšetřování selhání CI/CD pipeline, identifikaci chyb a zranitelností, doporučování oprav a přímé integrace do stávajících inženýrských pracovních postupů prostřednictvím nástrojů, jako jsou GitHub, GitLab, Jenkins, Jira a Slack. Namísto toho, aby se soustředila pouze na generování kódu, společnost se позиcionuje kolem toho, co popisuje jako „agentic quality gates“, pomáhající inženýrským týmům udržovat spolehlivost, bezpečnost a provozní dohled, protože se softwarový vývoj stále více posouvá směrem k autonomnímu a asistovanému kódování.

Vy jste vedl inženýrství ve společnostech Uber, Google a Intel Labs, pracoval na velkých vývojářských platformách a infrastruktuře. Jaké konkrétní zkušenosti z této cesty vás vedly k založení Gitaru, a proč se zaměřujete na validaci kódu místo generování kódu?

Po celou dobu mé kariéry ve společnostech Uber, Google, Facebook a Intel Labs jsem pracoval na vývojářských platformách v různých měřítcích, a vždy se mi ukazovalo, že zkušenost vývojáře je konkurenční výhodou. Skvělé nástroje přitahují a udržují nejlepší inženýry a umožňují společnostem pohybovat se rychle. Vývojáři chtějí rychlé, bezproblémové nástroje, které je udržují v pracovním toku a automatizují rutinní práci. Ale nástroje pro vývojáře jsou hluboce fragmentované, a většina společností spaluje enormní inženýrské zdroje pouze na to, aby vytvořily soudržnou zkušenost. Viděl jsem na vlastní oči, jak velkou výhodu existuje v opravě tohoto problému.

Umělá inteligence mění rovnici tím, že umožňuje automatizovat mnohem více vývojářského pracovního postupu, než dříve. Generování kódu je již dobře pokryto, ale to pouze posunulo úzké místo dále, na validaci, refaktorizaci a údržbu kódu, který nyní produkuje v nebývalém objemu. To je místo, kde se Gitar zaměřuje. Když umělá inteligence píše více kódu, vzácným zdrojem není generování; je to důvěra, správnost a udržovatelnost toho, co se dodává. Validace kódu je část pracovního postupu, která určuje, zda kód generovaný umělou inteligencí skutečně bezpečně dosáhne produkce, a to je složitější a cennější problém, který je třeba vyřešit.

S růstem kódu generovaného umělou inteligencí se mnoho týmů nyní potýká s tím, co někteří nazývají „přebytečným kódem“. Jak významný je tento problém uvnitř podniků dnes, a kde se týmy nejvíce potýkají?

Posun není v psaní kódu. Ta část se již pohybuje rychleji, než většina týmů může absorbovat. Co se změnilo, je všechno, co následuje. Nástroje umělé inteligence generují stálý tok žádostí o stažení, často rychleji, než týmy mohou provést kontrolu, což vytváří tlak na částech systému, které nebyly navrženy pro tento objem výstupu.

Každou změnu je stále třeba projít validací. Kontrola kódu. CI. Bezpečnostní kontroly. Schválení. Žádná z těchto věcí nezmizí pouze proto, že kód je generován rychleji. Co dříve bylo zvladatelným tokem, se stalo backlogem. Týmy nejsou zablokované na nápadech nebo implementaci již. Jsou zablokované na důvěře. Může být tento kód dodán? Je bezpečný? Zlomil něco jemného?

To je místo, kde nyní leží tření. Ne ve vytváření, ale v dostat kódu přes cílovou čáru bez zavedení rizika.

Průmysl se většinou zaměřil na generování kódu rychleji. Proč si myslíte, že validace byla přehlížena, a proč se stává kritičtější nyní?

Protože systém po generování kódu se nevyvinul ve stejném tempu. Když se zvyšuje výstup, všechno po něm je stresováno. Žádosti o stažení se stávají většími a častějšími. Selhání CI začínají hromadit. Cykly kontrol se stávají komprimovanými, protože nikdo nemá čas se hluboce zabývat každou změnou.

Kvalita začíná klesat, ne proto, že inženýři se o to nestarají, ale protože objem nutí kompromisy. Týmy platformy přebírají více zátěže, řeší problémy pipeline, triají selhání a snaží se udržet věci v pohybu. Senioři inženýři nakonec jednají jako koordinátoři, skládají together logy, diagnostikují problémy a rozhodují, co je bezpečné pro sloučení.

Týmy čelí volbě, která nefunguje ani jedním způsobem. Projít kód rychle a řešit regrese později, nebo zpomalit a chránit kvalitu, ale akceptovat, že rychlost klesá. To je napětí, které se nyní projevuje napříč inženýrskými organizacemi.

Gitar využívá agentů umělé inteligence k manipulaci s kontrolami kódu, testováním a pracovními postupy CI. Jak se tyto agenti fundamentálně liší od tradičních statických analytických nástrojů a pravidel založených na pipeline?

Rozdíl není kosmetický. Skutečný agent musí dělat více než reagovat na podněty. Musí zvládat vícekrokové práce, plánovat, používat nástroje, sledovat kontext a pohybovat úkoly vpřed bez konstantního vstupu.

Většina systémů nesplňuje tuto laťku. Generují výstupy, ale neřídí výkon. Když jsou tyto nástroje umístěny do skutečných pracovních postupů, mezery se rychle projeví. Ne snižují komplexitu. Ve mnoha případech přidávají další vrstvu, kterou někdo musí spravovat.

To je proč se konverzace posouvá od „máme agenti“ k „jakou práci lze skutečně zvládnout spolehlivě“.

Důvěra je hlavní bariérou pro automatizaci ve softwarovém vývoji. Jak Gitar zajišťuje, že jeho proces validace je dostatečně spolehlivý pro týmy, aby se na něj mohli spolehnout?

Schéma, které funguje, je jednoduché. Rozdělit práci na menší kroky. Definovat jasné hranice. Kontinuálně ověřovat výstupy. Udržovat lidi zapojené tam, kde rozhodnutí nesou riziko.

Agenti mohou kontrolovat kód a vyhledávat problémy, které jsou snadno přehlédnutelné v měřítku. Mohou analyzovat selhání CI, seskupovat související chyby a ukazovat na pravděpodobnou kořenovou příčinu. Mohou navrhovat opravy a v některých případech je aplikovat kontrolovaným způsobem.

To snižuje množství manuální triáže, které musí inženýři provádět. Neodstraňuje inženýry z smyčky, ale mění, kde tráví čas. Většina systémů funguje s kontrolními body, ne s úplnou nezávislostí.

Vaše platforma umožňuje týmům vytvářet své vlastní agenti. Jak důležitá je pro podnikové přijetí přizpůsobitelnost, a jaké jsou některé z nejzajímavějších případů použití, které vidíte?

Přizpůsobitelnost je esenciální pro podnikové přijetí. Každý tým platformy tráví významné zdroje přizpůsobováním CI svým konkrétním potřebám, a to tradičně vyžadovalo přizpůsobené skripty, konfiguraci, integraci nástrojů, procesory logů a zbytek lepicí pásky, která drží moderní infrastrukturu pro vývojáře pohromadě.

Gitar kolabuje tuto práci. Týmy platformy mohou psát vlastní kontroly pomocí přirozeně-jazykových podnětů, které jim umožňují ověřovat věci, které jsou obtížné nebo nemožné s tradiční analýzou programu, například označení uživatelsky orientovaných řetězců, které jsou nejednoznačné pro překlad, nebo ověřování aktualizací souborů AGENTS.md. Mohou také automatizovat vlastní pracovní postupy nad žádostmi o stažení: propojovat PR s Jira problémy, otevírat následné tikety pro nevyřešené komentáře k recenzi, automaticky opakovaně spouštět nestabilní testy nebo připojovat vlastní seznamy úkolů k souhrnům PR.

Nejzajímavější případy použití tendují být ty, které jsme nečekali. Týmy znají své kódy a své bolesti lépe než jakékoli dodavatelské společnosti, takže když jim dáte primitiv, který změní „přáli bychom si, aby CI mohl jen zkontrolovat X“ na 10řádkový podnět, okamžitě začnou automatizovat věci, které bychom nikdy nevytvořili výchozím způsobem. To je přesně to, co chceme.

Moderní inženýrské týmy spoléhají na komplexní sadu nástrojů, jako jsou GitHub, GitLab a Jira. Jak důležité je pro Gitar integrovat se do stávajících pracovních postupů, místo toho, aby se snažil nahradit je?

Přijetí závisí na setkání s vývojáři tam, kde již jsou. Inženýři nechtějí další povrch učit se, další dashboard zkontrolovat, nebo více přepínání kontextu mezi nástroji. Chtějí, aby jejich stávající pracovní postupy byly rychlejší a tišší. Takže hluboká integrace s GitHub, GitLab, Jira a zbytkem stacku není pro nás „hezké mít“; je to celá strategie.

Ale naše ambice jdou dále než integrace. Nejsme se snažící nahradit tyto nástroje, a nejsme se snažící se pouze zapojit do nich. Automatizujeme pracovní postupy, které běží napříč nimi. Kontrola PR, propojení tiketů, následné úkoly, opakované spuštění nestabilních testů, vše by se mělo stát autonomně na pozadí. A tlačíme dále: agent edituje PR přímo, aby adresoval zpětnou vazbu z recenze a opravil selhání CI, a nakonec zpracovává schválení a sloučení pro změny, které splňují zásady týmu. Role vývojáře se mění z řízení každého kroku na stanovení záměru, kontrolu výsledků a zpracování výjimek.

Konečný stav není nový nástroj, do kterého se vývojáři přihlašují. Je to stávající nástroje, které dělají více sami, takže vývojáři mohou zůstat soustředění na práci, která skutečně vyžaduje jejich úsudek.

Vy jste naznačili, že lidské kontroly kódu by se mohly nakonec stát výjimkou, spíše než pravidlem. Co musí nastat, aby se organizace cítili pohodlně s tímto posunem?

Důvěra se buduje ve fázích, ne najednou. Organizace potřebují vidět, s vlastním kódem, že umělá inteligence může najít chyby a zranitelnosti, které skutečně záleží, a vynucovat jejich vlastní pravidla s přesností a vysokou pokrytím. Od toho je cesta k autonomnímu slučování přirozeným postupem skrze čtyři úrovně rostoucí důvěry.

První úroveň je detekce. Týmy budují důvěru, že agenti najdou skutečné problémy s nízkou mírou falešných pozitiv. Jakmile je tato důvěra zavedena, dovolí AI automaticky blokovat PR, když najde kritické problémy.

Druhá úroveň je náprava. AI neonly označí problémy, ale opraví je, odemkne PR a otočí CI zeleně bez lidského zásahu. Důvěra zde znamená, že agent může řešit problémy a selhání CI přesně, bez rozbití věcí.

Třetí úroveň je schválení. Jakmile týmy uvidí, že agenti spolehlivě otočí PR zeleně, dovolí AI schválit PR pod pravidly, které definují. Poskytnutí organizacím explicitní kontroly nad podmínkami pro automatické schválení je to, co dělá tento krok bezpečným, spíše než bezohledným.

Čtvrtá úroveň je sloučení. AI přistane změnu, opět pod podmínkami, se kterými je tým spokojen. Tento krok má svou vlastní laťku: agent musí přesně vyřešit konflikty sloučení, bez zavedení regresí nebo rozbití hlavní větve. To záleží více, než si lidé uvědomují, protože frekvence konfliktů se zvyšuje s průtokem commitů, a průtok exploduje, protože umělá inteligence generuje více kódu. Velké monorepo již cítí toto; každý jiný brzy bude.

Posun k AI jako výchozímu recenzentovi není jednorázový skok víry. Je to žebřík, a organizace ho šplhají po jednom rungu najednou, jak se důkazy hromadí.

Jakmile se umělá inteligence vezme na více kódování, jak vidíte roli senior inženýrů, kteří se vyvíjí v průběhu příštích několika let?

Senioři inženýři již přecházejí do koordinačních rolí, skládají together logy, diagnostikují problémy a rozhodují, co je bezpečné pro sloučení. To není role, na kterou někdo plánoval. Je to reakce na systém, který se rozpadá pod zátěží.

Jak agenti přebírají více repetitivní validační práce, inženýři zůstávají ve smyčce, ale posouvají se výš na stack. Tráví méně času na manuální triáži a více času na rozhodování o tom, co by se mělo dodat a proč.

Gitar nedávno vybral 9 milionů dolarů, aby škáloval platformu. Jaké jsou vaše hlavní priority pro tento kapitál, a co vypadá úspěch v průběhu příštích 12 až 18 měsíců?

Kapitál jde směrem k dvěma prioritám. První je go-to-market: škálujeme naše podnikové hnutí a investujeme do povědomí vývojářů, aby týmy, které by mohly těžit z Gitaru, věděly, že existujeme. Druhá je produkt: pokračujeme ve výstavbě naší vize plně autonomní validace a kvality kódu, což znamená hlubší schopnosti agentů, širší pokrytí pracovních postupů a těsnější integraci s nástroji, které vývojáři již používají.

Úspěch v průběhu příštích 12 až 18 měsíců vypadá jako významná základna podnikových zákazníků, kteří běží Gitar napříč svými kódy, vývojářská komunita, která nás rozpoznává jako výchozí pro validaci kódu poháněnou umělou inteligencí, a jasný důkaz, že naši agenti dělají více kontrol, nápravy a slučování autonomně v průběhu času. Pokud jsme na správné cestě, konverzace za rok nebude o tom, zda umělá inteligence může validovat kód, ale o tom, kolik validační pipeline tým předal agentům.

Děkuji za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit Gitar.