Il responsabile globale dell’architettura dell’IA afferma che l’IA è un cambiamento del modello operativo, non il semplice lancio di uno strumento

Manish Jain è vicepresidente e responsabile globale dell'architettura dell'IA presso Firstsource, dove dirige un team di 50 persone. Attualmente si concentra sulla costruzione di sistemi agentici in grado di gestire attività in più fasi.

Abbiamo incontrato Manish per scoprire come l'IA stia cambiando il suo modello operativo. Ecco cosa ci ha raccontato.

Dal potenziale a una capacità pronta per la produzione

Sono Manish Jain, un responsabile dell'IA e della tecnologia che si occupa di aiutare le organizzazioni a trasformare il potenziale dell'IA in capacità affidabili e pronte per la produzione. Baso il mio lavoro sulla realtà pratica della trasformazione. Negli ultimi anni ho guidato numerose iniziative di IA e ML, ho collaborato a stretto contatto con i team aziendali e ho lavorato su attività di ingegneria e implementazione in cui il successo dipende da molto più della semplice selezione del modello giusto. Architettura, qualità dei dati, sicurezza, integrazione, adozione da parte degli utenti e chiaro valore aziendale devono convergere.

Attualmente guido iniziative di IA all'interno di un'organizzazione interfunzionale di circa 50 persone, tra cui ingegneri del software e delle piattaforme, professionisti dell'IA e dei dati, responsabili di prodotto, partner per la sicurezza ed esperti dei vari ambiti aziendali. Il lavoro comprende l'implementazione dell'IA aziendale e la fornitura di soluzioni direttamente sul campo. I team lavorano a stretto contatto con i clienti e gli stakeholder interni per portare i casi d'uso ad alto valore dalla fase di scoperta fino a un'implementazione in produzione sicura e scalabile.

Il nostro approccio è intenzionalmente indipendente dal cloud e dal modello. Implementiamo principalmente su Azure e AWS e utilizziamo Google Cloud in modo selettivo, in base all'ambiente del cliente, al patrimonio di dati e alle esigenze operative. Anziché progettare una soluzione intorno a un singolo provider cloud o a un unico modello di base, costruiamo architetture modulari che ci consentono di scegliere ed evolvere i componenti sottostanti al variare dei requisiti. Questo include il livello del modello, i servizi di recupero e dati, il framework di orchestrazione, gli strumenti di valutazione, l'osservabilità e i controlli di sicurezza.

La vera complessità non consiste semplicemente nel selezionare un LLM. Consiste nell'integrare l'IA nei flussi di lavoro aziendali tra fonti di dati frammentate, applicazioni legacy, autorizzazioni utente variabili e requisiti rigorosi in materia di sicurezza, affidabilità, costi e conformità. In genere iniziamo con un caso d'uso mirato e una valutazione rigorosa, quindi portiamo in produzione ciò che funziona attraverso limitazioni di sicurezza, supervisione umana ove appropriato, monitoraggio e iterazione continua. L'obiettivo è creare capacità di IA che rimangano adattabili con l'evoluzione della tecnologia e sufficientemente affidabili da permettere ai team di utilizzarle ogni giorno.

Sono particolarmente interessato al passaggio dai copiloti individuali ai sistemi agentici in grado di gestire attività in più fasi entro limiti definiti. Per i responsabili della tecnologia, l'opportunità è significativa, ma per coglierla sono necessarie un'ingegneria disciplinata, una governance ponderata e una forte attenzione ai risultati.

Perché una distribuzione dell'IA basata innanzitutto sulla valutazione migliora i risultati

Nell'ultimo anno ho spostato la distribuzione dell'IA da una mentalità orientata innanzitutto ai prototipi a una disciplina ingegneristica basata innanzitutto sulla valutazione. Un anno fa, i team costruivano spesso rapidamente prove di concetto impressionanti collegando i flussi di lavoro a singoli modelli. Tuttavia, spesso affrontavano troppo tardi i fattori che determinano l'affidabilità dell'IA in produzione — qualità, fondamento sulle fonti, controllo degli accessi, gestione degli errori, costi e responsabilità degli utenti.

Abbiamo introdotto un modello di distribuzione condiviso in cui ogni caso d'uso dell'IA inizia con una definizione chiara del successo, dati di valutazione rappresentativi, una revisione della sicurezza e dell'accesso ai dati, tracciabilità e monitoraggio continuo. Abbiamo inoltre costruito l'architettura sottostante in modo che fosse indipendente dal cloud e dal modello. Ciò consente ai team di valutare la combinazione più adatta di modelli, approcci di recupero e schemi di orchestrazione per ogni flusso di lavoro, senza vincolare il prodotto a un unico provider o a una sola generazione di modelli.

