Andatelo a spiegare a Garry Kasparov che l'IA non vi ruberà il lavoro.

Nel mondo degli scacchi si pensava che il vero vantaggio umano non fosse semplicemente calcolare le mosse, ma avere:

• intuizione;
• comprensione della posizione;
• capacità di elaborare una strategia;
• visione d'insieme.

Quando una macchina è diventata sufficientemente forte, quella distinzione si è rivelata meno protettiva di quanto si pensasse. Nel 1997 anche lui pensava che il contesto, l'intuizione e la visione d'insieme fossero roba solo umana. Poi ha perso contro Deep Blue.

Oggi sento dire le stesse cose sul codice:

• L'IA non capisce il contesto
• La parte difficile non è mai stata scrivere codice
• Faccio questo lavoro da anni, non può un'IA fare meglio il mio lavoro
• Funziona per le demo, non in produzione

Gran parte di quel “contesto umano” può diventare informazione esplicita, si può scrivere.

Se però è vero che una parte del contesto può essere formalizzata, nei progetti reali esiste anche molto contesto:

• implicito;
• contraddittorio;
• politico/organizzativo;
• distribuito tra persone diverse;
• non ancora scoperto;
• derivante dall'esperienza;
• che cambia mentre il progetto procede.

Soprattutto, qualcuno deve decidere quale contesto conta.

---

Nel settore tecnologico, la crescita professionale viene spesso raccontata attraverso 2 percorsi: approfondire una disciplina fino a raggiungere ruoli più senior, oppure spostarsi verso il people management. La realtà è più varia, ma questa divisione influenza ancora il modo in cui molte persone pianificano la propria carriera.

L'intelligenza artificiale rende più praticabile una terza possibilità: un ruolo da Individual Contributor (IC) che può assumere problemi più ampli usando strumenti AI per esplorare, costruire e verificare parti del lavoro che prima richiedevano più tempo o più persone.

Uso l’espressione AI-Augmented Individual Contributor come lente per ragionare su come può evolvere il contributo di engineer, architect e consultant.

L’IA può allargare il raggio d’azione di un professionista quando sa definire il problema, coordinare persone e strumenti, valutare i risultati e assumersi la responsabilità delle decisioni.

Il ruolo dell’Individual Contributor

Un Individual Contributor contribuisce all’organizzazione attraverso competenza, decisioni e influenza, anche quando non ha responsabilità gerarchica su un gruppo.

Un Enterprise Architect può influenzare standard, scelte architetturali e direzioni di lavoro senza avere collaboratori diretti. Il contributo passa dal giudizio tecnico, dalla capacità di coinvolgere team e stakeholder e dalla qualità delle decisioni che rendono possibili.

Un manager può ampliare il proprio impatto attraverso le persone, le priorità e l’organizzazione. Un IC può farlo attraverso la competenza, la progettazione e la capacità di risolvere problemi complessi.

La distinzione con il people management, quindi, non è tra lavorare da soli e lavorare con gli altri, è una differenza nel modo in cui si contribuisce al risultato. Nella pratica, questi contributi spesso si sovrappongono e si rafforzano a vicenda.

Una parte dell’impatto dell’IC dipende dal tempo e dall’attenzione che può dedicare direttamente alle attività. L’IA può cambiare questa proporzione, non eliminando il lavoro ma modificando quali parti conviene svolgere direttamente e quali possono essere delegate, esplorare alternative e preparare una prima versione di un risultato con meno lavoro manuale.

L'IA cambia la distribuzione del lavoro

Un’attività tecnica richiede di capire il problema, raccogliere contesto, valutare alternative, progettare, realizzare e verificare. Copilot e gli strumenti agentici possono accelerare alcune fasi, preparare bozze, esplorare opzioni o svolgere attività circoscritte. La qualità del risultato dipende ancora da come viene impostato il lavoro e da come viene controllato.

Per questo non vedo il cambiamento come un semplice passaggio dall’esecuzione all’orchestrazione. L’esecuzione resta importante.

Cambia piuttosto il modo in cui decidiamo di distribuire il lavoro:

