Moltiplicatore zero: perché il futuro del software non sarà il vibe coding

Il futuro del software non è semplicemente il vibe coding

Ho letto con interesse l’articolo pubblicato su Medium da Tobore, How AI Is Reshaping Software Development and the Tech Industry in 2026, perché fotografa bene qualcosa che ormai chi lavora quotidianamente con sistemi di coding AI fatica persino a considerare una novità, siamo usciti dalla fase nella quale l’Intelligenza Artificiale suggeriva qualche riga dentro un IDE ed abbiamo iniziato quella nella quale può analizzare un repository, modificare decine di file, eseguire programmi, leggere gli errori, scrivere test, correggersi, aprire pull request e portare avanti parti significative di un progetto con un’autonomia che soltanto due o tre anni fa sarebbe sembrata una dimostrazione preparata appositamente per una conferenza. L’articolo raccoglie dati, casi aziendali ed osservazioni che vanno tutti nella stessa direzione, produrre software sta diventando enormemente più veloce, ma proprio quando arriva al vibe coding io prendo una strada differente, perché penso che sotto questa trasformazione ce ne sia una ancora più importante e, a mio parere, molto meno compresa.

Il vibe coding, almeno nella formulazione originaria di Andrej Karpathy del febbraio 2025, è una cosa abbastanza precisa, perché Karpathy descriveva ironicamente un modo di sviluppare nel quale si accettano le modifiche prodotte dal modello senza leggere più davvero i diff, si restituiscono alla macchina gli errori, si continua a chiedere modifiche fino a quando l’applicazione funziona ed il codice finisce progressivamente oltre la comprensione dell’autore, precisando peraltro che l’approccio non era poi così male per progetti usa e getta del fine settimana. Questa precisazione conta parecchio, perché nel giro di pochi mesi il termine è stato allargato fino a diventare quasi sinonimo di sviluppo software mediante AI, quando invece agentic software engineering e vibe coding possono essere quasi opposti, nel primo caso posso delegare alla macchina quantità enormi di lavoro mantenendo specifiche, verifiche, policy, test, separazione dei privilegi e responsabilità architetturale, mentre nel secondo posso arrivare intenzionalmente al punto nel quale il codice cresce oltre la mia stessa comprensione.

Per un prototipo, un esperimento, una pagina realizzata in un pomeriggio oppure quel piccolo programma che serve tre volte e poi finirà dimenticato in una cartella, non ho nulla contro questo approccio, anzi è probabilmente una delle cose più divertenti che l’AI abbia reso possibili. Ma se qualcuno pensa che delegare interamente ad una macchina la realizzazione di un software destinato alla produzione, senza possedere le competenze per comprenderne l’architettura, valutarne la sicurezza e giudicarne le decisioni, costituisca il futuro dell’ingegneria del software, penso che stia confondendo due fenomeni completamente diversi, LA DEMOCRATIZZAZIONE DELLA CAPACITÀ DI PRODURRE CODICE e LA DEMOCRATIZZAZIONE DELLA COMPETENZA INGEGNERISTICA. La prima è già avvenuta, la seconda semplicemente no.

L’AI è un moltiplicatore di expertise

La cosa curiosa è che questa non è soltanto un’impressione maturata lavorando con gli agenti, perché il DORA State of AI-assisted Software Development 2025 di Google descrive l’AI principalmente come un amplificatore, cioè qualcosa che tende ad ingrandire tanto i punti di forza delle organizzazioni efficaci quanto le disfunzioni di quelle che funzionano male, con ritorni che dipendono molto meno dalla semplice presenza dello strumento di quanto dipendano dalla qualità del sistema tecnico ed organizzativo nel quale quello strumento viene inserito. È una formulazione che considero particolarmente importante, perché sposta immediatamente la discussione dal modello alla struttura che lo governa.

Nel giugno 2026 Anthropic ha pubblicato un’analisi su circa 400.000 sessioni reali di Claude Code svolte fra ottobre 2025 ed aprile 2026, ed il risultato, con tutte le cautele che richiede uno studio osservazionale, è quasi didascalico, perché normalmente l’essere umano continua a prendere gran parte delle decisioni relative a CHE COSA debba essere fatto mentre Claude prende gran parte delle decisioni relative a COME farlo, inoltre maggiore è l’expertise che la persona porta nella sessione e maggiore è la quantità di lavoro che l’agente riesce a svolgere utilmente per singola istruzione. Anthropic ha chiamato il fenomeno persistent returns to expertise, rendimenti persistenti dell’esperienza, ed il nome è interessante proprio perché descrive l’opposto della narrazione più ingenua secondo la quale un modello sufficientemente bravo dovrebbe rendere sostanzialmente irrilevante la differenza fra chi conosce profondamente il problema e chi lo sta appena scoprendo.

