Stiamo costruendo il dopoguerra del software?

Il nuovo boom edilizio è digitale

L’intelligenza artificiale ha reso la creazione di software accessibile come mai prima. Ma se tutti possono costruire qualsiasi cosa, cosa impedirà alle nostre applicazioni di diventare i palazzi anonimi di una nuova periferia digitale? Qualche giorno fa mi sono imbattuto in un intervento di Katie Dill, Head of Design di Stripe, che mi ha fatto riflettere su un parallelismo al quale non avevo mai pensato. Subito dopo la Seconda guerra mondiale, gli Stati Uniti attraversarono un periodo di espansione edilizia senza precedenti. Bisognava costruire, e bisognava farlo velocemente. Nuovi materiali, nuove tecniche e processi industrializzati permettevano di realizzare edifici con una rapidità fino a quel momento impensabile.

Il modernismo, con le sue geometrie essenziali, le superfici pulite e l’assenza di ornamenti, offriva un linguaggio architettonico particolarmente adatto a questa nuova capacità produttiva. Il problema, osserva Dill, è che progressivamente si cominciò a replicarne le forme dimenticando le idee che le avevano generate. Quello che inizialmente era stato un movimento architettonico animato da precise intenzioni progettuali si trasformò, in molte delle sue applicazioni successive, in una sorta di ricetta industriale. Edifici funzionali, economici, facilmente replicabili. Ma spesso anche anonimi, indifferenti al contesto, privi di una propria identità. Dill li chiama zombie buildings.

Ed è qui che arriva il parallelismo: oggi stiamo vivendo qualcosa di sorprendentemente simile nel mondo del software. Il nuovo boom edilizio è digitale Fino a pochissimo tempo fa, realizzare un prodotto software complesso richiedeva competenze diverse, un’organizzazione strutturata e soprattutto molto tempo. Oggi un singolo sviluppatore, affiancato da alcuni agenti AI, può affrontare progetti che soltanto pochi anni fa avrebbero richiesto un intero team e questa è sicuramente una trasformazione straordinaria.

Non condivido l’atteggiamento di chi guarda alla democratizzazione dello sviluppo come a una minaccia in sé. Ridurre le barriere d’ingresso significa permettere a molte più persone di trasformare un’idea in qualcosa di concreto. Significa anche dare una possibilità a progetti che prima non sarebbero mai nati perché economicamente insostenibili. Il problema non è che oggi possiamo costruire troppo facilmente ma cosa scegliamo di costruire una volta che la difficoltà di costruirlo non rappresenta più il principale ostacolo.

Il burrito surgelato

Apriamo una qualunque piattaforma di AI coding, chiediamo di generare una dashboard, un’applicazione SaaS o una landing page. Nel giro di pochi minuti abbiamo qualcosa di apparentemente professionale. Layout ordinato, tipografia moderna, colori equilibrati, componenti coerenti, animazioni gradevoli, eppure, dopo averne viste abbastanza, cominciamo a riconoscere sempre gli stessi schemi, le stesse card, le stesse dashboard, gli stessi gradienti, le stesse interazioni.

È come passeggiare in un quartiere dove ogni edificio è stato progettato dallo stesso architetto, per persone che non ha mai incontrato. Solo che, in questo caso, l’architetto è un modello statistico. Il problema non è la mediocrità. È la sua credibilità.

C’è un aspetto che trovo particolarmente insidioso negli strumenti generativi: non producono necessariamente risultati scadenti anzi spesso producono risultati sorprendentemente buoni ed è proprio questo il punto: Un’interfaccia mediocre, qualche anno fa, si riconosceva immediatamente, era evidente che mancasse del lavoro c’erano problemi di allineamento, inconsistenze grafiche, interazioni poco curate. Oggi possiamo ottenere in pochi minuti qualcosa che sembra il risultato di settimane di progettazione. Quella qualità superficiale rischia di trasformarsi in una forma di rassicurazione: funziona. È bello. Possiamo passare alla prossima feature.

Dill usa un’analogia piuttosto divertente: quella del burrito surgelato che diventa un pranzo in novanta secondi. Non è particolarmente buono, ma la velocità con cui risolve il problema ci porta a perdonargli parecchi difetti. Con l’AI rischiamo di fare esattamente la stessa cosa e qui aggiungerei una considerazione: la velocità non ha soltanto ridotto il costo della produzione ma ha alterato la nostra percezione di quanto lavoro meriti un risultato. Quando per costruire una schermata servivano giorni, dedicare qualche ora a discuterne il comportamento era naturale. Quando la stessa schermata viene generata in trenta secondi, dedicarle due ore di riflessione può sembrare improvvisamente uno spreco. Ma non lo è. Il valore di quella riflessione non è diminuito é semplicemente diventato meno evidente rispetto alla velocità della macchina. Abbiamo eliminato una parte della fatica non necessariamente quella giusta. C’è una distinzione che credo meriti attenzione, nello sviluppo software esistono almeno due forme di difficoltà: La prima è esecutiva: scrivere codice, implementare componenti, integrare servizi, costruire infrastrutture, risolvere problemi tecnici. La seconda è progettuale: capire cosa vale la pena realizzare, perché debba funzionare in un certo modo, quale esperienza vogliamo offrire e quali compromessi siamo disposti ad accettare. Gli LLM stanno abbattendo drasticamente il costo della prima.

