L'inglese invece del codice

Un linguaggio inventato perché i programmatori non servissero più ha generato una professione che è viva ancora oggi ed è pagata piuttosto bene, mentre un altro linguaggio è stato chiamato «inglese strutturato» e si pensava che potesse scriverlo qualunque contabile, e anche quello ha generato una nuova specializzazione con la sua bella forbice salariale. E poi ci fu il tentativo di arrivare alla «programmazione senza programmatori entro il duemila», che diede anch'esso il risultato opposto.

Credo che abbiate riconosciuto il COBOL, che ancora oggi viene usato quotidianamente in produzione e, secondo varie stime, sta dietro all'80% delle normali transazioni bancarie (quelle dei negozi), mentre la sua base di codice arriva a un paio di centinaia di miliardi di righe e continua a dare da mangiare a decine, se non centinaia, di migliaia di sviluppatori. Però, se si scava in questi bei numeri, quasi tutti risalgono a un unico sondaggio di fine anni novanta, poi riestrapolato all'infinito sul mondo intero, quindi è più onesto considerarli un ordine di grandezza e non dati precisi.

L'SQL ha generato la casta particolare dei DBA (Database Administrators) e dei Data Engineer, e oggi una persona che scrive «query semplici» può facilmente guadagnare come un mid, mentre il linguaggio stesso è diventato così complesso che i dialetti moderni (PostgreSQL, Oracle) sono linguaggi di programmazione a tutti gli effetti, con logica procedurale, in cui si può scrivere qualsiasi cosa, da un generatore di frattali a un motore di gioco.

La famiglia dei 4GL si è rivelata una «gabbia dorata» e funzionava benissimo finché bisognava fare la tipica form di «input-output», ma appena serviva una logica di business fuori standard o un'integrazione con un servizio esterno, lo strumento sbatteva contro i propri limiti e i programmatori dovevano aggiungere «stampelle» in linguaggi di basso livello, il che trasformava lo sviluppo in un cocktail infernale di design visuale e hack sporchi. E invece di far scomparire i programmatori, i 4GL hanno creato gli «architetti dei sistemi aziendali» che (per esempio SAP ABAP) sono diventati specialisti incredibilmente costosi, e nemmeno loro hanno eliminato la programmazione: l'hanno semplicemente spostata dalla zona dei «linguaggi universali» a quella degli «strumenti costosi e capricciosi» che legano l'azienda a un fornitore specifico.

Ogni dieci-quindici anni l'industria annuncia solennemente che non ci sarà più bisogno di scrivere codice a mano, vendendo un nuovo modo di «spiegare il compito alla macchina in normale linguaggio umano». E ogni volta, qualche anno dopo, si scopre che i programmatori non sono diminuiti ma aumentati, solo che ora si chiamano in un altro modo. Immagino che adesso stiamo vivendo l'ennesimo giro di questo ciclo, e che il nuovo nome per queste persone sarà vibe coder, e credo che questo strumento sia destinato alla stessa sorte dei tentativi precedenti.

L'idea di «parlare con la macchina in linguaggio umano» è più antica del concetto stesso di computer, ne è piena la fantascienza della prima metà del ventesimo secolo, dal «Metropolis» di Fritz Lang, che tra poco compirà cent'anni, con il suo doppio meccanico dell'essere umano, fino ai racconti in cui alla macchina si danno ordini a voce e lei li esegue obbediente. Ma appena negli anni quaranta comparvero le vere macchine di calcolo, si scoprì che il problema non è la macchina.

Konrad Zuse, che costruì lo Z3 nel quarantuno e inventò uno dei primi linguaggi di alto livello (Plankalkül), formulò il problema così: «non è tanto pericoloso che i computer diventino come gli uomini, quanto che gli uomini diventino come i computer». Molti sviluppatori che conosco considerano seriamente i linguaggi di programmazione una semplice versione peggiore dell'inglese, non starò a discutere con loro... Non è una «brutta versione dell'inglese», è uno strumento con proprietà radicalmente diverse, non peggiore del linguaggio naturale e non migliore, semplicemente parla di un'altra cosa.

Cosa fa davvero un linguaggio di programmazione

