Ali-Reza Adl-Tabatabai, Fondatore e Amministratore Delegato di Gitar – Serie di Interviste

Ali-Reza Adl-Tabatabai, Fondatore e Amministratore Delegato di Gitar, è un veterano leader di ingegneria la cui carriera copre alcune delle tecnologie più influenti a Silicon Valley, tra cui Uber, Google (GOOGL ), Facebook (META ), Intel (INTC ), AMD e IBM. Prima di lanciare Gitar nel 2023, ha ricoperto il ruolo di Senior Director of Engineering presso Uber, dove ha contribuito a guidare le iniziative della piattaforma di sviluppo dell’azienda, dopo aver ricoperto ruoli di leadership presso Google per la gestione della affidabilità del sito per prodotti come Communications, Photos, Social, Cloud e infrastrutture tecniche.

All’inizio della sua carriera, ha lavorato su tecnologie di compilazione, macchine virtuali, sistemi di calcolo parallelo e ottimizzazione hardware presso Intel Labs e il team HipHop VM di Facebook, oltre a insegnare progettazione avanzata di compilatori presso l’Università di Stanford. Il suo background decennale in linguaggi di programmazione, affidabilità delle infrastrutture, strumenti per sviluppatori e architettura di sistemi su larga scala lo ha posizionato come figura prominente nel panorama dell’ingegneria del software alimentata da AI.

Gitar si concentra su un problema crescente che emerge dall’aumento dello sviluppo del software assistito da AI: la convalida e la sicurezza del volume enorme di codice generato dalle macchine che ora fluisce nei sistemi aziendali. La piattaforma utilizza agenti AI per automatizzare la revisione del codice, indagare sui fallimenti della pipeline CI/CD, identificare bug e vulnerabilità, suggerire correzioni e integrarsi direttamente nei flussi di lavoro di ingegneria esistenti attraverso strumenti come GitHub, GitLab (GTLB ), Jenkins, Jira e Slack. Invece di competere solo nella generazione di codice AI, l’azienda si posiziona intorno a ciò che descrive come “porte di qualità agente”, aiutando i team di ingegneria a mantenere l’affidabilità, la sicurezza e la supervisione operativa mentre lo sviluppo del software si sposta sempre più verso flussi di lavoro di codifica autonomi e assistiti da AI.

Hai guidato l’ingegneria in Uber, Google e Intel Labs, lavorando su piattaforme di sviluppo e infrastrutture su larga scala. Quali esperienze specifiche di quel viaggio ti hanno portato a fondare Gitar e perché concentrarti sulla convalida del codice invece della generazione del codice?

In Uber, Google, Facebook e Intel Labs, ho lavorato su piattaforme di sviluppo a scale molto diverse, e la stessa lezione è emersa costantemente: l’esperienza dello sviluppatore è un vantaggio competitivo. Grandi strumenti attirano e mantengono i migliori ingegneri e permettono alle aziende di muoversi velocemente. Gli sviluppatori vogliono strumenti veloci e senza rumore che li mantengano nel flusso e automatizzino il lavoro di routine. Ma gli strumenti per sviluppatori sono profondamente frammentati, e la maggior parte delle aziende brucia enormi risorse ingegneristiche solo per cucire insieme un’esperienza coerente. Ho visto di persona quanto sia grande il vantaggio nel risolvere questo problema.

L’AI cambia l’equazione rendendo possibile automatizzare molto più del flusso di lavoro dello sviluppatore di quanto fosse possibile prima. La generazione di codice è già ben coperta, ma questo ha solo spostato il collo di bottiglia a valle, alla convalida, al refactoring e alla manutenzione del codice che stiamo producendo ad un volume senza precedenti. È lì che Gitar si concentra. Mentre l’AI scrive più codice, la risorsa scarsa non è la generazione; è la fiducia, la correttezza e la manutenibilità di ciò che viene spedito. La convalida del codice è la parte del flusso di lavoro che determina se il codice generato da AI può effettivamente raggiungere la produzione in modo sicuro, ed è il problema più difficile e più prezioso da risolvere.