Non è altrettanto evidente che stiano risolvendo la seconda.

Una buona idea da sola non basta

Possono certamente aiutarci a ragionare, suggerire alternative e mettere in discussione decisioni. Ma per farlo hanno bisogno di qualcuno che sappia porre le domande giuste e, soprattutto, riconoscere quando una risposta non è sufficientemente buona. Questo introduce una conseguenza interessante.. Per molto tempo la capacità di realizzare un prodotto ha rappresentato una parte significativa del vantaggio competitivo di chi sviluppava software. Adesso quel vantaggio si sta progressivamente riducendo. Se due persone hanno accesso agli stessi modelli e agli stessi strumenti, la differenza non sarà necessariamente determinata da chi riesce a produrre più codice ma potrebbe essere determinata da chi possiede una visione più interessante di ciò che quel codice dovrebbe diventare.

Naturalmente, una buona idea da sola non basta. Servono comunque competenza tecnica, capacità di esecuzione e conoscenza del dominio ma il rapporto tra queste competenze sta cambiando. Il nuovo collo di bottiglia è diventato saper scegliere.

Nell’intervento di Dill c’è un’osservazione che considero centrale: In passato, la scarsità di risorse imponeva una selezione naturale delle idee. Se un team aveva venti proposte ma poteva permettersi di svilupparne soltanto una, era necessario discuterle, confrontarle, scartarne diciannove. Oggi possiamo potenzialmente realizzare venti prototipi nella stessa settimana. È un progresso enorme. Possiamo verificare concretamente idee che prima sarebbero rimaste soltanto ipotesi ma abbiamo spostato il momento della selezione. Prima decidevamo cosa costruire adesso possiamo costruire tutto e decidere successivamente cosa meriti di esistere. Il problema è che scartare qualcosa che abbiamo già realizzato è psicologicamente molto più difficile e questo vale anche quando a realizzarlo è stata un’AI.

C’è sempre la tentazione di conservarlo, aggiustarlo, inserirlo da qualche parte nel prodotto. Dopotutto funziona, ed è già pronto. In questo scenario diventa fondamentale una competenza che nel mondo del software abbiamo forse sottovalutato: quella dell’editor. Qualcuno capace non soltanto di verificare che un prodotto funzioni, ma di chiedersi se abbia senso nel suo insieme, se ogni schermata contribuisca davvero all’esperienza, se un’interazione sia necessaria oppure esista soltanto perché era facile implementarla, se una funzionalità risolva un problema reale o sia semplicemente l’ennesima possibilità tecnica diventata disponibile.

Quando possiamo realizzare praticamente tutto, saper rinunciare diventa una competenza progettuale. Il design system non basta più. Dill racconta anche un’esperienza interessante maturata in Stripe. Il team aveva inizialmente cercato di rendere le proprie linee guida di design accessibili agli agenti AI attraverso un server MCP ma i risultati non erano soddisfacenti. Avere accesso alla documentazione non garantiva che i modelli prendessero decisioni coerenti. Stripe ha quindi sviluppato un approccio più strutturato, basato su una CLI integrata con il design system, che fornisce agli agenti non soltanto componenti e regole, ma anche template, flussi e indicazioni sul comportamento del prodotto.

L’obiettivo non è più soltanto garantire uniformità visiva. È trasmettere intenzioni progettuali.

Trovo questo passaggio particolarmente significativo, soprattutto per chi sviluppa software utilizzando agenti. Per anni abbiamo costruito design system pensando principalmente agli esseri umani che li avrebbero utilizzati. Adesso dobbiamo iniziare a progettare sistemi capaci di guidare anche decisioni prese autonomamente dalle macchine. Ma qui vedo anche un possibile paradosso. Più rendiamo i sistemi prescrittivi per ottenere coerenza, più rischiamo di limitare proprio quella varietà che vorremmo preservare. La soluzione, probabilmente, non consiste nel codificare ogni possibile decisione ma consiste nel distinguere ciò che deve rimanere coerente da ciò che può essere continuamente reinventato. Un buon sistema dovrebbe impedire gli errori ripetitivi, non impedire le buone idee impreviste. In altre parole, dovremmo automatizzare la coerenza senza automatizzare la creatività. E se stessimo usando l’AI per fare le stesse cose di prima?

Gran parte della conversazione attuale sull’AI nello sviluppo software ruota attorno alla produttività. Quanto codice riusciamo a generare? Quanti ticket possiamo chiudere? Quanto velocemente possiamo rilasciare una nuova versione? Sono domande legittime..ma rischiano di farci perdere di vista un’opportunità molto più interessante. Se disponiamo di strumenti che ci permettono di realizzare interazioni complesse, esplorare decine di alternative e sperimentare soluzioni che prima avremmo scartato per ragioni di costo, perché dovremmo limitarci a riprodurre gli stessi prodotti? Perché un’applicazione gestionale deve necessariamente somigliare alle altre applicazioni gestionali? Perché continuiamo a organizzare le informazioni seguendo convenzioni nate quando le capacità dei dispositivi e gli strumenti di sviluppo erano completamente diversi? E perché, soprattutto, consideriamo innovazione l’aver costruito più velocemente un’interfaccia che esiste sostanzialmente da quindici anni?

