Ali-Reza Adl-Tabatabai, Założyciel i Dyrektor Generalny Gitar – Wywiad

Ali-Reza Adl-Tabatabai, Założyciel i Dyrektor Generalny Gitar, jest doświadczonym liderem inżynierii, którego kariera obejmuje niektóre z najbardziej wpływowych firm technologicznych w Dolinie Krzemowej, w tym Uber, Google, Facebook, Intel, AMD i IBM. Przed założeniem Gitar w 2023 roku pełnił funkcję Starszego Dyrektora Inżynierii w Uberze, gdzie pomagał kierować inicjatywami platformy deweloperskiej, po wcześniejszych rolach kierowniczych w Google, nadzorując Inżynierię Niezawodności Witryn dla produktów takich jak Komunikacja, Zdjęcia, Społeczność, Chmura i infrastruktura techniczna.

We wczesnej fazie swojej kariery pracował nad technologiami kompilatora, maszyn wirtualnych, systemami obliczeń równoległych i optymalizacją sprzętu w Intel Labs i zespole HipHop VM w Facebooku, a także wykładał zaawansowany projekt kompilatora na Uniwersytecie Stanforda. Jego wieloletnie doświadczenie w językach programowania, niezawodności infrastruktury, narzędziach deweloperskich i architekturze systemów wielkoskalowych pozwoliło mu zostać prominentną postacią w ewoluującym krajobrazie inżynierii oprogramowania wspomaganej przez sztuczną inteligencję.

Gitar koncentruje się na rosnącym problemie wynikającym z rozwoju oprogramowania wspomaganego przez sztuczną inteligencję: walidacji i zabezpieczania ogromnej ilości kodu generowanego przez maszyny, który teraz wpływa do systemów przedsiębiorstw. Platforma wykorzystuje agenty sztucznej inteligencji do automatyzacji przeglądu kodu, badania awarii pipeline CI/CD, identyfikacji błędów i luk w zabezpieczeniach, sugerowania poprawek i integracji bezpośrednio z istniejącymi workflow inżynierskimi za pomocą narzędzi takich jak GitHub, GitLab, Jenkins, Jira i Slack. Zamiast konkurować wyłącznie w generowaniu kodu, firma pozycjonuje się wokół tego, co określa jako „bramki jakości agencji”, pomagając zespołom inżynierskim w utrzymaniu niezawodności, bezpieczeństwa i nadzoru operacyjnego, gdy rozwój oprogramowania coraz bardziej przechodzi w kierunku kodowania autonomicznego i wspomaganego przez sztuczną inteligencję.

Prowadziłeś inżynierię w Uberze, Google i Intel Labs, pracując nad dużymi platformami deweloperskimi i infrastrukturą. Jakie konkretnie doświadczenia z tej podróży skłoniły Cię do założenia Gitar, i dlaczego skoncentrowałeś się na walidacji kodu zamiast generowaniu?

Przez Uber, Google, Facebook i Intel Labs pracowałem nad platformami deweloperskimi w bardzo różnych skalach, i ta sama lekcja się powtarzała: doświadczenie deweloperskie jest przewagą konkurencyjną. Wielkie narzędzia przyciągają i zatrzymują najlepszych inżynierów i pozwalają firmom poruszać się szybko. Deweloperzy chcą szybkie, bezszumowe narzędzia, które pozwalają im pozostać w przepływie i automatyzują pracę rutynową. Ale narzędzia deweloperskie są głęboko fragmentowane, a większość firm spala ogromne zasoby inżynierskie, po prostu składając spójne doświadczenie. Zobaczyłem na własne oczy, jak wiele jest do zyskania, naprawiając to.

Sztuczna inteligencja zmienia równanie, czyniąc możliwym zautomatyzowanie o wiele więcej przepływu deweloperskiego niż wcześniej. Generowanie kodu jest już dobrze pokryte, ale to tylko przeniosło wąskie gardło w dół, do walidacji, refaktoryzacji i utrzymania kodu, który teraz produkujemy w niezwykłej ilości. To tam Gitar się koncentruje. Gdy sztuczna inteligencja pisze więcej kodu, rzadkim zasobem nie jest generacja; jest to zaufanie, poprawność i utrzymanie tego, co się wysyła. Walidacja kodu jest częścią przepływu, która decyduje, czy wygenerowany przez sztuczną inteligencję kod naprawdę trafia do produkcji bezpiecznie, i to jest trudniejszy, bardziej wartościowy problem do rozwiązania.