Capire → scomporre → delegare dove conviene → verificare → decidere

Quando si produce più materiale in meno tempo, saper distinguere ciò che è plausibile da ciò che è corretto diventa ancora più importante.

La parte difficile è stabilire che cosa delegare, quali informazioni fornire, quale risultato aspettarsi e come verificarlo. Servono conoscenza del dominio e capacità di giudizio. Quando l’IA produce più materiale in meno tempo, diventa ancora più importante distinguere ciò che suona plausibile da ciò che è corretto nel contesto specifico.

L’IA, quindi, non trasforma automaticamente un professionista in una figura più efficace. Il valore che ne ricaviamo dipende da come usiamo quel margine: per produrre più artefatti oppure per affrontare meglio il problema che conta.

Ampliare il raggio d’azione senza perdere profondità

Un Cloud Architect deve conoscere cloud architecture. Un Security Architect deve saper ragionare su identità, rete, minacce, governance e controlli. Un Software Engineer deve comprendere i sistemi che costruisce e mantiene.

Questa profondità resta la base del lavoro. L’IA può aiutare a operare con maggiore autonomia nelle discipline vicine: analizzare un requisito, preparare un’automazione, confrontare opzioni, stimare costi, esplorare un’integrazione, costruire un prototipo o spiegare una scelta tecnica a stakeholder con esigenze diverse.

Questo non significa diventare esperti di tutto. L’obiettivo è muoversi oltre i confini più stretti della propria specializzazione, riconoscendo quando si sta esplorando un tema e quando serve coinvolgere una persona con competenze più profonde.

L’ampiezza aumenta, ma non dovrebbe cancellare la consapevolezza dei propri limiti.

Perché il modello Forward Deployed è interessante

Il concetto di Forward Deployed Engineer (FDE) nasce nei primi anni 2010 in Palantir con i team Delta, creati per integrare piattaforme complesse direttamente dentro i sistemi reali e frammentati dei clienti, non è un ruolo nato con l’'IA e non ha una definizione perfettamente uniforme in tutte le aziende.

In generale, è una figura tecnica che lavora a stretto contatto con il cliente o con il contesto operativo in cui una soluzione deve funzionare. Unisce engineering, comprensione del problema, integrazione con sistemi esistenti e attenzione al risultato in produzione.

La descrizione pubblica del ruolo comprende discovery, definizione dello scope tecnico, system design, sviluppo e rilascio in produzione, con attenzione all’adozione e all’impatto misurabile sui workflow. La parte utile di questo modello è il modo di lavorare: avvicinarsi al problema reale, capire i vincoli dell’ambiente, costruire una soluzione adatta a quel contesto e controllare che funzioni una volta messa in uso.

Non tutti gli engineer o gli architect devono diventare FDE, e non tutti i ruoli permettono lo stesso livello di contatto con il cliente.

Questa mentalità però può essere utile anche in un team di piattaforma, in un progetto interno o nel lavoro di un Enterprise Solution Architect. In questi contesti la qualità dell’artefatto tecnico conta; conta anche il risultato che produce per chi lo utilizza.

Questa figura quindi deve essere bravissima a:

1. entrare nel contesto del cliente;
2. capire un problema spesso mal definito;
3. distinguere il requisito dichiarato dal problema reale;
4. trasformarlo in qualcosa di formalizzabile;
5. usare AI, agenti, codice e piattaforme per costruire rapidamente;
6. verificare che la soluzione funzioni nel mondo reale;
7. iterare insieme al cliente.

FROM	TO
Eseguire attività	Assumersi responsabilità dei risultati
Ricevere requisiti	Comprendere e individuare problemi
Specializzazione verticale	Competenza profonda con raggio d'azione più ampio
Consegnare un artefatto	Consegnare un risultato concreto e funzionante
Misurare lo sforzo	Misurare l'impatto
Comunicare aspetti tecnici	Tradurre tra business e tecnologia

Sei cambiamenti pratici nel modo di lavorare

Partire dal problema

Un requisito descrive un bisogno iniziale.

