Il direttore tecnico rinnova il ciclo di vita dell’ingegneria e il suo impatto sul team

Sergey Terentyev guida la tecnologia e l’ingegneria all’interno di un ambiente bancario digitale autorizzato. Nell’ultimo anno ha rinnovato l’intero ciclo di vita dell’ingegneria, integrando l’IA in ogni fase.

Abbiamo parlato con Sergey per saperne di più. Ci ha raccontato cosa ha cambiato e come questo abbia influito sul suo team.

L’IA sta cambiando più degli strumenti

Sono Sergey, attualmente CTO nel settore bancario e fintech negli Emirati Arabi Uniti. Ho iniziato come ingegnere del software e sono passato alla leadership sviluppando prodotti, ampliando i team e risolvendo problemi tecnologici complessi.

Il mio percorso verso la trasformazione basata sull’IA è stato semplice: i metodi tradizionali per costruire e gestire i team tecnologici stanno diventando troppo lenti. I team dedicano ancora troppo tempo al lavoro ripetitivo, al coordinamento, alla documentazione, all’assistenza e ai processi manuali.

Ora mi concentro sull’adozione pratica dell’IA nelle organizzazioni di ingegneria e di prodotto. Non sull’IA come fenomeno di moda, ma come strumento per muoversi più velocemente, migliorare la distribuzione, ridurre gli sprechi e aiutare i team più piccoli a ottenere risultati molto più importanti.

Considero questo momento un’occasione per ripensare il modo in cui lavorano le organizzazioni tecnologiche. L’IA non sta cambiando solo gli strumenti, ma anche i team, la leadership e il modo in cui le aziende sviluppano i prodotti.

Bilanciare innovazione e regolamentazione

L’organizzazione in cui guido la tecnologia e l’ingegneria opera in un settore altamente regolamentato, quindi il panorama tecnologico combina lo sviluppo moderno dei prodotti con requisiti di sicurezza, conformità e operativi di livello aziendale.

L’organizzazione di ingegneria si occupa di piattaforme mobili e web, servizi back-end, infrastruttura cloud, cybersicurezza, integrazioni, piattaforme dati e gestione dei fornitori. Lavoriamo sia allo sviluppo interno sia con partner esterni strategici, trasferendo gradualmente all’interno un numero maggiore di capacità fondamentali.

Dal punto di vista dell’architettura, ci stiamo orientando verso un modello più modulare e basato sulle API, con una maggiore responsabilità all’interno dei team di ingegneria del prodotto. L’ambiente è piuttosto complesso perché operiamo tra sistemi bancari, integrazioni fintech, infrastrutture di pagamento, applicazioni rivolte ai clienti e piattaforme operative interne.

La distribuzione e la messa in produzione sono altamente iterative, con una forte attenzione all’automazione, alla CI/CD, all’infrastruttura cloud, all’osservabilità e alla resilienza operativa. Una priorità fondamentale è ridurre la dipendenza dai modelli tradizionali di distribuzione e aumentare la velocità dell’ingegneria attraverso lo sviluppo assistito dall’IA e l’automazione.

Una parte importante del mio ruolo consiste nel bilanciare la rapidità dell’innovazione con le realtà operative di un ambiente finanziario regolamentato, in cui l’affidabilità, la sicurezza e la governance sono fondamentali.

Come l’IA obbligatoria cambia i flussi di lavoro dell’ingegneria

Abbiamo introdotto l’IA direttamente nel flusso di lavoro della distribuzione ingegneristica, invece di considerarla uno strumento individuale facoltativo.

Prima di allora, gli ingegneri dedicavano molto tempo ad attività ripetitive come l’implementazione del codice standard, la documentazione, l’analisi del codice, il debugging, la preparazione dei test, la revisione del codice dei fornitori e la traduzione dei requisiti aziendali in attività tecniche. Il sovraccarico operativo gravava sugli ingegneri senior, impedendo loro di concentrarsi sull’architettura e sulle decisioni relative al prodotto.

