Come si presenta l’eccellenza ingegneristica nell’era dell’IA?

Leggi la trascrizione:

Stiamo testando la trascrizione dei nostri podcast utilizzando un software. Scusate eventuali errori di battitura, il bot non è sempre preciso al 100%.

Hannah Clark: Sta diventando quasi uno scherzo: l’era dell’IA ha segnato la fine di ogni lavoro nella tecnologia. In effetti, così tanti lavori sono scomparsi quest’anno che mi stupisco di non essere stata invitata a più funerali. Il product management è morto, la user research è morta e, cosa più grave di tutte, lo sviluppo software è morto. Probabilmente sto parlando a chi la pensa come me, ma chi davvero crede che lo sviluppo software sia morto solo perché il vostro amichevole LLM di quartiere può scrivere codice, sicuramente non è un vero ingegnere.

Il mio ospite oggi, il fondatore di Cortex.io Anish Dhar, direbbe persino che l’ingegneria non è affatto morta. Sta semplicemente crescendo e maturando. Ex ingegnere in Uber, Anish ha fondato Cortex per rendere più facile agli ingegneri comprendere basi di codice complesse. Da ingegnere lui stesso e avendo come utenti principali altri ingegneri, quello che sta osservando è davvero un’evoluzione nell’eccellenza ingegneristica e una crescente distanza tra vecchi e nuovi modi di misurarla. Abbiamo condiviso idee all’avanguardia su come misurare e valutare l’eccellenza ingegneristica e una presa di posizione su come la tendenza del vibe coding si inserisca nel discorso. Entriamo nel vivo.

A proposito, teniamo conversazioni come questa ogni settimana, quindi se ti sembra interessante iscriviti! Ora, cominciamo davvero.

Bentornati al podcast The CPO Club. Oggi sono qui con Anish Dhar, fondatore di Cortex.io.

Anish, grazie per aver trovato il tempo per parlare con me oggi.

Anish Dhar: Grazie mille per avermi invitato.

Hannah Clark: Certo, ci puoi raccontare qualcosa del tuo background e di come sei arrivato al tuo ruolo attuale?

Anish Dhar: Sì, assolutamente. Sono il co-fondatore e CEO di Cortex.io. Abbiamo avviato l’azienda circa sei anni fa, ma prima lavoravo come ingegnere in Uber. La mia carriera è iniziata davvero lì e molti dei problemi che affrontavo come ingegnere a Uber sono stati la motivazione per fondare Cortex.

Due amici molto stretti. Uber ha questa enorme architettura interna dei servizi. Come ingegnere lì, era molto difficile comprendere le varie parti della base di codice, soprattutto quando sono entrato in azienda. C’erano così tanti servizi diversi in via di sviluppo e questo portava una complessità intensa. Parlavo con un caro amico che era ingegnere in una piccola startup chiamata Lend.

Avevano solo un centinaio di ingegneri mentre Uber ne aveva più di mille. Ma affrontavamo sfide simili nell’organizzare e comprendere l’architettura dei servizi. Questo per me è stato un campanello d’allarme: se un colosso come Uber e una piccola realtà che iniziava a lavorare con i microservizi avevano gli stessi problemi, si capisce quanto sia diffuso il problema nel settore.

Così abbiamo fondato l’azienda. Abbiamo fatto il batch Winter 20 di Y Combinator. Saltiamo ad oggi: abbiamo chiuso la serie C e ora collaboro con diverse centinaia di imprese che usano Cortex per gestire la loro complessità.

Hannah Clark: Fantastico. È un percorso davvero sorprendente ed è sempre bello sentire quando un’azienda nasce dalle ceneri di un problema che conosci bene.

E proprio di questo parleremo: eccellenza ingegneristica e che aspetto ha oggi nel contesto tecnologico attuale. Ovviamente è un tema che hai vissuto in prima persona nell’arco della tua carriera. Quindi, per iniziare: come definisci l’eccellenza ingegneristica nel 2025 e perché è diventata una priorità così critica per CTO e VP di ingegneria?

