Software Revolution

Come cambia il software, e il lavoro di chi lo crea

Andrej Karpathy ha coniato il termine vibe coding in un tweet del febbraio 2025. A un anno di distanza, Lovable ha raggiunto 100 milioni di dollari di ricavi ricorrenti in otto mesi (TechFundingNews, dicembre 2025), Cursor vale quasi 10 miliardi dopo un round da 900 milioni guidato da Thrive Capital (Vestbee, giugno 2025), e l’84% degli sviluppatori usa strumenti AI nel proprio lavoro secondo (Stack Overflow Developer Survey, 2025). Gartner stima che entro fine 2026 il 60% del nuovo codice sarà generato da un modello. Il CEO di Y Combinator Garry Tan ha dichiarato che il 25% delle startup nel batch Winter 2025 aveva codebase scritte per oltre il 95% dall’AI.

Scrivere codice è diventato economico. La conseguenza più visibile è che se ne scrive molto di più. Quella meno visibile, e più rilevante, è che quasi tutto questo codice replica la stessa architettura di dieci anni fa: form, CRUD, dashboard. L’AI accelera la produzione di software la cui forma è rimasta identica. Ma la forma del software deve cambiare, e con essa cambia il valore di chi lo progetta, lo sviluppa, lo gestisce.

Scrivere codice più in fretta è la risposta giusta alla domanda sbagliata. La domanda giusta è: che forma ha il software che vale la pena costruire, e cosa significa questo per chi ci lavora?

---

Quattro layer

Il software tradizionale raccoglie input attraverso form, elabora dati in background e restituisce risultati nello stesso luogo: tutto vive dentro un’unica interfaccia. Questa struttura smette di avere senso quando il valore del software si sposta dall’organizzazione del dato all’intelligenza applicata per arricchire e interpretare i dati.

Chiamo i pilastri della nuova forma del software EIID: Enrichment, Inference, Interpretation, Delivery.

1. Enrichment

Il primo layer gestisce l’ingresso dell’informazione. In un prodotto AI-native i dati non arrivano solo da database e API: arrivano da una foto scattata col telefono a un inventario scritto a mano, da un’email inoltrata, da un vocale su WhatsApp, da un thread Slack, da un export SAP, da un foglio Excel allegato a una mail. L’enrichment accetta tutti questi formati, li normalizza, li rende leggibili per il layer successivo.

Il principio di progettazione è uno: le persone non devono cambiare il modo in cui lavorano. Un responsabile di magazzino che manda i conteggi via messaggio dal telefono non impara un’interfaccia nuova; un buyer che riceve cataloghi in PDF dai fornitori non ricopia i dati in un gestionale. Il costo dell’adozione è storicamente il punto in cui la maggior parte dei progetti software fallisce, perché chiede alle persone di adattarsi al sistema. Il nuovo software inverte la direzione: il sistema si adatta alle persone.

Il valore progettuale sta nella copertura dei punti di ingresso e nella qualità della normalizzazione. Chi progetta l’enrichment deve capire come le persone lavorano davvero, quali strumenti usano, quali formati producono, e costruire un layer che li intercetti senza frizione. È lavoro di design nel senso più profondo del termine: progettare per il comportamento esistente.

2. Inference

Il secondo layer rileva pattern, fa previsioni, classifica, confronta. Quale cliente ha ridotto gli ordini oltre il 20% rispetto alla media trimestrale? Quali fornitori hanno tempi di consegna in peggioramento? Quale segmento di mercato mostra segnali di contrazione?

È il layer che l’AI ha reso economico più in fretta. Ciò che fino a due anni fa richiedeva un team di data science e mesi di lavoro oggi è una chiamata API. Il costo computazionale è basso e scende, ma la parte costosa resta sapere quali domande porre. La progettazione dell’inferenza richiede una comprensione del dominio che i modelli non hanno: quali deviazioni contano, per chi, con quale urgenza.

