Progettazione software AI-first dai primi principi: una guida per la pratica

La maggior parte delle squadre ha adottato l’IA senza rivedere una sola assunzione sottostante, ed è per questo che il risultato è diventato più rapido e i sistemi peggiori.

Ecco la domanda che la maggior parte delle squadre di ingegneria non ha ancora detto ad alta voce: se il modello può scrivere il codice, in cosa esattamente dovremmo essere bravi adesso?

Le risposte che sento sono in gran parte difensive. Arte del prompt. Revisione del risultato dell’IA. Sapere quale strumento prendere. Tutte competenze reali, tutte a valle dello spostamento vero, e nessuna spiega la cosa che continuo a vedere in pratica: squadre che hanno adottato gli stessi strumenti, nello stesso trimestre, con gli stessi modelli, e sono finite in posti completamente diversi. Un gruppo rilascia più in fretta e il software tiene. L’altro rilascia più in fretta e passa il trimestre successivo a scoprire cosa ha rotto.

Stessi strumenti. Esiti opposti. Quella differenza non riguarda il modello.

L’amplificatore che nessuno aveva messo nel conto

Il rapporto DORA del 2025 sullo stato dello sviluppo software assistito dall’IA ha messo dei numeri su questo. Il 90% delle persone che lavorano nella tecnologia usa ora l’IA al lavoro, e più dell’80% crede che abbia aumentato la propria produttività. Entrambe le cose non sorprendono. Il risultato che conta è il terzo: una maggiore adozione dell’IA è associata a un aumento della produttività di rilascio e a un aumento dell’instabilità dei rilasci, allo stesso tempo.

Rileggilo, perché è tutto l’argomento. Lo strumento ha reso le squadre più rapide a rilasciare e peggiori a tenere le cose in funzione. Non una cosa o l’altra. Entrambe.

L’inquadratura di DORA è che l’IA è un amplificatore: ingrandisce la pratica su cui atterra. I sistemi solidi diventano più solidi. I sistemi deboli diventano più rapidi nell’essere deboli.

Il che significa che la domanda interessante non è mai stata «come adottiamo l’IA». Era «cosa amplifica l’IA in noi». E per rispondere serve tornare più indietro di qualsiasi decisione su uno strumento.

Ragionare dal problema, non dallo strumento

Il pensiero dai primi principi è una di quelle espressioni ripetute fino a perdere senso, quindi vorrei essere preciso su cosa intendo e cosa no.

Ragionare per analogia è come è stata la maggior parte dell’adozione dell’IA. Avevamo un modo di lavorare nello sviluppo. È arrivata una nuova capacità. Ci siamo chiesti dove la capacità si inserisse nel flusso, l’abbiamo aggiunta nel punto di minor resistenza, di solito la scrittura del codice, e abbiamo lasciato tutto il resto uguale. Riunioni quotidiane, ticket, cicli di lavoro, revisioni, tutto conservato. Il flusso è stato trattato come un dato e lo strumento adattato a esso.

Ragionare dai primi principi pone una domanda più difficile. Riduci il processo a ciò che è davvero, fisicamente vero sul costruire software. Poi chiedi quale di quelle verità il modello abbia cambiato, e quale non abbia toccato. Ricostruisci da ciò che sopravvive.

Fallo con onestà e scoprirai che l’IA ha cambiato esattamente una cosa, e non è quella che la categoria sta vendendo.

Il costo di produrre codice è andato quasi a zero. Il costo di decidere quale codice dovrebbe essere non si è mosso.

Tutto ciò che è utile segue da questa singola asimmetria. Qui sotto ci sono le quattro conseguenze che vorrei che chiunque nella pratica sapesse enunciare a memoria.

Uno: il modello dei dati è il prodotto

Lo schermo è la parte più volatile di qualsiasi applicazione e il posto più tentante da cui partire, perché è la parte che si vede. È anche la parte che dovrebbe costare meno buttare.