Attenzione: non sto sostenendo che ogni prodotto debba reinventare la propria interfaccia. Le convenzioni esistono per una ragione. Sono familiari, riducono il carico cognitivo e rendono le applicazioni più accessibili. Innovare non significa rendere tutto diverso a ogni costo. Significa avere finalmente la libertà di chiedersi se una soluzione migliore sia possibile, senza doverla escludere preventivamente perché troppo costosa da sperimentare.

Ecco dove, secondo me, l’AI potrebbe produrre la trasformazione più interessante, non nella quantità di software che saremo capaci di costruire ma nella varietà di software che potremo permetterci di immaginare.

Il rischio più grande è smettere di essere curiosi

L’immagine degli edifici del dopoguerra è efficace, ma non credo che il problema sia stato semplicemente costruire velocemente o adottare uno stile architettonico replicabile. E sarebbe ingeneroso attribuire al modernismo in sé la responsabilità dell’anonimato di tanta edilizia successiva. Il problema emerge quando un linguaggio progettuale viene separato dalle ragioni che lo hanno prodotto e trasformato in una formula da applicare indiscriminatamente. È esattamente ciò che rischia di succedere con l’AI. Non perché i modelli siano incapaci di proporre alternative originali, ma perché i risultati più prevedibili sono spesso anche quelli che accettiamo più facilmente. Se chiediamo un prodotto convenzionale, otterremo probabilmente un buon prodotto convenzionale e dato che costa pochissimo realizzarlo, potremmo non sentire più il bisogno di domandarci se avremmo potuto fare qualcosa di diverso. Si crea così un circolo curioso: strumenti che ampliano enormemente le possibilità creative finiscono per essere utilizzati soprattutto per replicare ciò che conosciamo già.

Non è un limite inevitabile della tecnologia é un limite delle ambizioni con cui scegliamo di utilizzarla. C’è anche un’altra differenza rispetto al boom edilizio del dopoguerra che vale la pena ricordare. Un edificio costruito male può rimanere al suo posto per decenni, Il software, almeno in teoria, possiamo modificarlo continuamente. Questo dovrebbe renderci più liberi di sperimentare, correggere e ripensare ciò che abbiamo realizzato ma tale libertà ha valore soltanto se siamo disposti a esercitarla altrimenti finiremo semplicemente per produrre applicazioni anonime a una velocità mai vista prima, accumulando nel frattempo complessità e debito tecnico che qualcuno dovrà comunque gestire.

Costruire è diventato più facile. Avere qualcosa da dire no.

Non penso che l’intelligenza artificiale renderà meno importante il lavoro di chi progetta e sviluppa software semmai penso, piuttosto, che ci costringerà a riconsiderare dove risieda il valore di quel lavoro. La capacità di scrivere codice rimane importante, ma sempre meno coinciderà, da sola, con la capacità di creare un buon prodotto. Serviranno sensibilità, conoscenza del contesto, capacità critica, curiosità e soprattutto intenzionalità.

Servirà anche il coraggio di scartare un risultato tecnicamente impeccabile quando non è quello giusto.

E forse dovremo imparare a considerare il tempo risparmiato grazie all’AI non soltanto come un’opportunità per produrre di più, ma come una risorsa da reinvestire nella qualità di ciò che produciamo perché se una macchina ci permette di costruire in un giorno ciò che prima richiedeva un mese, non siamo obbligati a riempire i ventinove giorni risparmiati con altre ventinove cose. Potremmo utilizzarne qualcuno per realizzare meglio la prima.

Conclusioni

Dill conclude il suo intervento contrapponendo l’anonimato di certa edilizia moderna alla ricchezza dell’architettura gotica, nella quale ogni dettaglio conservava qualcosa della mano e delle intenzioni di chi lo aveva realizzato. Non credo che il software debba diventare gotico. E certamente non abbiamo bisogno di interfacce sovraccariche di decorazioni per dimostrare che qualcuno ci ha lavorato ma mi piace l’idea che un prodotto possa conservare qualcosa della personalità, della sensibilità e delle intenzioni delle persone che lo hanno immaginato anche quando gran parte del codice è stata scritta da una macchina.

Perché alla fine non sarà particolarmente interessante sapere che siamo riusciti a generare un’applicazione in trenta minuti, sarà interessante scoprire che cosa siamo riusciti a creare che, senza questi strumenti, probabilmente non avremmo neppure provato a immaginare e sarebbe un peccato sprecare una possibilità del genere per costruire soltanto l’ennesimo palazzo identico a tutti gli altri..

Questo articolo nasce da alcune riflessioni suscitate dall’intervento di Katie Dill, Head of Design di Stripe, al Lenny & Friends Summit 2026. Il video originale, “How to scale intent, quality, and artistry with AI”, è disponibile su YouTube.