Ali-Reza Adl-Tabatabai, Fondator și CEO la Gitar – Seria de interviuri

Ali-Reza Adl-Tabatabai, Fondator și CEO la Gitar, este un veteran al conducerii inginerești a cărui carieră cuprinde unele dintre cele mai influente companii de tehnologie din Silicon Valley, inclusiv Uber, Google, Facebook, Intel, AMD și IBM. Înainte de a lansa Gitar în 2023, el a ocupat funcția de Director Senior de Inginerie la Uber, unde a ajutat la conducerea inițiativelor platformei de dezvoltatori ai companiei, după rolurile de conducere anterioare de la Google, care supravegheau Ingineria Fiabilității Site-ului pentru produse precum Comunicații, Fotografii, Social, Cloud și infrastructură tehnică.

La începutul carierei sale, el a lucrat la tehnologii de compilare, mașini virtuale, sisteme de calcul paralel și optimizare hardware la Intel Labs și echipa HipHop VM de la Facebook, în timp ce a predat și proiectare avansată de compilatoare la Universitatea Stanford. Fondul său de cunoștințe de decenii în limbaje de programare, infrastructură de încredere, instrumente pentru dezvoltatori și arhitectură de sisteme la scară largă l-a poziționat ca o figură proeminentă în peisajul evolutiv al ingineriei software bazate pe inteligență artificială.

Gitar se axează pe o problemă în creștere care provine din ascensiunea dezvoltării software asistate de inteligență artificială: validarea și securizarea volumului enorm de cod generat de mașini care curge acum în sistemele enterprise. Platforma utilizează agenți inteligenți artificiali pentru a automatiza revizuirea codului, a investiga eșecurile pipeline-ului de integrare continuă/dezvoltare continuă, a identifica bug-uri și vulnerabilități, a recomanda remedieri și a se integra direct în fluxurile de lucru inginerești existente prin instrumente precum GitHub, GitLab, Jenkins, Jira și Slack. În loc să concureze doar în generarea de cod mai rapid, compania se poziționează în jurul a ceea ce descrie ca “porți de calitate agenților”, ajutând echipele de ingineri să mențină fiabilitatea, securitatea și supravegherea operațională pe măsură ce dezvoltarea software se îndreaptă tot mai mult către fluxuri de codare autonome și asistate de inteligență artificială.

Ai condus ingineria la Uber, Google și Intel Labs, lucrând la platforme de dezvoltatori și infrastructură la scară largă. Care sunt experiențele specifice din această călătorie care te-au determinat să fondezi Gitar, și de ce te-ai axat pe validarea codului în loc de generarea codului?

De-a lungul Uber, Google, Facebook și Intel Labs, am lucrat la platforme de dezvoltatori la scară foarte diferită, și aceeași lecție a apărut mereu: experiența dezvoltatorului este un avantaj competitiv. Uneltele bune atrag și rețin cei mai buni ingineri și permit companiilor să se miște rapid. Dezvoltatorii vor unelte rapide, fără zgomot, care îi țin în flux și automatizează munca de rutină. Dar instrumentele pentru dezvoltatori sunt profund fragmentate, și majoritatea companiilor ard resurse uriașe de inginerie doar pentru a coase o experiență coerentă. Am văzut direct cât de multă forță există în a remedia această problemă.

Inteligența artificială schimbă ecuația prin faptul că face posibilă automatizarea mult mai mult a fluxului de lucru al dezvoltatorului decât înainte. Generarea codului este deja bine acoperită, dar acest lucru a mutat doar încuietoarea mai jos, la validarea, refacerea și întreținerea codului pe care îl producem acum la un volum fără precedent. Acolo este axat Gitar. Pe măsură ce inteligența artificială scrie mai mult cod, resursa rară nu este generarea; este încrederea, corectitudinea și menținabilitatea a ceea ce se livrează. Validarea codului este partea fluxului de lucru care determină dacă codul generat de inteligență artificială ajunge în siguranță la producție, și aceasta este problema mai grea și mai valoroasă de rezolvat.

Cu ascensiunea codului generat de inteligență artificială, multe echipe se confruntă acum cu ceea ce unii numesc “supraîncărcare de cod”. Cât de semnificativă este această problemă în interiorul întreprinderilor de astăzi, și unde se luptă echipele cel mai mult?