Anish Dhar: Bella domanda. Quello che abbiamo visto in Cortex è che per lungo tempo la conversazione si è incentrata sull’esperienza degli sviluppatori. Questa è sicuramente una parte fondamentale di qualsiasi organizzazione tecnica, giusto? Sono cose semplici, come garantire che al momento dell’ingresso in azienda sia facile avere i sistemi interni configurati, collegarsi a GitHub e agli altri strumenti, oppure, quando si effettua un deploy di un servizio, che l’infrastruttura sia pronta e ci siano pochi problemi o passaggi da affrontare.

Ma soprattutto negli ultimi anni, il discorso si è spostato sempre più dalla sola esperienza degli sviluppatori a quello che chiamiamo eccellenza ingegneristica. E la differenza fondamentale è che l’eccellenza ingegneristica riguarda il focus dei vari team all’interno dell’organizzazione.

Puoi pensare, ad esempio, a SRE, sicurezza, produttività degli sviluppatori, persino esperienza degli sviluppatori, ma qui tutto è allineato ai risultati di business. E questa è la chiave: l’eccellenza ingegneristica si interroga su come il lavoro degli ingegneri impatti concretamente sul business e su come aiuti a raggiungere gli obiettivi prefissati, dalla direzione fino agli SRE.

Un esempio: se un’azienda vuole migliorare l’esperienza del cliente come leva per aumentare i ricavi, il team SRE può adottare una checklist di prontezza alla produzione. Solo una volta che i servizi soddisfano certi standard aziendali, vengono messi in produzione. Così, un’iniziativa nata dal team SRE si ricollega a un risultato di business concreto e prioritario.

Pensare le iniziative in questo modo riafferma il valore e l’allineamento tra le iniziative tecniche e quanto davvero interessa all’azienda. E credo che qui risieda il cuore dell’eccellenza ingegneristica.

Hannah Clark: Interessante. Come hai spesso raccontato, è un vero e proprio viaggio senza fine che coinvolge numerose discipline che lavorano in sinergia.

Parlami del framework che avete sviluppato: quali sono i pilastri chiave? Come lo applicate in azienda?

Anish Dhar: Proprio così, è davvero un viaggio senza fine. Tanti clienti con cui lavoriamo, dalle grandi imprese ricche di infrastruttura legacy alle startup più piccole, magari nate già con l’IA, condividono la necessità di adottare un approccio ragionato su come il lavoro impatta sui risultati aziendali. Ecco perché uno dei nostri obiettivi come framework è aiutare a definire cosa sia l’eccellenza ingegneristica per ciascuna realtà.

Noi partiamo dall’eccellenza aziendale: ci sono obiettivi di innovazione, riduzione del time-to-market, abbattimento dei costi, incremento dell’efficienza e miglioramento della qualità e dell’esperienza del cliente.

Al di sotto di questi obiettivi ci sono i pilastri dell’eccellenza ingegneristica: i team e le figure che concretamente guidano queste iniziative. Qui troviamo aspetti come velocità, efficienza, sicurezza, affidabilità. In ciascuna di queste aree possono esserci iniziative come migrazioni di sicurezza, checklist per la prontezza in produzione, processi di gestione degli incidenti, oppure il monitoraggio di metriche come DORA per capire la produttività del team.

La base, però, sono quelli che chiamiamo le quattro C: visibilità completa, miglioramento continuo, esperienza sviluppatore coerente e proprietà chiara del codice e dei servizi. Senza proprietà e comprensione dei servizi, è difficile portare avanti le iniziative. Strumenti interni come portali o IDP facilitano questa base, permettendo di comprendere cosa viene costruito e come promuovere l’eccellenza.

Hannah Clark: Interessante quello che hai detto sulle metriche di performance: so che spesso c’è tensione quando si tratta di misurare la produttività degli sviluppatori, come ad esempio con la conta delle linee di codice.

Queste metriche possono essere fonte di discussione fra ingegneri: come dovrebbero i leader tecnici misurare la produttività in modo olistico tenendo conto delle C e di questi principi?

Anish Dhar: Senza dubbio. Molto spesso si parla di produttività degli sviluppatori collegata a linee di codice o metriche DORA — ci sono tanti framework che cercano di semplificare la misurazione della produttività, e c’è sicuramente una parte di verità in queste metriche.