Ancora più interessante è il lavoro pubblicato su Science nel 2026 da Simone Daniotti e colleghi, che ha applicato un classificatore per individuare codice generato dall’AI a più di 30 milioni di commit prodotti da 160.097 sviluppatori software in sei Paesi, trovando che negli Stati Uniti l’adozione degli strumenti generativi era associata ad un aumento della produttività e ad una maggiore esplorazione di nuove librerie e nuovi domini soprattutto fra gli sviluppatori senior, mentre per gli sviluppatori all’inizio della carriera non emergevano benefici statisticamente significativi comparabili. Questo non significa naturalmente che un principiante non possa utilizzare proficuamente l’AI, e sarebbe scorretto trasformare un risultato osservazionale in una legge universale, ma mette seriamente in crisi l’idea secondo cui l’Intelligenza Artificiale annullerebbe automaticamente il vantaggio dell’esperienza. Potrebbe accadere esattamente il contrario, perché dando a tutti un amplificatore rendiamo ancora più importante ciò che ciascuno mette all’ingresso dell’amplificatore.

Ed è questo il punto che mi interessa, perché l’Intelligenza Artificiale è un moltiplicatore. Se le fornisco una buona architettura può svilupparla ad una velocità impressionante, se le fornisco requisiti chiari può trasformarli in decine di componenti coerenti, se le fornisco una strategia di sicurezza corretta può applicarla disciplinatamente attraverso centinaia di punti dell’applicazione e se conosco profondamente il dominio del cliente posso usare l’AI per trasformare quella conoscenza in software con una produttività che prima sarebbe stata economicamente impossibile. Ma se parto da nessuna competenza il problema diventa quasi aritmetico, naturalmente lo zero non è letterale perché il modello porta con sé una quantità enorme di conoscenza appresa e può insegnare, suggerire, correggere ed in qualche misura compensare alcune lacune dell’utente, ma ciò che può mancare non è la capacità della macchina di scrivere un buon pezzo di codice, è qualcuno capace di sapere SE QUEL CODICE AVREBBE DOVUTO ESISTERE PROPRIO IN QUELLA FORMA.

Un modello può scrivere codice migliore del tuo senza sapere che stai costruendo la cosa sbagliata

Questa è forse la parte che nel dibattito viene sottovalutata maggiormente, perché il problema del software generato dall’AI non è necessariamente la qualità sintattica del software, anzi siamo ormai arrivati a modelli che in moltissime circostanze producono codice eccellente, spesso più ordinato, documentato e consistente di quello scritto velocemente da un essere umano, ma il problema si sposta altrove. Un sistema può implementare perfettamente una pessima specifica, può costruire magnificamente una cattiva architettura, può realizzare con eleganza un requisito che non avrebbe mai dovuto essere approvato, può creare una funzione perfettamente funzionante che viola il modello di autorizzazione dell’applicazione, può applicare in maniera impeccabile la regola sbagliata e, cosa ancora più interessante, può farlo cento volte più velocemente di noi.

Questo significa che l’AI non elimina necessariamente l’errore umano, può invece dargli capacità industriale, perché quando un programmatore sbaglia una funzione talvolta produce un errore locale mentre quando l’essere umano che dirige una software factory agentica sbaglia un principio architetturale e gli agenti lo interpretano correttamente, quell’errore può propagarsi con una coerenza meravigliosa attraverso database, endpoint, interfacce, autorizzazioni, API e test. Una macchina può essere straordinariamente consistente anche nel fare la cosa sbagliata, ed è per questo che considero il vibe coding quasi l’opposto di ciò verso cui dovrebbe tendere lo sviluppo professionale assistito dall’AI, perché non voglio sapere meno di ciò che viene prodotto, voglio produrre enormemente di più aumentando contemporaneamente la capacità di governarlo.

Nel mio laboratorio non ho smesso di programmare, ho spostato il punto nel quale programmo