Prima di progettare, conviene capire chi è coinvolto, come funziona oggi il processo, dove si trova la difficoltà e quale cambiamento giustificherebbe l’investimento.

Le domande sono concrete:

• che cosa non funziona?
• Chi ne subisce le conseguenze?
• Quanto spesso accade?
• Come capiremo se la situazione è migliorata?

Questa attività fa parte del lavoro tecnico, perché influenza architettura, priorità e criteri di accettazione. Se il problema è definito male, anche un’implementazione ben eseguita può produrre poco valore.

Delegare con criterio

Un problema complesso può essere scomposto in attività di ricerca, progettazione, codice, test, analisi di sicurezza, documentazione e valutazione dei costi. Alcune richiedono il giudizio diretto del professionista; altre possono essere affidate a colleghi, automazioni o agenti IA.

La domanda da porsi è:"Quali parti richiedono davvero il mio intervento, quali posso delegare e come controllerò il risultato?".

La delega funziona quando il contesto è sufficiente, il compito è ben delimitato e la verifica è proporzionata al rischio.

Nei sistemi enterprise, l’affidabilità dipende anche dai dati utilizzati, dai permessi coinvolti e dal comportamento del sistema quando le informazioni sono incomplete.

Seguire il lavoro fino al risultato

Nei progetti, le responsabilità sono spesso distribuite per fase: discovery, architecture, implementation, security e operations.

Questa divisione aiuta a chiarire i compiti, ma può creare passaggi di consegne in cui ogni persona completa la propria parte senza che qualcuno tenga insieme il risultato.

Avere ownership end-to-end significa mantenere coerenza tra obiettivo, decisioni tecniche, integrazione, rilascio, adozione e feedback. Il lavoro si misura anche da ciò che cambia per le persone che useranno la soluzione.

Questo approccio conta ancora di più quando l’IA rende semplice produrre prototipi e codice.

Collegare tecnologia e business

Le soluzioni vivono dentro processi, vincoli economici, sistemi legacy, requisiti di sicurezza e abitudini degli utenti. Capire questi elementi permette di prendere decisioni tecniche più adatte e di spiegare i trade-off in modo comprensibile.

Un buon professionista tecnico sa ascoltare, mettere in discussione un’assunzione quando serve e tradurre un’esigenza di business in una scelta architetturale. Sa spiegare anche i limiti: che cosa è fattibile, a quale costo, con quali rischi e con quali compromessi.

L’IA può aiutare a esplorare una soluzione. La priorità del problema e i compromessi accettabili restano decisioni da prendere nel contesto dell’organizzazione.

Prototipare per imparare

Un prototipo è utile quando verifica un’ipotesi specifica. Può mostrare se un’integrazione è praticabile, se un workflow è comprensibile o se una capacità di intelligenza artificiale è abbastanza affidabile per un caso d’uso.

Il risultato della prova dovrebbe chiarire che cosa abbiamo imparato e quali dubbi restano aperti.

L’IA abbassa il costo di esplorare alternative e costruire una prima versione. Conviene sfruttare questa possibilità per imparare prima, mantenendo chiaro che cosa il prototipo deve dimostrare e quali aspetti vanno ancora verificati.

Se la prova dà esito positivo, il lavoro continua con dati reali, permessi, test, gestione degli errori, logging, monitoraggio, fallback e supporto operativo.

Misurare ciò che cambia

Numero di prompt, righe di codice generate, documenti creati o agenti utilizzati sono metriche di attività.

Per valutare il miglioramento servono indicatori legati al processo e al risultato. Anche il tempo risparmiato è soltanto una parte del quadro: conta come viene impiegato e se cambia il risultato.

Le metriche dipendono dal problema.

Potrebbero riguardare il tempo necessario per completare un processo, il tasso di errore, i passaggi manuali, la qualità del servizio o il rischio residuo. Conviene stabilire una baseline, scegliere un indicatore credibile e verificare che il miglioramento duri nel tempo.

La domanda che uso per valutare un’iniziativa è: che cosa è cambiato grazie a questo lavoro? Quando questa domanda resta senza risposta, potremmo aver aumentato l’output senza aver dimostrato l’impatto.