Con l’aumento del codice generato da AI, molte squadre stanno ora affrontando ciò che alcuni chiamano “sovraccarico di codice”. Quanto è significativo questo problema all’interno delle aziende oggi e dove le squadre lottano di più?

Il cambiamento non è nella scrittura del codice. Quella parte si sta già muovendo più velocemente di quanto la maggior parte delle squadre possa assorbire. Ciò che è cambiato è tutto ciò che segue. Gli strumenti AI generano un flusso costante di richieste di pull, spesso più velocemente di quanto le squadre possano esaminarle, il che crea pressione in parti del sistema che non erano state progettate per questo livello di output.

Ogni modifica deve ancora superare la convalida. Revisione del codice. CI. Controlli di sicurezza. Approvazioni. Nessuna di queste cose scompare solo perché il codice viene generato più velocemente. Ciò che un tempo era un flusso gestibile si è trasformato in un backlog. Le squadre non sono più bloccate dalle idee o dall’implementazione, ma sono bloccate dalla fiducia. Posso spedire? È sicuro? Ha rotto qualcosa di sottile?

È lì che si trova l’attrito ora. Non nella creazione, ma nel far arrivare il codice alla fine senza introdurre rischi.

L’industria si è concentrata in gran parte sulla generazione di codice più veloce. Perché pensi che la convalida sia stata trascurata e perché sta diventando più critica ora?

Perché il sistema a valle della generazione del codice non è evoluto allo stesso ritmo. Quando l’output aumenta, tutto ciò che si trova a valle viene sottoposto a stress. Le richieste di pull diventano più grandi e più frequenti. I fallimenti CI iniziano ad accumularsi. I cicli di revisione si comprimono perché nessuno ha il tempo di andare in profondità su ogni modifica.

La qualità inizia a scendere, non perché gli ingegneri non si curano, ma perché il volume costringe a compromessi. I team di piattaforma assumono più del carico, gestiscono problemi di pipeline, diagnosticano problemi e cercano di tenere tutto in movimento. Gli ingegneri senior finiscono per agire come coordinatori, assemblando log, diagnosticando problemi e decidendo cosa è sicuro da unire.

Le squadre affrontano una scelta che non funziona veramente in nessun modo. Spingere il codice rapidamente e affrontare le regressioni in seguito, o rallentare e proteggere la qualità, ma accettare che la velocità diminuisce. Quella tensione sta emergendo in tutta l’organizzazione di ingegneria in questo momento.

Gitar utilizza agenti AI per gestire le revisioni del codice, i test e i flussi di lavoro di integrazione continua (CI). In che modo questi agenti differiscono fondamentalmente dagli strumenti di analisi statica tradizionali e dalle pipeline basate su regole?

La differenza non è cosmetica. Un agente reale deve fare più che rispondere a prompt. Deve gestire il lavoro a più passaggi, pianificare, utilizzare strumenti, tenere traccia del contesto e spostare le attività in avanti senza input costante.

La maggior parte dei sistemi non raggiunge questo standard. Generano output, ma non gestiscono l’esecuzione. Quando questi strumenti vengono inseriti in flussi di lavoro reali, le lacune si manifestano rapidamente. Non riducono la complessità. In molti casi, aggiungono un altro livello che qualcuno deve gestire.

È per questo che la conversazione si sta spostando da “abbiamo agenti” a “quale lavoro può essere gestito in modo affidabile”.

La fiducia è una grande barriera all’automazione nello sviluppo del software. Come fa Gitar a garantire che il suo processo di convalida sia sufficientemente affidabile per le squadre?

Il modello che funziona è semplice. Suddividere il lavoro in passaggi più piccoli. Definire confini chiari. Convalidare gli output in modo continuo. Tenere gli esseri umani coinvolti laddove le decisioni portano rischi.