È sostanzialmente ciò che ho osservato nel mio esperimento con Agentiko, perché per una webapp sufficientemente complessa ho preso volontariamente una decisione abbastanza radicale, non scrivere personalmente codice applicativo lasciando che gli agenti producessero backend, frontend, database, CSS, modifiche e test, mentre io rimanevo nel ciclo come Review Gate, Human-in-the-Loop e soprattutto come autore delle decisioni che precedevano il codice. Apparentemente non programmavo, in realtà programmavo ad un livello differente, decidevo quali informazioni un agente dovesse vedere, quali strumenti gli fossero consentiti, quale parte dell’architettura appartenesse al frontend e quale al backend, stabilivo il modello delle autorizzazioni, i vincoli del database, i criteri di accettazione, il significato funzionale di una schermata, il momento nel quale fermare una modifica e quello nel quale lasciarla proseguire. Quando una funzione era sbagliata, il problema raramente consisteva nello scrivere personalmente la versione corretta, consisteva nel capire PERCHÉ fosse sbagliata e trasformare quel giudizio in un’informazione sufficientemente precisa affinché il sistema correggesse non soltanto quella funzione ma il principio che l’aveva generata.

È una differenza che può sembrare sottile soltanto finché non la si prova, ed OpenAI ha descritto qualcosa di concettualmente molto simile nel proprio esperimento interno pubblicato l’11 febbraio 2026, nel quale un team ha iniziato da un repository Git vuoto ed ha costruito un prodotto con zero righe di codice scritte manualmente, lasciando a Codex codice applicativo, test, configurazione CI, documentazione, osservabilità e tooling, mentre gli esseri umani lavoravano soprattutto sulla struttura dell’ambiente, sulle intenzioni e sui feedback. OpenAI stima che il progetto sia stato realizzato in circa un decimo del tempo necessario scrivendo tutto manualmente e riassume il modello con una formula molto semplice, humans steer, agents execute. Il numero è interessante ma la formula lo è molto di più, perché descrive il passaggio da un mestiere centrato sulla produzione materiale delle righe ad un mestiere nel quale una parte crescente del valore risiede nel progettare l’ambiente entro cui qualcun altro, in questo caso una macchina, può produrle in maniera affidabile.

Questo, per me, è il futuro interessante, non il programmatore che non capisce il codice ma il programmatore che non ha più bisogno di scriverlo tutto personalmente perché ne comprende abbastanza bene la natura da poter dirigere chi lo scrive al posto suo.

Scrivere software e consegnare software non sono la stessa cosa

Esiste poi un dato economico che trovo illuminante, perché un working paper NBER pubblicato nel 2026 ha analizzato più di mezzo milione di sviluppatori GitHub confrontando diverse generazioni di strumenti AI, dall’autocomplete agli agenti interattivi fino agli agenti autonomi, trovando un aumento cumulativo dell’attività di coding pari a circa il 30 per cento con autocomplete, il 180 per cento con gli agenti interattivi ed il 240 per cento con gli agenti autonomi. Ma salendo nella catena produttiva accade qualcosa di molto più interessante, perché quel 240 per cento scende a circa l’80 per cento quando si osserva il numero di progetti ed a circa il 30 per cento quando si osservano le release effettivamente pubblicate. Gli autori interpretano il risultato attraverso una weak-link hypothesis, cioè l’idea che accelerare violentemente una fase non significhi accelerare nella stessa misura l’intero sistema quando le attività complementari svolte dagli esseri umani rimangono colli di bottiglia.

È quasi la dimostrazione econometrica del problema, possiamo produrre molto più codice di quanto riusciamo a comprendere, revisionare, integrare, testare e mettere responsabilmente in produzione, ed è possibile che questa sproporzione diventi uno dei problemi centrali dell’ingegneria del software dei prossimi anni. Il collo di bottiglia non sarà più scrivere, sarà CAPIRE, perché il costo marginale della generazione si sta abbassando ad una velocità impressionante mentre il costo cognitivo della verifica non diminuisce nella stessa misura, e se un agente produce in mezz’ora una quantità di modifiche che prima avrebbe richiesto tre giorni qualcuno deve comunque essere in grado di stabilire se quelle modifiche abbiano senso nel contesto complessivo.