In pratica, questo ha portato a una riduzione delle rilavorazioni e a una maggiore fiducia nelle implementazioni in produzione. I team possono identificare regressioni nella qualità o nei costi prima che influiscano sugli utenti, prendere decisioni esplicite su dove collocare la revisione umana e migliorare i sistemi sulla base di dati concreti anziché di feedback aneddotici.

Guardando al futuro, ritengo che ciò costituisca la base per un'IA agentica responsabile. Man mano che i sistemi vanno oltre la risposta alle domande e iniziano a compiere azioni in più fasi attraverso i flussi di lavoro aziendali, non possiamo aggiungere valutazione, osservabilità, autorizzazioni e governance in un secondo momento. Devono far parte del tessuto ingegneristico fin dal primo giorno.

Come le persone diventano più importanti con l'ingegneria agentica

Utilizziamo l'IA durante tutto il ciclo di vita del prodotto. Nella fase di scoperta, trasforma gli input degli stakeholder, il feedback dei clienti e la documentazione esistente in requisiti iniziali, storie utente, criteri di accettazione e domande tecniche. Nell'ingegneria, supporta l'esplorazione della base di codice, la documentazione, l'implementazione, il refactoring, la preparazione delle richieste di integrazione e la generazione dei test. Nelle operazioni, riassume i log, mette in correlazione gli avvisi con i rilasci recenti, recupera il contesto degli incidenti precedenti e restringe lo spazio di ricerca durante il triage. I team dedicano meno tempo alla raccolta del contesto tra gli strumenti e più tempo alla convalida delle decisioni, alla risoluzione di problemi complessi e all'avanzamento della distribuzione.

Manteniamo in capo agli esseri umani la responsabilità dell'architettura, l'approvazione della sicurezza, le decisioni sull'accesso ai dati, l'approvazione dei rilasci e i compromessi relativi alle priorità. Queste decisioni richiedono contesto aziendale, responsabilità e una comprensione delle conseguenze che va oltre ciò che possono contenere un ticket, un prompt o un repository di codice. L'IA può analizzare le alternative, identificare le dipendenze, segnalare problemi di sicurezza e raccogliere le evidenze, ma la decisione viene presa da un ingegnere o da un responsabile consapevole delle proprie responsabilità.

Facciamo deliberatamente questa distinzione mentre ci avviciniamo a un'ingegneria sempre più agentica. Mi aspetto che l'IA si occupi di un numero maggiore di attività esecutive circoscritte, come implementare modifiche ben definite, generare ed eseguire test, convalidare i criteri di distribuzione o proporre interventi di risoluzione degli incidenti. In questo processo, il ruolo umano diventa più importante, non meno. Gli ingegneri definiscono l'intento, i permessi, le soglie di qualità e i limiti per il rollback, quindi verificano se il sistema ha raggiunto il risultato previsto.

Come l'IA alimenta efficacemente i flussi di lavoro ingegneristici dall'inizio alla fine

Ecco il nostro flusso di lavoro dall'inizio alla fine, che porta una richiesta di prodotto ben definita attraverso la progettazione, l'implementazione, la convalida e il rilascio in produzione. Il processo inizia quando un responsabile di prodotto e un responsabile dell'ingegneria definiscono il risultato per il cliente, i vincoli e i criteri di accettazione. L'IA sintetizza quindi il contesto aziendale pertinente, la documentazione esistente, i modelli architetturali e le dipendenze in una bozza di progettazione tecnica, di piano di implementazione e di strategia di test. Un ingegnere esamina il piano, prende le decisioni architetturali e suddivide il lavoro in piccole modifiche verificabili in modo indipendente.

Durante l'implementazione, gli ingegneri utilizzano l'IA all'interno della base di codice per comprendere i servizi pertinenti, generare il codice iniziale e le modifiche alla configurazione, aggiornare la documentazione e creare test unitari e di integrazione. Ogni modifica è comunque sottoposta al controllo del codice sorgente, ai controlli CI automatizzati, alla revisione tra pari, alla scansione di sicurezza e al processo di rilascio stabilito. Se un test fallisce, l'IA interpreta l'errore, identifica la probabile dipendenza o regressione e propone una correzione, ma l'ingegnere verifica la soluzione prima che proceda.

Dopo la distribuzione, il flusso di lavoro continua. L'IA riassume i log dell'applicazione, mette in correlazione le anomalie con i rilasci recenti e presenta all'ingegnere reperibile gli incidenti precedenti o i manuali operativi pertinenti. Misuriamo l'intero ciclo attraverso il tempo di consegna, la copertura dei test, il tasso di insuccesso delle modifiche, la frequenza dei rollback e il tempo necessario alla risoluzione.