Il modello dei dati è l’opposto. Decide cosa puoi chiedere, cosa puoi indicizzare, cosa puoi cambiare dopo senza una migrazione che spaventa tutti. Ogni capacità a valle è vincolata da scelte prese, o improvvisate, a quel livello.

Quando il codice era costoso, questo ordine si imponeva da sé. Nessuno scriveva a mano cento schermate contro uno schema a cui non aveva pensato, perché scrivere a mano cento schermate richiedeva un trimestre. La generazione ha rimosso quel cancello naturale. Ora puoi produrre un’interfaccia intera contro un modello dei dati che nessuna persona ha mai rivisto, e sembrerà finita.

L’ordine deve quindi diventare deliberato. Prima il modello, poi il contratto, poi l’interfaccia. Non perché sia tradizionale, ma perché è il solo ordine in cui le decisioni costose vengono prese quando cambiarle costa ancora poco.

Due: una decisione rinviata viene presa comunque

È quella che chi sta nella pratica sottovaluta.

Ogni decisione che non prendi esplicitamente viene comunque presa. La prende il generatore, al momento della generazione, da un contesto che non comprende la tua attività, la tua superficie di conformità, la tua storia di migrazioni o i tuoi piani per il trimestre prossimo. Il modello non si rifiuta di decidere. Sceglie qualcosa di plausibile e va avanti.

Cosa può ancora vedere un utente con un abbonamento disdetto? Cosa succede quando due persone modificano lo stesso record? Un indirizzo di posta elettronica è unico, e unico rispetto a cosa? Nessuno ha promptato quelle domande, quindi nessuno ha risposto, e l’applicazione ora ha una risposta a tutte e tre, scelta per inferenza, scopribile solo sbattendoci contro in produzione.

È il meccanismo dietro ciò che le comunità di chi costruisce hanno chiamato il problema del 70%. Il progresso si arresta non perché il lavoro che resta sia difficile, ma perché è bloccato da decisioni prese in silenzio, diverse centinaia di generazioni prima, che non si possono più cambiare senza smontare tutto.

La pratica che risolve questo ora ha un nome: sviluppo guidato dalle specifiche. Scrivi prima i requisiti, i vincoli e i criteri di successo. Tratta quel documento come la fonte della verità. Lascia che l’agente costruisca contro di esso. GitHub ha rilasciato Spec Kit, AWS ha rilasciato Kiro, e la convergenza non è un caso.

Tre: quando la generazione è gratis, i vincoli vanno scritti

Per decenni la correttezza è stata in parte sostenuta dal costo di scrivere codice. Chi implementava una regola doveva tenere la regola in mente. La conoscenza tacita in una testa umana era un posto accettabile per conservare un vincolo, perché una persona era sempre nel ciclo.

Quel luogo di conservazione non funziona più. Se un vincolo non è espresso in qualche punto leggibile dalle macchine (un vincolo di schema, un tipo, una regola di validazione, un test, una riga esplicita in una specifica) per il generatore non esiste. Esiste solo nella memoria di chi sta per essere sorpreso.

È il nucleo pratico del progetto AI-first, e non è affatto affascinante. Spingi gli invarianti giù nello strato che può imporli. «Non nullo» e «unico» nel database anziché in un gestore di modulo. Tipi ai confini anziché in un commento nel codice. Autorizzazione come politica che il sistema valuta anziché come condizione che qualcuno si è ricordato di scrivere in un punto di accesso.

Ogni vincolo che porti fuori è una decisione che il modello non può più sbagliare.

Quattro: ora stai costruendo per due consumatori

L’ultima è la più recente, e quella che la maggior parte delle squadre non ha interiorizzato affatto.

La tua applicazione ora ha due tipi di utente. Uno è una persona che guarda uno schermo. L’altro è un agente che chiama un’API, che non vede mai la tua interfaccia e non può essere persuaso dal buon design. Se una capacità esiste nella tua interfaccia ma non nella tua API, allora per quanto riguarda l’economia degli agenti non esiste.