Gli agenti possono esaminare il codice e portare alla luce problemi che sono facili da perdere a livello di scala. Possono analizzare i fallimenti CI, raggruppare errori correlati e indicare una probabile causa radice. Possono suggerire correzioni e, in alcuni casi, applicarle in modo controllato.

Ciò riduce la quantità di triage manuale che gli ingegneri devono fare. Non rimuove gli ingegneri dal ciclo, ma cambia dove spendono il loro tempo. La maggior parte dei sistemi opera con punti di controllo, non con indipendenza completa.

La tua piattaforma consente alle squadre di creare i propri agenti. Quanto è importante la personalizzazione per l’adozione aziendale e quali sono alcuni dei casi d’uso più interessanti che state vedendo?

La personalizzazione è essenziale per l’adozione aziendale. Ogni team di piattaforma spende risorse significative per adattare CI alle specifiche esigenze della propria azienda, e questo ha tradizionalmente richiesto script personalizzati, configurazioni, integrazioni di strumenti, processori di log e il resto del nastro adesivo che tiene insieme l’infrastruttura di sviluppo moderna.

Gitar riduce questo lavoro. I team di piattaforma possono scrivere controlli personalizzati utilizzando prompt in linguaggio naturale, che consente loro di convalidare cose che sono difficili o impossibili con l’analisi del programma tradizionale, ad esempio, segnalare stringhe che affrontano l’utente che sono ambigue per la traduzione, o convalidare gli aggiornamenti dei file AGENTS.md. Possono anche automatizzare flussi di lavoro personalizzati in cima alle richieste di pull: collegare le PR ai problemi di Jira, aprire biglietti di follow-up per commenti di revisione non risolti, ritentare automaticamente test instabili o allegare elenchi di cose da fare personalizzati alle riassuntive delle PR.

I casi d’uso più interessanti tendono a essere quelli che non avevamo previsto. Le squadre conoscono meglio i loro codici e i loro punti deboli di quanto faccia qualsiasi fornitore, quindi quando diamo loro una primitiva che trasforma “vorremmo che CI potesse solo controllare X” in un prompt di 10 righe, immediatamente iniziano ad automatizzare cose che non avremmo mai costruito per impostazione predefinita. È esattamente ciò che vogliamo.

Le squadre di ingegneria moderne si affidano a un insieme complesso di strumenti come GitHub, GitLab e Jira. Quanto è importante per Gitar integrarsi nei flussi di lavoro esistenti invece di cercare di sostituirli?

L’adozione dipende dall’incontrare gli sviluppatori laddove già si trovano. Gli ingegneri non vogliono un’altra superficie da imparare, un’altra dashboard da controllare o più commutazione di contesto tra strumenti. Vogliono che i loro flussi di lavoro esistenti diventino più veloci e più silenziosi. Quindi integrarsi profondamente con GitHub, GitLab, Jira e il resto dello stack non è un optional per noi; è l’intera strategia.

Ma la nostra ambizione va oltre l’integrazione. Non stiamo cercando di sostituire questi strumenti e non stiamo solo cercando di collegarci a essi. Stiamo automatizzando i flussi di lavoro che si svolgono attraverso di essi. La revisione della PR, il collegamento dei biglietti, i compiti di follow-up, le ritentate dei test instabili, tutto dovrebbe avvenire in modo autonomo, in background. E stiamo spingendo oltre: un agente modifica direttamente la PR per affrontare il feedback della revisione del codice e risolvere i fallimenti CI, e alla fine gestisce l’approvazione e l’unione per le modifiche che soddisfano le politiche del team. Il ruolo dello sviluppatore si sposta da guidare ogni passaggio a impostare l’intento, esaminare i risultati e gestire le eccezioni.

Lo stato finale non è uno strumento nuovo in cui gli sviluppatori si connettono. È lo strumento esistente che fa di più da solo, in modo che gli sviluppatori possano rimanere concentrati sul lavoro che richiede effettivamente il loro giudizio.

Hai suggerito che le revisioni del codice umane potrebbero eventualmente diventare l’eccezione piuttosto che la regola. Cosa deve accadere perché le organizzazioni si sentano a proprio agio con questo cambiamento?