DORA ha descritto una tensione molto simile nel 2026 partendo dai risultati del proprio rapporto 2025, osservando che l’AI accelera la generazione iniziale del codice ma una parte del tempo risparmiato viene frequentemente riassorbita da audit e verifica, quella che viene definita verification tax, mentre una maggiore adozione dell’AI può associarsi contemporaneamente ad un aumento del throughput e ad una maggiore instabilità quando la base tecnica ed organizzativa non è sufficientemente solida. È una conseguenza quasi ovvia una volta che la si guarda dal punto giusto, perché generare più velocemente non significa revisionare più velocemente, integrare più velocemente oppure capire più velocemente. Ed è anche la ragione per cui il numero di righe generate dall’AI mi sembra una metrica abbastanza insignificante, sarebbe come misurare la produttività di una tipografia contando le pagine stampate senza sapere che cosa c’è scritto sopra.

La nuova risorsa scarsa è il giudizio

Per moltissimo tempo il software ha avuto un collo di bottiglia materiale, tradurre un’idea in istruzioni per un computer richiedeva persone capaci di scrivere manualmente migliaia o milioni di righe secondo sintassi precise ed una parte sostanziale del valore economico del programmatore derivava anche da questa rarità. Quella scarsità sta rapidamente diminuendo, perché non è difficile immaginare un mondo nel quale produrre altre diecimila righe di codice costerà praticamente nulla, ma proprio quando una risorsa diventa abbondante il valore economico tende a spostarsi verso ciò che rimane scarso, cioè capire realmente il problema, distinguere un requisito necessario da uno inutile, conoscere il settore nel quale il software verrà utilizzato, prevedere una condizione anomala che il cliente non ha pensato di raccontare, capire perché una struttura dati funzionerà oggi ma diventerà ingestibile fra tre anni, riconoscere una vulnerabilità che non produce alcun errore visibile, sapere quali dati non dovrebbero proprio arrivare al modello, progettare un sistema nel quale il fallimento di un componente non comprometta tutto il resto, dire di no ad una funzionalità richiesta dal cliente perché tecnicamente oppure normativamente pericolosa ed infine mettere il proprio nome professionale dietro una frase che pesa molto più di diecimila righe di codice, QUESTO SISTEMA PUÒ ESSERE MESSO IN PRODUZIONE.

Il codice è soltanto una delle rappresentazioni materiali di tutte queste decisioni, e per anni abbiamo confuso in parte la competenza con la capacità di produrre manualmente quell’artefatto perché non esisteva un altro modo per ottenerlo, mentre adesso questa separazione sta diventando visibile. Ed è filosoficamente interessante, perché ci costringe a domandarci dove risieda davvero la professionalità, nell’esecuzione di un gesto oppure nella capacità di giudicare l’esito di quel gesto?

Il paradosso del non-programmatore che può programmare

Da qui nasce un fenomeno che sarà probabilmente enorme, perché una persona che non ha mai scritto software può oggi descrivere un’applicazione ad un agente ed ottenere qualcosa che funziona davvero, ed è straordinario, ma bisogna capire che cosa significa la parola funziona. Si apre nel browser, salva correttamente alcuni dati, mostra una dashboard, invia una mail oppure supera il test che noi stessi abbiamo chiesto all’AI di scrivere? Sono criteri perfettamente validi per molti esperimenti, ma un sistema informativo reale possiede dimensioni che diventano visibili soprattutto quando qualcosa va storto, come concorrenza, consistenza delle transazioni, race condition, escalation di privilegi, perdita dei dati, rollback, gestione degli errori, idempotenza, disponibilità, osservabilità, audit, privacy, aggiornamenti delle dipendenze, migrazioni dello schema, comportamento sotto carico e recovery dopo un guasto.

Un utente inesperto può non sapere nemmeno che alcune di queste domande esistono, ed una delle caratteristiche più insidiose degli LLM è che possono nascondere perfettamente questa ignoranza producendo qualcosa di estremamente convincente. Il software mediocre prodotto dall’AI non deve necessariamente avere l’aspetto di software mediocre, può essere bellissimo, può funzionare durante una demo, può avere codice apparentemente elegante e può perfino possedere una batteria di test, mentre il problema rimane ciò che nessuno ha pensato di chiedere. Per questo considero sbagliato dire semplicemente che con l’AI tutti diventano programmatori, perché tutti possono diventare PRODUTTORI DI SOFTWARE, non necessariamente ingegneri del software, ed è la stessa differenza che esiste fra possedere una macchina fotografica eccezionale ed essere un fotografo oppure avere accesso ad un sintetizzatore orchestrale e diventare un compositore. Lo strumento comprime enormemente la difficoltà materiale dell’esecuzione, ma non trasferisce automaticamente all’utilizzatore l’intera struttura di conoscenze necessaria per giudicare il risultato.

