La maggior parte degli sviluppatori usa ancora l'AI nello stesso modo in cui usavano ChatGPT nel 2023.
Aprire una chat. Fare una domanda. Copiare del codice. Incollarlo nell'editor. Ripetere.
Funziona. Nessuno dice che non funzioni.
Ma sta già diventando superato in modi che la maggior parte delle persone non ha ancora notato. E gli sviluppatori che se ne accorgono presto si stanno silenziosamente costruendo un vantaggio che sarà molto difficile da colmare in seguito.
Sta emergendo una nuova categoria di sviluppatori. Non usano l'AI come assistente alla programmazione come fanno tutti gli altri. Ci stanno costruendo sopra interi sistemi operativi. Sistemi strutturati con memoria, contesto, agenti specializzati, cicli di verifica e flussi di lavoro che si accumulano nel tempo.
Il divario tra questi due approcci sta diventando uno dei vantaggi competitivi più significativi nello sviluppo software. Non perché un gruppo sia più intelligente dell'altro. Ma perché un gruppo ha capito prima che la vera leva non era mai nel modello. Era sempre nel sistema che circonda il modello.
Gli sviluppatori che capiscono questo cambiamento oggi avranno un vantaggio che continuerà a crescere per i prossimi anni. Perché il futuro dello sviluppo software non riguarda lo scrivere codice più velocemente. Riguarda l'orchestrare l'intelligenza su larga scala.
La discussione che tutti stanno facendo è la discussione sbagliata
Negli ultimi due anni l'intero dibattito sull'AI è stato dominato da una domanda che si ripete in forme diverse.
Quale modello è migliore?
Claude contro GPT. GPT contro Gemini. Gemini contro DeepSeek. Open-source contro proprietario. Tutti a confrontare benchmark, punteggi di programmazione, finestre di contesto e valutazioni sul ragionamento, come se il modello stesso fosse il punto d'arrivo della competizione.
Quella discussione sta lentamente diventando meno importante di quanto pensino le persone che la fanno.
Una domanda più preziosa sta emergendo silenziosamente sotto tutto il rumore.
Come si trasforma un modello linguistico in un ingegnere software produttivo?
Non un chatbot che risponde a domande. Non un motore di autocompletamento che risparmia battute. Non un generatore di codice che produce funzioni su richiesta. Un vero sistema ingegneristico capace di pianificare il lavoro, ricercare soluzioni, revisionare il codice, trovare bug, scrivere test, aggiornare la documentazione, gestire il contesto su progetti lunghi, imparare dalle decisioni precedenti e migliorare i propri output nel tempo.
Questa trasformazione sta avvenendo ora intorno a strumenti come Claude Code. Ed è molto più grande di quanto suggeriscano i dibattiti sui benchmark.
La prima ondata di strumenti AI per la programmazione ha risolto il problema sbagliato
La prima generazione di strumenti AI per la programmazione si è concentrata quasi interamente sulla generazione di codice. Era il problema ovvio da risolvere ed era un problema reale che valeva la pena affrontare.
GitHub Copilot ha dimostrato che l'AI poteva completare il codice in modi davvero utili. ChatGPT ha reso lo sviluppo software conversazionale per la prima volta. I modelli sono migliorati rapidamente. Le finestre di contesto si sono ampliate. La qualità del codice è aumentata al punto che gli output erano spesso pronti per la produzione con modifiche minime.
Per un po' è sembrato che l'intero settore stesse correndo verso un unico obiettivo chiaro. Generare più codice, più velocemente, con meno errori.
Ma gli ingegneri esperti hanno presto scoperto qualcosa che sarebbe dovuto essere ovvio fin dall'inizio.
Scrivere codice è raramente la parte più difficile dello sviluppo software.
Il vero lavoro, quello che consuma la maggior parte del tempo di un ingegnere senior e la maggior parte dell'energia di un team, di solito si presenta così. Comprendere requisiti incompleti o contraddittori. Ricercare soluzioni in un codebase con anni di storia e decisioni incorporate. Fare scelte architetturali che si trasformeranno in vantaggi o in debito tecnico a seconda di quanto siano state ben ponderate. Gestire quel debito tecnico una volta accumulato. Testare i casi limite a cui nessuno ha pensato durante la pianificazione. Revisionare le implementazioni per correttezza, sicurezza e manutenibilità. Correggere bug in produzione sotto pressione. Mantenere una documentazione sempre leggermente obsoleta. Coordinare progetti complessi tra persone con modelli mentali diversi di ciò che si sta costruendo.
La maggior parte del ciclo di vita dell'ingegneria avviene al di fuori dell'editor.
Ed è esattamente lì che i flussi di lavoro AI tradizionali, l'approccio "apri una chat, copia del codice", hanno iniziato a crollare completamente.
Perché Claude Code sembra davvero diverso da tutto ciò che è venuto prima
Claude Code ha introdotto un'idea fondamentalmente diversa, e vale la pena enunciarla con precisione perché la differenza è facile da sottovalutare.
Invece di trattare l'AI come qualcosa che consulti occasionalmente per avere aiuto, la colloca direttamente nel flusso di lavoro stesso come partecipante attivo nell'esecuzione.
Sembra una distinzione sottile. Non lo è per niente.
Un chatbot aspetta istruzioni e risponde. Un operatore partecipa all'esecuzione e compie azioni nel tuo ambiente reale. Questa distinzione cambia l'intera natura del rapporto tra lo sviluppatore e lo strumento.
Quando gli sviluppatori hanno iniziato a lavorare seriamente con Claude Code, la conversazione è passata dal chiedersi se l'AI potesse scrivere una funzione specifica al chiedersi se l'AI potesse gestire un intero flusso di lavoro dall'inizio alla fine. Una volta che quella domanda ti entra in mente, smetti di pensare alla generazione di codice come obiettivo. Inizi a pensare ai sistemi. E i sistemi sono dove è sempre esistita la vera leva in ingegneria.
Gli sviluppatori che oggi ottengono di più da Claude Code non sono quelli che scrivono i singoli prompt più intelligenti. Sono quelli che hanno costruito i sistemi più ponderati intorno ad esso.
Il collo di bottiglia non è quasi mai l'intelligenza
La maggior parte delle persone presume che quando l'AI produce output mediocri sia perché il modello non è abbastanza intelligente. Questa ipotesi porta a una ricerca costante di un modello migliore che finalmente produca i risultati che tutti aspettano.
In realtà il collo di bottiglia è quasi sempre il contesto. Non l'intelligenza. Il contesto.
Pensa di assumere il miglior ingegnere software che tu possa immaginare e poi non dargli alcuna documentazione, nessuna cronologia del progetto, nessuno standard di codifica, nessuna registrazione delle precedenti decisioni architetturali e nessuna conoscenza dei bug già trovati e corretti. Quell'ingegnere farebbe enormemente fatica. Non perché non sia capace. Perché opera senza il contesto che rende la capacità utile.
I modelli AI affrontano esattamente lo stesso problema in ogni conversazione che ricomincia da capo senza memoria di ciò che è venuto prima.
Questo spiega qualcosa che confonde le persone quando lo incontrano per la prima volta. Due sviluppatori possono usare lo stesso identico modello e ottenere risultati che sembrano provenire da strumenti completamente diversi. Uno ottiene output davvero utili e pronti per la produzione. L'altro ottiene output mediocri che richiedono più correzioni del codice originale che avrebbe scritto.
La differenza non è quasi mai il modello. La differenza è la gestione del contesto. Uno sviluppatore ha dato al modello ciò di cui aveva bisogno per funzionare bene. L'altro no.
Questa è una delle cose più importanti da capire praticamente quando si lavora con l'AI a un livello serio. Non stai solo scegliendo un modello. Stai costruendo un ambiente in cui quel modello possa operare efficacemente. L'ambiente determina l'output molto più della capacità grezza del modello al suo interno.
Il contesto sta diventando la nuova infrastruttura
La maggior parte delle discussioni sull'AI si concentra sui prompt perché i prompt sono lo strato visibile. Sono ciò che scrivi. Sono ciò che vedi. Sembra che siano ciò che controlli.
Ma i prompt sono solo la superficie.
Sotto ogni flusso di lavoro AI di successo costante si trova un'infrastruttura molto più ampia a cui la maggior parte delle persone non pensa mai esplicitamente e di cui quasi mai si discute pubblicamente.
Questa infrastruttura include sistemi di memoria che conservano le informazioni tra una sessione e l'altra invece di ricominciare da zero ogni volta. Archivi di conoscenza che catturano decisioni, standard e modelli in una forma che il modello può consultare. Recupero del contesto che porta in superficie le informazioni giuste al momento giusto senza sopraffare il modello con tutto in una volta. Orchestrazione del flusso di lavoro che sequenzia i compiti nell'ordine giusto con gli input corretti che fluiscono tra di essi. Cicli di valutazione che controllano gli output rispetto agli standard prima che passino alla fase successiva. Controlli di sicurezza che definiscono ciò che il modello può e non può toccare. Pipeline di verifica che intercettano gli errori prima che si accumulino. Monitoraggio delle prestazioni che identifica dove il sistema produce output scadenti in modo che quei punti possano essere migliorati.
Questi sistemi determinano se un'AI diventa davvero utile per un'organizzazione ingegneristica o rimane un costoso motore di autocompletamento che risparmia qualche battuta e impressiona le persone nelle demo.
Le aziende e i singoli sviluppatori che costruiscono questi strati oggi stanno effettivamente costruendo i sistemi operativi dell'era dell'AI. Non stanno solo usando gli strumenti che esistono. Stanno costruendo l'infrastruttura su cui funzionerà la prossima generazione di strumenti.
L'ascesa dello sviluppo agentico e perché rispecchia il modo in cui si costruiscono i grandi team
È qui che sta andando lo sviluppo software ed è più facile da capire se lo colleghi a qualcosa che ha già un senso intuitivo.
Pensa a come funziona un'organizzazione ingegneristica davvero efficace. Non assumi una persona e le chiedi di fare tutto. Hai specialisti con competenze profonde in aree specifiche. Ricercatori che capiscono lo spazio del problema. Architetti che prendono decisioni strutturali. Revisori che individuano i problemi nell'implementazione. Ingegneri della sicurezza che pensano a cosa potrebbe andare storto in modi che gli ingegneri orientati al prodotto non colgono. Ingegneri QA che testano le ipotesi contro la realtà. Scrittori tecnici che rendono il sistema comprensibile a tutti coloro che ci lavorano. Operatori che mantengono tutto in esecuzione in produzione.
Lo stesso modello sta emergendo all'interno dei flussi di lavoro AI avanzati.
Un sistema agentico ben progettato oggi potrebbe muoversi attraverso un Agente di Ricerca che indaga lo spazio del problema prima che vengano prese decisioni, poi un Agente di Architettura che progetta l'approccio strutturale basato su quella ricerca, poi un Agente di Implementazione che scrive il codice secondo le specifiche architetturali, poi un Agente di Test che verifica l'implementazione rispetto ai requisiti e ai casi limite, poi un Agente di Sicurezza che esamina le vulnerabilità, poi un Agente di Documentazione che cattura cosa è stato costruito e perché, poi un Agente di Deployment che gestisce il processo di rilascio.
Ogni sistema ha una responsabilità specifica. Ogni sistema si concentra su un problema specifico. Insieme si comportano meno come un chatbot e più come un'organizzazione ingegneristica con ruoli definiti e passaggi di consegne chiari tra di loro.
Ecco perché gli utenti più sofisticati di Claude Code non passano più la maggior parte del tempo a creare singoli prompt. Passano il loro tempo a progettare flussi di lavoro. Il prompt è solo l'input per una fase di un sistema più ampio. Il sistema è ciò che produce risultati costantemente buoni.
La memoria potrebbe alla fine contare più della capacità del modello
Questo è il cambiamento che la maggior parte delle persone non sta prendendo abbastanza sul serio ed è quello che penso conterà di più nei prossimi anni.
I modelli stanno migliorando rapidamente e il divario tra i migliori modelli disponibili si sta riducendo. I benchmark tra i modelli all'avanguardia si stanno avvicinando, non allontanando. Le guerre dei modelli che dominano la conversazione si combattono su differenze che si stanno riducendo.
Ma la memoria crea vantaggi cumulativi che non si riducono. Crescono.
Pensa a cosa rende un ingegnere senior davvero prezioso rispetto a un ingegnere junior con un'intelligenza grezza simile. L'esperienza. E l'esperienza conta perché l'esperienza crea memoria. La memoria crea intuizione su cosa funziona e cosa no. L'intuizione crea decisioni migliori prese più velocemente con meno energia. Quelle decisioni migliori si accumulano nel tempo in un track record e una profondità di giudizio che non possono essere replicati rapidamente.
Senza memoria, ogni progetto ricomincia da zero indipendentemente da ciò che è venuto prima. Ogni errore viene ripetuto perché non c'è traccia che sia già stato commesso. Ogni lezione appresa scompare alla fine della sessione. Ogni flusso di lavoro che ha funzionato bene deve essere ricostruito la volta successiva. Questa è un'enorme inefficienza che si accumula invisibilmente in ogni progetto.
Ecco perché i costruttori di sistemi AI più lungimiranti si stanno concentrando fortemente sulla persistenza delle sessioni che trasporta il contesto tra le conversazioni, sulla memoria a lungo termine che cattura modelli e decisioni in una forma recuperabile, sull'accumulo di conoscenza che si basa su se stessa invece di resettarsi e sull'evoluzione del flusso di lavoro che migliora il sistema in base a ciò che ha funzionato prima.
Il futuro che sta effettivamente arrivando non sono semplicemente modelli più intelligenti. Sono sistemi più intelligenti che ricordano e migliorano. Il vantaggio cumulativo appartiene a chiunque costruisca quei sistemi per primo.
Lo strato nascosto che la maggior parte delle persone ignora completamente
Ecco l'osservazione a cui continuo a tornare quando penso a dove risiede il vero vantaggio.
Tre sviluppatori possono usare oggi lo stesso identico modello Claude. Uno ottiene risultati nella media, marginalmente migliori che scrivere il codice a mano. Uno ottiene risultati eccellenti che accelerano significativamente la loro produttività. Uno costruisce un'intera azienda di software intorno al modello e produce cose che non sarebbero state possibili con un team di qualsiasi dimensione qualche anno fa.
La differenza tra questi tre risultati non è l'intelligenza. Non è nemmeno lo sforzo, almeno non direttamente. È l'infrastruttura.
Lo stack tecnico vincente assomiglia sempre più a una torta a strati in cui il modello si trova in cima, visibile e costantemente discusso, e tutto ciò che sta sotto è dove risiede il vero vantaggio competitivo. La memoria sotto il modello. L'orchestrazione del flusso di lavoro sotto quella. I sistemi di valutazione che controllano gli output. I controlli di sicurezza che definiscono i confini. L'automazione che rimuove i passaggi ripetitivi. Le pipeline di esecuzione che concatenano tutto insieme.
La maggior parte delle persone si concentra solo sullo strato superiore. Si concentrano sul modello perché il modello è ciò con cui interagiscono direttamente e ciò che il marketing enfatizza.
La leva più alta, il posto dove si stanno costruendo i maggiori vantaggi in questo momento, esiste in tutto ciò che è al di sotto dello strato visibile.
Perché questo momento mi ricorda la rivoluzione del cloud
Il parallelo merita di essere preso sul serio perché continua a rivelarsi accurato col senno di poi, anche se al momento sembra sempre facoltativo.
La maggior parte degli sviluppatori oggi vede i flussi di lavoro agentici come un esperimento interessante o un miglioramento della produttività da esplorare quando c'è tempo. È esattamente così che appariva il cloud computing nel 2008 e 2009. La gente pensava di poter semplicemente gestire i propri server. Gli sviluppatori che hanno costruito sull'infrastruttura cloud all'inizio sembravano aver esagerato con l'ingegneria. Poi il cloud è diventato lo standard e quelli che non avevano fatto il cambiamento si sono ritrovati improvvisamente indietro in modi che erano costosi da correggere.
Lo stesso modello è apparso con il version control, con i container, con l'integrazione continua e il deployment. Ogni cambiamento infrastrutturale inizialmente sembra un trucco di produttività opzionale per persone che hanno tempo per sperimentare. Poi diventa un vantaggio competitivo per le organizzazioni che lo hanno adottato presto. Poi diventa il modo di lavorare predefinito e tutti gli altri sono in recupero.
Lo sviluppo agentico sta seguendo la stessa traiettoria. Oggi è sperimentale e praticato da una minoranza di sviluppatori che ne sono sproporzionatamente entusiasti. Domani sarà previsto dalle organizzazioni ingegneristiche che vogliono rimanere competitive. La finestra in cui l'adozione precoce crea un vantaggio duraturo è aperta ora e non rimarrà aperta indefinitamente.
Le competenze dello sviluppatore si stanno evolvendo in una direzione specifica
Per la maggior parte della storia dell'ingegneria del software, il successo era fortemente correlato alla capacità di implementazione. Quanto velocemente potevi scrivere codice corretto. Quanto profondamente capivi linguaggi e framework specifici. Quanti algoritmi potevi ricordare e applicare. Quelle competenze contavano enormemente e contano ancora.
Ma gli sviluppatori a più alta leva del prossimo decennio si concentreranno sempre più su un insieme diverso di capacità.
Progettare flussi di lavoro che sequenziano gli agenti AI attraverso compiti complessi nell'ordine giusto con gli input e output corretti in ogni fase. Gestire il contesto in modo che i modelli abbiano ciò di cui hanno bisogno per funzionare bene senza essere sopraffatti. Costruire sistemi di valutazione che verificano gli output prima che vengano utilizzati. Creare architetture di memoria che accumulano conoscenza e migliorano nel tempo. Coordinare agenti specializzati che si concentrano ciascuno su problemi specifici. Definire processi di verifica che mantengono la qualità all'aumentare del volume degli output. Strutturare pipeline di esecuzione che si concatenano in sistemi automatizzati affidabili.
Il lavoro si sta evolvendo dal costruire cose al dirigere l'intelligenza. Dall'era scrivere codice al progettare i sistemi che producono codice. Dall'implementazione all'orchestrazione.
Questo è un cambiamento significativo in ciò che significa padronanza. Gli sviluppatori che lo riconoscono presto e iniziano a costruire queste competenze ora saranno posizionati in modo molto diverso da quelli che continuano a ottimizzare per la vecchia definizione di eccellenza ingegneristica.
Dove porta e quanto potrebbe essere lontano
L'evoluzione del rapporto dello sviluppatore con l'AI sembra muoversi attraverso fasi riconoscibili.
La prima fase era uno sviluppatore che lavorava con un editor, producendo tutto manualmente con strumenti che organizzavano e visualizzavano il codice ma non contribuivano a scriverlo.
La seconda fase è uno sviluppatore che lavora con un assistente AI che risponde a domande, genera codice su richiesta e accelera compiti specifici mentre lo sviluppatore rimane il principale produttore.
La terza fase, dove si trovano oggi i professionisti più avanzati, è uno sviluppatore che lavora con qualcosa di più simile a un team AI. Molteplici sistemi specializzati che gestiscono diverse parti del flusso di lavoro con lo sviluppatore che dirige e revisiona piuttosto che produrre ogni output direttamente.
La quarta fase, che sta diventando visibile all'orizzonte, è uno sviluppatore che lavora con un sistema operativo AI. Un'infrastruttura completa che gestisce ricerca, pianificazione, implementazione, test, sicurezza, documentazione e deployment come funzioni integrate con lo sviluppatore che opera come architetto e decisore piuttosto che esecutore.
La maggior parte degli sviluppatori attivi oggi si trova da qualche parte tra la seconda e la terza fase. Il movimento verso la terza fase sta accelerando. La quarta fase non è così lontana come potrebbe sembrare.
La cosa a cui vale davvero la pena prestare attenzione
La maggior parte della conversazione sull'AI in questo momento è focalizzata sulle guerre dei modelli. Claude contro GPT. Open-source contro proprietario. Punteggi di benchmark su valutazioni che potrebbero o meno riflettere le prestazioni nel mondo reale.
Questi dibattiti sono interessanti e non del tutto privi di valore. Ma potrebbero contare molto meno di quanto pensino le persone che li fanno.
La storia più grande è che lo sviluppo software stesso sta diventando agentico. La struttura di come viene costruito il software sta cambiando a un livello fondamentale, non solo diventando più veloce ai margini.
I vincitori in quel mondo non saranno necessariamente gli sviluppatori con accesso al singolo modello più intelligente. Saranno gli sviluppatori che hanno costruito i sistemi più intelligenti intorno a quei modelli. Quelli che hanno capito che la gestione del contesto conta più della capacità grezza del modello. Che la memoria crea vantaggi cumulativi. Che la progettazione del flusso di lavoro è dove risiede la vera leva. Che orchestrare l'intelligenza è un'abilità più preziosa che generare codice.
Claude Code conta come segnale, non solo come strumento. È uno dei primi sguardi più chiari su come appare l'ingegneria del software quando l'intelligenza diventa infrastruttura programmabile piuttosto che una consultazione occasionale.
Una volta che quel cambiamento atterrerà completamente, la domanda non sarà più se l'AI possa scrivere codice. Tutti sanno già che può scrivere codice.
La domanda diventa quanto dell'intero ciclo di vita dello sviluppo software può essere posseduto da sistemi AI ben progettati, diretti da sviluppatori che capiscono come costruirli e gestirli.
La risposta a questa domanda cresce ogni mese. E le persone che stanno costruendo verso quella risposta in questo momento stanno lavorando con un vantaggio che si accumula silenziosamente e diventa molto difficile da colmare una volta che diventa abbastanza grande.
Siamo ancora nei primi capitoli di tutto questo. Le decisioni prese nei prossimi due o tre anni conteranno per molto tempo dopo.