La fiducia si costruisce in fasi, non tutto in una volta. Le organizzazioni devono vedere, con il loro stesso codice, che l’AI può trovare i bug e le vulnerabilità che contano veramente ed applicare le loro regole personalizzate con precisione e copertura elevata. Da lì, il percorso verso l’unione autonoma è una progressione naturale attraverso quattro livelli di fiducia crescente.

Il primo livello è la rilevazione. Le squadre costruiscono la fiducia che gli agenti trovino problemi reali con un basso tasso di falsi positivi. Una volta che questa fiducia è stabilita, lasciano che l’AI blocchi automaticamente le PR quando trova problemi critici.

Il secondo livello è la correzione. L’AI non segnala solo i problemi, ma li risolve, sbloccando la PR e rendendo CI verde senza intervento umano. La fiducia qui significa che l’agente può risolvere problemi e fallimenti CI con precisione, senza rompere nulla.

Il terzo livello è l’approvazione. Una volta che le squadre vedono gli agenti approvare PR in modo affidabile, lasciano che l’AI approvi PR secondo regole che definiscono. Dare alle organizzazioni un controllo esplicito sulle condizioni per l’approvazione automatica è ciò che rende questo passo sicuro anziché avventato.

Il quarto livello è l’unione. L’AI atterra il cambiamento, di nuovo secondo condizioni con cui il team è a proprio agio. Questo passo ha la sua own barra: l’agente deve risolvere i conflitti di unione con precisione, senza introdurre regressioni o rompere il main. Ciò conta più di quanto la gente realizzi, perché la frequenza dei conflitti aumenta con il throughput dei commit, e il throughput sta esplodendo mentre l’AI genera più codice. I monorepo grandi già sentono questo; tutti gli altri lo sentiranno presto.

Il passaggio all’AI come revisore predefinito non è un singolo salto di fede. È una scala, e le organizzazioni la scalano un gradino alla volta mentre le prove si accumulano.

Man mano che l’AI assume più del processo di codifica, come vedi evolversi il ruolo degli ingegneri senior nei prossimi anni?

Gli ingegneri senior stanno già spostandosi in ruoli di coordinamento, assemblando log, diagnosticando problemi e decidendo cosa è sicuro da unire. Questo non è un ruolo che qualcuno ha pianificato. È una reazione al sistema che si rompe sotto carico.

Mentre gli agenti assumono più del lavoro di convalida ripetitivo, gli ingegneri rimangono nel ciclo ma si spostano più in alto nella pila. Spendono meno tempo nella triage manuale e più tempo prendendo decisioni su cosa dovrebbe essere spedito e perché.

Gitar ha recentemente raccolto 9 milioni di dollari per scalare la piattaforma. Quali sono le tue priorità principali per questo capitale e cosa significa il successo per te nei prossimi 12-18 mesi?

Il capitale va verso due priorità. La prima è il go-to-market: stiamo scalando il nostro movimento aziendale e investendo nella consapevolezza degli sviluppatori in modo che le squadre che trarrebbero beneficio da Gitar sappiano effettivamente che esistiamo. La seconda è il prodotto: stiamo continuando a costruire verso la nostra visione di convalida del codice e qualità completamente autonoma, il che significa capacità di agente più profonde, una copertura del flusso di lavoro più ampia e un’integrazione più stretta con gli strumenti che gli sviluppatori già utilizzano.

Il successo nei prossimi 12-18 mesi significa una base significativa di clienti aziendali che eseguono Gitar su tutti i loro codici, una comunità di sviluppatori che ci riconosce come il default per la convalida del codice guidata da AI e prove chiare che i nostri agenti stanno facendo più del lavoro di revisione, correzione e unione in modo autonomo nel tempo. Se siamo sulla strada giusta, la conversazione tra un anno non sarà se l’AI possa convalidare il codice, ma quanto della pipeline di convalida una squadra ha affidato agli agenti.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Gitar.