Schimbarea nu este în scrierea codului. Acea parte se mișcă deja mai rapid decât majoritatea echipelor pot absorbi. Ceea ce s-a schimbat este tot ceea ce vine după. Uneltele de inteligență artificială generează un flux constant de solicitări de tragere, adesea mai rapid decât echipele pot revizui, ceea ce creează presiune în părți ale sistemului care nu au fost proiectate pentru acest nivel de ieșire.

Fiecare modificare trebuie să treacă încă prin validare. Revizuirea codului. Integrarea continuă/dezvoltare continuă. Verificările de securitate. Aprobările. Nimic din toate acestea nu dispare doar pentru că codul este generat mai rapid. Ceea ce era o flux gestionabil s-a transformat într-o listă de așteptare. Echipele nu sunt blocate pe idei sau implementare. Sunt blocate pe încredere. Poate fi livrat? Este sigur? A stricat ceva subtil?

Acolo stă frictica acum. Nu în creare, ci în a face ca codul să treacă de linia de finish fără a introduce risc.

Industria s-a axat în mare măsură pe generarea codului mai rapid. De ce crezi că validarea a fost neglijată, și de ce devine mai critică acum?

Pentru că sistemul din aval de generarea codului nu a evoluat cu același ritm. Când ieșirea crește, totul din aval este stresat. Solicitările de tragere devin mai mari și mai frecvente. Eșecurile de integrare continuă/dezvoltare continuă încep să se îngrămădească. Ciclurile de revizuire se comprimă pentru că nimeni nu are timp să se adâncească în fiecare modificare.

Calitatea începe să alunece, nu pentru că inginerii nu se preocupă, ci pentru că volumul forțează compromisuri. Echipele de platformă preiau mai mult din povara muncii, gestionând problemele pipeline-ului, triajând eșecurile și încercând să țină totul în mișcare. Inginerii seniori ajung să acționeze ca coordonatori, asamblând jurnale, diagnosticând probleme și decidând ce este sigur de a fi fuzionat.

Echipele se confruntă cu o alegere care nu funcționează cu adevărat în niciun fel. Treceți codul rapid și faceți față regresiei mai târziu, sau încetiniți și protejați calitatea, dar acceptați că viteza scade. Această tensiune apare în toate organizațiile de inginerie în acest moment.

Gitar utilizează agenți inteligenți artificiali pentru a gestiona revizuirile codului, testele și fluxurile de integrare continuă/dezvoltare continuă. Cum se diferențiază fundamental acești agenți de uneltele tradiționale de analiză statică și pipeline-urile bazate pe reguli?

Diferența nu este cosmetică. Un agent real trebuie să facă mai mult decât să răspundă la prompturi. Trebuie să gestioneze munca în mai multe etape, să planifice, să utilizeze unelte, să țină cont de context și să mute sarcinile înainte fără input constant.

Majoritatea sistemelor nu îndeplinesc această bară. Ele generează ieșiri, dar nu gestionează execuția. Când aceste unelte sunt plasate în fluxuri de lucru reale, golurile devin evidente rapid. Nu reduc complexitatea. În multe cazuri, adaugă un strat suplimentar pe care cineva trebuie să îl gestioneze.

De aceea, conversația se mută de la “avem agenți” la “ce muncă poate fi gestionată cu adevărat în mod fiabil”.

Încrederea este o barieră majoră pentru automatizarea în dezvoltarea software. Cum asigură Gitar că procesul său de validare este suficient de fiabil pentru ca echipele să se bazeze pe el?

Modelul care funcționează este simplu. Împărțiți munca în pași mai mici. Definiți limite clare. Validați ieșirile continuu. Țineți oamenii implicați acolo unde deciziile implică risc.

Agenții pot revizui codul și poate evidenția probleme care sunt ușor de pierdut la scară. Pot analiza eșecurile de integrare continuă/dezvoltare continuă, pot grupa erorile corelate și pot indica o cauză probabilă a rădăcinii. Pot sugera remedieri și, în unele cazuri, pot aplica remedieri într-un mod controlat.