Wraz ze wzrostem kodu generowanego przez sztuczną inteligencję, wiele zespołów ma teraz do czynienia z tym, co niektórzy nazywają przeciążeniem kodem. Jak istotny jest ten problem wewnątrz przedsiębiorstw dzisiaj, i gdzie zespoły mają największe trudności?

Zmiana nie polega na pisaniu kodu. Ta część już porusza się szybciej, niż większość zespołów może pochłonąć. To, co się zmieniło, to wszystko, co pochodzi później. Narzędzia sztucznej inteligencji generują stały strumień wniosków o przyjęcie, często szybciej, niż zespoły mogą je przeglądać, co tworzy presję w częściach systemu, które nie były zaprojektowane do tego poziomu wydajności.

Każda zmiana musi nadal przejść przez walidację. Przegląd kodu. CI. Kontrole bezpieczeństwa. Akceptacje. Nic z tego nie znika tylko dlatego, że kod jest generowany szybciej. To, co kiedyś było zarządzalnym przepływem, stało się zaległością. Zespoły nie są zablokowane przez pomysły lub wdrożenie już teraz. Są one zablokowane przez zaufanie. Czy to może się wydarzyć? Czy jest bezpieczne? Czy to coś złamało?

To tam siedzi tarcie teraz. Nie w tworzeniu, ale w tym, aby dostać kod przez linię mety bez wprowadzania ryzyka.

Branża w dużej mierze koncentrowała się na generowaniu kodu szybciej. Dlaczego uważasz, że walidacja była zaniedbana, i dlaczego staje się coraz bardziej krytyczna teraz?

Ponieważ system w dół od generacji kodu nie ewoluował w tym samym tempie. Gdy wydajność wzrasta, wszystko w dół staje się zestresowane. Wnioski o przyjęcie stają się większe i częstsze. Awarie CI zaczynają się piętrzyć. Cykle przeglądu są ściśnięte, ponieważ nikt nie ma czasu, aby głęboko zajrzeć w każdą zmianę.

Jakość zaczyna się ślizgać, nie dlatego, że inżynierowie nie dbają, ale dlatego, że objętość wymusza kompromisy. Zespoły platformowe biorą na siebie więcej ciężaru, radząc sobie z problemami pipeline, triażując awarie i starając się utrzymać wszystko w ruchu. Starsi inżynierowie kończą jako koordynatorzy, łącząc dzienniki, diagnozując problemy i decydując, co jest bezpieczne do scalenia.

Zespoły stają przed wyborem, który nie działa naprawdę w żaden sposób. Pchnąć kod przez szybko i radzić sobie z regresjami później, lub zwolnić i chronić jakość, ale zaakceptować, że prędkość maleje. To napięcie pojawia się w organizacjach inżynierskich w tej chwili.

Gitar wykorzystuje agenty sztucznej inteligencji do obsługi przeglądów kodu, testów i przepływów ciągłej integracji (CI). Jak te agenty fundamentalnie różnią się od tradycyjnych narzędzi analizy statycznej i pipeline opartych na regułach?

Różnica nie jest kosmetyczna. Prawdziwy agent musi robić coś więcej niż tylko reagować na polecenia. Musi radzić sobie z wieloetapową pracą, planować, używać narzędzi, śledzić kontekst i przesuwać zadania do przodu bez stałego wprowadzania.

Większość systemów nie spełnia tego poziomu. Generują dane wyjściowe, ale nie zarządzają wykonaniem. Gdy te narzędzia są umieszczane wewnątrz prawdziwych workflow, luki szybko się pojawiają. Nie redukują złożoności. W wielu przypadkach dodają kolejną warstwę, którą ktoś musi zarządzać.

To dlatego rozmowa przechodzi od „czy mamy agenty” do „jaką pracę można naprawdę obsłużyć w sposób niezawodny”.

Zaufanie jest dużą barierą dla automatyzacji w rozwoju oprogramowania. Jak Gitar zapewnia, że jego proces walidacji jest wystarczająco niezawodny, aby zespoły mogły na niego liczyć?

Wzorzec, który działa, jest prosty. Podziel pracę na mniejsze kroki. Zdefiniuj wyraźne granice. Waliduj dane wyjściowe w sposób ciągły. Zachowaj ludzi zaangażowanych tam, gdzie decyzje niosą ze sobą ryzyko.

Agenci mogą przeglądać kod i ujawniać problemy, które są łatwe do przeoczenia w skali. Mogą analizować awarie CI, grupować powiązane błędy i wskazywać prawdopodobną przyczynę. Mogą sugerować poprawki i, w niektórych przypadkach, stosować je w kontrolowany sposób.