Cosa significa per un contabile la frase «calcola i premi trimestrali ai dipendenti»? All'inizio della mia carriera sono capitato in una piccola ditta che generava entropia in questo mondo scrivendo qualcosa tipo un motore 1C per il calcolo degli stipendi, quindi questa palude l'ho toccata un po'. A una persona in carne e ossa quella frase bastava per ricostruire decine di valori impliciti: a chi esattamente accreditare, con quale formula, cosa fare con chi è arrivato a metà trimestre, cosa con i licenziati, se arrotondare e in quale direzione, in quale valuta, cosa fare se di una persona non ci sono dati per niente. Il linguaggio naturale funziona proprio perché chi ascolta tappa quei buchi con il contesto, il buon senso e le conoscenze generali, di cui ha in abbondanza, perché lavora in quel settore.

Un programma, proprio un programma, il codice... così non sa fare. Ognuna di quelle decisioni deve essere fissata da qualche parte, sostenuta, scritta come procedura, altrimenti il risultato viene non deterministico, e una contabilità non deterministica non è più contabilità ma un buon motivo per una chiacchierata con il fisco. E spesso nemmeno i contabili esperti riuscivano a tenere conto di tutto subito, perciò una breve frase in linguaggio naturale si dispiega in qualcosa del genere:

«calcola i premi trimestrali»
    ▼
- quale trimestre esattamente (di calendario? fiscale? dalla data di assunzione?)
- chi rientra nel calcolo (dipendenti? part-time? licenziati a metà?)
- la base di calcolo (stipendio base? base + straordinari? media del periodo?)
- la formula (una percentuale? una cifra fissa? una scala progressiva?)
- la proporzione per un trimestre incompleto (per giorni? per mesi? nessuna?)
- l'arrotondamento (matematico? per difetto? al rublo? al copeco?)
- valuta e cambio (a quale data prendiamo il cambio?)
- dati mancanti (saltare? contare zero? fallire con un errore?)

Otto altre domande da una sola, e qui ho fatto anche il pigro, e ogni domanda genera altre domande, e quando una domanda smette di generarne altre, allora si può descrivere nei termini dei linguaggi di programmazione.

Un linguaggio di programmazione esiste non malgrado questa noiosa precisione ma proprio per essa, perché fornisce una sintassi in cui l'ambiguità è fisicamente inesprimibile e una semantica in cui lo stesso programma significa sempre la stessa cosa. Il programmatore che «traduce» il desiderio del manager e del contabile in codice in realtà non è occupato a tradurre le specifiche in codice, ma prende in carico quelle otto o più domande e si assume la responsabilità delle risposte.

Basta dirlo a parole...

non funziona. Ci sono ragioni per cui il «linguaggio naturale invece del codice» sbatte contro un tetto, e riguardano noi... gli umani, non i tool, i compilatori, le librerie standard o i limiti dei linguaggi di programmazione esistenti, e la principale è l'ineliminabile ambiguità dei linguaggi naturali.

Cosa fareste se vi chiedessero di «cancellare tutti i file più vecchi di 30 giorni in questa cartella»? Molto probabilmente selezionereste i file per data di modifica e li cancellereste... sembra un'azione semplice, ma con la vostra esperienza avete appena risposto al 90% delle sottodomande. E quelle sottodomande non sono affatto poche, se si comincia a formalizzare la domanda di base:

— Più vecchi per data di creazione o per data di modifica?
— Le sottocartelle e i file al loro interno li tocchiamo?
— E i file nascosti li cancelliamo?
— E i symlink: cancelliamo il link o il file stesso?
... e così via

Per togliere l'ambiguità bisogna o fare un mucchio di domande di chiarimento e con questo scrivere di fatto la specifica (il codice del programma) a parole, oppure prendere le decisioni al posto di chi ha chiesto e magari fare non quello che voleva. I linguaggi di programmazione risolvono le sottodomande che emergono con la logica bruta, perché ogni costrutto ha esattamente un solo significato, e mtime non diventerà mai all'improvviso ctime.

Ma anche avendo risposto con precisione a tutte le domande e alle domande collegate, sbattiamo contro il teorema di Rice, un trattato matematico piuttosto noioso del 1953 con un corollario pratico poco allegro per noi umani, che suona così: nessuna proprietà semantica non banale di un programma può essere verificata algoritmicamente nel caso generale. Cioè non si può garantire automaticamente che il codice generato faccia esattamente quello che è stato chiesto, e quindi qualcuno deve controllare cosa è venuto fuori. E per controllare bisogna leggere il codice, e per leggere il codice serve un linguaggio formale. Il cerchio si è chiuso.