È vero: il numero puro di linee di codice non è una buona indicazione di produttività. Ma se produci zero linee di codice per mesi, qualcosa non va nemmeno nel risultato! Quindi, di solito è interessante avere questi dati, ma oggi il dibattito non è solo su possedere i dati, ma su come aiutare davvero gli ingegneri a ragionarci e a migliorare.

Ottenere i dati è facile—si può interrogare l’API di GitHub e vedere come sta andando il team. Ma mostrare una serie di metriche a un ingegnere e dire serve migliorare questa metrica, non significa molto per chi crea software e si concentra sull’impatto del proprio lavoro.

Il vero cambiamento, che vediamo soprattutto nei CTO che seguiamo, sta infatti nel passaggio da “abbiamo queste metriche” a “come traduciamo queste metriche in qualcosa di significativo per chi sviluppa?”

Ed è qui che interviene l’eccellenza ingegneristica: gli ingegneri, in particolare quelli che lavorano nelle aziende più innovative, vogliono vedere il frutto del proprio lavoro. La produttività degli sviluppatori non si limita ormai all’esposizione dei dati, ma riguarda la connessione alle esigenze reali dell’azienda e la traduzione in compiti concreti e motivanti per chi sviluppa.

Questa è la grande svolta degli ultimi tempi.

Hannah Clark: Hai notato che si sta abbandonando qualche metodo di valutazione ormai superato o KPI obsoleti? Quali sarebbero i nuovi modelli di valutazione? Hai qualche esempio concreto?

Anish Dhar: Certo. Distinguerei tra metriche di input e di output. Quelle di output sono i classici framework adottati oggi—DORA, per esempio, che offre un quadro olistico sulla performance del team di ingegneri.

Oggi le organizzazioni ingegneristiche vogliono vedere queste metriche, ma la vera sfida è capire come influenzarle e vederle migliorare. Con Cortex, per esempio, abbiamo osservato il valore fondamentale delle metriche di input che influenzano quelle di output.

Prendiamo la frequenza di deploy: è una metrica ottima perché la rapidità con cui si pubblica software rivela quanto velocemente un’azienda può portare una novità sul mercato e superare i concorrenti.

Se decidi che la metrica principale è la frequenza di rilascio, puoi mostrarla in dashboard e dire: ragazzi, ora deployamo due volte a settimana, vogliamo arrivare a quattro. Ma l’ingegnere si chiede: cosa significa questo per il mio lavoro? Se rilasciamo di più, aumentano i bug? Calerà l’affidabilità?

Ed ecco perché le metriche di input sono fondamentali: sono loro che influenzano quelle di output. Quindi, per aumentare i rilasci, si può adottare una checklist di prontezza alla produzione con 8-9 metriche di input: se l’on call è impostato, il processo di build passa, ci sono test automatizzati, ecc.

Questo fornisce agli ingegneri delle linee guida concrete sulle loro responsabilità. Nei nostri casi, abbiamo visto clienti passare da due a quattro deploy a settimana, riducendo al contempo incident e problemi critici.

In sintesi: le imprese devono tradurre le metriche aggregate in azioni concrete per gli sviluppatori, pensando alla produttività come a un racconto completo tra metriche di input e output.

Hannah Clark: Sì, penso che “olistico” sia una parola chiave in questa visione. Cambiando leggermente argomento, ma restando sul tema del rilascio rapido, non si può parlare di ingegneria nel 2025 senza citare il vibe coding.

Parliamo di questi strumenti AI che stanno trasformando i flussi di lavoro di sviluppo. Ti ho sentito dire che non puoi fare vibe coding e arrivare a un milione di utenti al giorno. Una provocazione? Allora, qual è secondo te la realtà rispetto all’hype attorno all’uso dell’IA in ambienti di produzione su larga scala?

Anish Dhar: Sicuramente un tema caldissimo. Tutte le organizzazioni di ingegneria stanno ragionando sull’IA o hanno adottato assistenti di coding basati su IA (ce ne sono diversi, come Cursor). Tutto il nostro team di sviluppo in Cortex ne usa almeno uno.