Nell’ultimo anno abbiamo integrato sistematicamente lo sviluppo assistito dall’IA nei processi ingegneristici quotidiani. Ciò ha incluso la generazione del codice, il supporto alla revisione del codice, la generazione della documentazione, l’analisi dell’impatto, l’analisi degli incidenti e la prototipazione più rapida.

Il cambiamento ha influito non solo sulla velocità, ma anche sul modo in cui lavorano i team. Ora gli ingegneri dedicano meno tempo alle attività ripetitive di scarso valore e più tempo alla progettazione dei sistemi, alla riflessione sul prodotto e al processo decisionale. Ha inoltre ridotto la dipendenza da un numero ristretto di persone senior, rendendo più facile distribuire le conoscenze tra i team.

Il cambiamento più importante è stato probabilmente di carattere culturale. I team hanno smesso di considerare l’IA uno strumento sperimentale, che è diventato parte del normale flusso di lavoro dell’ingegneria. Ora si aspettano l’automazione come impostazione predefinita, invece di presumere che ogni processo debba essere manuale.

Sergey condivide

Abbiamo introdotto l’IA direttamente nel flusso di lavoro della distribuzione ingegneristica, invece di considerarla uno strumento individuale facoltativo.

Come l’IA può intervenire in ogni parte del ciclo di vita dell’ingegneria

Esaminiamo il percorso dal requisito aziendale all'implementazione tecnica pronta per la produzione.

Di solito tutto inizia con una richiesta di prodotto o aziendale scritta in un linguaggio di alto livello. L'IA aiuta a tradurla in requisiti tecnici strutturati, identifica le dipendenze, suggerisce i contratti API ed evidenzia tempestivamente possibili casi limite o rischi di integrazione.

Da lì, gli ingegneri utilizzano gli strumenti di sviluppo assistiti dall'IA durante l'implementazione per creare la struttura dei servizi, generare schemi di codice ripetitivi, creare casi di test e accelerare la documentazione. L'obiettivo non è una programmazione completamente autonoma, ma la riduzione del lavoro manuale a basso valore, così che gli ingegneri possano concentrarsi sull'architettura e sulla logica.

Durante lo sviluppo, l'IA assiste anche nelle revisioni del codice, spiega le parti non familiari della base di codice, identifica possibili vulnerabilità e convalida gli approcci di implementazione. Per i sistemi soggetti a incidenti, gli ingegneri utilizzano l'IA per analizzare i log e riassumere i comportamenti anomali molto più rapidamente rispetto a un'indagine manuale tradizionale.

Una volta che le modifiche entrano nelle pipeline di distribuzione, l'automazione gestisce test, convalida e osservabilità. L'IA torna a essere utile dopo la distribuzione, aiutando i team a interpretare gli avvisi, correlare gli incidenti e ridurre i tempi di indagine durante i problemi operativi.

Come si può vedere, oggi l'IA è integrata nell'intero ciclo di vita dell'ingegneria, invece di essere soltanto un chatbot isolato o un assistente alla programmazione. È diventata parte del flusso di lavoro quotidiano, dalla pianificazione alle operazioni.

Perché i CTO devono migliorare la leggibilità per le macchine

Abbiamo ridotto la dipendenza dalle conoscenze centralizzate e dal coordinamento manuale. Invece di lasciare che le informazioni critiche risiedessero esclusivamente presso determinate persone o team, abbiamo introdotto flussi di lavoro in cui l'IA aiutava gli ingegneri a orientarsi nei sistemi, comprendere l'architettura, analizzare gli incidenti e accelerare autonomamente l'inserimento dei nuovi membri.

Questo mi porta a un altro importante cambiamento che abbiamo apportato: progettare sistemi pensati per la leggibilità da parte delle macchine, non solo per quella umana.

API pulite, documentazione strutturata, osservabilità, servizi modulari e interfacce ben definite migliorano notevolmente sia la produttività umana sia l'efficacia dell'IA.

