Coding, ingegneria del software e mercato del software
Sono tre cose diverse che spesso vengono confuse. È utile capirne natura e relazioni anche per comprendere meglio gli annunci che si susseguono nel campo dell'AI.
Disclaimer
Il post è piuttosto lungo, ma vi chiedo la pazienza di arrivare fino in fondo. Al termine del post c’è una sorpresa che credo apprezzerete 😏: ho chiesto a Perplexity Pro che ne pensasse e ho riportato per intero il giudizio che mi ha dato. Non ho apportato le integrazioni suggerite per lasciarvi la possibilità di vedere il commento nella sua interezza. Nell’app o nella mail potreste vederne solo l’inizio: dovete aprirlo nel browser.
Ho scritto queste note ricercando la massima semplicità di lettura ed eliminando tutto ciò che non avrebbe contribuito in modo utile a lettori non tecnici, ma avrebbe solo confuso le loro idee. Però, se pensate che sia utile integrarle per aumentarne la leggibilità o per correggere errori e imprecisioni, ditemelo e, ringraziandovi fin da ora, lo farò appena possibile.
Uno dei temi di maggiore discussione in queste settimane è il ruolo della GenAI nelle attività di sviluppo del software.
GenAI esercita da tempo un'influenza significativa su molte applicazioni e piattaforme digitali. Tipicamente, i produttori stanno integrando funzioni di GenAI nei loro prodotti per migliorare le modalità di assistenza e supporto all’utente (help, tutorial, guide…) o per arricchire le funzionalità vere e proprie dei prodotti. Per esempio, l’intera suite di Microsoft 365 è oggi configurata per offrire un’interazione guidata tramite Copilot.
Le integrazioni strutturali di GenAI sono ormai disponibili in moltissimi prodotti. Ad esempio, Salesforce ha Agentforce, SAP ha Joule Agent, ServiceNow ha gli AI Agent, Oracle ha AI Agent per le Fusion Applications. Anche aziende più piccole dei colossi che ho appena citato stanno integrando GenAI nei loro sistemi. Per esempio, Todoist (un task manager) ha creato Ramble per semplificare la creazione dei task.
Tuttavia, molti osservatori e commentatori stanno andando oltre e sostengono che sistemi come OpenAI Codex e Claude Code abbiano capacità tali da permettere a una pluralità di soggetti di sviluppare nuove applicazioni, mettendo quindi in crisi i produttori tradizionali. Quanto meno, l’aumento di produttività che esse consentono cancellerà molti posti di lavoro. Elon Musk, in un recente intervento, ha detto che dal pensiero si passerà direttamente al codice eseguibile: “Imagination-to-software.” Ha anche detto che GenAI genererà del codice eseguibile molto più efficiente di quello prodotto dai compilatori che usiamo oggi.
Su quest’ultimo punto conto di tornare in un prossimo post.
Un’applicazione è sviluppata attraverso un processo composto da alcune fasi chiave. Le presento in sequenza per illustrarle concettualmente. In realtà, sono attività che, nel concreto, si ripetono e si intersecano in modo molto iterativo e interattivo (pensate a come funziona il modello Agile, ad esempio).
1. Comprendere i bisogni
Innanzitutto è necessario comprendere i bisogni dell’utente: perché e a quale scopo deve essere sviluppata una certa applicazione. È forse la fase più delicata, perché, in generale, è molto difficile capire esattamente cosa voglia l’utente/cliente, soprattutto se non è un tecnico. A meno che non si tratti di un software molto semplice.
Tradurre i bisogni dell’utente/cliente in specifiche, cioè indicazioni per chi deve sviluppare l’applicazione, si presta a molti fraintendimenti ed errori, perché spesso l’utente non sa rappresentare bene i propri bisogni, oppure vengono compresi male, oppure cambiano nel tempo e ciò che era vero un giorno, cessa di esserlo dopo qualche tempo.
La traduzione dei bisogni in specifiche costituisce quindi un primo passaggio chiave. Di solito (ahimè) le specifiche sono scritte o comunicate in linguaggio naturale, come testi. Ma questi sono, per loro natura, ambigui e si prestano a molteplici interpretazioni, con conseguenti errori. Per questo, nel corso di decine di anni di ricerca è stata sviluppata una grande varietà di notazioni per rendere più agevole e preciso il processo di stesura dei requisiti. Si sono sviluppati linguaggi grafici formali e semiformali, notazioni basate sulla logica, formalismi ispirati a molti diversi paradigmi e principi.
Per esempio, qualche giorno fa su X un utente mi ha segnalato Universalis (di Erik Meijer), una sorta di “linguaggio strutturato” che permette di scrivere “specifiche/codici” molto vicine al linguaggio naturale, ma con struttura e significato.
This design tradeoff means that Universalis scripts are structured in a way that closely resembles natural language, making them intuitive and accessible even to those without formal programming training.
Esiste un problema di fondo: meno si è formali e precisi, maggiore è l’incertezza nell’interpretazione di una specifica, anche se la sua scrittura è più agevole; più si è formali, maggiore è la precisione, ma anche il costo e il tempo necessari per formularla. Per questo si combina l’uso di notazioni non eccessivamente complicate (ad esempio UML o, addirittura, il linguaggio naturale con alcuni schemi predefiniti) all’interno di cicli di sviluppo molto iterativi, così da permettere un confronto continuo tra l’utente e lo sviluppatore e, di conseguenza, verificare se effettivamente si sta sviluppando ciò che serve.
Molti, peraltro, sostengono che l’unico “oggetto” da produrre sia il codice e che esso debba essere “la” sola documentazione. Non voglio entrare qui in discussioni tecniche, ma diciamo che è un tema molto delicato che non riesco ad affrontare in questa sede. In ogni caso, il problema di capire in modo convincente e coerente ciò che il cliente/utente vuole rimane in tutta la sua complessità e criticità.
2. Progettare l’architettura e la struttura del software
Se nella prima fase l’aspetto più critico è ascoltare i bisogni, comprenderli e strutturarli (il cliente è “king”), la seconda è quella in cui si deve concepire la struttura dell’applicazione. Ci sono applicazioni con una struttura molto semplice e, al contempo, abbastanza standardizzata. Ma ce ne sono molte altre che richiedono un’attività di progettazione molto più strutturata, anche perché spesso il sistema da sviluppare deve integrarsi con molte altre applicazioni.
Nella fase di progettazione, è l’ingegnere del software che deve capire quale sia la soluzione architetturale migliore sulla base della quale costruire l’applicazione.
3. Scrivere il codice e testarlo
Ovviamente, prima o poi bisogna scrivere il codice e, per questo, negli anni sono stati sviluppati tantissimi linguaggi e framework di sviluppo. Ce ne sono centinaia (se non migliaia): qui una panoramica sintetica su Wikipedia.
Lo sviluppo dei linguaggi di programmazione è stato incentrato sull’aumento della loro potenza espressiva, per semplificare la vita dello sviluppatore. Il primo linguaggio che io imparai a usare fu Fortran, che è molto più semplice di Python, Java, Rust, Scala, Javascript o qualunque altro venga in mente a uno dei software developer che dovessero leggere queste note. La crescita dei paradigmi linguistici (e dei relativi ambienti di sviluppo) ha permesso, nel corso degli anni, di aumentare moltissimo la produttività dei progettisti e sviluppatori, consentendoci di creare sistemi di incredibile ricchezza e complessità.
La fase di scrittura è ciò che, in senso stretto, chiamiamo coding, cioè la produzione del codice sorgente in un linguaggio di programmazione.
Peraltro, al coding si accompagna la fase di test in tutte le sue dimensioni: test di modulo (un singolo pezzetto di software), test di integrazione, test prestazionale… È cruciale la validazione funzionale, ossia la verifica che ciò che si è prodotto risponda effettivamente ai bisogni del cliente/utente.
4. Mettere l’applicazione in produzione (deployment)
Quando un programma è ritenuto sufficientemente stabile, viene messo in produzione, cioè consegnato agli utenti. Questa fase include anche tutte le attività di formazione degli utenti, l'integrazione con altri sistemi, il consolidamento della documentazione del progetto e dei sistemi di help online, nonché la creazione dei processi di supporto per gli utenti che avessero problemi.
5. Manutenerla e farla evolvere
Un software utile non muore mai e cambia sempre, sia perché si rilevano errori, sia perché nascono nuovi bisogni o cambiano le condizioni al contorno. Pensate ad un sistema contabile che deve evolvere per tenere conto di nuove norme sulla fiscalità.
Per questo la messa in produzione non è la fine della storia, ma semplicemente un passaggio intermedio in un ciclo che smette di iterare solo quando quel software non è più utile e quindi non viene più utilizzato.
SaaS e custom software
Notate che se uso un SaaS tutto questo discorso cambia radicalmente. Quanto visto è, in linea di massima, il processo seguito per scrivere codice ad hoc, "custom software”. Se uso un SaaS (ad esempio Salesforce), le funzionalità sono già state sviluppate dal produttore: ciò che va fatto è personalizzarle o customizzarle per specifici processi o bisogni dell’utente/cliente. Quindi, l’aspetto critico è la raccolta e l’analisi dei bisogni e dei requisiti dell’utente. Spesso non c’è bisogno di alcuna attività di sviluppo software in senso classico.
A scanso di equivoci, ripeto quanto detto in precedenza: ho presentato queste fasi in sequenza per descriverle, ma nella pratica si alternano e si ripetono in modo molto iterativo e, per l’appunto, Agile. In alcuni casi in cui sono necessarie verifiche molto approfondite (pensate al software di un aeroplano), l’organizzazione di queste attività è molto più strutturata per garantire la massima affidabilità dei sistemi sviluppati.
Si noti anche che più “vecchio” è un errore di concezione di un'applicazione, maggiore è il costo per la sua correzione. Se ho capito male il bisogno del cliente, svilupperò del codice che non serve e mi toccherà rifarlo. Se concepisco male l’architettura, dovrò apportare modifiche alla struttura del codice per rimediare.
Perché ho fatto questa lunga premessa? Per poter fare alcune semplici considerazioni.
Quando usiamo le espressioni software e ingegneria del software, ci riferiamo a un prodotto (il software) e a un’attività/disciplina (l’ingegneria del software) che vanno ben oltre il “solo” codice. Spero che questo sia emerso da quanto ho sommariamente presentato nei paragrafi precedenti.
Inoltre, un’azienda che produce software deve capire come concepirlo, venderlo, farlo pagare e farlo evolvere tenendo conto delle dinamiche del mercato, delle richieste dei clienti e dell’evoluzione delle tecnologie stesse.
La figura che segue non ha un significato tecnico. Vuol semplicemente far capire che il codice, l’attività di coding, è solo una parte del processo di ingegneria del software, che a sua volta non esaurisce ciò che un’azienda produttrice di software deve fare per restare in gioco sul mercato.
Ha senso, quindi, dire che l’industria del software è in pericolo perché, con GenAI, ciascuno può “semplicemente esprimere i propri bisogni” e Codex produce il codice necessario?
Lascio a voi giudicare.
Ma, si dirà, GenAI ci fa accelerare la scrittura del codice! Non ci sono ancora evidenze così nette perché non è che basti far produrre il codice e il lavoro è finito. Bisogna valutarlo, verificare se è efficiente e affidabile, ben integrabile con altre componenti. Il costo e il tempo totali di “codifica” devono includere anche queste fasi, e qui emergono indicazioni secondo cui, quantomeno, dobbiamo essere prudenti. Ne scrivevo qualche settimana fa qui su Substack. E comunque, il coding non è tutto; spero che risulti chiaro.
Alcuni segnalano che sul mercato del lavoro sono già emerse evidenze di una riduzione delle assunzioni tra i giovani. In realtà, le dinamiche sono molto articolate e ne ho scritto in un post precedente sull’AI washing riprendendo varie fonti a partire da un articolo di pochi giorni fa del NYT.
Questo è ciò che mi segnalava Perplexity Pro analizzando i dati in rete. Gli avevo chiesto di interpretare il calo in borsa dei grandi produttori di software e i licenziamenti del personale.
E ci sono anche altri segnali in controtendenza come questo di qualche giorno fa: “IBM is tripling the number of Gen Z entry-level jobs after finding the limits of AI adoption”.
But some companies are realizing that cutting young workers out of the pipeline isn’t a sustainable long-term strategy: $240 billion tech giant IBM just revealed it’s ramping up hiring of Gen Z.
“The companies three to five years from now that are going to be the most successful are those companies that doubled down on entry-level hiring in this environment,” Nickle LaMoreaux, IBM’s chief human resources officer, said this week.
“We are tripling our entry-level hiring, and yes, that is for software developers and all these jobs we’re being told AI can do.”
Tuttavia, secondo alcuni, non sarà più necessario nemmeno scrivere codice: diamo “istruzioni” e dati a un agente e il sistema LLM farà ciò che faceva l’applicazione tradizionale. Anche questo, ad oggi, non funziona. Ho chiesto a GenAI di riassumere i problemi che questo approccio comporta.
Quindi?
Quindi l’AI è una tecnologia straordinaria che dobbiamo studiare, valutare e adottare con lungimiranza e intelligenza. Ma dobbiamo metterla alla prova tenendo conto dell’interezza dei problemi e di evidenze che non siano casi puntuali o i claim dei produttori di GenAI.
Altrimenti facciamo un danno all’AI, alle imprese e, alla fine, a tutti noi.
Che ne pensa GenAI?
Ho chiesto a Perplexity Pro un commento senza aver visto il post (ho solo scritto una frase che sintetizza la tesi) e un giudizio dopo averlo letto. Eccoli, leggete fino in fondo 😏
Sottolineo che non ho apportato le modifiche suggerite (sulle quali sono d’accordo) per dare a voi la possibilità di leggere quanto prodotto da Perplexity Pro nella sua interezza.
Commento senza aver visto il post
Temi chiave da considerare
Miti comuni da evitare o affrontare:
L’idea che l’AI sostituirà completamente gli sviluppatori (oltre il 70% dei developer ritiene che l’AI trasformerà, non rimpiazzerà, il loro ruolo)[riseuplabs]
La convinzione che l’AI produca codice perfetto (manca di giudizio umano per bilanciare trade-off come velocità vs scalabilità)[hackreactor]
L’idea che i modelli “comprendano” i problemi (in realtà predicono pattern, non capiscono il contesto)[theserverlessedge]
La percezione che l’AI sia completamente autonoma (richiede supervisione umana continua)[riseuplabs]
Aspetti da non trascurare:
I principi fondamentali del software engineering (modularità, coesione, accoppiamento) spesso mancano nel codice generato dall’AI[arxiv]
L’importanza del contesto e della definizione corretta del problema diventa ancora più critica con l’AI[theserverlessedge]
La distinzione tra automazione, workflow AI-driven e veri agenti AI[substack]
Condividi il testo e potrò fornirti una revisione dettagliata e specifica per il tuo articolo!
Commento dopo aver letto il post
Punti di forza
Chiarezza espositiva: La progressione dalle cinque fasi dello sviluppo software alla distinzione tra coding, ingegneria e business è logica e ben articolata. L’uso del diagramma concentrico aiuta a visualizzare efficacemente i concetti.
Equilibrio: Eviti sia l’eccessivo entusiasmo che il catastrofismo riguardo all’AI, mantenendo un approccio pragmatico supportato da evidenze.
Accessibilità: Il linguaggio è appropriato per un pubblico non tecnico senza essere semplicistico.
Correzioni necessarie
1. Affermazione di Elon Musk sulla compilazione
Situazione attuale nel testo: Riporti correttamente l’affermazione di Elon Musk (”GenAI genererà del codice eseguibile molto più efficiente di quello prodotto dai compilatori che usiamo oggi”) e dici che conti di tornarci in un prossimo post.
Problema: L’affermazione di Musk è tecnicamente molto controversa e merita un commento critico immediato, anche breve, per non lasciare il lettore con l’impressione che sia una prospettiva plausibile. I compilatori moderni applicano ottimizzazioni matematicamente dimostrabili (constant folding, dead code elimination, loop unrolling, register allocation ottimale) che rappresentano decenni di ricerca in teoria dei linguaggi e ottimizzazione. L’idea che un LLM possa “saltare” la compilazione generando direttamente binari più efficienti è altamente speculativa e contrasta con i fondamenti dell’informatica.
Suggerimento di modifica: Dopo “Su quest’ultimo punto conto di tornare in un prossimo post”, aggiungi:
“Anticipo però che questa affermazione è tecnicamente molto controversa. I compilatori moderni implementano ottimizzazioni matematicamente dimostrate che sono frutto di decenni di ricerca. L’idea che un LLM possa bypassarli generando direttamente codice macchina più efficiente richiederebbe una verifica molto approfondita e contrasta con i fondamenti consolidati dell’informatica.”
2. Universalis di Erik Meijer
Situazione attuale: Menzioni Universalis come “una sorta di linguaggio strutturato” che permette di scrivere “specifiche/codici” vicine al linguaggio naturale.
Precisazione necessaria: Universalis è un linguaggio sperimentale progettato specificamente per essere eseguito da LLM (come “macchina virtuale neurale”), non è un linguaggio di specifica tradizionale. È un framework di program synthesis che combina notazione leggibile dagli umani con esecuzione tramite AI. Questa distinzione è importante perché rappresenta un approccio radicalmente diverso dai linguaggi di specifica formale o semiformale che menzioni (UML, logica formale).
Suggerimento di modifica: Sostituire “una sorta di ‘linguaggio strutturato’ che permette di scrivere ‘specifiche/codici’ molto vicine al linguaggio naturale, ma con struttura e significato” con:
“un linguaggio sperimentale progettato per essere interpretato ed eseguito direttamente da LLM, che permette di scrivere istruzioni molto vicine al linguaggio naturale mantenendo struttura e precisione—un approccio radicalmente diverso dai linguaggi di specifica tradizionali”
Approfondimenti consigliati (non obbligatori)
3. Produttività del coding con AI: dati contrastanti
Situazione attuale: La tua affermazione “Non ci sono ancora evidenze così nette” sulla produttività è corretta ma potrebbe essere più specifica.
Dati da considerare:
Positivi: Alcuni studi riportano incrementi del 30-45% nel tempo di sviluppo iniziale del codice; 97% degli sviluppatori usa strumenti GenAI e riporta guadagni di produttività percepiti
Problematici: Uno studio ha trovato che sviluppatori usando AI hanno impiegato il 19% in più di tempo rispetto a quelli senza AI, pur percependo di essere più veloci—un gap di percezione di 43 punti percentuali; il codice generato da AI richiede revisione intensiva per qualità, sicurezza e coerenza architettonica; solo il 29% degli sviluppatori si fida dell’accuratezza dell’AI
Suggerimento di espansione: “Non ci sono ancora evidenze così nette perché la ricerca mostra risultati molto contrastanti. Alcuni studi riportano incrementi del 30-45% nella velocità di scrittura iniziale del codice, ma altri hanno rilevato che includendo tempo di revisione, debugging e correzione, il tempo totale può addirittura aumentare. Un aspetto preoccupante emerso dalla ricerca è che gli sviluppatori spesso percepiscono di essere più veloci con l’AI anche quando i dati mostrano il contrario—un bias cognitivo che può portare a valutazioni errate della reale produttività. Bisogna valutarlo, verificare se è efficiente e affidabile, ben integrabile con altre componenti. Il costo e il tempo totali di ‘codifica’ devono includere anche queste fasi, e qui emergono indicazioni secondo cui, quantomeno, dobbiamo essere prudenti.”
4. Mercato del lavoro: dinamiche più complesse
Situazione attuale: La tua discussione sul mercato del lavoro è equilibrata, ma potresti aggiungere una sfumatura importante.
Dati da considerare:
Le posizioni junior sono effettivamente diminuite del 40% rispetto al pre-2022
Tuttavia, aziende come IBM stanno triplicando le assunzioni entry-level nel 2026, ma con ruoli completamente ridefiniti: meno coding routinario, più interazione con clienti, architettura e orchestrazione di sistemi AI
La Gen Z viene vista come più “AI-fluent” e alcune aziende stanno aumentando programmi per giovani del 25%
Implicazione: Non è semplicemente una riduzione dei posti, ma una trasformazione dei ruoli entry-level.
Suggerimento di espansione: Dopo aver menzionato IBM, potresti aggiungere: “IBM non è un caso isolato: sta triplicando le assunzioni entry-level, ma con ruoli completamente ridefiniti. I nuovi sviluppatori junior trascorreranno meno tempo su coding routinario e più su architettura, interazione con clienti e orchestrazione di sistemi AI. Non stiamo assistendo solo a una riduzione, ma a una trasformazione dei requisiti delle posizioni entry-level.”
5. Fase di Requirements Engineering
Rafforzamento suggerito: Potresti menzionare che le debolezze nel requirements engineering sono considerate una delle principali cause di fallimento dei progetti software. Questo rafforza il tuo punto che GenAI, che può aiutare con il coding, non risolve affatto i problemi più critici.
6. Costi di manutenzione
Rafforzamento suggerito: Potresti aggiungere dati: la manutenzione rappresenta tipicamente 50-80% del costo totale del ciclo di vita del software, e può costare 2-4 volte lo sviluppo iniziale su 10 anni. Un sistema sviluppato rapidamente con AI ma senza attenzione ad architettura e manutenibilità potrebbe accumulare debito tecnico che moltiplica i costi futuri.
Elementi mancanti (opzionali)
Debito tecnico: Potresti menzionare brevemente il concetto di “technical debt”—codice scritto velocemente con AI senza attenzione alla qualità può creare problemi a lungo termine che moltiplicano i costi di manutenzione.
Ruolo dell’ingegnere che evolve: Un punto che emerge dalla ricerca è che il ruolo dell’ingegnere software sta evolvendo da “code writer” a “system orchestrator” e “AI conductor”. Questo rafforza la tua distinzione tra coding e ingegneria.
Conclusione generale
Il post è sostanzialmente accurato, ben bilanciato e pedagogicamente efficace. Le uniche correzioni necessarie riguardano:
Obbligatoria: Aggiungere un commento critico immediato sull’affermazione di Musk sulla compilazione
Consigliata: Chiarire la natura di Universalis
Gli approfondimenti suggeriti (dati più specifici su produttività, mercato del lavoro, costi di manutenzione) rafforzerebbero l’argomentazione, ma non sono necessari per la correttezza del post.
Non ci sono semplificazioni eccessive o errori concettuali sostanziali. Il post raggiunge efficacemente l’obiettivo di rendere accessibile a un pubblico non tecnico una distinzione importante spesso confusa nel dibattito pubblico sull’AI.
Una cosa che AI fa piuttosto bene é la traduzione linguistica; mi servirà per tradurre questo post in Inglese per condividerlo con qualche collega che non parla Italiano e che ha disperato bisogno di leggere una spiegazione così chiara su cosa sta intorno al lavoro di Software Engineering, al di là del coding.
Sul drop del mercato SaaS, i nostri analisti di Bain condividono un paio di altre idee oltre a quelle riportate da Perplexity. Uno dei punti forti della loro analisi é il potere negoziale che AI offre ai procurement offices nello stato del mercato attuale. Non importa (per ora) se i claim dei GenAI provider sono accurati o meno, se la percezione é che l'azienda può rimpiazzare il prodotto SaaS con qualche licenza di ChatGPT, al rinnovo non solo non accetterà il tipico aumento del prezzo del 5-8%, ma anzi cercherà di ridurre i costi. L'altro angolo negoziale é che con tanti dei servizi MCP messi a disposizione dei SaaS vendor, poche decine di licenze saranno sufficienti a costruire una AI experience che serve 100+ utenti, rompendo il modello di business basato sul numero di "seats". Questa seconda considerazione la vedo meno rilevante, perché già stiamo vedendo vendor prezzare MCP a volume, API a consumo, cercando di mettere una pezza al problema / workaround.
La cosa che mi suona meno probabile nella storia del SaaS impact é che ogni utente business di ogni azienda rimpiazzerà diversi prodotti SaaS con una licenza ChatGPT. L'ultima volta che ci siamo visti, mi parlava della fungaia, il proliferare di tool, file excel, workflow e strumenti home grown da parte di team diversi e tutti disallineati, che sono l'incubo di ogni IT. Espongono problemi di sicurezza, dati non allineati, riconciliazioni impossibili, diverse source of truth. Inoltre tutti questi piccoli ottimi locali, perdono la prospettiva di un ottimo globale sistemico. Mancanza di integrazioni, silo informativi, processi che non possono essere resi efficienti perché la knowledge é frammentata o persino assente (nessuno conosce il codice generato). Chi si occuperà di supportare questi utenti? L'IT veramente vuole spingere l'acceleratore su questo trend e poi trovarsi migliaia di pezzi di tool vibe coded da supportare e completare?
Tutto questo ammesso che l'utente business con GenAI sia in grado di produrre risultati utili almeno per le sue esigenze, che é una cosa non scontata. Come scrive nel primo capitolo di questo post, spesso gli utenti non sanno nemmeno cosa vogliono, il lavoro dell'engineer richiede anche la capacità di organizzare queste richieste disomogenee in un sistema coerente. L'assunto che GenAI sarà capace di far tutto ciò non é fondata su nessuna evidenza e richiede leap tecnologici importanti.