Cos'è lo sviluppo software AI-native
Lo sviluppo software con l'AI, nella versione che Anthropic chiama AI-native, è un modo di costruire software in cui l'intelligenza artificiale lavora in ogni fase del ciclo di vita, dall'idea alla manutenzione, e ogni fase si chiude con un documento scritto e salvato che la fase successiva legge. Non è "far scrivere il codice a ChatGPT": è riorganizzare tutto il processo intorno a un agente che scrive, verifica e mantiene, con le persone che decidono nei punti che richiedono giudizio.
Il ciclo di vita del software si chiama SDLC (Software Development Life Cycle): è il percorso che porta un'idea a diventare un programma usato da tutti. Nel modello classico le fasi sono sei: raccolta dei requisiti, progettazione, scrittura del codice, test, messa online e manutenzione. Per decenni la fase più lenta è stata la scrittura del codice, fatta a mano per settimane o mesi.
Il 21 agosto 2026 Anthropic, l'azienda che sviluppa Claude e Claude Code, ha pubblicato "The AI-native SDLC playbook", firmato da Louis Claxton: il documento che spiega come ricostruire ogni fase quando il codice lo scrive un agente. Fonte: Anthropic, The AI-native SDLC playbook, 2026.
Come funziona il ciclo AI-native di Anthropic: le 6 fasi
Il playbook parte da una constatazione: con agenti come Claude Code la costruzione del software passa da settimane a ore, e a quel punto il collo di bottiglia non è più il codice, ma le fasi che vanno ancora alla velocità delle persone: capire cosa serve, rivedere, approvare. Le sei fasi servono a velocizzare proprio quelle, e sono legate da una catena di documenti: intent.md, spec.md, plan.md, poi il codice, la revisione e il registro degli incidenti.
1. Plan: l'intent.md, che può scrivere chiunque
Tutto parte da un file breve, l'intent.md (il file dell'intenzione). Lo scrive chi ha avuto l'idea, anche una persona non tecnica, facendo un brainstorming con Claude: un commerciale che vede un problema nei preventivi, un'amministrazione che perde ore su un report. Secondo il playbook contiene cinque parti:
- Il problema: cosa non funziona oggi;
- Il risultato atteso: cosa deve cambiare;
- Utenti e sistemi coinvolti: chi e cosa viene toccato;
- I vincoli: cosa non si può fare o cambiare;
- Le domande aperte: cosa non si sa ancora.
Prima di passare alla fase successiva, un responsabile di prodotto (il product owner) lo approva. Il risultato: niente più settimane di riunioni per raccogliere i requisiti. Il playbook indica come obiettivo passare dalle settimane di raccolta alle ore.
2. Design: lo spec.md, rivisto dal responsabile di prodotto
Il product owner prende gli intent.md approvati e, insieme a Claude, li trasforma in uno spec.md: requisiti e progetto tecnico nello stesso documento. Qui entrano le regole dell'azienda (sicurezza, privacy, marchio, esperienza d'uso), scritte come skill che Claude applica mentre scrive, invece di scoprirle a lavoro finito. Lo spec.md risponde anche alle domande aperte dell'intento e segnala i punti delicati da decidere.
3. Build: il plan.md, approvato prima di scrivere codice
Dallo spec.md Claude prepara il plan.md, il piano di lavoro: quali file cambiano, in che ordine, quali rischi ci sono e come si dimostrerà che funziona. Il criterio di qualità del playbook è netto: si itera finché un ingegnere che non ha mai visto la conversazione potrebbe realizzare la modifica leggendo solo il piano. Un ingegnere approva il plan.md, e solo allora Claude scrive il codice.
4. Test: Claude controlla il proprio lavoro
Il codice non si considera finito quando è scritto, ma quando ha superato i controlli: test automatici, compilazione, controllo della forma del codice e, per le interfacce, confronto delle schermate. Nella pratica i controlli sono di tre livelli: le funzioni (ogni pezzo fa quello che deve), l'interfaccia (pulsanti e schermate si comportano bene) e il percorso completo dell'utente dall'inizio alla fine (i test end-to-end). Se un controllo fallisce, Claude corregge e riprova prima che una persona veda il lavoro.
In più il playbook consiglia di raccogliere da 20 a 50 lavori reali recenti, ognuno con il risultato atteso, e di usarli come banco di prova ogni volta che si cambiano le istruzioni o le skill dell'agente.
5. Deploy: revisione e approvazione
Prima di andare online il codice passa una revisione automatica contro le regole aziendali (errori, sicurezza, conformità) e poi l'approvazione di una persona responsabile. Una regola vale più di tutte: l'agente che ha scritto il codice non ha modo di approvarlo.
6. Maintain: il ciclo si chiude da solo
Quando il software è online, Claude sorveglia i dati di produzione: errori, rallentamenti, anomalie. Se qualcosa esce dai limiti, fa una diagnosi e scrive lui stesso un nuovo intent.md, che rientra nella fase 1 e segue lo stesso percorso di approvazioni. È questo che trasforma il ciclo in miglioramento continuo: le persone non partono ogni volta da zero, ma rivedono quello che l'agente ha trovato.
| Fase | Ciclo tradizionale | Ciclo AI-native (Anthropic) |
|---|---|---|
| Plan | Riunioni e documenti di requisiti, per settimane | intent.md scritto da chiunque con Claude, in ore |
| Design | Architetti traducono i requisiti in specifiche | spec.md scritto da Claude con le regole aziendali, rivisto dal product owner |
| Build | Codice scritto a mano, settimane o mesi | plan.md approvato, poi codice scritto da Claude in ore |
| Test | Team di qualità dopo lo sviluppo | Claude verifica da solo prima di consegnare, più 20-50 casi reali |
| Deploy | Revisione manuale riga per riga | Revisione automatica e approvazione umana obbligatoria |
| Maintain | Un team risponde ai problemi quando arrivano | Claude sorveglia i dati e scrive i nuovi intent.md |
Un modo diverso di guardare lo stesso tema, quello dell'agente che lavora in cicli di esecuzione e verifica, è nella nostra guida al Loop Engineering. Qui invece il punto è l'organizzazione: chi scrive cosa, e dove decide una persona.
Sviluppo software AI-native per le PMI italiane
Il playbook nasce in un'azienda con centinaia di ingegneri, ma la sua idea più utile per una PMI è un'altra: chi conosce il problema può scriverlo, senza saper programmare. Nella maggior parte delle PMI italiane chi ha le idee migliori su cosa automatizzare (il titolare, il responsabile commerciale, l'amministrazione) non ha gli strumenti per trasformarle in software, e il fornitore tecnico riceve richieste vaghe a voce. Un intent.md con problema, risultato atteso, utenti, vincoli e domande aperte è già una richiesta chiara, e costa mezz'ora di brainstorming con Claude.
In una piccola azienda i ruoli si accorciano: il product owner è spesso il titolare, l'ingegnere è una persona interna o un'agenzia esterna. Ma le tre regole di fondo restano valide anche con due persone:
- Ogni passaggio lascia un documento salvato insieme al codice, così niente vive solo nella testa di qualcuno;
- Le regole aziendali si scrivono una volta (privacy, tono del marchio, cosa non fare) e l'agente le applica sempre;
- Una persona approva nei punti in cui serve giudizio, e l'agente non approva mai il proprio lavoro.
Il limite oggi non è la tecnologia ma le competenze: secondo ISTAT, quasi il 60% delle imprese che avevano valutato un investimento in intelligenza artificiale e poi hanno rinunciato indica come freno la mancanza di competenze adeguate. Un processo scritto, con documenti semplici e approvazioni chiare, è proprio il modo per abbassare quella soglia. Fonte: ISTAT, Imprese e ICT, anno 2025.
Come l'AI sta trasformando lo sviluppo software nel 2026
Gli sviluppatori l'intelligenza artificiale la usano già quasi tutti. Nel sondaggio 2025 di Stack Overflow, l'84% dei partecipanti usa o prevede di usare strumenti di AI per sviluppare, contro il 76% dell'anno prima. Nello stesso sondaggio però il 46% dice di non fidarsi dell'accuratezza di quello che l'AI produce. Fonte: Stack Overflow, Developer Survey 2025, sezione AI.
L'84% degli sviluppatori usa o userà l'AI, ma il 46% non si fida di quello che produce: il problema non è scrivere codice più in fretta, è sapere quando quel codice è giusto. (Stack Overflow, Developer Survey 2025)
È esattamente il vuoto che il playbook di Anthropic prova a colmare: la fiducia non viene dal modello, viene dal processo. Dentro Anthropic il cambiamento è già radicale. Boris Cherny, il creatore di Claude Code, ha scritto che negli ultimi trenta giorni il 100% dei suoi contributi a Claude Code era stato scritto da Claude Code stesso. Fonte: Boris Cherny, post su X.
In Italia l'adozione è ancora all'inizio ma accelera: nel 2025 il 16,4% delle imprese con almeno 10 addetti usa almeno una tecnologia di intelligenza artificiale, il doppio dell'8,2% del 2024. Tra le PMI la quota è del 15,7%, tra le grandi imprese del 53,1%. Fonte: ISTAT, Imprese e ICT, anno 2025.
Quanto costa sviluppare software con l'AI
Gli strumenti costano poco rispetto al lavoro che spostano. Claude Code è incluso in tutti i piani a pagamento di Claude, e i prezzi pubblicati da Anthropic sono questi:
| Piano | Prezzo | Per chi |
|---|---|---|
| Pro | 20 $ al mese (17 $ con pagamento annuale) | Una persona che inizia |
| Max | Da 100 $ al mese | Chi lo usa molte ore al giorno |
| Team | 25 $ a persona al mese (20 $ annuale); postazione Premium 125 $ (100 $ annuale) | Piccoli gruppi di lavoro |
Fonte: Anthropic, prezzi di Claude.
Il costo vero non è l'abbonamento, è l'impostazione del processo: scrivere le regole aziendali come skill, preparare i controlli automatici, raccogliere i 20-50 casi reali per le prove, decidere chi approva cosa. È un lavoro che si fa una volta e poi regge ogni progetto successivo. Il rischio opposto, usare l'AI senza processo, costa di più: codice veloce da scrivere e lento da correggere.
Come iniziare: i 3 passi per una PMI italiana
1. Scrivi il primo intent.md
Scegli un problema concreto e ripetitivo (un report che richiede ore, un'attività fatta a mano ogni giorno) e scrivilo con Claude nelle cinque parti del playbook: problema, risultato atteso, utenti coinvolti, vincoli, domande aperte. Se non riesci a riempirle, il problema non è ancora maturo per essere automatizzato.
2. Metti processo e regole in un unico posto
Tieni intent, specifiche, piani e codice nello stesso archivio, con la cronologia delle versioni. Scrivi le regole della tua azienda (privacy, dati dei clienti, tono) in un file di istruzioni e in skill che l'agente legge sempre: è quello che il playbook chiama governance scritta come codice.
3. Decidi i controlli prima di scrivere il codice
Stabilisci come si dimostra che il lavoro funziona: test automatici, da 20 a 50 casi reali con il risultato atteso, e una persona che approva prima della messa online. Senza controlli l'AI scrive più in fretta, ma non meglio.
Come Ogaia costruisce sistemi di sviluppo AI-native per le PMI
In Ogaia | Soluzioni AI & Customer generation per Aziende Italiane costruiamo software e automazioni con Claude Code ogni giorno, e lo facciamo con lo stesso principio del playbook: ogni lavoro parte da un'intenzione scritta, passa da un piano approvato e si chiude con controlli che l'agente non può saltare. Per le PMI progettiamo il processo su misura: come si scrivono le richieste, quali regole aziendali diventano skill, quali controlli automatici servono e dove decide una persona.
Il risultato è un'azienda che trasforma un problema descritto in mezz'ora in uno strumento funzionante, senza dipendere da un reparto tecnico interno. Se vuoi capire quali processi della tua azienda sono pronti per questo metodo, prenota una call gratuita di 45 minuti: uscirai con una mappa chiara dei tuoi colli di bottiglia, indipendentemente da quello che decidi di fare dopo.