Confronto
Deep Work Plan e le alternative
Scelga il livello giusto per la sua situazione. Ogni alternativa è descritta nei suoi termini, ogni fatto risale alla documentazione ufficiale corrispondente e la pagina indica quando è stata revisionata l’ultima volta. Questa è una mappa, non una classifica.
Come leggere questa pagina
Tre valori descrivono ogni capacità. Dicono dove vive una capacità in uno strumento, non quanto è valido lo strumento.
- Integrato
- Opzionale o tramite estensione
- Fuori ambito
Ultima revisione:
Le alternative, nei loro termini
Strumenti di sviluppo spec-driven
-
Strumenti di sviluppo spec-driven
GitHub Spec Kit
Trasforma una funzionalità in una specifica eseguibile attraverso una constitution, una spec, un piano e un elenco di task, guidato da slash command che si integrano con più di cinquanta agenti di coding, e può verificare che gli artefatti restino coerenti tra loro prima dell’implementazione.
Team che vogliono un flusso ripetibile di specify, plan, tasks e implement dentro l’agente che già usano.
-
Strumenti di sviluppo spec-driven
OpenSpec
Cattura ogni modifica come una proposta con spec delta (aggiunte, modificate, rimosse) e requisiti RFC 2119 con scenari, poi le archivia in specifiche vive, con un validatore che verifica la completezza della proposta e la copertura degli scenari prima che una modifica sia accettata.
Team che lavorano su sistemi esistenti e vogliono che le specifiche crescano una modifica alla volta.
-
Strumenti di sviluppo spec-driven
Amazon Kiro
Un IDE e una CLI agentici le cui spec passano da requisiti in stile EARS al design ai task, con file di steering e hook che scattano sugli eventi dell’editor, e che può generare spec per una codebase esistente per individuare le lacune nei requisiti prima che inizi il design.
Sviluppatori che vogliono lo sviluppo spec-driven integrato nel proprio editor con strumenti supportati da AWS.
Framework di workflow per agenti
-
Framework di workflow per agenti
BMAD Method
Un framework agile di ruoli di agenti specializzati (analisi, prodotto, architettura, sviluppo, qualità) che produce brief, requisiti, documenti di architettura e file di story, con una Definition of Done che richiede la revisione di ogni story da parte di un collega o di un agente AI dedicato prima che sia considerata conclusa.
Team che prediligono le cerimonie basate sui ruoli e vogliono un ciclo di vita agile completo per il lavoro degli agenti.
-
Framework di workflow per agenti
Superpowers
Una libreria di skill e un workflow per brainstorming, pianificazione in piccoli passi test-first, esecuzione con subagent e revisione prima del completamento, integrato con più host di agenti di coding di qualsiasi altra alternativa qui presente, oltre a una revisione in due fasi tramite subagent (conformità alla spec, poi qualità del codice) su ogni task.
Sviluppatori che vogliono un’esecuzione test-driven disciplinata dentro il proprio agente di coding.
-
Framework di workflow per agenti
GSD Core
Un sistema di pianificazione con una directory .planning, id dei requisiti, piani per fasi, esecuzione a contesto fresco e un passaggio di verifica rispetto ai deliverable osservabili dall’utente estratti da ogni piano, pensato per contrastare il degrado del contesto eseguendo ricerca, pianificazione ed esecuzione in subagent usa e getta e individuando verifiche obsolete tramite controlli di fingerprint dei contenuti.
Sviluppatori singoli e piccoli team che vogliono context engineering e verifica con poca cerimonia.
-
Framework di workflow per agenti
Gentle-AI
Configura gli agenti di coding che già usi con una memoria persistente che instrada anche tra sessioni e modelli diversi, skill curate, server MCP, personas e, in modo opzionale, Spec-Driven Development o Receipt-Driven Development. La configurazione viene scritta di default nelle impostazioni globali dell’agente; un’installazione con ambito workspace è opzionale.
Sviluppatori che vogliono un ecosistema di agenti configurato che ricordi il lavoro tra le sessioni e possa produrre evidenze su richiesta.
AI-native SDLC
-
AI-native SDLC
Claude's AI-native SDLC
Un ciclo in sei fasi da Plan e Design a Build, Test, Deploy e Maintain, con approvazione umana obbligatoria a ogni fase, artefatti durevoli sottoposti a commit nel repository tra una fase e l’altra, un passaggio di revisione dedicato alla sicurezza prima del deploy e valutazioni continue che pubblicano indicatori di delivery anticipatori e consuntivi.
Team che valutano il playbook di consegna software end-to-end di Claude Code e il suo ciclo di feedback in produzione.
Modalità plan native dei vendor
-
Modalità plan native dei vendor
Modalità plan native dei vendor
I prodotti agentici possono offrire modalità plan, file di istruzioni e skill basati sugli standard aperti e multi-vendor AGENTS.md e Agent Skills, anche se il comportamento esatto della modalità plan dipende ancora dal vendor, dal client e dalla versione. Agent Skills in particolare carica solo un breve riepilogo all’avvio e le istruzioni complete solo all’attivazione, tenendo fuori dal contesto le capacità non utilizzate.
Chiunque voglia la pianificazione dentro un singolo agente senza adottare una metodologia.
Cosa porta Deep Work Plan
-
Indipendente dallo strumento e nativo del repository
La harness e il piano sono file nel Suo repository, leggibili da qualsiasi agente che segue gli standard AGENTS.md e Agent Skills. Cambiare agente non fa perdere il piano.
-
Validazione selezionata da ciò che ogni task ha toccato
Ogni task dichiara la propria superficie toccata ed esegue i test del comportamento modificato e dei suoi consumer, ampliando alla suite completa quando l’impatto non può essere delimitato. Zero test selezionati non è mai un esito positivo.
-
Un solo Final Review con passaggio di sicurezza
Un piano si chiude con una revisione di sicurezza dell’insieme di modifiche accumulato, inclusa una revisione locale obbligatoria del diff, e con una validazione dello stato finale. I rilievi critical bloccano il completamento.
-
Uno stato che sopravvive a sessioni e agenti
Checkbox del README, log dei task, un indice di lavoro delimitato e un file di stato leggibile dalle macchine vengono scritti a ogni confine, così un’altra sessione o un altro agente prosegue da disco. Anche una creazione del piano interrotta è recuperabile.
-
Un verificatore di conformità per il repository stesso
Uno script in sola lettura verifica la harness e ogni piano rispetto alla specifica, riconosce entrambi i cicli di vita dei piani ed esce con un codice adatto alla CI.
-
Carico di istruzioni misurato e pubblicato
Uno script sottoposto a commit pubblica due misurazioni per ogni flusso — il pacchetto d’ingresso caricato all’avvio di una sessione e il percorso end-to-end una volta scattati i trigger reali — più ciò che ciascuna esclude, cosicché la sola cifra d’ingresso non sia mai letta come il costo totale di un’esecuzione. I risultati, aumenti inclusi, sono pubblicati in byte, mai come percentuali di token o di costo.
Limiti onesti
Deep Work Plan non ha un meccanismo di specifica viva o delta; OpenSpec e strumenti simili sono più solidi su quel fronte. Non esiste ancora un benchmark indipendente della metodologia; una valutazione di prima parte con agenti freschi è stata eseguita sotto un protocollo congelato, su piccola scala — un carico di lavoro, due funzionalità per configurazione, una macchina — e i suoi risultati sono pubblicati in entrambe le direzioni: gli agenti su alberi con harness leggevano meno byte in entrambi i task e le sessioni della versione attuale consumavano meno input e output di modello riportati dall’harness rispetto alla versione maggiore precedente, mentre la direzione netta dei token per carico di lavoro è stata mista e nessun vantaggio di tempo di clock viene rivendicato. Il registro del carico di istruzioni misura i byte caricati, non token, costi o esiti, e la cifra del pacchetto d’ingresso non è un limite a ciò che un’esecuzione legge. DWP è deliberatamente limitato al repository: non è un sistema di memoria multi-progetto, non è un framework di agenti basato su ruoli e non è un IDE, quindi non compete nemmeno su questi fronti — abbinalo a uno strumento che copra uno di essi quando è ciò di cui il lavoro ha bisogno.
Ci aiuti a mantenere questa pagina accurata
Ci aiuti a mantenere questa pagina accurata
Questa pagina viene revisionata nella data indicata e corretta su richiesta. Se la descrizione di un Suo strumento è obsoleta o incompleta, apra una issue e la corregeremo.