Qui succede qualcosa che riguarda direttamente lo spostamento del valore nel lavoro. Le startup AI-native stanno vincendo nei segmenti dove l’inferenza opera su dati non strutturati che vivono fuori dai sistemi tradizionali. Qualche esempio: Clay e Actively nel sales lavorano su segnali che il CRM non cattura, come attività social o cambi di ruolo. Rillet e Numeric nella finanza operano su flussi che l’ERP non aggrega. Il valore si sposta verso la capacità di scegliere cosa inferire e su quali dati: è un lavoro di giudizio.

3. Interpretation

Questo layer è il più sottovalutato e il più difficile da progettare. L’inferenza produce un output grezzo, ma è l’interpretazione che lo trasforma in qualcosa su cui una persona può agire.

Per farlo bisogna aggiungere contesto: confronto con le baseline, direzione del trend, spiegazione probabile, azione raccomandata. È il layer dove la competenza di dominio pesa di più, perché il contesto non vive nei dati: vive nella relazione tra l’organizzazione e il suo mercato, nella storia di quel cliente specifico, nelle sfumature che un modello non legge.

Quando una competenza diventa abbondante grazie all’AI, la scarsità si sposta nel suo complemento. L’informazione è abbondante? La capacità di interpretarla nel contesto giusto diventa scarsa. L’esecuzione è abbondante? Il giudizio su cosa vale la pena eseguire diventa scarso. La produzione è abbondante? Il coordinamento diventa scarso.

L’interpretation layer è dove questa scarsità complementare prende forma concreta nel software. È il punto in cui il prodotto smette di mostrare dati e inizia a produrre decisioni informate, e la distanza tra le due cose è dove si concentra il valore più alto dell’intera catena.

4. Delivery

L’ultimo layer restituisce i risultati attraverso gli stessi canali da cui i dati sono entrati. Chi ha mandato un vocale su WhatsApp riceve la risposta su WhatsApp. Chi ha inoltrato un’email riceve una risposta nella propria casella. Input e output condividono i canali.

La delivery è attivata da condizioni: una soglia superata, una scadenza, un evento, una richiesta esplicita. La scelta progettuale critica è il timing. Un insight su un cliente che sta per uscire non serve a niente se arriva dopo la data di rinnovo. Un’allerta sulle scorte conta nella finestra in cui il riordino è ancora possibile a condizioni favorevoli. Il delivery layer mal progettato trasforma uno strumento utile in un generatore di notifiche inutili.

L’interfaccia web, in questo modello, serve per due cose: visualizzazioni che non entrano in un messaggio (grafici, mappe, confronti complessi, timeline) e configurazione del sistema (fonti dell’enrichment, soglie dell’inferenza, regole di delivery, gestione utenti). L’interfaccia è il pannello di controllo del layer invisibile. Se il prodotto funziona bene, l’utente ci entra di rado.

---

La prima decisione del design

Nei prodotti software tradizionali il designer inizia con gli schermi. Wireframe, user flow, prototipi. In un prodotto costruito su EIID la prima decisione per ogni layer è diversa: ha bisogno di una superficie visiva?

Un delivery layer che manda messaggi su WhatsApp o Telegram ha bisogno di struttura dei messaggi e formattazione per canale, non di schermate. Un enrichment layer che accetta email inoltrate ha bisogno di regole di parsing, non di form. Un inference layer che opera su batch notturni ha bisogno di configurazione delle soglie, non di dashboard in tempo reale.

Solo i layer che richiedono visualizzazione o configurazione complessa ottengono un’interfaccia grafica. L’information architecture viene prima di qualsiasi decisione visiva: quali sono gli oggetti centrali per l’utente, quanti elementi può contenere la navigazione, qual è il punto focale di ogni schermata, quale contenuto è di superficie (quotidiano), quale a un click di profondità (settimanale), quale sepolto (mensile).

Un prodotto AI-native ben progettato potrebbe avere tre schermate contro le trenta di un software tradizionale. La complessità si è spostata nella progettazione dei layer invisibili: le regole di parsing dell’enrichment, la scelta delle domande dell’inferenza, la struttura narrativa dell’interpretazione, il timing della delivery. Il lavoro di design più importante è quello che l’utente non vede.