Non si tratta di sviluppo software autonomo. È un sistema di distribuzione guidato dall'uomo e potenziato dall'IA, in cui l'IA riduce i tempi necessari per raccogliere il contesto e svolgere le attività, mentre gli ingegneri mantengono la responsabilità della progettazione, della qualità, della sicurezza e del risultato in produzione.

Manish ci racconta

L’IA ha ridotto significativamente il tempo che gli ingegneri dedicano alla raccolta del contesto e alla produzione della prima versione delle attività di routine. Aiuta i team a passare più rapidamente da un requisito iniziale a un approccio tecnico strutturato, all’implementazione, alla copertura dei test e alla documentazione.

Come l'IA crea un flusso migliore tra le funzioni

Per quanto riguarda i risultati, l'IA ha ridotto significativamente il tempo che gli ingegneri dedicano alla raccolta del contesto e alla produzione della prima versione delle attività di routine. Aiuta i team a passare più rapidamente da un requisito iniziale a un approccio tecnico strutturato, all'implementazione, alla copertura dei test e alla documentazione. Ha accelerato lo sviluppo di nuove funzionalità e capacità del prodotto, soprattutto quando gli ingegneri devono analizzare una base di codice sconosciuta, tracciare le dipendenze o lavorare su più servizi.

L'IA fornisce inoltre indicazioni sulle decisioni architetturali. Può sintetizzare rapidamente la documentazione del sistema esistente, identificare le dipendenze, confrontare le opzioni di implementazione, mettere in evidenza i probabili compromessi e aiutare i team a creare documenti delle decisioni architetturali. Le decisioni architetturali finali spettano agli esseri umani, ma i team affrontano queste discussioni disponendo di un contesto migliore. Possono dedicare più tempo a discutere le decisioni che contano davvero, come scalabilità, resilienza, sicurezza, costi e manutenibilità a lungo termine.

Il miglioramento non consiste semplicemente nella generazione più rapida del codice. Vediamo un flusso migliore lungo l'intero ciclo di vita perché prodotto, ingegneria, QA e operazioni partono da un contesto più completo e coerente. Gli ingegneri dedicano più tempo alla progettazione dei sistemi, ai casi limite, alla complessità dell'integrazione e all'impatto sui clienti, invece di assemblare manualmente informazioni provenienti da repository, ticket, dashboard, log e incidenti passati.

Come misurare il successo con l'AI

Abbiamo anche appreso lezioni importanti sugli svantaggi. L'AI può creare una falsa sensazione di velocità quando i team accettano risultati plausibili senza una validazione sufficiente. Può generare codice che sembra corretto, ma che non si adatta all'architettura circostante, non tiene conto di regole aziendali sottili, introduce complessità non necessaria o crea problemi di sicurezza e manutenibilità. Anche i guadagni di produttività sono disomogenei. A trarre i maggiori benefici sono gli ingegneri che conoscono il sistema, definiscono con precisione il lavoro e convalidano rigorosamente i risultati.

Per questo misuriamo il successo attraverso la qualità della distribuzione, anziché tramite metriche sull'attività dell'AI. I risultati che ci interessano sono una distribuzione più rapida delle funzionalità, tempi di ciclo più brevi, rilasci stabili, una maggiore copertura dei test, meno rilavorazioni, una risoluzione più rapida degli incidenti e un'affidabilità costante. L'opportunità a lungo termine è significativa, ma solo se l'AI migliora il giudizio e l'esecuzione ingegneristica invece di diventare un sostituto dell'uno o dell'altra.

Come i nuovi vincoli cambiano la struttura dei team

La generazione di codice non è più il vincolo alla velocità di sviluppo. I veri vincoli sono spesso requisiti poco chiari, contesto aziendale frammentato, dipendenze architetturali, revisione della sicurezza, integrazione tra sistemi e il tempo necessario per convalidare che una modifica funzioni in modo sicuro in produzione. I dati del settore indicano la stessa direzione: la programmazione rappresenta una quota relativamente ridotta della giornata di un ingegnere e l'adozione dell'AI nella programmazione non si traduce automaticamente in aumenti proporzionali della produttività.

Questo ha cambiato il mio modo di pensare alla struttura dei team. Invece di considerare semplicemente l'AI come un modo per ridurre lo sforzo di distribuzione, ci stiamo orientando verso team più piccoli e interfunzionali, con una responsabilità più forte dalla fase di scoperta fino all'apprendimento in produzione. Gli ingegneri devono dedicare meno tempo alla creazione delle prime bozze e più tempo a definire l'intento, progettare l'architettura, convalidare i risultati e migliorare il sistema dopo il rilascio.

