Dall’esperienza diretta con l’AI programming alla visione di un nuovo paradigma di sviluppo software
Questo articolo esplora l’emergente paradigma della programmazione basata su intenti attraverso l’analisi di recenti ricerche del MIT, Stanford e di studi sulla collaborazione uomo-AI. Partendo da un’esperienza concreta di sviluppo di un sistema di gestione incassi per la farmacia di mia moglie, realizzato esclusivamente tramite prompt, l’articolo esamina come la Cognitive Load Theory e i framework di distributed cognition stiano ridefinendo il ruolo del programmatore. L’analisi si concentra sulla transizione dal paradigma imperativo a quello dichiarativo-intenzionale, evidenziando sfide tecniche, cognitive ed etiche. Attraverso evidenze empiriche e framework teorici, viene proposta una visione del programmatore del 2035 come orchestratore di sistemi AI, dove la competenza principale diventa la capacità di specificare intenti complessi piuttosto che implementare algoritmi.
1. Introduzione
Era una mattina di gennaio quando mia moglie, che gestisce una farmacia, mi ha presentato l’ennesima richiesta: “Mi servirebbe un sistema per gestire incassi e sospesi, sai, qualcosa di semplice ma che funzioni davvero”. Ora, a certe richieste del capo di casa non si può dire di no – lo sanno tutti i mariti che lavorano nell’IT!
Il tipo di applicazione che negli anni ’90 avrei sviluppato in Visual Basic, poi in PHP, successivamente in Angular. Ma questa volta, vuoi per sfida personale, vuoi per curiosità verso i limiti dell’AI, ho deciso di non scrivere una sola riga di codice.
Armato solo di Claude e di quella particolare motivazione che deriva dal dover dimostrare a tua moglie che “sì, l’AI può davvero fare queste cose”, ho iniziato a descrivere quello che serviva: “Ho bisogno di un sistema che tenga traccia degli incassi giornalieri della farmacia, gestisca i sospesi per cliente, generi report mensili, si integri con il gestionale…”. Quattro ore, molte iterazioni e qualche “ma sei sicuro che funzioni?” dopo, avevo un’applicazione funzionante. Non perfetta, ma funzionante. E io non avevo scritto codice – avevo solo comunicato intenti.
Questo episodio, nato tra le mura domestiche ma con implicazioni professionali concrete, rappresenta in realtà un cambio di paradigma profondo, che le ultime ricerche del MIT e Stanford stanno iniziando a mappare sistematicamente.
2. Background e Stato dell’Arte
Il MIT CSAIL ha recentemente pubblicato “Challenges and Paths Towards AI for Software Engineering”, evidenziando come la narrativa popolare riduca spesso l’ingegneria del software a “programmazione da undergraduate”, mentre la pratica reale include refactoring continuo, migrazioni massive di codice legacy, testing complesso e manutenzione infinita. [news.mit.edu]
Il Stanford AI Index Report 2025 mostra come i modelli AI stiano superando sistematicamente i benchmark: nel 2024, i punteggi sono aumentati del 18.8% su MMMU, 48.9% su GPQA e 67.3% su SWE-bench rispetto all’anno precedente. Ma questi progressi sollevano domande fondamentali sulla natura stessa della programmazione. [ibm.com]
La ricerca sulla collaborazione uomo-AI ha identificato tre framework teorici chiave per comprendere questa transizione:
- Cognitive Load Theory (CLT): Sweller e colleghi dimostrano come i sistemi AI-driven, informati da insights neurofisiologici tramite EEG e fNIRS, possano gestire dinamicamente il carico cognitivo, adattando i percorsi di apprendimento in tempo reale [mdpi.com]
- Distributed Cognition: Il pensiero computazionale non risiede più solo nella mente del programmatore, ma è distribuito tra umano e AI
- Theory of Mind in AI: La capacità crescente dei LLM di interpretare intenti impliciti e contesto
Nella mia esperienza diretta con Azure OpenAI Service, ho potuto osservare come questi framework teorici si traducano in pratica: il sistema non solo genera codice, ma comprende il contesto aziendale – in questo caso, le specificità di una farmacia – suggerisce architetture appropriate, identifica potenziali problemi di sicurezza e conformità.
3. Analisi Scientifica
3.1 Il Paradigma Intent-Based Programming
Solar-Lezama del MIT osserva che “abbiamo strumenti molto più potenti di qualsiasi cosa vista prima, ma c’è ancora molta strada per ottenere la piena promessa dell’automazione”. La programmazione basata su intenti rappresenta un salto qualitativo rispetto al prompt engineering tradizionale. [news.mit.edu]
Nel sistema di gestione per la farmacia, ho sperimentato tre livelli di astrazione:
- Intento funzionale: “Voglio tracciare i pagamenti dei clienti che lasciano i sospesi”
- Intento architetturale: “Usa un pattern event-sourcing per l’audit trail – in farmacia la tracciabilità è fondamentale”
- Intento non-funzionale: “Deve essere usabile da mia moglie e le sue collaboratrici senza formazione IT”
La ricerca sulla CLT e AI mostra come i modelli Deep Learning (CNN, RNN, SVM) migliorino l’accuratezza della classificazione, rendendo i sistemi di apprendimento adattivo AI-powered più efficienti e scalabili. Questo si traduce nella capacità dell’AI di interpretare intenti sempre più astratti – come “gestisci i sospesi come fa una farmacia vera”, comprendendo implicitamente normative, prassi e necessità specifiche del settore. [link.springer.com]
3.2 Sfide Cognitive e Automation Bias
La ricerca di Romeo e Conti (2025) sull’automation bias evidenzia come la tendenza a fare eccessivo affidamento sulle raccomandazioni automatizzate rappresenti una sfida critica nella collaborazione uomo-AI. Nel progetto per la farmacia, ho dovuto combattere costantemente la tentazione di accettare acriticamente il codice generato. [link.springer.com]
I fattori che influenzano l’automation bias includono:
- Alfabetizzazione AI: La mia esperienza trentennale vs la fiducia ingenua
- Livello di expertise professionale: Sapere cosa cercare nel codice generato
- Profilo cognitivo: Bilanciare entusiasmo tecnologico e scetticismo pratico
- Dinamiche di fiducia: “Se lo dice l’AI sarà giusto” vs “Fammi controllare”
- Complessità delle spiegazioni: Quando Claude spiega perché ha fatto certe scelte
Paradossalmente, i meccanismi di Explainable AI progettati per mitigare il bias possono rafforzare la fiducia mal riposta, specialmente tra professionisti meno esperti con bassa alfabetizzazione AI. [link.springer.com]
Un esempio concreto: quando l’AI ha generato il modulo di gestione scontrini, ha creato una struttura apparentemente logica ma che non teneva conto delle particolarità fiscali delle farmacie italiane. Solo l’esperienza (e le domande serali di mia moglie) mi hanno fatto notare le lacune.
3.3 Il Modello Cognitivo del Programmatore-Architetto
Basandomi su Social Cognitive Theory di Bandura e Cognitive Load Theory di Sweller, propongo un modello a tre componenti per il programmatore del futuro: [sciencedirect.com]
Component 1 – Intent Specification
- Capacità di articolare obiettivi complessi (“gestisci le ricette dematerializzate”)
- Comprensione dei trade-off architetturali (performance vs usabilità per non-tecnici)
- Visione sistemica (integrazione con gestionale, SOGEI, cassa)
Component 2 – Verification & Validation
- Competenza nel riconoscere pattern errati (il classico “funziona ma non è giusto”)
- Testing cognitivo del codice generato (“prova con 100 clienti simultanei”)
- Debugging di intenti mal interpretati (“no, non tutti i farmaci hanno l’IVA al 10%”)
Component 3 – Orchestration
- Gestione di multiple AI specializzate (una per UI, una per business logic, una per DB)
- Composizione di soluzioni ibride (AI per il boilerplate, umano per la logica critica)
- Mediazione tra intenti conflittuali (velocità vs accuratezza contabile)
3.4 Evidenze Empiriche e Limitazioni
Lo studio MIT identifica bottleneck critici: “L’ottimizzazione del codice a scala industriale – come il re-tuning dei kernel GPU o i raffinamenti multi-layer dietro il motore V8 di Chrome – rimane ostinatamente difficile da valutare”. [news.mit.edu]
Nel caso del sistema per la farmacia, l’applicazione generata funzionava ma presentava inefficienze che un programmatore esperto avrebbe evitato:
- Query N+1 non ottimizzate (che mia moglie notava come “lentezza quando ci sono molti clienti”)
- Gestione naive della concorrenza (problematica con due postazioni cassa)
- Pattern di error handling inconsistenti (tradotto in: “a volte dà errori strani”)
- Mancanza di ottimizzazioni domain-specific (non cachava i dati dei farmaci più venduti)
Questo conferma che siamo in una fase di transizione, non di sostituzione. E me lo ricorda ogni sera a cena quando mi dice: “Il sistema va bene, ma quello vecchio che avevi scritto tu era più veloce…”
3.5 L’Esperimento Completo: Metriche e Risultati
Dopo tre mesi di utilizzo in produzione, posso condividere alcuni dati:
Tempo di sviluppo:
- Sistema AI-generato: 4 ore di prompting + 2 ore di testing
- Stima sviluppo tradizionale: 40-60 ore
Qualità del codice:
- Copertura funzionale: 85% dei requisiti
- Bug critici trovati: 3 (gestione date, calcolo IVA mista, concorrenza)
- Performance: 60% rispetto a soluzione ottimizzata manualmente
Manutenibilità:
- Pro: Codice molto commentato e strutturato
- Contro: Pattern inconsistenti tra moduli diversi
4. Implicazioni Pratiche
Per le Aziende
La mia esperienza con la farmacia e con clienti enterprise mostra tre scenari di adozione:
- Prototipazione Rapida: La farmacia ora ha un sistema che prima non c’era – meglio del nulla
- Modernizzazione Legacy: Migrazioni massive da COBOL a Java che ridefiniscono interi business [news.mit.edu]
- Augmentation Cognitiva: Sviluppatori senior che moltiplicano la produttività del 5-10x
Per i Professionisti
Il programmatore del 2035 dovrà sviluppare:
- Meta-competenze: Non “come implementare un hash table” ma “quando serve davvero un hash table”
- Domain Expertise: Capire profondamente il business (le farmacie hanno logiche uniche)
- Pensiero Sistemico: L’AI genera pezzi, l’umano vede l’insieme
- Verificazione Critica: “L’engagement dell’utente emerge come il punto di intervento più fattibile e impattante” [link.springer.com]
Rischi e Opportunità
L’AI Index Report solleva preoccupazioni: “L’eccitazione e il momentum del progresso potrebbero avere priorità sul prendersi cura di etica, equità e bias”. [ibm.com]
Dalla mia esperienza diretta emergono rischi concreti:
- Perdita di competenze fondamentali: Cosa succede quando nessuno sa più debuggare?
- Dipendenza da sistemi black-box: Se OpenAI va down, la farmacia si ferma?
- Amplificazione di bias nascosti: L’AI assume che tutti i clienti abbiano uno smartphone
- False economie: Risparmi 50 ore di sviluppo, spendi 100 ore di debugging
Ma anche opportunità uniche:
- Democratizzazione dello sviluppo (mia moglie ora modifica da sola i report)
- Focus su problemi di business invece che technicalities
- Iterazione rapidissima (cambiamo funzionalità in minuti, non giorni)
5. Conclusioni e Riflessioni
Guardando al sistema della farmacia – funzionante, imperfetto, generato attraverso dialogo, ma soprattutto approvato dal capo di casa – vedo un’anteprima del 2035. Non sarà un mondo senza programmatori, ma un mondo dove programmare significa orchestrare intelligenze, specificare intenti, validare risultati.
Come nota il MIT, “il futuro richiede che gli umani si concentrino sul design di alto livello mentre il lavoro di routine viene automatizzato”. Ma “routine” è un concetto in evoluzione: quello che oggi richiede expertise, domani sarà commodity. [news.mit.edu]
La mia profezia per il 2035?
Il codice diventerà invisibile come l’assembler lo è oggi. Scriveremo intenti, non algoritmi. Progetteremo esperienze, non implementazioni. E forse, finalmente, potremo concentrarci su quello che davvero conta: risolvere problemi umani, non problemi computazionali.
Ma c’è una condizione: dobbiamo rimanere architetti, non diventare semplici richiedenti. La differenza sta nella comprensione profonda di cosa stiamo chiedendo e perché. Altrimenti, come mi è successo quel gennaio, ci ritroveremo con sistemi che funzionano ma non eccellono, che risolvono ma non innovano. E con mogli che ti ricordano gentilmente che “il vecchio sistema era meglio”.
Il programmatore del futuro non scriverà codice. Scriverà futuri. E magari riuscirà anche a impressionare il capo di casa.
Anche se, conoscendo mia moglie, probabilmente mi chiederà: “Sì, ma può anche fare il caffè?”
Riferimenti
- Bandura, A. (1986). Social foundations of thought and action: A social cognitive theory. Prentice-Hall.
- Gkintoni, E., Antonopoulou, H., Sortwell, A., & Halkiopoulos, C. (2025). Challenging Cognitive Load Theory: The Role of Educational Neuroscience and Artificial Intelligence in Redefining Learning Efficacy. Brain Sciences, 15(2), 203.
- MIT CSAIL (2025). Challenges and Paths Towards AI for Software Engineering. MIT News, July 16, 2025.
- Romeo, G., & Conti, D. (2025). Exploring automation bias in human–AI collaboration: a review and implications for explainable AI. AI & Society, 41, 259–278.
- Solar-Lezama, A., et al. (2025). Can AI really code? Study maps the roadblocks to autonomous software engineering. MIT Computer Science and Artificial Intelligence Laboratory.
- Stanford HAI (2025). Artificial Intelligence Index Report 2025. Stanford Institute for Human-Centered Artificial Intelligence.
- Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257-285.
- Twabu, K. (2025). Enhancing the cognitive load theory and multimedia learning framework with AI insight. Discover Education, 4, 160.
Rispondi