To redukuje ilość ręcznej triażu, którą inżynierowie muszą wykonać. Nie usuwa inżynierów z pętli, ale zmienia, gdzie spędzają czas. Większość systemów działa z punktami kontrolnymi, a nie pełną niezależnością.

Twoja platforma pozwala zespołom tworzyć własne agenty. Jak ważna jest dostosowywalność dla przyjęcia w przedsiębiorstwach, i jakie są niektóre z najbardziej interesujących przypadków użycia, które widzisz?

Dostosowywalność jest niezbędna dla przyjęcia w przedsiębiorstwach. Każdy zespół platformy spędza znaczne zasoby na dostosowywanie CI do specyficznych potrzeb swojej firmy, co tradycyjnie wymagało niestandardowych skryptów, konfiguracji, integracji narzędzi, procesorów dzienników i reszty kleju, który trzyma nowoczesną infrastrukturę deweloperską razem.

Gitar składa tę pracę. Zespoły platformowe mogą pisać niestandardowe kontrole przy użyciu poleceń w języku naturalnym, co pozwala im walidować rzeczy, które są trudne lub niemożliwe do wykonania przy użyciu tradycyjnej analizy programu, na przykład flagowanie napisów użytkowników, które są niejednoznaczne do tłumaczenia, lub walidacja aktualizacji plików AGENTS.md. Mogą również automatyzować niestandardowe przepływy na podstawie wniosków o przyjęcie: łączenie wniosków o przyjęcie z problemami Jira, otwieranie kolejnych biletów dla nierozwiązanych komentarzy przeglądu, automatyczne ponowne uruchamianie testów, które są kapryśne, lub dołączanie niestandardowych list zadań do podsumowań wniosków o przyjęcie.

Najbardziej interesujące przypadki użycia mają tendencję do być tymi, których nie przewidzieliśmy. Zespoły znają swoje bazy kodu i swoje punkty bólu lepiej niż jakikolwiek dostawca, więc gdy dajesz im prymityw, który zmienia „chcielibyśmy, aby CI sprawdziło X” w 10-liniowe polecenie, natychmiast zaczynają automatyzować rzeczy, których byśmy nigdy nie zbudowali domyślnie. To jest dokładnie to, czego chcemy.

Nowoczesne zespoły inżynierskie polegają na złożonej stercie narzędzi, takich jak GitHub, GitLab i Jira. Jak ważne jest dla Gitar, aby integrować się z istniejącymi workflow, zamiast próbować je zastąpić?

Przyjęcie zależy od spotkania z deweloperami tam, gdzie już są. Inżynierowie nie chcą nowej powierzchni do nauki, nowego pulpitu do sprawdzania, ani więcej przełączania kontekstu między narzędziami. Chcą, aby ich istniejące workflow stały się szybsze i cichsze. Więc głęboka integracja z GitHub, GitLab, Jira i resztą sterty nie jest dla nas „miłym dodatkiem”; to cała strategia.

Ale nasza ambicja idzie dalej niż integracja. Nie próbujemy zastąpić tych narzędzi, i nie próbujemy tylko włączyć się do nich. Automatyzujemy przepływy, które działają przez nie. Przegląd wniosków o przyjęcie, łączenie biletów, zadania follow-up, ponowne uruchamianie testów, które są kapryśne, wszystko to powinno dziać się automatycznie, w tle. I idziemy dalej: agent edytuje wniosek o przyjęcie bezpośrednio, aby rozwiązać komentarze dotyczące przeglądu kodu i awarie CI, i ostatecznie obsługuje akceptację i scalenie zmian, które spełniają politykę zespołu. Rola dewelopera zmienia się z prowadzenia każdego kroku do ustawiania intencji, przeglądania wyników i obsługi wyjątków.

Stan końcowy nie jest nowym narzędziem, do którego deweloperzy logują się. To istniejące narzędzia, które robią więcej samodzielnie, aby deweloperzy mogli pozostać skupieni na pracy, która naprawdę wymaga ich osądu.

Uzasadniłeś, że przeglądy kodu ludzkiego mogą ostatecznie stać się wyjątkiem, a nie regułą. Co musi się wydarzyć, aby organizacje czuły się komfortowo z tym przesunięciem?