Questo ha una conseguenza di progetto: la parità non è un’aggiunta gradevole. Tutto ciò che una persona può fare tramite l’interfaccia dovrebbe essere raggiungibile tramite una superficie definita, documentata e reperibile. Ed è anche il motivo per cui GraphQL calza meglio di REST per il consumo da parte degli agenti: uno schema che si descrive da sé è qualcosa che una macchina può esplorare senza che prima una persona scriva note di integrazione.

Costruisci per l’agente e l’interfaccia umana diventa più semplice come effetto collaterale. Costruisci solo per la persona e finirai per applicare a posteriori un’API sotto la pressione di una scadenza, che è il momento peggiore possibile per progettarne una.

Come appare nei dati saltare tutto questo

GitClear ha analizzato 623 milioni di modifiche al codice dal 2023 al 2026, e il quadro della manutenibilità è coerente con tutto quanto sopra.

Rispetto al riferimento del 2023, i blocchi di codice duplicati sono aumentati dell’81%. Il copia e incolla dentro lo stesso invio è salito dal 9,4% nel 2022 al 15,7% nella prima metà del 2026. I costrutti che mascherano gli errori sono aumentati del 47%. Nel frattempo le chiamate di funzione tra file, il segnale più chiaro disponibile del riuso del codice, sono calate del 35%, e l’attività di rifattorizzazione è crollata dal 21% delle modifiche nel 2022 al 3,8% finora nel 2026.

Chi sviluppa ha ora circa cinque volte più probabilità di copiare e incollare che di rifattorizzare. Nel 2022 quel rapporto andava nella direzione opposta.

Nulla di questo è un problema di qualità del modello. Duplicazione anziché riuso, gestione degli errori che inghiotte anziché portare a galla, rifattorizzazione che smette di accadere: è ciò che ottieni quando la generazione è economica e la struttura non è il compito esplicito di nessuno. Il risultato è localmente plausibile e globalmente incoerente, che è precisamente il modo di fallire che un flusso partito dallo schermo non può rilevare.

Come lavorare così, iniziando questa settimana

Nulla di tutto questo richiede una riorganizzazione. Richiede di cambiare l’ordine di quattro o cinque abitudini.

1. Scrivi il modello dei dati prima della prima schermata. Entità, relazioni, cardinalità, cosa rende unica una riga, cosa si propaga alla cancellazione. Un’ora qui è l’ora con più leva del progetto, ed è quella che gli strumenti ti invitano attivamente a saltare.
2. Fai della specifica l’artefatto che rivedi, non del diff. Se la specifica è giusta e la generazione le è fedele, rivedere migliaia di righe di codice generato è teatro. Rivedi il documento che le ha prodotte. Discuti della specifica mentre discutere costa ancora poco.
3. Porta fuori ogni vincolo che riesci a nominare. Prima di generare, elenca le regole che non devono mai essere violate e metti ciascuna in un punto dove il sistema la impone. Tutto ciò che resta nella conversazione verrà prima o poi violato da qualcosa che non ha mai partecipato alla conversazione.
4. Progetta l’API come la superficie del prodotto. Poi tratta l’interfaccia umana come un consumatore di essa. È più una scelta di ordine che di ingegneria, e ordinarla tardi è ciò che la rende costosa.
5. Misura l’instabilità, non solo la produttività. Il risultato di DORA è che velocità e fragilità sono cresciute insieme, quindi misurare solo la velocità ti mostrerà la metà buona della tua tendenza. Il tasso di guasto delle modifiche e il tempo di ripristino sono i numeri che ti dicono se l’amplificatore stia lavorando per te.

Quanto costa

Voglio essere sincero sul compromesso anziché fingere che non ci sia.

Lavorare così è più lento per la prima settimana di un progetto e materialmente più rapido per ogni settimana successiva. È un costo reale, pagato in anticipo, esattamente nel momento in cui lo slancio sembra più prezioso e un concorrente sta rilasciando qualcosa di visibile. Ci saranno cicli di lavoro in cui la squadra che ha saltato tutto questo sembrerà in vantaggio.

