La crescita degli agenti di coding sta segnando un cambiamento molto più ampio della semplice automazione della programmazione. Le dichiarazioni di Greg Brockman, presidente di OpenAI, fotografano un passaggio ormai evidente: l’intelligenza artificiale applicata al codice non è più soltanto un assistente laterale che suggerisce funzioni, completa righe o accelera il lavoro degli sviluppatori, ma sta diventando uno strato operativo centrale nella produzione software e, progressivamente, anche nel lavoro digitale di persone che non sono programmatori di professione. Secondo quanto riportato da AI Times, Brockman ha indicato che gli strumenti di coding agentico sarebbero passati, nell’arco di pochi mesi, dal generare circa il 20% del codice a coprirne fino all’80%, trasformandosi da supporto accessorio a componente principale del processo di sviluppo.
Il punto più importante non è solo la percentuale in sé, ma il tipo di trasformazione che quella percentuale rappresenta. Nei primi anni degli assistenti di programmazione basati su AI, il modello dominante era quello dell’autocompletamento intelligente: lo sviluppatore scriveva codice, l’AI suggeriva frammenti, funzioni, test o spiegazioni. Con gli agenti di nuova generazione, invece, il rapporto cambia: l’utente descrive un obiettivo, assegna un task, fornisce un contesto di progetto e il sistema può leggere file, modificare codice, eseguire comandi, produrre patch, correggere bug, proporre pull request e lavorare in parallelo su più attività. OpenAI descrive Codex come un agente capace di leggere, modificare ed eseguire codice, operare in ambienti cloud dedicati e lavorare anche in background su task paralleli.
Questa evoluzione sposta il coding da un’attività centrata sulla scrittura manuale a un’attività centrata sulla supervisione, sulla specifica degli obiettivi e sulla revisione dei risultati. Lo sviluppatore non scompare, ma cambia posizione nella catena produttiva: dedica meno tempo alla digitazione diretta di ogni singola implementazione e più tempo alla definizione del comportamento atteso, alla verifica dell’architettura, al controllo della qualità, alla sicurezza, all’integrazione con sistemi esistenti e alla valutazione di ciò che l’agente ha prodotto. In questo senso, l’AI non sta semplicemente “scrivendo codice”; sta comprimendo molte fasi intermedie del ciclo di sviluppo, dalla comprensione del codebase alla generazione di modifiche, dalla costruzione di test alla preparazione di una proposta di merge.
La frase attribuita a Brockman sulla crescita dal 20% all’80% va letta con attenzione tecnica. Non è sempre chiaro se queste percentuali indichino righe di codice finali effettivamente generate dall’AI, codice co-scritto con intervento umano, task di sviluppo completati con forte assistenza del modello o semplice coinvolgimento dell’AI in una parte del processo. Questa distinzione è rilevante, perché dire che un agente ha “scritto” l’80% del codice può significare cose molto diverse: può aver generato l’implementazione iniziale poi corretta da un umano, può aver prodotto boilerplate e test, può aver suggerito refactoring, oppure può aver guidato interi task fino alla proposta di pull request. The Next Web ha sottolineato proprio questa ambiguità interpretativa, osservando che il dato può essere letto sia come quota di codice prodotto sia come misura di coinvolgimento dell’AI nel lavoro di sviluppo.
Anche con questa cautela, il segnale resta molto forte. Quando le aziende iniziano a comunicare sistematicamente che una parte consistente del codice è generata, co-generata o accelerata dall’AI, significa che l’adozione è uscita dalla fase sperimentale. Airbnb, per esempio, ha dichiarato che circa il 60% del codice prodotto dai suoi ingegneri nel primo trimestre del 2026 è stato scritto con l’AI, collegando questo dato a una maggiore velocità di rilascio e iterazione delle funzionalità. Shopify ha indicato che oltre la metà del codice viene ormai scritto con supporto AI, mentre DoorDash ha parlato di una quota vicina ai due terzi, confermando che il fenomeno non riguarda più solo i laboratori di intelligenza artificiale, ma aziende operative con prodotti, clienti, infrastrutture e cicli di rilascio complessi.
Il caso Airbnb è particolarmente significativo perché lega l’uso dell’AI coding a un cambiamento organizzativo. Brian Chesky ha spiegato che l’AI sta modificando il modo in cui l’azienda lavora e ha sostenuto che anche i manager tecnici e di design devono tornare a essere più direttamente coinvolti nel prodotto, arrivando a usare strumenti come Claude Code o a scrivere codice in prima persona. Secondo quanto riportato da AI Times, Chesky ha respinto l’idea di figure manageriali puramente amministrative, sottolineando che in un’organizzazione sempre più potenziata dall’AI non basta coordinare persone senza mantenere un contatto operativo con il lavoro tecnico.
Questa è una delle conseguenze meno superficiali dell’agentic coding. Se la scrittura del codice diventa più automatizzabile, il valore non si concentra più soltanto sulla capacità di produrre sintassi corretta, ma sulla capacità di capire cosa deve essere costruito, perché deve essere costruito, quali compromessi tecnici sono accettabili, quali vincoli di prodotto devono essere rispettati e quali errori l’AI potrebbe introdurre. Il manager tecnico non può più limitarsi a gestire risorse, perché deve essere in grado di giudicare output prodotti da agenti, riconoscere debito tecnico, valutare architetture, leggere patch generate automaticamente e capire quando una soluzione apparentemente funzionante è fragile, ridondante o non sostenibile.
Questo spiega perché gli agenti di coding non sono semplicemente una minaccia o una sostituzione del lavoro degli sviluppatori, ma una redistribuzione delle competenze richieste. Chi sa programmare continuerà ad avere un vantaggio importante, ma dovrà spostare parte della propria attenzione dalla produzione diretta alla direzione del sistema. Chi non è programmatore potrà invece ottenere risultati tecnici prima irraggiungibili, purché sia capace di descrivere con precisione il risultato desiderato, valutare se l’output risponde davvero all’esigenza e lavorare con esperti quando il prodotto deve diventare stabile, sicuro e scalabile. È qui che emerge il concetto di “solopreneur” citato da Brockman: una singola persona, grazie agli agenti, può costruire prototipi, strumenti, servizi digitali e workflow complessi senza dover assumere fin dall’inizio un intero team tecnico.
Il passaggio dal coding per sviluppatori al coding come strumento generale è forse l’aspetto più rilevante della notizia. Brockman ha immaginato un futuro in cui l’utente non dovrà più spiegare al computer ogni singolo passaggio operativo, come aprire un file, copiare un testo, incollarlo altrove, modificare un documento o completare una procedura. L’agente dovrebbe comprendere il contesto, ricostruire l’intento e portare a termine il compito con un livello di autonomia molto più alto. In questa prospettiva, il codice non è più solo il linguaggio degli ingegneri, ma diventa il mezzo con cui il computer esegue attività complesse per chiunque lavori davanti a uno schermo.
La differenza rispetto alle macro, agli script tradizionali o agli strumenti no-code è notevole. Una macro esegue una sequenza predefinita; uno script richiede competenze tecniche; un tool no-code funziona entro blocchi e integrazioni già predisposte. Un agente di coding, invece, può teoricamente analizzare un ambiente, generare il codice necessario, adattarlo al contesto, correggere errori, interagire con strumenti esterni e modificare il proprio piano sulla base dei risultati. Questo crea una forma di automazione molto più flessibile, ma anche più difficile da controllare, perché l’utente non sta più soltanto attivando un flusso statico: sta delegando a un sistema la scelta dei passaggi intermedi.
Da qui nasce la questione della responsabilità umana. Brockman ha precisato che non si tratta di usare questi strumenti in modo cieco, né di rifiutarli per principio: tutto il codice che viene unito in un progetto deve rimanere sotto responsabilità umana. Questo punto è centrale perché separa la generazione dalla governance. Un agente può produrre una patch, ma qualcuno deve decidere se quella patch rispetta gli standard del progetto, se introduce regressioni, se mantiene la sicurezza, se è leggibile, se non aumenta inutilmente la complessità e se non risolve un problema locale creando danni strutturali altrove.
La maturazione dell’agentic coding richiede quindi un’evoluzione dei processi di sviluppo. Non basta aggiungere un agente al repository e misurare quante righe produce. Servono test automatici più robusti, code review più attente, controllo delle dipendenze, analisi statica, scanning di sicurezza, ambienti sandbox, policy sui permessi, tracciabilità dei prompt, log delle azioni compiute dall’agente e criteri chiari per decidere cosa può essere eseguito autonomamente e cosa richiede approvazione umana. OpenAI stessa, parlando della sicurezza operativa di Codex, descrive la necessità di controlli, confini e telemetria per governare agenti capaci di rivedere repository, eseguire comandi e interagire con strumenti di sviluppo.
Il motivo è che il codice generato dall’AI non è automaticamente codice buono. Può essere corretto nella forma ma debole nell’architettura, può superare un test limitato ma fallire su casi marginali, può usare librerie non desiderate, può duplicare logica già esistente, può introdurre vulnerabilità o può produrre soluzioni più verbose del necessario. La ricerca recente sul codice AI in repository reali mostra che il problema non è soltanto teorico: uno studio su oltre 304.000 commit verificati come AI-authored in più di 6.000 repository GitHub ha identificato centinaia di migliaia di issue introdotte, con una quota rilevante di problemi che restano presenti nelle revisioni successive.
Questo non significa che l’AI coding sia inadatto alla produzione, ma che richiede una disciplina diversa. La produttività ottenuta generando rapidamente codice può trasformarsi in debito tecnico se l’organizzazione non aggiorna i propri controlli. Una funzione generata in pochi secondi può richiedere ore di debugging se non è coerente con il modello dati, con le policy di sicurezza o con l’architettura esistente. Una pull request prodotta da un agente può sembrare completa, ma includere assunzioni implicite non documentate. Un test generato automaticamente può confermare il comportamento che il modello ha già implementato, senza verificare davvero il requisito originale. Il vantaggio competitivo non sta quindi solo nell’adozione dello strumento, ma nella capacità di costruire un ciclo di revisione in cui l’AI accelera il lavoro senza abbassare la qualità.
Le dichiarazioni delle grandi aziende hanno anche una componente di comunicazione finanziaria. Quando Airbnb, Shopify, DoorDash o Google parlano della quota di codice generata dall’AI, stanno inviando un messaggio agli investitori: la produttività interna aumenta, i team possono rilasciare più velocemente, l’azienda può mantenere o ampliare la capacità di sviluppo senza far crescere proporzionalmente l’organico. AI Times nota infatti che una parte di queste comunicazioni può essere letta anche come segnale di efficienza operativa verso il mercato, non solo come descrizione tecnica neutrale.
Questa dimensione non va sottovalutata. La percentuale di codice AI è diventata una nuova metrica narrativa della Silicon Valley, quasi una prova pubblica di modernità aziendale. Dire che metà, due terzi o tre quarti del codice sono prodotti con AI significa presentarsi come organizzazione capace di incorporare rapidamente le nuove tecnologie nei processi interni. Ma la metrica è ancora imperfetta: non misura il valore del codice, non misura la qualità del prodotto, non misura il grado di supervisione necessario e non distingue tra codice generato, codice suggerito, codice modificato o codice semplicemente assistito. Per questo la percentuale va interpretata come indicatore di adozione, non come misura completa di produttività reale.
La questione diventa ancora più complessa quando gli agenti escono dall’ambito strettamente ingegneristico. Se un agente come Codex viene concepito non solo per scrivere software, ma per aiutare chiunque lavori al computer, allora la distinzione tra sviluppatore e utente avanzato si assottiglia. Un responsabile marketing potrebbe chiedere un piccolo tool per analizzare campagne, un analista potrebbe generare script per trasformare dataset, un product manager potrebbe costruire prototipi interattivi, un founder potrebbe creare una prima versione funzionante di un servizio. Questo allarga enormemente la platea di persone in grado di produrre artefatti tecnici, ma rende ancora più importante stabilire quando un prototipo può restare personale e quando deve passare attraverso controlli professionali.
L’effetto più probabile non è la scomparsa immediata degli sviluppatori, ma la crescita di una nuova alfabetizzazione tecnica diffusa. In futuro, saper usare un agente di coding potrebbe diventare una competenza simile a saper usare Excel, Word o un motore di ricerca: non tutti diventeranno ingegneri software, ma molte più persone potranno creare automazioni, strumenti e interfacce. La differenza è che, mentre un foglio Excel mal costruito può creare errori gestionali, un agente di coding può generare software che interagisce con API, dati, sistemi aziendali e infrastrutture. La potenza dello strumento rende più alta anche la responsabilità del suo utilizzo.
Per le aziende, il cambiamento organizzativo sarà probabilmente più importante del singolo tool scelto. Codex, Claude Code, Copilot, Cursor, Devin, Jules o altri agenti potranno competere su qualità del modello, integrazione nell’IDE, capacità di ragionamento, autonomia, gestione del contesto e sicurezza, ma il valore dipenderà dal modo in cui vengono inseriti nel processo di sviluppo. Un’organizzazione matura non chiederà semplicemente agli sviluppatori di “usare l’AI”, ma definirà quali task sono adatti agli agenti, quali richiedono revisione obbligatoria, quali repository sono esclusi, quali dati non possono essere esposti, quali metriche osservare e come misurare il rapporto tra velocità, qualità e manutenzione.
Il ruolo dei manager tecnici, in questo scenario, cambia in modo radicale. Non basta più assegnare ticket e controllare lo stato di avanzamento. Bisogna progettare sistemi di lavoro in cui persone e agenti collaborano: task ben descritti, contesti aggiornati, repository leggibili, test affidabili, criteri di accettazione chiari e ambienti in cui l’AI possa operare senza creare danni. Un agente produce risultati migliori quando il progetto è strutturato, documentato e testabile; produce risultati peggiori quando il codebase è caotico, le decisioni architetturali sono implicite e i requisiti cambiano senza traccia. Paradossalmente, l’AI rende ancora più preziose le buone pratiche ingegneristiche, perché sono proprio quelle pratiche a trasformare la generazione automatica in output affidabile.
La prospettiva di Brockman sui “solopreneur” va letta dentro questa cornice. Una persona sola può oggi fare molto più di quanto fosse possibile pochi anni fa, ma non perché l’AI elimini ogni competenza, bensì perché riduce il costo iniziale dell’esecuzione. Il valore si sposta sulla visione, sulla capacità di scegliere bene il problema, sulla definizione del prodotto, sulla distribuzione, sull’esperienza utente e sulla revisione critica. Chi non sa programmare può arrivare più vicino a un prototipo funzionante; chi sa programmare può moltiplicare la propria capacità esecutiva; chi sa progettare sistemi può orchestrare molti agenti contemporaneamente. Il collo di bottiglia diventa sempre meno la scrittura di codice e sempre più la qualità del giudizio umano.
Questo è il punto più profondo della transizione. Quando il codice costa meno da produrre, aumenta la quantità di software possibile, ma non aumenta automaticamente la quantità di buon software. Anzi, il rischio è che crescano prototipi fragili, applicazioni duplicate, sistemi poco mantenibili e automazioni costruite senza piena comprensione delle conseguenze. La scarsità si sposta quindi dalla capacità di generare codice alla capacità di decidere quale codice merita di esistere, quale problema vale la pena risolvere, quale architettura reggerà nel tempo e quali compromessi sono accettabili.
Gli agenti di coding stanno diventando una tecnologia orizzontale, non più confinata allo sviluppo software tradizionale. La loro diffusione dentro aziende come OpenAI, Airbnb, Shopify, DoorDash e Google mostra che il settore sta passando dalla sperimentazione individuale all’integrazione nei processi reali. Questo non rende irrilevante il lavoro umano, ma lo obbliga a spostarsi verso controllo, supervisione, progettazione e responsabilità. Il codice scritto dall’AI può accelerare enormemente lo sviluppo, ma il prodotto finale resta il risultato di decisioni umane: cosa chiedere all’agente, cosa accettare, cosa rifiutare, cosa correggere e cosa mettere in produzione.
Il cambiamento descritto da Brockman è quindi meno una previsione futuristica e più una fotografia di un passaggio già in corso. Il coding agentico sta diventando il nuovo livello di interazione tra persone e computer: non più solo scrivere istruzioni precise, ma delegare obiettivi complessi a sistemi capaci di trasformarli in azioni tecniche. Se questa trasformazione verrà governata bene, potrà aumentare la capacità creativa e produttiva di sviluppatori, manager, founder e professionisti non tecnici. Se verrà adottata solo come scorciatoia quantitativa, rischierà invece di produrre software più veloce ma più fragile. La vera competizione non sarà tra chi usa o non usa gli agenti di coding, ma tra chi saprà usarli come infrastruttura disciplinata di sviluppo e chi li tratterà come generatori automatici di codice senza una responsabilità reale sul risultato.