Acest lucru reduce cantitatea de triaj manual pe care inginerii trebuie să o facă. Nu îi elimină pe ingineri din buclă, dar schimbă unde își petrec timpul. Majoritatea sistemelor funcționează cu puncte de control, nu cu independență completă.

Platforma dvs. permite echipelor să creeze agenți personalizați. Cât de importantă este personalizarea pentru adoptarea la nivel de întreprindere, și care sunt unele dintre cele mai interesante cazuri de utilizare pe care le vedeți?

Personalizarea este esențială pentru adoptarea la nivel de întreprindere. Fiecare echipă de platformă cheltuie resurse semnificative pentru a adapta integrarea continuă/dezvoltare continuă la nevoile specifice ale companiei, și acest lucru a necesitat în mod tradițional scripturi personalizate, configurare, integrare de unelte, procesare de jurnale și restul bandului adeziv care ține infrastructura de dezvoltare modernă împreună.

Gitar reduce această muncă. Echipele de platformă pot scrie verificări personalizate folosind prompturi de limbaj natural, ceea ce le permite să valideze lucruri care sunt dificile sau imposibile cu analiza programatică tradițională, de exemplu, marcarea șirurilor cu caracter utilizator ambiguu pentru traducere, sau validarea actualizărilor fișierelor AGENTS.md. De asemenea, pot automatiza fluxuri de lucru personalizate deasupra solicitărilor de tragere: linkarea solicitărilor de tragere la probleme Jira, deschiderea de bilete de urmărire pentru comentarii de revizuire nerezolvate, retragerea automată a testelor instabile, sau atașarea de liste de sarcini personalizate la rezumatele solicitărilor de tragere.

Cele mai interesante cazuri de utilizare tind să fie cele pe care nu le-am anticipat. Echipele cunosc mai bine codebase-urile și punctele lor slabe decât orice furnizor, așa că atunci când le oferiți un primitiv care transformă “ne dorim ca integrarea continuă/dezvoltare continuă să poată verifica X” într-un prompt de 10 linii, ei încep imediat să automatizeze lucruri pe care nu le-am fi construit în mod normal. Acesta este exact ceea ce vrem.

Echipele de inginerie modernă se bazează pe un stivă complexă de unelte precum GitHub, GitLab și Jira. Cât de important este pentru Gitar să se integreze în fluxurile de lucru existente, în loc de a încerca să le înlocuiască?

Adoptarea depinde de a întâlni dezvoltatorii acolo unde deja sunt. Inginerii nu vor o altă suprafață de învățat, o altă panou de control de verificat, sau mai multă comutare de context între unelte. Vor ca fluxurile lor de lucru existente să devină mai rapide și mai liniștite. Prin urmare, integrarea profundă cu GitHub, GitLab, Jira și restul stivei nu este un lucru bun pentru noi; este întreaga strategie.

Dar ambiția noastră merge mai departe decât integrarea. Nu încercăm să înlocuim aceste unelte, și nu încercăm să ne conectăm la ele. Suntem automatizarea fluxurilor de lucru care rulează peste ele. Revizuirea solicitării de tragere, linkarea bileților, sarcinile de urmărire, retragerea testelor instabile, toate acestea ar trebui să se întâmple în mod autonom, în fundal. Și mergem mai departe: un agent editează direct solicitarea de tragere pentru a aborda feedback-ul de revizuire și a remedia eșecurile de integrare continuă/dezvoltare continuă, și în cele din urmă gestionează aprobarea și fuziunea pentru modificările care îndeplinesc politicile echipei. Rolul dezvoltatorului se schimbă de la a conduce fiecare pas la a stabili intenția, a revizui rezultatele și a gestiona excepțiile.

Starea finală nu este un nou instrument în care dezvoltatorii se autentifică. Este uneltele existente care fac mai multe singure, astfel încât dezvoltatorii să poată rămâne concentrați pe munca care necesită cu adevărat judecata lor.

Ai sugerat că revizuirile de cod umane ar putea deveni în cele din urmă excepția, mai degrabă decât regula. Ce trebuie să se întâmple pentru ca organizațiile să se simtă confortabil cu această schimbare?

