Spec Kit e' un toolkit open source di GitHub per lo sviluppo guidato dalle specifiche con agenti di coding AI. Da' al team una sequenza fissa di comandi, constitution, specify, plan, tasks, implement, cosi' l'agente lavora da una specifica scritta e non da un prompt approssimativo. Il repository e' con licenza MIT e, alla consultazione del 6 ottobre 2026, mostrava oltre 140.000 stelle. Cio' che standardizza e' l'input: cosa si chiede all'agente di costruire, in che ordine, con quali principi. Non produce invece un registro di cosa l'agente ha fatto davvero: quali file sono cambiati, quali controlli sono girati, chi ha rivisto il risultato e chi lo ha firmato. Una specifica e' un'istruzione scritta prima del lavoro. La prova e' cio' che resta dopo, e chi consegna software a un cliente ha bisogno di entrambe.
Cosa standardizza davvero Spec Kit?
Il problema e' reale. Senza una struttura condivisa, ogni funzionalita' parte da un prompt diverso e l'interpretazione di "costruisci questo" da parte dell'agente cambia da una sessione all'altra. Spec Kit fissa la forma della conversazione. Un file constitution contiene i principi non negoziabili del progetto. Il passo specify trasforma una richiesta in una specifica scritta. Plan e tasks la scompongono in decisioni tecniche e unita' di lavoro ordinate, e implement le esegue con l'agente supportato che il team usa.
E' un miglioramento vero rispetto all'improvvisazione, ed e' il motivo per cui si e' diffuso. Rientra anche nel movimento piu' ampio verso il context engineering: quanto meglio e' scritto il contesto, tanto meno l'agente deve tirare a indovinare. Il merito va riconosciuto: un team che lo usa istruisce i propri agenti in modo piu' coerente di uno che non lo fa.
Specifica, piano, task: qual e' il contratto prima del lavoro?
Si legge la sequenza come un contratto. La specifica dice cosa, il piano dice come, i task dicono in che ordine. Ogni passo e' un file markdown nel repository, versionato insieme al codice, che e' meglio di una cronologia di chat destinata a sparire.
| Artefatto | Scritto | Risponde a | Non risponde a | | --- | --- | --- | --- | | Constitution | Una volta, all'inizio | Quali principi valgono sempre | Se questa modifica li ha rispettati | | Specifica | Prima del lavoro | Cosa va costruito | Se cio' che e' stato costruito corrisponde | | Piano | Prima del lavoro | Come va costruito | Se l'agente lo ha seguito | | Task | Prima del lavoro | In che ordine | Quale task ha cambiato quale file |
Ogni artefatto della tabella descrive un'intenzione. Nessuno e' scritto dopo che l'agente ha finito, quindi nessuno puo' descrivere cosa e' successo.
C'e' un divario fra la specifica e il diff che arriva?
Si', ed e' lo stesso divario che AGENTS.md lascia aperto. Una specifica si legge all'inizio di una sessione. L'agente puo' seguirla fedelmente, in parte, o interpretare una riga ambigua in un modo che nessuno voleva. L'unico modo per saperlo e' confrontare la specifica con il diff reale, e quel confronto e' un passo a parte che i file di specifica del toolkit non eseguono da soli.
Il toolkit offre anche passi per affinare e riconciliare i documenti scritti, utili a intercettare contraddizioni fra loro. Confrontano documenti con documenti. La domanda di un cliente o di un revisore e' un'altra: il codice di questa pull request fa quello che era stato concordato, e cosa lo dimostra?
Perche' il tasso di successo al primo colpo non e' una traccia di audit?
Gli strumenti guidati dalle specifiche si vendono di solito con una metrica: quante volte l'agente ci azzecca al primo tentativo. E' utile per il pomeriggio dello sviluppatore. Non e' una prova per nessun altro. Un tasso di successo alto dice che la maggior parte delle esecuzioni e' andata bene, non quale esecuzione ha prodotto questa modifica, con quale autorizzazione, rivista da chi. Lo studio randomizzato di METR pubblicato il 10 luglio 2025 ricorda che velocita' percepita e risultati misurati possono divergere: sviluppatori esperti hanno impiegato il 19% in piu' con gli strumenti AI credendo di essere piu' veloci. Il successo dichiarato da chi lavora e' il segnale piu' debole, e una traccia di audit deve essere indipendente da quello che l'agente dice di se'.
Cosa serve a un flusso guidato dalle specifiche per diventare prova?
Si tiene il flusso di specifica. Poi si aggiunge cio' che non e' stato pensato per contenere, come elenco:
- Un passo di verifica eseguito da qualcosa di diverso dall'agente, con l'output conservato.
- Un controllo di perimetro: il diff tocca solo i percorsi che il task permetteva.
- Un collegamento da ogni task del piano al commit che lo ha implementato.
- Una persona con nome che ha rivisto il risultato e lo ha firmato prima del rilascio.
- Un registro che sopravvive alla sessione, cosi' la risposta a "cosa e' successo martedi' scorso" non dipende dalla memoria di nessuno.
E' il livello che Detent, l'impianto di delivery end-to-end aggiunge sopra una specifica: il sistema prepara, una persona firma, e senza quella firma niente viene rilasciato. Una software house puo' usare Spec Kit per il briefing e avere comunque bisogno di quel livello per la prova. Per il quadro piu' ampio di cosa deve coprire un flusso controllato, vedi cosa serve a un framework di AI governance per il codice scritto da agenti, e per il confronto fra gli strumenti su cosa lasciano dopo, il benchmark.