I CTO e gli SE interni stanno diventando 'SIer interni' grazie allo sviluppo basato sull'IA?

@qumaiu
GIAPPONESE1 mese fa · 08 giu 2026
562K
587
69
4
845

TL;DR

L'IA rende la programmazione veloce, ma rischia di creare 'sistemi isolati' frammentati. I CTO e gli SE interni devono passare dal ruolo di costruttori a quello di architetti, dando priorità all'integrazione dei dati a livello aziendale e alla decisione strategica di cosa non costruire.

Nel mio articolo precedente, ho parlato dello stato attuale della definizione dei requisiti per l'IA—di come il processo si stia spostando dall'"organizzare" al "decidere," e della mia preoccupazione che molti luoghi di lavoro stiano delegando ciecamente il proprio pensiero senza rendersi conto di questo cambiamento.

Questa volta, voglio lanciare un altro allarme su una questione correlata.

Il problema Ú che i CTO e gli SE interni, poiché ora riescono a programmare molto velocemente con lo sviluppo guidato dall'IA, stanno diventando dei semplici esecutori di ordini per i reparti business—essenzialmente degli 'SI interni.'

Le Nuove Dinamiche Create dallo Sviluppo Guidato dall'IA

È un dato di fatto innegabile che la diffusione dello sviluppo guidato dall'IA abbia abbassato drasticamente la barriera alla programmazione.

Di conseguenza, le richieste dai reparti business come 'Voglio questo' o 'Voglio sistematizzare questo' arrivano a una velocità senza precedenti. Non Ú raro che il personale business elenchi i requisiti usando l'IA da solo, o addirittura crei prototipi.

A prima vista, sembra una cosa positiva. Sembra uno scenario ideale in cui i reparti business guidano la DX e collaborano con l'IT per lanciare velocemente i sistemi.

Tuttavia, c'Ú una trappola qui.

Sento che sempre più CTO e SE interni stanno diventando 'persone che danno semplicemente forma alle richieste dei reparti business.' Ricevono una richiesta, la realizzano tecnicamente e la consegnano. Questo Ú esattamente ciò che fa un SI interno.

Cosa Attende alla Fine dell'Esecuzione degli Ordini

Rispondere alle richieste business non Ú sbagliato di per sé. Il problema Ú cosa succede quando continui a soddisfare ogni richiesta individuale di un reparto così com'Ú.

Io chiamo questo la proliferazione di 'sistemi ibridi' e 'database ibridi.'

Le Vendite creano il proprio CRM, il Marketing configura una piattaforma di analisi dati separata e il Servizio Clienti costruisce la propria gestione ticket. Ogni reparto Ú soddisfatto perché ha ottenuto un sistema ottimizzato per il proprio lavoro ad alta velocità.

Ma per quanto riguarda l'azienda nel suo complesso?

I dati sono sparsi in posti diversi e i formati non sono unificati. Le stesse informazioni sui clienti esistono in forme diverse in più database. Ogni volta che provi a collegare dati tra reparti, hai bisogno di lavoro manuale o sviluppo personalizzato.

Questo Ú un silo tecnico.

Poiché lo sviluppo guidato dall'IA rende così facile costruire sistemi, questa frammentazione procede a una velocità senza precedenti. Prima, gli alti costi di sviluppo fungevano da freno naturale. C'era una dinamica del tipo 'Ú difficile da costruire, quindi selezioniamo rigorosamente solo ciò che Ú veramente necessario.'

Ora, quel freno Ú sparito. Poiché può essere costruito, viene costruito. Di conseguenza, sistemi e database ibridi si moltiplicano, e il numero di app e infrastrutture da gestire continua ad aumentare.

Perché Questo Ú Fatale nell'Era dell'IA

Potresti pensare: 'Anche se i sistemi sono un po' sparsi, va bene finché funzionano.' Tuttavia, nell'era dell'IA, questa frammentazione causa problemi più fatali che mai.

Il motivo Ú semplice: Il valore dell'IA Ú proporzionale al grado di integrazione dei dati.

L'IA mostra veramente la sua potenza quando i dati sono integrati in tutta l'azienda, permettendo intuizioni che attraversano i reparti. Solo quando i dati di vendita, la cronologia dei clienti, gli effetti di marketing e i dati finanziari sono integrati, l'IA può fornire intuizioni che aiutano le decisioni manageriali.

In un ambiente pieno di sistemi ibridi, i dati non sono collegati fin dall'inizio. Potresti ottenere piccole ottimizzazioni IA all'interno dei reparti, ma non raggiungerai mai un utilizzo aziendale dell'IA—il tipo che ha veramente un impatto sul business.

Accumulando ottimizzazioni di reparto, perdi permanentemente l'ottimizzazione totale. Questo Ú il rischio che i CTO e gli SE interni che eseguono ordini creano inconsapevolmente.

Il Vero Ruolo che CTO e SE Interni Dovrebbero Svolgere

Quindi, come dovrebbero essere i CTO e gli SE interni?

La risposta Ú chiara: Diventare 'progettisti e decisori' piuttosto che semplici 'costruttori.'

'Progettare' qui non significa progettare sistemi individuali. Significa progettare l'architettura dei dati e dei sistemi per l'intera azienda.

Quando arriva una richiesta da un reparto business, invece di costruirla e basta, giudichi 'come questa richiesta dovrebbe essere posizionata nell'architettura aziendale.' In alcuni casi, devi dire: 'Questo non dovrebbe essere costruito individualmente.' Se può essere gestito espandendo piattaforme esistenti, guidali lì.