Ma quello che abbiamo visto, sia nel nostro team sia dai clienti, è che gli assistenti di coding sono ottimi per validare rapidamente un’idea iniziale, fare prototipi o visualizzare un’interfaccia velocemente.

Nel processo di sviluppo, questi strumenti sono perfetti per creare qualcosa di veloce, testare un concetto o per imprenditori che vogliono validare un’idea. È anche per questo che il mercato cresce così rapidamente.

Ma la realtà è che oggi non ti puoi fidare di codice generato solamente da vibe coding per sistemi critici, usati da milioni di utenti. Ad oggi, il vibe coding equivale a un ingegnere junior che ha appena imparato a programmare. Qui entra in gioco l’esperienza dei senior: serve chi sa costruire e gestire sistemi in produzione su larga scala. Non ci siamo ancora arrivati, anche se il progresso dell’IA sarà sorprendente nei prossimi anni.

Al momento, nessuna impresa affida i propri sistemi critici al vibe coding. Il livello di competenza necessario per scalare, diagnosticare e garantire la robustezza delle infrastrutture è ancora troppo alto per l’IA. Tuttavia, la produttività generale è aumentata grazie agli assistenti, solo in aree diverse da quelle di cui si parla di solito.

Insomma: il vibe coding non è ancora pronto per la produzione enterprise.

Hannah Clark: È un sentimento che molti professionisti condividono: spesso chi sta fuori dalla professione si entusiasma per l’automazione tramite IA, ma questo non significa necessariamente che sia pronta a sostituire davvero chi ci lavora.

Per i leader dell’ingegneria che devono bilanciare investimenti tra strumenti IA e assunzioni: cosa dovrebbero considerare davvero? Come valutare l’impatto effettivo dell’IA sulla produttività e inserirlo a bilancio?

Anish Dhar: Una domanda complessa. Penso che per la salute e qualità del team sia un errore impedire agli ingegneri di accedere agli strumenti IA come Cursor o GitHub Copilot. Nei prossimi 10 anni, gran parte del codice iniziale sarà assistito dall’IA, proprio perché per validare e iterare velocemente è dieci volte più rapido usare questi strumenti.

In generale, i team che apprendono ad adottare queste soluzioni saranno avvantaggiati rispetto a chi le snobba. Anzi, è utile che anche chi non è tecnico (PM, TPM, data scientist) abbia accesso a questi strumenti, per trasformare idee in prototipi e collaborare meglio con gli sviluppatori. Da qui, ha senso prevedere budget per strumenti del genere.

La grande domanda è: quanto aumenta davvero la produttività? Tutte le aziende ci stanno lavorando. Spesso i clienti comprano Cortex insieme a Copilot e la domanda che ci rivolgono subito è: “stiamo davvero moltiplicando la produttività?”

Serve un approccio a 360 gradi su input e output: se Copilot mi fa rilasciare più velocemente ma con codice scadente, rischiamo di peggiorare la qualità. Bisogna misurare l’impatto con vari indicatori e chiedersi se davvero l’introduzione dell’IA contribuisce agli obiettivi di crescita.

A volte l’impatto non è immediato e ci vuole tempo per capire dove questi strumenti possono far la differenza. Un errore frequente è farsi travolgere dalla moda, licenziare subito 5.000 strumenti e dopo sei mesi domandarsi senza criteri chiari: “ha davvero avuto un impatto?”

Quindi: occorre capire le proprie motivazioni e monitorare se stanno producendo i risultati attesi.

Hannah Clark: Concordo. In questo momento c’è tanta pressione per padroneggiare questi strumenti, ma la differenza fra quantità di produzione e qualità dei risultati è ancora enorme.

E serve molta attenzione non solo nei team di sviluppo: ha senso usare questi strumenti solo se, nel contesto giusto, permettono di rendere più efficace il lavoro umano. Non bisogna assumere alla cieca che l’IA ridurrà l’organico l’anno prossimo.

Siamo in una fase in cui tutti stanno cercando di capire come integrare questi strumenti nei flussi di lavoro e non è facile. A proposito di equilibrio fra qualità del codice, sicurezza, affidabilità ed essere comunque avanguardistici, come vi siete regolati voi?