L’AI abbassa il costo della produzione, non quello della verità

Qui il discorso assume per me una sfumatura quasi filosofica, perché per due secoli l’automazione ha prevalentemente ridotto il costo dell’azione, una macchina industriale poteva produrre cento oggetti nel tempo nel quale un artigiano ne produceva uno, il computer ha fatto la stessa cosa con il calcolo ed ora l’Intelligenza Artificiale sta iniziando a farlo con una parte della produzione cognitiva. Ma produrre una risposta e sapere che quella risposta è corretta sono due problemi diversi, produrre codice e sapere che quel codice è corretto sono due problemi diversi, produrre un progetto e sapere che quel progetto è quello giusto sono due problemi diversi, perché la generazione è diventata improvvisamente economica mentre LA VERITÀ NO.

Il Developer Survey 2026 di Stack Overflow fotografa bene questa frattura, perché circa il 66 per cento degli intervistati utilizza coding assistant o coding agent e, fra chi utilizza questi strumenti, il 73 per cento li usa quotidianamente, ma quando viene chiesto in quali circostanze ci si fidi dell’AI la risposta più comune, indicata dal 48 per cento, è quando posso verificare facilmente l’output, mentre soltanto il 6,6 per cento dichiara di fidarsi dell’AI per molti compiti includendo anche decisioni importanti sul lavoro. Non mi sembra resistenza culturale, mi sembra razionalità, perché l’AI ha reso la produzione talmente veloce che la capacità di verifica sta diventando la vera unità di misura della competenza.

Il vero significato dello Human-in-the-Loop

Per questo trovo spesso riduttivo parlare di Human-in-the-Loop come se l’essere umano fosse semplicemente la persona che deve premere Approva prima che l’agente faccia qualcosa di pericoloso, perché l’essere umano dovrebbe essere il luogo nel quale risiede la responsabilità epistemica del sistema e deve quindi possedere abbastanza conoscenza da poter contestare la macchina. Altrimenti non è un controllo umano, è una cerimonia. Se l’agente propone una migrazione del database ed io non so che cosa sia una transazione, il mio click su Approve non introduce realmente supervisione, se mi presenta un’architettura OAuth e non conosco i modelli di attacco ai quali può essere sottoposta la mia approvazione non aumenta significativamente la sicurezza, se genera diecimila righe e non conosco il linguaggio, il framework, il dominio e le assunzioni fondamentali sulle quali sono costruite non sto revisionando nulla, sto autorizzando, ed è molto diverso.

Per questo le architetture agentiche serie stanno andando verso sandbox, policy di rete, permessi differenziati, telemetria, approvazioni contestuali e separazione degli strumenti. OpenAI descrive nel 2026 esattamente questo tipo di modello per Codex, con attività a basso rischio che possono procedere fluidamente entro confini tecnici definiti ed azioni più rischiose che devono diventare esplicite, essere bloccate, ottenere approvazione oppure lasciare telemetria sufficiente per essere ricostruite ed auditate. Il buon sistema agentico non nasce dal presupposto che il modello sia infallibile, nasce dal presupposto contrario.

Ed ecco perché il problema dei junior diventa molto serio

C’è però una conseguenza meno evidente e molto più preoccupante, perché l’esperienza non nasce spontaneamente ed il senior di oggi è quasi sempre il junior di ieri che per anni ha scritto codice mediocre, corretto bug, seguito colleghi più esperti, fatto errori, letto sistemi mal progettati ed imparato lentamente perché certe cose che sembravano eleganti sulla carta diventavano disastrose in produzione. Se affidiamo proprio quelle attività iniziali all’AI rischiamo di togliere il primo gradino della scala professionale, ed il problema è già abbastanza visibile da meritare attenzione.