Indirettamente salta fuori un'altra proprietà, che non riguarda più Rice ma il linguaggio naturale stesso. Più complessa è la composizione che vogliamo costruire, peggio si adatta alle parole. Detto in parole povere, una piccola funzione si può descrivere a parole, e viene anche piuttosto bene e chiara, ma un sistema da un milione di righe a parole non si può descrivere, e non è che manchino le parole: il linguaggio naturale semplicemente non si compone, e il significato può sovrapporsi, scorrere da una frase all'altra o dipendere dalle frasi vicine, catturando paragrafi e a volte porzioni ancora più grandi dell'opera.

Adesso arriva un blocco difficile, lo nasconderò sotto uno spoiler, e se la linguistica non vi prende potete scorrere fino alla sezione successiva: il concetto viene ripetuto lì attraverso cose e confronti comprensibili a uno sviluppatore.

Ma se vi interessa da dove nasce in generale questa «irriducibilità alle parole», l'hanno descritta da tempo e in dettaglio i linguisti, molto prima di qualunque IA. Hanno provato a scrivere e calcolare formalmente il significato di una normale frase umana e hanno scoperto che il significato di una frase non si può calcolare guardando solo la frase stessa. Nessun testo in linguaggio naturale può essere trasposto così com'è in altre forme di rappresentazione senza perdere il contesto o il significato di singole parti. Il processo di trasposizione richiede un certo lavoro di suddivisione del contesto comune in parti, una valutazione della complessità essenziale del compito (essential complexity).

In questo stato si trova il programmatore prima di scrivere qualunque codice, e si chiama... rullo di tamburi... paralisi analitica (a volte lo chiamano anche stupore di Brooks, come processo di superamento di quella stessa essential complexity). Su questo stato inciampa sia l'idea di «basta dirlo alla macchina a parole» sia il calato dall'alto «ecco le specifiche a parole, scrivi il programma in...», perciò vale la pena dare un'occhiata a cosa è stato scavato in quarant'anni.

Su Rice, Kamp e la DRT

Ma il linguaggio naturale ha un'altra disgrazia, e questa non riguarda più Rice. Le frasi stesse possono essere costruite illogicamente, triplicate, sbavate e inventate a rovescio, storte e ingarbugliate, cucite alla rinfusa e intrecciate di traverso, così che i sentieri in quel giardino di parole non sono uno solo, ma quelli che ci sono si biforcano in mezzo alla frase, e voi lo capite solo arrivando alla fine, o addirittura rileggendo dall'inizio. Non che io sia stato un grande linguista, ma alla fine degli anni dieci mi è toccato completare un filtro per le parolacce in una delle nostre app, e nella grande e potente lingua russa si poteva mandare qualcuno a quel paese in modi davvero molto diversi, così ho dovuto toccare un po' anche questo tema. Ma torniamo alle nostre pecore... cioè alle parole.

Finché parliamo con frasi piccole tipo «cancella il file», va tutto bene: la frase sta interamente in testa e non si trascina dietro una coda di contesto. Ma appena si prova a descrivere a parole qualcosa di più complicato, si scopre che le parole cominciano a «darsi fastidio» o a «dipendere l'una dall'altra» attraverso i confini delle frasi, mentre una variabile in un normale linguaggio di programmazione deve dipendere solo dal contesto preciso in cui viene usata.

La frase classica «ogni contadino che ha un asino lo picchia» è comprensibile a qualunque parlante italiano e di solito si legge senza inciampi. E ora provate a spezzarla in parti conservando il significato di ogni parte separatamente, come fa il compilatore con un'espressione.

«Che ha un asino» ora afferma soltanto l'esistenza di un asino presso un certo contadino, mentre «lo picchia», separato da tutto il resto, non fa capire proprio chi venga picchiato, perché quel «lo» compare dopo che l'«asino» ha già fatto la sua comparsa ed è formalmente uscito dall'area di visibilità.

L'uomo non lo nota, perché tiene in testa l'intero pezzo e costruisce quel legame al volo, mentre una funzione che calcola il significato della frase pezzo per pezzo da sinistra a destra, come fa qualunque normale parser, o si rompe, o diventa così complessa che non si parla nemmeno più della sua applicazione pratica.

Per un programmatore sarebbe una variabile dichiarata dentro una funzione e visibile anche in quella successiva, senza passaggio esplicito e senza global, perché da qualche parte si è agganciato il contesto d'uso. Nessun linguaggio permette una cosa così, e gli scope sono stati inventati proprio perché ciò fosse impossibile by design, mentre il linguaggio naturale vive solo di questo: il suo «asino» filtra attraverso il confine della frase, e questo è considerato comportamento normale.