Anish Dhar: È una domanda fondamentale. Sintetizzando: l’idea che l’IA sostituirà gli ingegneri mi sembra alquanto esagerata. Magari nelle fasi iniziali si può assumere qualche ingegnere in meno, oggi si può testare più rapidamente di prima e l’iterazione veloce è preziosa. Ma sulle applicazioni critiche, pensare di ridurre davvero il numero di sviluppatori grazie all’IA è solo uno slogan mediatico. Posso garantirlo.

Hannah Clark: Senza fare nomi…

Anish Dhar: Esatto, tutte continueranno ad assumere sviluppatori. Tornando alla domanda su affidabilità e sicurezza con l’IA: questa è la vera incognita che preoccupa molti team, soprattutto SRE, sicurezza, operational excellence. L’introduzione di questi strumenti aumenta la superficie esposta perché si scrive più codice e spesso si conosce di meno ogni sua parte.

Quando arriverà un problema di affidabilità (e capiterà sempre, in qualunque sistema), sarà più difficile per gli ingegneri orientarsi tra parti di codice generato in modo automatico. Ed è qui che torna fondamentale la base dell’eccellenza ingegneristica: visibilità completa e proprietà chiara sono capisaldi.

Più sistemi realizzi con l’IA, meno copertura effettiva hai su chi possiede o comprende ogni componente. Questa è la cosa che preoccupa davvero i team di sicurezza e affidabilità. Lo vediamo anche internamente: quando pubblichiamo codice generato con l’IA, gli ingegneri lo esplicitano, così possiamo fare review approfondite.

C’è un trend di strumenti che fanno test assistiti da IA, pseudo-ingegneri che revisionano i test automatici. Tuttavia, anche questi strumenti hanno limiti: l’IA sta facendo più bene che male nei team oggi, ma non vorrei mai che l’80% del mio sistema fosse generato da IA. Ne risentirebbero tempi di risoluzione incident e sicurezza, proprio per la ridotta visibilità e comprensione.

Hannah Clark: Concordo: è un aspetto pratico che si affronta troppo poco. L’aumentata velocità rischia di aumentare anche la richiesta di controllo e revisione.

La scorsa settimana ne parlavo con l’SVP di product management di Mastercard Gateway, raccontava come le IA stanno accelerando processi come la compilazione dei documenti per l’ingresso in nuovi mercati, permettendo di rispettare le normative più rapidamente. Ma serve mantenere oversight e ownership di ciò che si sottomette. Così: puoi spedire più in fretta, ma devi anche essere responsabile con la stessa rapidità. È un grande collo di bottiglia logistico sia per i team di sviluppo sia per altri reparti che usano questi strumenti.

Insomma: possiamo sfornare rapidamente, ma siamo poi in grado di assumerci la responsabilità di ciò che facciamo con la stessa velocità? Interessantissimo. Abbiamo sentito leader in tanti reparti e discipline: le preoccupazioni sono spesso parallele anche in mondi diversi.

Grazie mille per i tuoi spunti, Anish. La nostra puntata termina qui. Dove possono seguirti online?

Anish Dhar: Potete seguirmi su LinkedIn o Twitter: basta cercare il mio nome e mi trovate. Anche Cortex è su LinkedIn. Postiamo regolarmente, organizziamo access summit in tutto il mondo: se ne facciamo uno nella vostra città passate a trovarci. È bello vedere nascere queste community di confronto sull’eccellenza ingegneristica.

Abbiamo anche una conferenza, IDPCON, dedicata all’eccellenza dell’ingegneria: partecipano leader ed ingegneri da realtà molto diverse per confrontarsi. L’evento sarà a New York a ottobre—magari ci vediamo lì!

Hannah Clark: Sembra fantastico. Grazie per avercelo detto, lo segnaleremo nella descrizione. E grazie ancora per averci dedicato il tuo tempo.

Anish Dhar: È stato un piacere, grazie a voi.

Hannah Clark: Grazie per l’ascolto! Per altre idee, guide pratiche e recensioni di strumenti, iscriviti alla nostra newsletter su theproductmanager.com/subscribe. Puoi ascoltare altri episodi come questo iscrivendoti a The CPO Club ovunque trovi i tuoi podcast.