Încrederea se construiește în etape, nu o dată. Organizațiile trebuie să vadă, cu propriul lor cod, că inteligența artificială poate găsi bug-urile și vulnerabilitățile care contează cu adevărat și să impună reguli personalizate cu precizie și acoperire ridicată. De acolo, calea către fuziunea autonomă este o evoluție naturală prin patru niveluri de încredere crescândă.

Primul nivel este detectarea. Echipele construiesc încredere că agenții găsesc probleme reale cu o rată scăzută de fals pozitive. Odată ce această încredere este stabilită, ei lasă inteligența artificială să blocheze automat solicitările de tragere atunci când găsește probleme critice.

Al doilea nivel este remedierea. Inteligența artificială nu doar semnalează probleme, ci și le remediază, deblochează solicitarea de tragere și face integrarea continuă/dezvoltare continuă verde fără intervenție umană. Încrederea aici înseamnă că agentul poate rezolva probleme și eșecuri de integrare continuă/dezvoltare continuă cu precizie, fără a strica lucrurile.

Al treilea nivel este aprobarea. Odată ce echipele văd agenții care aprobă solicitările de tragere în mod fiabil, sub regulile pe care le definesc, le permit inteligenței artificiale să aprobe solicitările de tragere. A da organizațiilor control explicit asupra condițiilor pentru aprobarea automată este ceea ce face acest pas să se simtă sigur, mai degrabă decât nechibzuit.

Al patrulea nivel este fuziunea. Inteligența artificială aterizează modificarea, din nou sub condițiile cu care echipa este confortabilă. Acest pas are propria sa bară: agentul trebuie să rezolve conflictele de fuziune cu precizie, fără a introduce regresii sau a strica main. Acest lucru contează mai mult decât oamenii realizează, deoarece frecvența conflictelor crește odată cu debitul de angajare, și debitul explodează pe măsură ce inteligența artificială generează mai mult cod. Monorepozitoriile mari simt deja acest lucru; toată lumea este pe cale să o facă.

Schimbarea către inteligența artificială ca revizor implicit nu este un singur salt de încredere. Este o scară, și organizațiile urcă una câte una pe măsură ce dovezi se acumulează.

Pe măsură ce inteligența artificială preia mai mult din procesul de codare, cum vezi evoluând rolul inginerilor senior în următorii ani?

Inginerii seniori se mută deja în roluri de coordonare, asamblând jurnale, diagnosticând probleme și decidând ce este sigur de a fi fuzionat. Acesta nu este un rol pe care cineva l-a planificat. Este o reacție la sistemul care se rupe sub sarcină.

Pe măsură ce agenții preiau mai mult din munca de validare repetitivă, inginerii rămân în buclă, dar se mută mai sus în stivă. Petrec mai puțin timp cu triajul manual și mai mult timp luând decizii despre ce ar trebui să fie livrat și de ce.

Gitar a strâns recent 9 milioane de dolari pentru a scala platforma. Care sunt prioritățile dvs. de top pentru acest capital, și ce reprezintă succesul în următorii 12 până la 18 luni?

Capitalul se îndreaptă către două priorități. Prima este piața: suntem scalând mișcarea noastră de întreprindere și investim în conștientizarea dezvoltatorilor, astfel încât echipele care ar beneficia de Gitar să știe că existăm. A doua este produsul: continuăm să construim spre viziunea noastră de validare și calitate de cod complet autonomă, ceea ce înseamnă capabilități de agent mai profunde, acoperire de flux de lucru mai largă și integrare mai strânsă cu uneltele pe care dezvoltatorii le folosesc deja.

Succesul în următorii 12 până la 18 luni arată ca o bază semnificativă de clienți de întreprindere care rulează Gitar pe codebase-urile lor, o comunitate de dezvoltatori care ne recunosc ca standardul pentru validarea codului condusă de inteligență artificială, și dovezi clare că agenții noștri fac mai mult din munca de revizuire, remediere și fuziune în mod autonom pe parcursul timpului. Dacă suntem pe drumul cel bun, conversația de anul viitor nu este dacă inteligența artificială poate valida codul, ci cât din pipeline-ul de validare o echipă a încredințat agenților.

Mulțumim pentru acest interviu minunat, cititorilor care doresc să afle mai multe despre Gitar.