Perché l'IA non può gestire il giudizio in un settore regolamentato

L'IA accelera in modo particolare la distribuzione e riduce il lavoro ingegneristico ripetitivo. Ad esempio, durante la risposta agli incidenti, l'IA aiuta gli ingegneri ad analizzare i log, identificare le possibili cause principali, riassumere i risultati e velocizzare l'indagine.

Allo stesso tempo, alcune aree rimangono esplicitamente guidate dall'intervento umano. Le decisioni architetturali finali, la governance della sicurezza, l'accettazione del rischio, la definizione delle priorità e la responsabilità per la produzione richiedono ancora che persone esperte prendano decisioni basate sul proprio giudizio.

In poche parole, l'IA eccelle nell'accelerazione e nel riconoscimento degli schemi, ma le decisioni di leadership nei sistemi complessi dipendono ancora dal contesto, dai compromessi, dalle priorità aziendali, dalla regolamentazione e dalla visione a lungo termine. Soprattutto nei servizi finanziari, non è possibile automatizzare completamente la responsabilità.

Come l'IA può avere un impatto negativo sui team di ingegneria

Il risultato positivo più significativo è stato la velocità dell'ingegneria. Attività che in precedenza richiedevano giorni ora a volte richiedono ore. Anche gli ostacoli operativi si sono ridotti, migliorando il flusso complessivo di distribuzione e consentendo alle persone senior di concentrarsi maggiormente sull'architettura e sul processo decisionale, invece di occuparsi continuamente della gestione delle emergenze.

Abbiamo inoltre osservato un inserimento più rapido dei nuovi membri, perché il supporto dell'IA aiuta gli ingegneri a comprendere molto più rapidamente i sistemi non familiari.

Tuttavia, c'è stato anche un aspetto negativo:

• Abbiamo imparato che l'IA può creare una falsa sensazione di sicurezza. Il codice generato spesso sembra corretto anche quando le ipotesi sottostanti sono errate. Senza solide basi ingegneristiche e processi di revisione, i team possono procedere più velocemente nella direzione sbagliata.
• Abbiamo notato che gli ingegneri meno esperti a volte diventano eccessivamente dipendenti dagli strumenti di IA senza comprendere appieno i sistemi che costruiscono. Pertanto, una sfida inaspettata è stata garantire che l'IA aumenti le capacità invece di ridurre la profondità tecnica.
• La governance e la sicurezza sono diventate una sfida maggiore. Negli ambienti regolamentati, è necessario definire confini chiari riguardo ai dati a cui i sistemi di IA esterni possono accedere, alle modalità di revisione del codice generato e a come garantire che le decisioni rimangano verificabili.

Dove l'IA non sta mantenendo le promesse

L'IA non ha ancora realizzato l'ingegneria del software autonoma. L'idea di sistemi completamente generati dall'IA o di sostituire i team di ingegneria suscita entusiasmo, ma nella pratica siamo ancora lontani da questo obiettivo nei complessi ambienti aziendali.

L'IA accelera, realizza prototipi e assiste molto bene gli ingegneri esperti. Tuttavia, quando i sistemi diventano grandi, interconnessi, regolamentati e operativamente critici, i limiti diventano evidenti. La gestione del contesto, la coerenza a lungo termine, i compromessi architetturali e la comprensione approfondita dei sistemi sono ancora deboli rispetto a quelli degli esseri umani esperti.

Anche l'affidabilità degli output destinati alla produzione mi ha deluso. Il codice generato dall'IA spesso appare inizialmente impressionante, ma la qualità può deteriorarsi rapidamente nei casi limite, in presenza di problemi di scalabilità, requisiti di sicurezza o esigenze di manutenibilità. L'ultimo 20 percento del lavoro ingegneristico è ancora profondamente umano.

Sergey condivide

L’IA accelera, realizza prototipi e assiste molto bene gli ingegneri esperti. Tuttavia, quando i sistemi diventano grandi, interconnessi, regolamentati e operativamente critici, i limiti diventano evidenti.