Non è nemmeno gratis in disciplina. Scrivere i vincoli è meno piacevole che guardare un’interfaccia apparire. Rivedere una specifica è meno soddisfacente che rivedere codice. Queste abitudini decadono sotto la pressione delle scadenze, che è la stessa pressione che le rende importanti.

E parte di tutto questo davvero non si applica. Se stai validando un’idea questo fine settimana e intendi buttare il risultato, buttalo: nulla di quanto sopra vale la pena per software con due giorni di vita. L’argomento qui riguarda le applicazioni che sopravvivono alla propria dimostrazione.

La parte che non è mai stata automatizzabile

Alcuni ruoli costruiti attorno alla produzione di codice si ridurranno. Alcuni scompariranno. Sostenere il contrario non aiuta nessuno a prepararsi, e le persone che ti dicono che ogni posto in ingegneria è al sicuro non ti stanno facendo un favore.

Ma guarda cosa ha fatto davvero quell’asimmetria. Ha automatizzato l’espressione delle decisioni e ha lasciato le decisioni stesse completamente intatte. Cosa costruire. Cosa non costruire. Quali invarianti valgono. Cosa il sistema non deve mai fare. Dove stanno i confini e chi può attraversarli.

Quel lavoro è sempre stato la parte difficile. Era solo nascosto sotto la fatica di digitare, che era abbastanza costosa da sembrare il lavoro.

Digitare non è mai stato il lavoro.

Letture collegate

La pratica in profondità: sviluppo guidato dalle specifiche. Se stai scegliendo uno strumento: i migliori costruttori di app con IA nel 2026.

Domande frequenti

Che cosa significa «progettazione software AI-first»? Progettare un’applicazione partendo dall’assunto che la maggior parte del codice verrà generata anziché scritta a mano, e che alcuni consumatori saranno agenti anziché persone. In pratica significa che modello dei dati, vincoli e contratto di API vengono definiti esplicitamente in anticipo, perché sono le decisioni che la generazione non può prendere per te.

In cosa il progetto AI-first differisce dall’usare semplicemente strumenti di IA per il codice? Usare strumenti di IA aggiunge una capacità a un flusso invariato. Il progetto AI-first cambia l’ordine delle operazioni del flusso: modello e contratto prima dell’interfaccia, specifica come artefatto rivisto, vincoli spinti in strati che li impongono. La ricerca DORA del 2025 ha trovato che l’adozione dell’IA ha alzato insieme produttività e instabilità, che è ciò che accade quando cambia lo strumento e non la pratica.

Quali sono i primi principi della progettazione software nell’era dell’IA? Quattro tengono: il modello dei dati è il prodotto e lo schermo ne è una vista; qualsiasi decisione che non prendi esplicitamente viene presa implicitamente dal generatore; i vincoli devono vivere in un posto imponibile dalle macchine anziché nella testa di qualcuno; e la tua applicazione ora serve sia un’interfaccia umana sia un’API rivolta agli agenti, che hanno bisogno di parità.

Progettare così rallenta le squadre? Anticipa il lavoro anziché aggiungerlo. Le decisioni catturate in un modello dei dati e in una specifica vengono prese comunque da qualcuno: o deliberatamente all’inizio o implicitamente da un modello che indovina più tardi. La seconda via è l’origine delle rilavorazioni, e rilavorare non è più rapido.

Lo sviluppo guidato dalle specifiche è la stessa cosa del progetto AI-first? Lo sviluppo guidato dalle specifiche è la pratica; il progetto AI-first è l’insieme più ampio di conseguenze architetturali. Il primo copre lo scrivere la specifica e generare contro di essa. Il progetto AI-first copre anche l’ordine della modellazione dei dati, il luogo in cui i vincoli vengono imposti e il progettare per consumatori agentici accanto a quelli umani.

Quando va bene saltare tutto questo? Prototipi, dimostrazioni, pezzi interni una tantum e qualsiasi cosa che pensi di scartare. Il peso in più vale la pena solo per software che deve sopravvivere a utenti veri, dati veri e cambiamento nel tempo.