---

Dove si sposta il valore

Se la forma del software cambia, cambiano i ruoli di chi lo costruisce. Il World Economic Forum riporta che il 65% degli sviluppatori si aspetta una ridefinizione del proprio ruolo nel 2026, dalla scrittura di codice verso architettura, integrazione e decision-making. La direzione è giusta, ed EIID è la risposta che in Play New ci siamo dati per renderla concreta.

Chi programma passa dalla costruzione di interfacce alla progettazione dei flussi tra i quattro layer: come i dati entrano, come vengono normalizzati, quali inferenze vengono eseguite, come i risultati vengono impacchettati e consegnati attraverso quale canale. La competenza che guadagna valore è il pensiero sistemico e la capacità di vedere come i componenti interagiscono. La scrittura di codice, che l’AI replica a costo decrescente, perde valore economico. Il valore intrinseco (saper programmare) resta: lo porta con sé chi sa applicarlo a problemi di sistema.

Chi progetta passa dal disegno di schermate alla progettazione di architetture informative e logiche di consegna. La domanda si sposta: “questo layer ha bisogno di uno schermo, e se sì, quale informazione deve contenere e in quale ordine di priorità?” Il design di un prodotto AI-native è per l’80% invisible design: struttura dei messaggi, template di notifica, regole di escalation, formato delle interpretazioni. Il 20% visivo è denso, funzionale, costruito attorno a visualizzazioni che non possono vivere in un messaggio. Il designer che lavora solo su schermi ha una superficie d’azione che si restringe, mentre quello che sa progettare un sistema di delivery ha una superficie che si espande.

Chi gestisce il prodotto passa dal backlog alla mappa delle domande. In un prodotto AI-native la roadmap diventa una mappa delle domande a cui il sistema sa rispondere e di quelle che non sa ancora formulare. Il product manager diventa il traduttore tra la conoscenza di dominio del cliente e la logica di inferenza del sistema: dove il segnale è debole, dove il contesto manca, dove il timing della delivery va ricalibrato.

Nessuno di questi ruoli scompare: si spostano verso l’alto nella catena del valore, dove il giudizio umano ha più peso dell’esecuzione. La dinamica è quella che Choudary descrive per ogni competenza che l’AI tocca: il valore intrinseco (saper fare la cosa) resta intatto, il valore economico (quanto il mercato paga per quella competenza) si redistribuisce seguendo la scarsità, il valore contestuale (quanto quella competenza è determinante nel sistema specifico in cui opera) cresce per chi sa leggere il contesto del proprio dominio.

Chi continua a scrivere codice per feature, disegnare schermate per dashboard, priorizzare backlog per sprint sta lavorando sulla parte della catena dove il valore economico scende. Chi impara a progettare per i quattro layer sta lavorando dove il valore sale. La scelta è individuale, ma la direzione del movimento no.

---

Progettare per il sistema

La produzione di codice è più abbondante e più economica di quanto sia stata in qualsiasi anno precedente. La capacità di progettare sistemi dove quell’abbondanza di codice produce valore reale per chi lo usa resta scarsa, e lo sarà per anni.

EIID è una griglia operativa: prendere un prodotto, scomporlo nei quattro layer, e per ciascuno decidere cosa automatizzare, dove il giudizio umano è determinante, e quali configurazioni diventano possibili ora che un vincolo precedente è caduto. È la stessa logica delle tre mosse strategiche descritte nell’articolo sull’organizzazione AI-ready, applicata alla progettazione del software.

Con Play New abbiamo tradotto questa griglia in uno strumento. SuperSkills è un plugin open source per Claude Code che applica il modello EIID alla progettazione, all’audit e alla manutenzione di prodotti AI-native. Mappa i quattro layer, identifica gap strategici, verifica la coerenza del design, genera un sistema di decisioni architetturali documentato. Lo stiamo testando e migliorando continuamente: il feedback è benvenuto!