Lo Stanford AI Index 2026 registra negli Stati Uniti una contrazione di quasi il 20 per cento dell’occupazione dei software developer fra 22 e 25 anni rispetto al 2024, mentre le fasce più mature mostrano una tenuta migliore. Sarebbe scorretto attribuire automaticamente tutta questa variazione all’AI, perché intervengono ciclo economico, politiche di assunzione, correzioni successive all’espansione del settore e molti altri fattori, ma il segnale diventa più interessante quando lo si mette accanto ai risultati di Science sugli early-career developer ed al quadro del PwC AI Jobs Barometer 2026, secondo il quale nei ruoli entry-level maggiormente esposti all’AI le offerte richiedono molto più frequentemente competenze tradizionalmente associate a profili senior, con le posizioni più esposte sette volte più propense a richiedere capacità come giudizio, leadership e competenze umane di livello superiore.

PwC distingue inoltre fra lavori democratizzati dall’AI, nei quali lo strumento rende più accessibile l’attività anche ai non esperti, e lavori professionalizzati, nei quali l’AI funziona soprattutto come moltiplicatore dell’esperto e rende ancora più importante il giudizio umano, osservando che questi ultimi stanno mostrando una crescita più forte. Ed ecco il paradosso, perché il mercato potrebbe chiedere ai giovani di possedere prima l’esperienza che un tempo acquisivano svolgendo precisamente i lavori che il mercato sta iniziando ad automatizzare. La domanda quindi non è soltanto quanti junior verranno assunti, è COME PRODURREMO I SENIOR DEL 2040.

La scuola non deve insegnare il vibe coding

Ed è qui che considero sbagliata tanto la scuola che proibisce l’AI quanto quella che pensa di innovare mettendo semplicemente un chatbot davanti agli studenti, perché la scuola dovrebbe insegnare l’opposto del vibe coding, dovrebbe insegnare a non accettare ciecamente, a chiedere perché ed a fornire esattamente quelle conoscenze che consentiranno un giorno allo studente di contestare la macchina. Il framework per l’AI literacy pubblicato nel giugno 2026 da OCSE e Commissione europea va precisamente in questa direzione, perché definisce l’alfabetizzazione all’AI attraverso conoscenze, competenze ed atteggiamenti che permettono di comprendere come funzionano questi sistemi, valutarne criticamente gli output ed usarli in maniera responsabile, etica e creativa.

In un istituto tecnico continuerei quindi ad insegnare programmazione manuale, non perché penso che nel 2035 migliaia di aziende cercheranno persone da pagare otto ore al giorno per battere sintassi che una macchina produrrà in pochi secondi, ma perché è difficile controllare ciò che non si comprende. Prima insegnerei allo studente che cosa sia una variabile, una funzione, una struttura dati, una query, una transazione, un protocollo, un processo concorrente ed un modello di autorizzazione, gli farei scrivere codice, sbagliare, eseguire debugger e risolvere errori, poi gli darei gli agenti e gli chiederei di costruire dieci volte tanto. A quel punto la valutazione non dovrebbe più essere soltanto «funziona?», dovrebbe diventare «perché hai scelto questa architettura, quali permessi hai concesso all’agente, quali parti hai verificato, come hai dimostrato che questa funzione è corretta, che cosa succede se il database non risponde, quali test non hai fatto scrivere all’AI, quale decisione del modello hai rifiutato e perché?». Lo studente che sa rispondere a queste domande può utilizzare un agente, quello che non sa rispondere possiede soltanto un potentissimo generatore di cose che non comprende.

Il codice sta diventando una commodity, la responsabilità no

Penso quindi che nei prossimi anni assisteremo ad una progressiva svalutazione economica della mera produzione meccanica del codice, e questo non significa che il software varrà meno, probabilmente ne verrà prodotto enormemente di più, significa però che sarà sempre più difficile vendere come competenza rara l’attività di tradurre requisiti sufficientemente chiari in implementazioni standard, perché quello è precisamente il genere di trasformazione nel quale i modelli stanno diventando formidabili. Il valore si sposterà a monte ed a valle, a monte nel capire il problema ed a valle nel verificare il risultato, mentre in mezzo ci sarà una quantità crescente di lavoro svolto dalle macchine.