La fuga di contesto l'hanno descritta i linguisti molto prima di qualunque IA: Hans Kamp all'inizio degli anni ottanta nel lavoro sulle semantiche dinamiche e quasi contemporaneamente Irene Heim nella tesi sulla file change semantics, entrambi indipendentemente sono sbattuti contro il fatto che il significato di una frase non si può calcolare senza portarsi dietro quello che è stato detto prima.

Così è nata la teoria della rappresentazione del discorso, la DRT, la cui unica conclusione pratica per noi programmatori suona noiosa e inapplicabile, perché nel suo «habitat naturale» lui lavora fuori dalla DRT. Non si può garantire formalmente che un pezzo di testo si possa capire isolatamente dai pezzi vicini, e quindi non si può nemmeno pretendere dal linguaggio con cui spiegate un compito alla macchina che si comporti come codice rimanendo linguaggio naturale.

L'habitat naturale del programmatore è il Codice, e il Codice è immune da questa malattia, e la chiamata calculateAge(1985, 2026) significa una sola e identica cosa, sia che la infiliate in un game loop sia in un report per il fisco, e dietro di essa non si trascina una coda invisibile di righe precedenti che ne cambiano il senso.

E il compito del programmatore è assemblare un Grande Sistema da pezzi indipendenti, e questo è possibile solo se i pezzi non cambiano il proprio significato in base a dove li si mette, e il linguaggio naturale non ne è capace per principio: lo stato di una piccola frase gli deriva dalla dimensione del contesto in cui l'hanno ficcata. Difficilmente piacerebbe a qualcuno se il risultato di sum(a + b) di colpo cominciasse a dipendere dalla lunghezza della funzione chiamante.

Spero di non avervi stancato troppo con questo discorso?

Questo l'hanno già provato. E più di una volta...

La storia conosce diversi assalti importanti al tema «liberiamoci dei programmatori con un linguaggio vicino all'inglese». È divertente che ognuno di essi abbia dato lo stesso effetto collaterale: i vecchi programmatori restavano, ma nascevano nuove specializzazioni, dando lavoro a una nuova generazione di programmatori.

Il COBOL (1959) fu creato con l'obiettivo di dare a manager e analisti di business la possibilità di leggere e scrivere programmi. Per questo la sintassi fu resa appositamente simile alle frasi inglesi, ADD SALARY TO TOTAL GIVING NEW-TOTAL si legge come una frase quasi normale, beh, normale per loro nelle Americhe. Il risultato è stata la professione del programmatore COBOL, viva ancora oggi e su cui gira ancora una fetta considerevole dei sistemi bancari e statali, come ho detto all'inizio dell'articolo. E i manager, cosa caratteristica, non hanno mai iniziato a scriverci, e hanno continuato a scrivere report a mano, in Word, sotto forma di tabelle e schemi, e a distribuire compiti, adesso agli sviluppatori COBOL.

Poi arrivò l'epoca dell'SQL (1974), che inizialmente si chiamava SEQUEL, cioè Structured English Query Language, e si chiamava così proprio perché doveva permettere alle persone non tecniche di porre domande al «programma» in un quasi-inglese. Più tardi fu rinominato SQL per motivi pubblicitari e di soldi, ma l'intento dell'«inglese per le query» è rimasto cucito dentro il nome. Oggi lo sviluppatore SQL è una professione a parte, e la «persona non tecnica, il manager» che incontra una LEFT JOIN con tre subquery e una funzione finestra di solito va a cercarsi un tecnico che capisca questo costrutto a tre piani, grande e potente.

Poi ci furono i 4GL e i CASE (Computer-Aided Software Engineering, anni ottanta), considerati linguaggi di quarta generazione, i «linguaggi di programmazione naturali», e di nuovo promettevano la «programmazione senza programmatori». La pubblicità usciva da ogni ferro da stiro ed era così potente che alla fine degli anni ottanta molti temevano davvero l'effetto degli uffici vuoti, con la maggior parte delle applicazioni creata senza scrivere codice e gli sviluppatori in fila verso la «cassa libera». Ma di nuovo, entro il duemila l'industria non solo non si era liberata dei programmatori, ma si era dotata di un'intera schiera di nuovi specialisti altamente pagati di SAP, Oracle e framework proprietari.