Questo potrebbe sembrare scomodo per i reparti business. Potrebbero chiedere: 'Perché stai parlando di tutta l'azienda quando voglio solo che questo venga costruito ora?'

Ma solo i CTO e gli SE interni possono fare quel giudizio. I reparti business hanno incentivi per ottimizzare la propria area, ma nessun incentivo a proteggere l'architettura aziendale. Ecco perché gli esperti tecnici devono svolgere il ruolo di guardiani dell'ottimizzazione totale.

La 'Decisione di Non Costruire' Ú la Massima Competenza Tecnica

Ironia della sorte, l'abilità più importante richiesta ai CTO e agli SE interni nell'era dell'IA potrebbe essere la 'decisione di non costruire.' Ecco perché li chiamo 'decisori.'

Arriva una richiesta da un reparto business. È tecnicamente possibile. Con l'IA, può essere modellata in pochi giorni. Ma devi avere il potere di chiederti se costruirla sia veramente giusto per l'intera azienda.

Questa richiesta può essere gestita dalle piattaforme esistenti? La struttura dei dati Ú allineata con le regole aziendali? Un sistema simile Ú già in esecuzione in un altro reparto? Aggiungere un sistema ottimizzato individualmente renderà difficile l'integrazione futura dei dati?

Essere in grado di porsi queste domande Ú la vera forza tecnica nell'era dell'IA.

L'IA si occuperà della programmazione. Tuttavia, giudicare cosa costruire e cosa non costruire Ú qualcosa che l'IA non può fare. Come ho menzionato nell'articolo precedente che 'la definizione dei requisiti diventerà un processo decisionale,' il ruolo dei CTO e degli SE interni segue esattamente la stessa struttura.

Piuttosto che essere esecutori di ordini, il tuo ruolo di progettista dell'architettura aziendale diventa sempre più importante proprio a causa dell'era dell'IA.

Creare uno 'Stato di Prontezza' Perché il Futuro Ú Imprevedibile

Mentre ho enfatizzato l'importanza della 'decisione di non costruire,' c'Ú un'altra prospettiva che i CTO e gli SE interni dovrebbero avere.

Poiché il futuro Ú imprevedibile nell'era dell'IA, devi mantenere l'azienda in uno stato in cui possa muoversi in qualsiasi momento.

Attualmente, si sta diffondendo il discorso che 'il SaaS Ú morto.' Da quando l'amministratore delegato di Microsoft Satya Nadella ha pronunciato queste parole alla fine del 2024, molti hanno previsto la fine del SaaS. In effetti, le valutazioni SaaS vengono compresse e l'interesse degli investitori si sta rapidamente spostando verso piattaforme native dell'IA.

Ma il SaaS sta davvero morendo?

Non penso sia così semplice. Le aziende SaaS stanno investendo massicciamente in R&D per trovare la forma ottimale di software per l'era dell'IA. Integrazione IA agentiva, fatturazione basata sui risultati, piattaforme IA specifiche per settore... c'Ú un'alta possibilità che emergano prodotti in forme che al momento non possiamo immaginare.

In altre parole, sia concludere che 'il SaaS Ú morto' e precipitarsi nello sviluppo interno, sia fermare il pensiero pensando che 'il SaaS Ú sufficiente,' sono rischi.

La posizione che un CTO/SE interno dovrebbe assumere non Ú scommettere sull'una o sull'altra cosa. È progettare un'architettura che possa rispondere qualunque sia la direzione che le cose prenderanno.

Nello specifico, standardizza come vengono conservati i dati e crea una struttura che non sia bloccata su un particolare SaaS o strumento. Mantieni le connessioni di sistema debolmente accoppiate tramite API. Non lasciare che i sistemi ibridi proliferino; unifica la base dati dell'azienda.

Con questa filosofia di progettazione, se il SaaS si evolve ed escono prodotti migliori, puoi cambiare. Al contrario, se diventa chiaro che costruire internamente Ú meglio per una certa area, puoi migrare lì.

Non puoi prevedere il futuro. Ma puoi creare una struttura che possa rispondere ad esso. Questa Ú l'essenza della progettazione architetturale richiesta ai CTO e agli SE interni nell'era dell'IA. Al contrario, solo gli esperti tecnici possono fare questo. Non voglio che tu spenda quelle preziose risorse come un SI interno.

Accelerare i Processi a Monte con l'IA

Come strumento per supportare la trasformazione dei processi a monte, abbiamo rilasciato 'GEAR-UI,' uno strumento IA per la definizione di schermate e la generazione di mock, come OSS (Open Source Software).

Rendendolo OSS, speriamo di liberare gli utenti dagli ostacoli di implementazione e aiutarli ad affrontare l'essenziale. Usatelo soprattutto per i giudizi 'pre-costruzione' di cui ho parlato.

La personalizzazione Ú gratuita. Fatevene tesoro.

https://x.com/qumaiu/status/1910985993806913746

https://x.com/qumaiu/status/2063097253808734344

Salva con un clic

Leggi in profondità gli articoli virali con l’AI di YouMind

Salva la fonte, fai domande mirate, riassumi l’argomentazione e trasforma un articolo virale in note riutilizzabili in un unico spazio di lavoro AI.

Scopri YouMind
Per i creator

Trasforma il tuo Markdown in un articolo 𝕏 pulito

Quando pubblichi i tuoi testi lunghi, formattare immagini, tabelle e blocchi di codice per 𝕏 Ú una seccatura. YouMind trasforma un'intera bozza Markdown in un articolo 𝕏 pulito e pronto da pubblicare.

Prova Markdown verso 𝕏

Altri pattern da decodificare

Articoli virali recenti

Esplora altri articoli virali