Come l'IA mette in discussione le ipotesi sui team e sull'architettura

La crescita ingegneristica non deriva più principalmente dall'aggiunta di nuove persone.

Team più piccoli e altamente tecnici, dotati di solidi strumenti di IA, possono muoversi molto più velocemente di organizzazioni molto più grandi gravate da processi onerosi. In alcuni casi, il coordinamento stesso è diventato un ostacolo maggiore rispetto all'effettivo lavoro ingegneristico.

Per questo siamo passati a team di ingegneria più piccoli e orientati al prodotto, con maggiore responsabilità e più automazione per la distribuzione, le operazioni e la documentazione.

L'IA ha anche cambiato il mio modo di concepire la seniority. In precedenza, l'accesso alle informazioni e all'esperienza creava forti colli di bottiglia intorno a pochi ingegneri senior o architetti. L'IA riduce parte di questa asimmetria perché conoscenze, documentazione ed esplorazione tecnica diventano molto più accessibili in tutta l'organizzazione.

Dal punto di vista architetturale, inoltre, mi ha spinto verso sistemi più semplici e modulari. L'IA funziona molto meglio quando i sistemi sono ben strutturati, osservabili e chiaramente separati. Gli ambienti complessi e non documentati creano attriti sia per gli esseri umani sia per i sistemi di IA.

Perché nell'adozione dell'IA le persone richiedono più attenzione degli strumenti

Ho sottovalutato l'aspetto umano dell'adozione.

Inizialmente ci siamo concentrati soprattutto sugli strumenti e sulle capacità. Davamo per scontato che, una volta ottenuto l'accesso a sistemi di IA efficaci, gli ingegneri li avrebbero adottati naturalmente. I team hanno reagito in modo molto diverso. Alcuni ingegneri sono diventati immediatamente molto più produttivi, mentre altri hanno modificato a malapena i propri flussi di lavoro.

Se potessi rifare una parte dell'implementazione, dedicherei meno tempo alla valutazione di decine di strumenti di IA e più tempo alla riprogettazione dei flussi di lavoro, alla formazione dei team e alla definizione di modelli operativi chiari per l'utilizzo dell'IA nell'ingegneria.

Perché i CTO devono considerarlo un cambiamento del modello operativo

Il mio consiglio ai CTO è di considerare l'IA come un cambiamento del modello operativo, non solo come un aggiornamento degli strumenti.

Molte aziende continuano ad affrontare l'IA come hanno affrontato le precedenti ondate di software: acquistando piattaforme, eseguendo progetti pilota e aggiungendo casi d'uso isolati. Questo fa perdere di vista il cambiamento più importante. L'IA rimodella il modo in cui lavorano i team di ingegneria, il modo in cui vengono realizzati i prodotti e il modo in cui le organizzazioni crescono.

In secondo luogo, mantenete un approccio pragmatico. Al momento esiste un enorme entusiasmo e molte aziende cercano di introdurre l'IA in problemi in cui apporta poco valore. I risultati migliori derivano solitamente dal miglioramento innanzitutto dei flussi di lavoro esistenti, invece di inseguire idee futuristiche.

In terzo luogo, investite con decisione nei fondamenti dell'ingegneria invece di presumere che l'IA li sostituisca. Un'architettura solida, una buona cultura ingegneristica, responsabilità chiare, disciplina operativa e persone esperte sono ancora più importanti in un ambiente guidato dall'IA.

Infine, i CTO dovrebbero utilizzare personalmente questi sistemi direttamente, non attraverso report o dimostrazioni dei fornitori, ma mettendoci le mani. Il ritmo del cambiamento è troppo rapido per gestire questo tema solo a livello strategico, senza un'esposizione diretta alla tecnologia stessa.

Segui

Puoi seguire il lavoro di Sergey Terentyev su LinkedIn.

Seguiranno altre interviste con esperti su The CTO Club.