Si è scoperto che la «naturalezza» dei sistemi 4GL era la stessa illusione del COBOL e dell'SQL prima di lui, che nascondeva solo dietro una facciata di blocchi visuali una mostruosa complessità di configurazione e un comportamento imprevedibile del sistema. Più gli strumenti CASE provavano ad automatizzare la scrittura del codice, più tempo i programmatori passavano a combattere con i limiti di quegli stessi strumenti, trasformandosi da creatori di logica in «architetti delle integrazioni di sistema», e alla fine, invece della scomparsa degli sviluppatori, abbiamo avuto la loro carenza, mentre la «programmazione senza programmatori» si è semplicemente trasferita su un altro piano, dove ora, invece di scrivere codice in C++ o Pascal, bisogna imparare a capire la «conoscenza segreta» di un fornitore specifico, trasformando il costruttore visuale nell'ennesimo strumento di programmazione, magari molto costoso.

Davvero costoso, perché lo stipendio di un normale sviluppatore SAP vola facilmente oltre i 100k$ più la formazione più gli esami annuali, e sopra a questo ci sono corsi da Xk$ e la riqualificazione annuale obbligatoria, senza la quale il certificato semplicemente scade, e tutto ciò è legato all'abbonamento a pagamento del fornitore stesso.

Poi arrivò il turno dell'UML e della Model-Driven Architecture (anni novanta e duemila) con la bella idea di disegnare diagrammi che avrebbero generato il codice. In pratica l'UML è sopravvissuto come strumento di documentazione e schema per gli sviluppatori, che poi il codice lo scrivono comunque a mano, e a volte disegnano i diagrammi sul codice già scritto, cosa che in qualche modo la dice lunga. Poi nell'UML di soldi ce n'erano molti meno, e le persone che vendevano Model-Driven Architecture all'inizio degli anni dieci si sono spostate in massa verso startup e ditte No-Code e Low-Code di ogni tipo e dimensione, cosa che anche questa la dice lunga.

Bubble, Webflow, OutSystems, Mendix hanno iniziato a vendere a chiunque volesse la formula «ora qualunque azienda si assembla l'applicazione da sé», e in pratica si è ridotto a compiti tipici, form, interfacce CRUD e automazioni, con i propri formatori, scuole, strumenti e supporto. Ma di nuovo, appena serve una logica fuori standard, un'integrazione o le prestazioni, tocca costruire stampelle di blocchi dentro la piattaforma, oppure assumere uno sviluppatore che conosca proprio quella piattaforma e sappia scrivere codice «normale» in C++/Java/Swift/scegliete il vostro. Cioè è comparsa, sorpresa... un'altra specializzazione. Si è scoperto che l'industria che vendeva il sogno «non vi serve più uno sviluppatore», per un piccolo guadagno vende in parallelo il certificato «sono uno sviluppatore per questa cosa». È arrivato il turno degli LLM...

Voi siete qui, e questa è qualitativamente diversa dalle precedenti, perché per la prima volta lo strumento ha iniziato a lavorare con linguaggio naturale arbitrario e non con un DSL limitato fatto di blocchi, schemi, parole speciali. È un salto molto grande, paragonabile a COBOL/SQL/UML e agli altri, e qui lo dico senza alcuna ironia. Ma i limiti fondamentali dell'ambiguità, della verificabilità e della riproducibilità non sono andati da nessuna parte, perché non riguardano lo strumento ma la natura del compito. Qualcuno deve comunque formulare il compito, formularlo con precisione e in piccole porzioni, leggere il codice generato e rispondere di quello che quel codice farà in produzione alle tre di notte.

Se vi girate a guardare questo elenco, vedrete che ogni onda ha davvero ucciso qualche strato di lavoro manuale, ma ogni onda ha anche creato un nuovo strato di lavoro sopra di sé.

Il paradosso di Jevons

Nel 1865 William Stanley Jevons notò che più le macchine a vapore diventavano efficienti e meno carbone serviva a ognuna per produrre un'unità di lavoro, più carbone si finiva per consumare complessivamente, perché l'unità di lavoro diventata più economica aprì così tante nuove applicazioni che il volume totale di lavoro necessario crebbe.

Ogni volta che uno strumento rende più economico scrivere codice, la domanda di software cresce più in fretta di quanto scenda il costo della sua produzione. Così il numero di programmatori è passato da qualche migliaio all'inizio degli anni cinquanta a centinaia di migliaia negli anni novanta, milioni negli anni duemila e decine di milioni oggi, e questo nonostante il fatto che uno sviluppatore moderno con framework, IDE, package manager e ricerca...

