Qualche mese fa, la comunità degli sviluppatori è stata affascinata da un nuovo fenomeno: il vibe coding. La premessa era inebriante nella sua semplicità: non serviva un piano, un diagramma di flusso o persino una profonda comprensione della sintassi; bastava descrivere una sensazione a un agente IA e guardare il codice materializzarsi. Sembrava magia, finché non è apparso il primo bug critico. Improvvisamente, quell'esperienza fluida si è trasformata in un ciclo frenetico di "aggiusta questo" e "ora quello si è rotto", lasciando lo sviluppatore intrappolato in una conversazione con una macchina che aveva perso il filo del discorso.
Storicamente, passavamo mesi a rifinire documenti di requisiti esaustivi prima di scrivere una singola riga di codice — un processo rigido che spesso soffocava l'innovazione; oggi, spesso rilasciamo codice prima ancora di aver deciso cosa il prodotto debba effettivamente fare — un'abitudine caotica che crea un enorme debito tecnico. Questa tensione ha dato vita a un nuovo paradigma: lo spec-driven development (SDD), ovvero lo sviluppo guidato dalle specifiche. È la via di mezzo pragmatica, progettata per dare agli agenti IA i binari di cui hanno bisogno senza tornare ai gonfi metodi waterfall degli anni '90.
Fondamentalmente, lo sviluppo guidato dalle specifiche riguarda la creazione di una "fonte di verità" che sia gli esseri umani che le macchine possano leggere. Den Delimarsky di Microsoft descrive una specifica come un "controllo di versione per il tuo pensiero" e, in pratica, funziona come un contratto vincolante. Invece di lanciare prompt vaghi a uno schermo sperando nel meglio, lo sviluppatore scrive un documento conciso e strutturato che definisce esattamente come il codice debba comportarsi.
Tecnicamente parlando, questo cambiamento risolve il problema della "deriva del contesto". Gli agenti IA sono brillanti nell'esecuzione ma inclini a dimenticare il "perché" dietro una funzionalità dopo cinquanta cicli di revisioni. Ancorando il processo di sviluppo a una specifica, ci assicuriamo che l'IA rimanga un assistente piuttosto che una mina vagante. Birgitta Böckeler di Thoughtworks identifica tre livelli di questa evoluzione: spec-first, dove il piano precede il codice; spec-anchored, dove il documento sopravvive per guidare la manutenzione; e l'aspirazionale spec-as-source, dove l'essere umano tocca solo la specifica e il codice sottostante rimane interamente "sotto il cofano".
Sviluppato da un team d'opinione all'interno di AWS, Kiro è uno strumento robusto che tratta la costruzione del software come una disciplina ingegneristica piuttosto che come un gioco d'ipotesi. Offre sia un IDE che una CLI, ma il suo vero potere risiede nei suoi requisiti markdown strutturati. Kiro utilizza EARS (Easy Approach to Requirements Syntax), una notazione che forza la chiarezza attraverso un modello semplice: QUANDO [condizione], IL SISTEMA DOVRÀ [comportamento].
Attraverso questa lente utente, scrivere un requisito EARS sembra meno "programmare" e più mappare la logica. Questa struttura permette a Kiro di generare test basati sulle proprietà che sono molto più completi dei test unitari standard, intercettando casi limite che uno sviluppatore umano — o un'IA guidata dal "vibe" — probabilmente trascurerebbe. Inoltre, Kiro introduce il concetto di file di "guida" (steering files). Questi documenti — product.md, tech.md e structure.md — agiscono come l'infrastruttura invisibile del progetto, garantendo che ogni pezzo di codice generato rispetti lo stack tecnologico e le convenzioni architettoniche scelte.
Lo Spec Kit di Microsoft adotta un approccio diverso, funzionando come un ponte open-source tra trenta diversi agenti di codifica e un processo strutturato in quattro fasi. Mentre il vibe coding sembra un brainstorming non strutturato, lo Spec Kit sembra un workshop professionale. Introduce una suite di comandi slash — come /speckit.plan e /speckit.analyze — che costringono l'agente a fermarsi e pensare prima di iniziare a scrivere.
Paradossalmente, aggiungendo questi "punti di attrito", lo Spec Kit accelera effettivamente lo sviluppo. Previene i "cicli di allucinazione" in cui un agente cerca di correggere un bug introducendone uno nuovo e più complesso. Che si stia costruendo un progetto greenfield da zero o si cerchi di districare una codebase legacy frammentata, lo Spec Kit fornisce una costituzione per il progetto. Sposta lo sviluppatore umano dal ruolo di dattilografo a quello di revisore, concentrandosi sulla logica di alto livello mentre l'agente gestisce i dettagli implementativi più pesanti.
Tessl introduce un livello affascinante nell'ecosistema SDD: il registro dei pacchetti. Se pensiamo al codice come a una ricetta, Tessl fornisce gli ingredienti standardizzati e le tecniche di cottura attraverso i suoi "tile" (tasselli). Questi tasselli contengono workflow procedurali (competenze), standard di codifica obbligatori (regole) e documentazione che gli agenti possono interrogare su richiesta.
In termini quotidiani, usare Tessl è come dare al proprio agente IA una tessera della biblioteca e un insieme di regole della casa. Installando il tassello SDD di Tessl e chiedendo semplicemente all'agente di "usare lo sviluppo guidato dalle specifiche", il flusso di lavoro cambia. L'agente smette di agire come un completamento automatico servile e inizia ad agire come un ingegnere junior che pone domande di chiarimento e redige un piano prima di toccare il repository. Questa trasparenza è vitale; trasforma l'opaca "scatola nera" della generazione IA in un processo visibile e verificabile.
Se gli altri strumenti si concentrano sul "cosa" e sul "come", Zenflow si concentra sul "chi" e sul "dove". Sviluppato dal team di Zencoder, Zenflow funge da livello di orchestrazione, coordinando più agenti IA per lavorare in parallelo senza corrompere la codebase. Tratta ogni funzionalità come un workflow, utilizzando worktree Git isolati per garantire che le modifiche siano testate e revisionate prima di raggiungere il ramo principale.
Allargando lo sguardo a livello industriale, Zenflow rappresenta un passaggio verso i sistemi "multi-agente". In questo modello, un agente potrebbe scrivere la specifica, un altro implementa il codice e un terzo esegue una revisione del codice tra agenti. Questo sistema di pesi e contrappesi imita un team di ingegneria umano ad alte prestazioni. Per l'utente, il risultato è un ciclo di sviluppo resiliente in cui i test falliti innescano correzioni automatiche e il codice viene rilasciato solo una volta superati tutti i gate di verifica.
La transizione dal vibe coding allo sviluppo guidato dalle specifiche rivela un profondo cambiamento nel nostro rapporto con il software. Ci stiamo rendendo conto che la "magia" dell'IA è più efficace quando è guidata dall'intenzionalità umana. Proprio come un armadio disordinato è facile da riempire ma impossibile da navigare, una codebase non strutturata è facile da generare ma impossibile da mantenere.
In definitiva, l'ascesa di strumenti come Kiro, Spec Kit, Tessl e Zenflow suggerisce che il futuro della programmazione non riguarda la scomparsa del rigore tecnico, ma la sua evoluzione. Ci stiamo allontanando dall'era dell'"hacker solitario" per dirigerci verso l'era dell'"architetto tecnico". In questo nuovo mondo, il nostro valore come esseri umani non risiede nella capacità di ricordare la sintassi, ma nella capacità di definire specifiche chiare, etiche ed efficienti per le macchine che costruiscono il nostro mondo.
Mentre navighiamo in questi cambiamenti, dovremmo guardare i nostri strumenti digitali con un occhio più attento. La prossima volta che l'aggiornamento di un'app sembra pesante o macchinoso, chiedetevi: è stato costruito con una specifica o era solo un "vibe"? Riconquistare il controllo sul nostro software inizia esigendo la chiarezza che solo una specifica ben scritta può fornire.



La nostra soluzione di archiviazione e-mail crittografata end-to-end fornisce i mezzi più potenti per lo scambio sicuro dei dati, garantendo la sicurezza e la privacy dei tuoi dati.
/ Creare un account gratuito