Zaufanie buduje się etapami, a nie wszystko naraz. Organizacje muszą zobaczyć, z własnym kodem, że sztuczna inteligencja może znaleźć błędy i luki w zabezpieczeniach, które naprawdę mają znaczenie, i egzekwować ich niestandardowe reguły z precyzją i wysokim pokryciem. Od tego momentu droga do autonomicznego scalania jest naturalną progresją przez cztery poziomy rosnącego zaufania.

Pierwszy poziom to wykrywanie. Zespoły budują zaufanie, że agenci znajdują prawdziwe problemy z niskim wskaźnikiem fałszywych pozytywów. Gdy to zaufanie zostanie ustanowione, pozwalają sztucznej inteligencji automatycznie blokować wnioski o przyjęcie, gdy znajduje krytyczne problemy.

Drugi poziom to naprawa. Sztuczna inteligencja nie tylko flaguje problemy, ale także je naprawia, odblokowując wniosek o przyjęcie i robiąc CI zielone bez interwencji człowieka. Zaufanie tutaj oznacza, że agent może rozwiązać problemy i awarie CI precyzyjnie, bez łamania rzeczy.

Trzeci poziom to akceptacja. Gdy zespoły widzą, że agenci niezawodnie robią wnioski o przyjęcie zielone, pozwalają sztucznej inteligencji akceptować wnioski o przyjęcie pod regułami, które definiują. Dając organizacjom wyraźną kontrolę nad warunkami autoakceptacji, czyni ten krok bezpiecznym, a nie lekkomyślnym.

Czwarty poziom to scalanie. Sztuczna inteligencja ląduje zmianę, ponownie pod warunkami, z którymi zespół jest zadowolony. Ten krok ma swój własny próg: agent musi rozwiązać konflikty scalania precyzyjnie, bez wprowadzania regresji lub łamania głównego. To ma znaczenie, ponieważ częstotliwość konfliktów wzrasta wraz z przepływem commitów, a przepływ wybuchowy rośnie, gdy sztuczna inteligencja generuje więcej kodu. Duże monorepo już to czują; wszyscy inni będą wkrótce.

Przesunięcie w kierunku sztucznej inteligencji jako domyślnego recenzenta nie jest jednym skokiem wiary. To drabina, a organizacje wspinają się po niej stopniowo, gdy dowody się kumulują.

Jak widzisz ewolucję roli starszych inżynierów w ciągu najbliższych kilku lat, gdy sztuczna inteligencja zajmuje się coraz większą częścią procesu kodowania?

Starsi inżynierowie już przechodzą w role koordynacyjne, łącząc dzienniki, diagnozując problemy i decydując, co jest bezpieczne do scalenia. To nie jest rola, na którą ktoś planował. To reakcja na system, który łamie się pod obciążeniem.

Gdy agenci zajmują się więcej powtarzalną pracą walidacji, inżynierowie pozostają w pętli, ale przechodzą wyżej w stosie. Spędzają mniej czasu na ręcznej triaż i więcej czasu na podejmowanie decyzji o tym, co powinno się wydarzyć, i dlaczego.

Gitar niedawno podniósł 9 milionów dolarów, aby skalować platformę. Jakie są Twoje najwyższe priorytety dla tego kapitału, i co stanowi sukces w ciągu najbliższych 12 do 18 miesięcy?

Kapitał idzie w kierunku dwóch priorytetów. Pierwszy to ruch w kierunku rynku: skalujemy nasz ruch w kierunku przedsiębiorstw i inwestujemy w świadomość deweloperów, aby zespoły, które mogą skorzystać z Gitar, wiedziały, że istniejemy. Drugi to produkt: kontynuujemy budowanie w kierunku naszej wizji w pełni autonomicznej walidacji i jakości kodu, co oznacza głębsze możliwości agentów, szersze pokrycie przepływu i głębszą integrację z narzędziami, których deweloperzy już używają.

Sukces w ciągu najbliższych 12 do 18 miesięcy wygląda jak znacząca baza klientów przedsiębiorstw, którzy uruchamiają Gitar na swoich bazach kodu, społeczność deweloperów, która rozpoznaje nas jako domyślne rozwiązanie dla walidacji kodu napędzanej przez sztuczną inteligencję, oraz klarowne dowody, że nasi agenci wykonują więcej przeglądu, naprawy i scalania pracy autonomicznie w czasie. Jeśli będziemy na dobrej drodze, rozmowa za rok nie będzie już „czy sztuczna inteligencja może walidować kod”, ale „ile rurociągu walidacji zespół przekazał agentom”.

Dziękuję za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Gitar.