Esempio: agente per l'incident management

Immaginiamo che un team chieda di costruire un agente IA che sintetizzi gli incidenti e suggerisca possibili cause.

Una prima demo potrebbe leggere una descrizione e generare un riepilogo plausibile. È una dimostrazione utile, ma non risponde alla domanda più importante: migliora davvero il lavoro di chi deve gestire l’incidente?

Un approccio orientato al risultato partirebbe dal processo attuale. Quali informazioni consulta il tecnico? Dove si trovano log, deployment recenti, runbook e ownership dei servizi? Quanto tempo si perde nel ricostruire il contesto? Quali dati l’agente può leggere e quali azioni non deve poter eseguire?

A quel punto si può scegliere un obiettivo circoscritto, ad esempio ridurre il tempo necessario a raccogliere il contesto iniziale, e verificare la soluzione su casi rappresentativi. Occorre misurare non solo la velocità, ma anche la correttezza e l’utilità delle informazioni, il comportamento quando mancano dati, la tracciabilità delle risposte e la capacità dell’utente di ignorare un suggerimento sbagliato.

L’integrazione con gli strumenti esistenti, i controlli di accesso, la gestione dei fallimenti e il monitoraggio non sono rifiniture da aggiungere alla fine: fanno parte della soluzione.

Se il prototipo non migliora il processo o introduce rischi non accettabili, la decisione corretta può essere modificarlo o non portarlo in produzione.

È questo il tipo di ragionamento che considero trasferibile dal modello FDE a molti ruoli tecnici.

Non basta costruire qualcosa, bisogna verificare se quella capacità inserita in un contesto reale genera un risultato migliore.

Come applicarlo alla propria crescita professionale

Partirei dal lavoro concreto e da una piccola area in cui sperimentare un modo diverso di affrontare i problemi.

• Mantieni la profondità tecnica. Ti serve per valutare le risposte e riconoscere errori che il sistema potrebbe non segnalare.
• Allarga il raggio con intenzione. Usa l’IA per esplorare discipline vicine e coinvolgi specialisti quando serve maggiore profondità.
• Allenati a definire il problema. Chiarisci l’utente, il vincolo, il risultato atteso e il modo in cui lo misurerai.
• Sperimenta la delega su attività delimitate. Definisci contesto, criteri di successo e controlli prima di aumentare il livello di autonomia.
• Segui il lavoro. Osserva integrazione, adozione, affidabilità e manutenzione.
• Raccogli evidenze. Confronta prima e dopo, includendo qualità e rischio oltre la velocità.

A volte il costo di preparare, controllare e correggere un risultato generato supera il beneficio. Anche questa valutazione fa parte del giudizio professionale.

Un'idea diversa di seniority

L’IA da sola non cambia il nostro modo di lavorare: possiamo produrre le stesse cose più velocemente e seguire comunque lo stesso processo. L’adozione dell’IA incide sul lavoro quando cambia le decisioni e le responsabilità che ci assumiamo.

Il cambiamento si vede quando ci consente di affrontare problemi più ampi e seguire le soluzioni fino al loro utilizzo reale. Per questo il modello FDE è interessante anche fuori dalla job title: partire dal problema reale, lavorare dentro il contesto e verificare l’impatto. L’IA può aiutare lungo il percorso; la responsabilità resta di chi progetta, decide e mette la soluzione nelle mani degli utenti.

L'intelligenza artificiale però è una leva, non una garanzia.

La seniority potrebbe dipendere sempre più dalla complessità che sappiamo gestire responsabilmente: coinvolgere le competenze giuste, usare gli strumenti adatti e mantenere il giudizio tecnico mentre il perimetro del problema si allarga.

Nel lavoro enterprise, il contesto è molto meno ordinato di una scacchiera.

Le informazioni possono essere incomplete, le priorità entrano in conflitto e il risultato dipende da sistemi e persone che non controlliamo direttamente.

Con questi strumenti a disposizione, quale problema puoi assumerti oggi che fino a poco tempo fa sarebbe rimasto fuori dal tuo perimetro?