Inoltre, il nostro focus nelle assunzioni si è spostato dalla pura produzione di codice al pensiero sistemico, al giudizio sul prodotto e alla convalida del lavoro assistito dall'AI. Apprezziamo gli ingegneri capaci di gestire l'ambiguità, compiere scelte ponderate tra architettura e sicurezza e assumersi la responsabilità dei risultati in produzione.

Manish ci racconta

Il futuro non consiste solo in un’implementazione più rapida. Consiste in un allineamento più veloce e in un ciclo più stretto tra un’idea, un risultato in produzione e l’apprendimento che orienta la decisione successiva.

Il futuro non consiste solo in un'implementazione più rapida. Consiste in un allineamento più veloce e in un ciclo più stretto tra un'idea, un risultato in produzione e l'apprendimento che orienta la decisione successiva.

Perché i test devono essere riprogettati per un futuro potenziato dall'AI

I test devono essere riprogettati.

L'AI sta rendendo molto più rapida la creazione del codice, il che significa che la garanzia della qualità deve diventare continua, automatizzata e integrata nel flusso di distribuzione, invece di essere considerata un controllo finale. I team hanno bisogno della generazione assistita dall'AI dei test, di set di dati realistici per la valutazione, di controlli di sicurezza e prestazioni, del monitoraggio in produzione e di una chiara responsabilità umana per le eccezioni.

In un ciclo di vita potenziato dall'AI, il vantaggio competitivo non sarà di chi genera il codice più velocemente, ma di chi sa convalidare le modifiche in sicurezza e apprendere dalla produzione più rapidamente.

Come evitare gli attriti iniziali legati all'AI

Avevamo sottovalutato le realtà operative dell'AI. Il consumo di token e i limiti di utilizzo possono vincolare significativamente la distribuzione, soprattutto nei flussi di lavoro di programmazione agentica che richiedono il contesto di basi di codice estese o iterazioni ripetute. Ora consideriamo la spesa per l'AI una decisione relativa alla capacità ingegneristica, con visibilità sull'utilizzo, sull'instradamento dei modelli, sulla gestione del contesto e sul valore prodotto, non soltanto sul costo della licenza. Anche l'affidabilità del servizio è importante. Un modello esterno o una piattaforma di programmazione può presentare problemi di latenza, limitazione della frequenza o disponibilità, quindi i flussi di lavoro critici necessitano di modelli alternativi, un degrado controllato e modalità che consentano agli ingegneri di continuare a lavorare senza il servizio di AI.

Avremmo potuto evitare gli attriti iniziali definendo fin dall'inizio gli strumenti approvati, confini chiari per i dati, aspettative per le revisioni, controlli dei costi e schemi di fallback.

Inoltre, non renderei obbligatorio prematuramente un singolo strumento o flusso di lavoro. La tecnologia sta cambiando troppo rapidamente. L'approccio migliore consiste nel fornire accesso sicuro, garanzie riutilizzabili, opportunità di apprendimento tra pari e una chiara responsabilizzazione. Un ingegnere è ancora responsabile di ciò che progetta, esamina, integra e gestisce in produzione.

Perché l'IA dovrebbe essere considerata un cambiamento del modello operativo

Il mio consiglio ai CTO è di considerare l'IA come un cambiamento del modello operativo, non come un'implementazione di strumenti. Iniziate con un numero ridotto di flussi di lavoro ad alto valore, per i quali possiate stabilire una baseline, misurare l'impatto e imparare rapidamente. Costruite una piattaforma IA condivisa e una disciplina di distribuzione basate su modelli approvati, accesso sicuro ai dati, valutazione, osservabilità e modelli di integrazione riutilizzabili, mantenendo l'architettura indipendente dal cloud e dal modello. In questo modo eviterete che ogni team reinventi gli stessi controlli o rimanga vincolato troppo presto a un fornitore.

Altrettanto importante è investire nelle persone. Le organizzazioni che otterranno i maggiori vantaggi non saranno quelle che si limiteranno a generare più codice. Saranno quelle che aiuteranno ingegneri, team di prodotto, partner della sicurezza e leader aziendali a imparare a definire chiaramente il lavoro, convalidare gli output dell'IA e gestire sistemi agentici entro limiti definiti. Agite con urgenza, ma rendete imprescindibili fiducia, qualità, sicurezza e risultati misurabili.

L'IA sta diventando un livello fondamentale per l'esecuzione aziendale, quindi il ruolo del CTO è creare l'architettura, la governance e la cultura che ne consentano una crescita responsabile.

Segui gli aggiornamenti

Potete seguire il lavoro di Manish Jain sul suo Substack e su LinkedIn.

Seguiranno altre interviste con esperti su The CTO Club!