A volte per errore sforni in un giorno quanto il suo collega del secolo scorso scriveva in giorni e mesi, perché la produttività del programmatore medio è cresciuta di ordini di grandezza, e anche il suo carico di lavoro è cresciuto, perché il codice economico ha reso convenienti progetti che prima nessuno avrebbe iniziato. Quindi se il vostro intuito vi suggerisce «lo strumento fa il lavoro al posto mio, quindi il lavoro diminuirà», Jevons ha per voi delle brutte notizie, che hanno centosessant'anni.

Cosa cambia davvero

Da tutto quello che ho detto non segue però che non cambi niente — cambia, e piuttosto tanto, solo non nella direzione che vediamo. Se ne va il fondo del mercato, il codice standard, i semplici sistemi CRUD, il markup e la generazione di boilerplate, tutto quel lavoro in cui la soluzione è già nota e va solo battuta a macchina. Qui le reti neurali sono davvero brave.

Ma cresce l'alto: la progettazione dei sistemi, la comprensione del dominio, il debug, l'ottimizzazione delle prestazioni (una delle aree in cui anche l'onnipotente Claude galleggia come un'ascia e sforna claudate di merda, non fai che rifiutare commit), la sicurezza e l'inserimento di componenti in sistemi che sono obbligati a funzionare in modo prevedibile. Qualcuno dovrà pur controllare cosa ha generato col generatore il generatore del generatore, no? E questo qualcuno deve capire il Sistema, no, già nemmeno più il Codice... più a fondo di chi lo ha generato, perché chi lo ha generato sbatte contro il teorema di Rice e i lavori di Kamp.

Si può dire che il confine di «cosa sa fare la macchina» si sposta, e in fretta, ma il confine di «cosa serve al business» si sposta ancora più in fretta. I programmatori in questo ambiente non scompaiono, ma cambia la composizione del loro lavoro: ora bisogna battere meno a macchina, pensare di più, e rispondere come prima di tutto.

La programmazione è immortale?

A tenere a galla i linguaggi di programmazione non è la sintassi, non le abitudini dello sviluppatore né la resistenza dell'industria ai cambiamenti, anche se di resistenza ce n'è in abbondanza. I linguaggi di programmazione risolvono un compito per il quale il linguaggio naturale (in qualunque strumento lo si avvolga) in linea di principio non è adatto, né sotto forma di schemi, né di file md o piani, né di dialogo con Claude. Un linguaggio di programmazione descrive in modo univoco il comportamento di sistemi che sono obbligati a funzionare in modo prevedibile.

Finché esistono sistemi per i quali «più o meno giusto» significa perdita di profitto, di tempo o un danno, e sono più o meno tutte le banche, tutta la medicina, tutta l'aviazione e forse la maggior parte delle normali aziende, servirà un modo formale di descrivere cosa esattamente devono fare. Questo modo formale è appunto il linguaggio di programmazione, qualunque aspetto abbia nel 2050, sia come testo, sia come voce, sia come pensiero direttamente dalla testa.

Una macchina che accetta «voglio un milione di dollari» e lo esegue magicamente è ancora una trama fantascientifica dell'inizio del secolo scorso e non una realtà ingegneristica, perché qualcuno dovrà dire alla macchina da dove vengono quei soldi, in quale valuta, su quale conto trasferirli e cosa fare se al posto dei soldi si presentano dei ragazzi in giacca corta. Questo qualcuno è appunto il programmatore, tranne che nel caso dei ragazzi, indipendentemente dal fatto che batta transfer(amount, account) a mano, chiacchieri con un bot o detti a voce a un assistente.

Vi sto portando alla conclusione su quello che è sempre stato la base della professione del programmatore. Il vibe coding non ha eliminato la necessità di formulare il compito con precisione, ha solo spostato il momento in cui si paga per l'imprecisione delle formulazioni. E viene fuori che il problema di nuovo non è stato risolto, e risolverlo non si può, ma, come sempre, si può portarlo al livello di una persona tecnica, solo che ora la chiameranno in qualche altro modo — Senior Opus Engineer, per esempio, e tra una decina d'anni qualcuno su Habr scriverà un articolo su da dove è nata la nuova professione con la sua forbice salariale. D'accordo?