Il professionista prezioso non sarà necessariamente quello che conosce a memoria più funzioni di una libreria, potrebbe essere il programmatore con enorme conoscenza del settore logistico, il sistemista che comprende veramente sicurezza ed infrastruttura, il medico che sa progettare il workflow nel quale l’AI può essere utilizzata senza trasformarsi nel decisore clinico, l’avvocato che sa costruire verifiche documentali oppure il commercialista che comprende talmente bene un processo amministrativo da riuscire a formalizzarlo in una catena di agenti controllabili. La competenza verticale diventa il carburante, l’AI diventa il motore, ed è anche il motivo per cui l’idea di un mondo popolato da prompt engineer generici mi ha sempre convinto poco, perché il prompt in sé è una tecnologia transitoria mentre la capacità di sapere che cosa chiedere, come verificare ciò che viene restituito e quali conseguenze produce quella risposta appartiene al dominio della competenza.

Gli ultimi amanuensi e i primi direttori d’orchestra

Naturalmente esisterà anche l’errore opposto, perché ci saranno programmatori eccellenti che rifiuteranno questi strumenti per orgoglio professionale continuando a considerare autentico soltanto il codice battuto personalmente sulla tastiera, e li capisco persino perché esiste qualcosa di profondamente gratificante nel costruire personalmente un sistema, conoscere ogni funzione, vedere crescere l’applicazione riga dopo riga e sapere di esserne direttamente l’autore. Ma il mercato raramente remunera a lungo un metodo produttivo soltanto perché possiede fascino artigianale, e se un professionista riesce a produrre in undici giorni ciò che prima richiedeva mesi mantenendo qualità, controllo e responsabilità comparabili sarà difficile sostenere indefinitamente che il valore professionale consista nel numero di caratteri digitati personalmente.

Gli ultimi amanuensi potranno continuare a realizzare manoscritti magnifici, il problema è che nel frattempo qualcuno avrà inventato la stampa, ma esiste anche l’errore speculare e forse ancora più pericoloso, pensare che l’invenzione della stampa trasformi automaticamente tutti in scrittori. È precisamente qui che colloco il vibe coding, perché l’AI ha inventato una macchina straordinaria per produrre software ma non ha reso inutile sapere che cosa sia il buon software, anzi ha reso questa conoscenza ancora più preziosa.

Il vero cambiamento non è chi scrive il codice

Per molto tempo abbiamo identificato il programmatore con un gesto fisico, qualcuno seduto davanti ad una tastiera che traduce pensieri in istruzioni formali, ed è probabile che questa immagine stia diventando storica, ma sarebbe un errore concludere che stia scomparendo il programmatore, perché sta cambiando il punto nel quale esercita la propria competenza. Prima doveva dire alla macchina esattamente COME fare ogni cosa, oggi può iniziare a dirle soprattutto CHE COSA deve ottenere e dentro quali confini, domani potrebbe dirigere decine di agenti specializzati senza scrivere personalmente quasi nessuna delle righe che finiranno in produzione, ma qualcuno dovrà continuare a capire il sistema, qualcuno dovrà conoscere abbastanza bene la materia da accorgersi quando cinquanta agenti perfettamente coordinati stanno correndo nella direzione sbagliata, qualcuno dovrà stabilire che un requisito è pericoloso prima ancora che venga trasformato in codice e qualcuno dovrà assumersi la responsabilità dell’artefatto finale.

Ed è forse proprio questa la trasformazione più profonda prodotta dall’Intelligenza Artificiale nel lavoro intellettuale, SEPARARE SEMPRE DI PIÙ L’ESECUZIONE DALLA COMPETENZA, perché per secoli le due cose sono state quasi inseparabili in quanto l’esperto era anche colui che materialmente produceva l’opera, mentre adesso possiamo iniziare ad avere opere quasi interamente prodotte da macchine sotto la direzione di qualcuno che possiede la conoscenza necessaria a giudicarle. Non significa che l’expertise stia scomparendo, significa che non possiamo più misurarla contando quanto lavoro materiale una persona abbia eseguito personalmente, ed è per questo che non credo che il futuro appartenga al vibe coder che non legge più il codice, penso appartenga esattamente al suo contrario, a chi potrà permettersi di non scrivere quasi più codice proprio perché, dopo averlo scritto e capito per anni, saprà riconoscere in pochi minuti se quello prodotto da una macchina è buono, sbagliato, pericoloso oppure semplicemente inutile.

L’Intelligenza Artificiale è un moltiplicatore, e come tutti i moltiplicatori rende gigantesco ciò che gli mettiamo davanti, competenza compresa, ignoranza compresa!