Desenvolvimento Orientado por Especificações
Tenho mantido uma codebase pessoal (workspaces, boilerplates, packages, scripts) e venho desenvolvendo projetos pessoais em paralelo — acredito que ter o próprio arsenal de ferramentas no dia a dia poupa muito trabalho. Neste post, decidi checar como está a situação da autonomia dos agentes — e, como vimos no primeiro post, nem todo agente foi desenhado com autonomia nativa em sua filosofia. Segue uma pesquisa sobre as técnicas e os frameworks utilizados para essa finalidade.
O teste roda sobre um fixture: um blog mínimo em Node puro, com posts servidos por rotas REST sobre o módulo http nativo e uma convenção de resposta e de erro já estabelecida. A tarefa dada a cada framework foi adicionar um sistema de comentários a esse blog — não é um cenário greenfield, e sim uma feature construída em cima de convenções que já existem. É isso que o teste mede: cada framework respeita o padrão existente ou o ignora e reinventa do zero?
(Repositório com os sete worktrees: github.com/vitorinoguilherme/sdd-frameworks-compared.)
Conceitos Fundamentais
Antes de comparar os frameworks, vale alinhar alguns conceitos que aparecem ao longo do post:
Prompt Engineering: técnica de estruturar a instrução enviada ao modelo para obter melhores respostas. Não resolve, por si só, problemas de memória, continuidade entre sessões, execução longa ou manutenção de estado.
Context Engineering: organizar documentação, arquitetura, regras, especificações e convenções para que o agente trabalhe com informação relevante e bem estruturada. O post 1 mostra um exemplo de como organizo tudo isso numa pasta
.ai/.
Spec-Driven Development: desenvolvimento guiado por especificações — você define páginas, estados, entidades, fluxos, regras, contratos e critérios de aceite antes da execução. Objetivo: reduzir ambiguidade, drift, inconsistência e decisões erradas durante a implementação.
Workflow-Driven Development: separa a execução em fases distintas. Objetivo: evitar overload de contexto, perda de foco e execução caótica.
Runtime State: memória operacional persistente entre execuções. Importante porque o LLM esquece, resume errado e perde o objetivo original ao longo de sessões longas.
Checkpoints: paradas formais entre fases — por exemplo, validar, resumir, persistir o estado e só então seguir para a próxima fase. Objetivo: evitar degradação cognitiva do modelo ao longo da execução.
Orchestration: coordenação geral da execução. Pode incluir planejamento, retries, validação, divisão de tarefas e checkpoints.
| Conceito | Foco | Mitiga |
|---|---|---|
| Prompt engineering | prompt | instrução |
| Context engineering | contexto | consistência |
| Spec-driven | especificação | ambiguidade |
| Workflow-driven | execução | perda de foco / execução caótica |
| Runtime state | memória | continuidade |
| Checkpoints | transição entre fases | degradação de contexto |
| Orchestration | coordenação | autonomia |
Onde entram os frameworks
Os conceitos acima descrevem problemas; os frameworks abaixo são tentativas de resolvê-los de forma sistemática, cada um com uma filosofia diferente. Os problemas que os motivam se repetem: context drift, perda de objetivo, summaries ruins, recency bias, atenção diluída — e a hipótese que este post põe à prova é que todos compartilham um denominador comum: a falta de estado persistente entre execuções. Existe também a opção mais simples de todas: usar o LLM direto, sem framework algum — é o que o Baseline representa aqui, a condição de controle. E há ainda uma categoria paralela surgindo, focada especificamente no problema de memória — ferramentas como agent-memory — que não tentam orquestrar o fluxo inteiro como os frameworks abaixo, só resolver a parte de estado persistente. Fica fora do escopo deste teste, mas é outro ângulo atacando a mesma causa raiz.
| Framework | Foco real |
|---|---|
| Baseline | controle sem framework |
| Ralph Loop | execute → verify (loop stateless) |
| OpenSpec | specs + contracts |
| Superpowers | methodology enforcement |
| BMAD-METHOD | workflow multiagente |
| Open GSD | orchestration + decomposition |
| GitHub Spec Kit | TDD + spec contracts |
Rodando o experimento
A ideia aqui não é comparar os frameworks no papel, e sim rodar cada um de ponta a ponta na mesma tarefa real — o sistema de comentários completo do TASK.md, não um exemplo mínimo. Cada framework recebeu a tarefa inteira, no seu próprio worktree isolado, e correu até concluir ou travar. Mesmo um resultado incompleto — "parou em X" — já revela algo sobre como o framework conduz a execução.
Por baixo de toda a comparação está um tradeoff: dar mais autonomia ao agente ganha velocidade de execução, mas custa controle de contexto a cada etapa.
Antes de rodar qualquer framework, separei algumas decisões de desenho — porque sem isso a comparação vira só "qual ferramenta pareceu mais legal", não dado.
A primeira foi isolar tudo num fixture descartável, sem relação com nenhum
projeto real. Um fixture é uma aplicação mínima de blog criada só pra esse
teste — Node puro, sem nenhuma dependência externa, rotas de posts só com
http nativo. Qualquer coisa além disso (Express, ORM, framework de teste)
faria o agente gastar parte da decisão em "qual lib usar", que não é o que
quero medir.
A tarefa é um sistema de comentários — mas não greenfield disfarçado. O fixture já chega com convenção estabelecida (rota REST simples, um padrão de erro 404, formato de resposta), e a pergunta que o teste faz é se cada framework respeita isso ou ignora e reinventa. Coloquei duas armadilhas de propósito: o corpo do comentário não pode permitir HTML/script arbitrário (testa se o framework pensa em segurança sem eu pedir explicitamente), e a remoção de um comentário precisa preservar a thread das respostas (testa se ele pensa em efeito cascata, não só CRUD superficial). Também defini um "fora de escopo" explícito — sem isso, framework mais "completista" tende a expandir a tarefa sozinho (notificação, moderação, likes), e aí a comparação entre eles deixa de ser justa.
Cada framework roda numa branch separada, todas nascendo do mesmo commit via
git worktree — um repo só, não sete pastas soltas. Isso garante ponto de
partida idêntico entre os testes: qualquer diferença de resultado vem do
framework, não de qual contexto cada um teve disponível.
A régua de avaliação tem duas dimensões. A primeira é como cada framework lidou com as decisões que a tarefa deixou em aberto de propósito: decidiu em silêncio e embutiu o valor no código, decidiu e documentou o racional, propôs e esperou aprovação, ou perguntou uma a uma. A segunda é a qualidade do resultado além de "terminou": os testes gerados rodam de fato e cobrem os casos que o TASK.md pedia — rate limit, thread preservada no soft-delete, limite de caracteres — ou a suíte passa verde deixando justamente esses casos de fora.
Baseline
O baseline é o controle: o mesmo agente, o mesmo modelo, sem nenhum framework — só o TASK.md colado como entrada. Zero install, zero configuração. A única pergunta que ele respondeu foi a tarefa em si.
O agente explorou a codebase antes de codar (seis leituras: server.js, posts.js,
package.json, os arquivos de protocolo). Em seguida, declarou todas as quatro decisões
ambíguas como um bloco de texto no início da resposta — não perguntou nada. Limite de
caracteres: 2000. Janela de edição: 15 minutos. Resposta quando o pai é removido:
entrada permanece, text e name ficam nulos, flag deleted: true. Rate limit: 5
comentários por IP a cada 10 minutos. Valores razoáveis, dentro do que se esperaria de
uma escolha humana rápida — mas o usuário não foi consultado em nenhum deles.
Uma decisão ficou fora do radar inteiramente: persistência. O agente não perguntou, não
declarou, não levantou — simplesmente usou um array em memória (const comments = []) e
um Map para rate limit. package.json ficou sem nenhuma dependência. Isso manteve a
convenção zero-deps do fixture, mas significa que os dados somem a cada restart. O GSD,
ao contrário, levantou persistência como uma decisão a ser tomada antes de começar.
TDD: não — o transcript confirma a ordem: comments.js primeiro, server.js na sequência, testes por último. Os 10 novos testes cobriram os 5 casos obrigatórios do TASK.md mais quatro extras (parentId, post inexistente 404, GET de listagem, rejeição de texto acima do limite); 12/12 pass. Zero intervenção humana, zero artefatos de planejamento, zero dependências externas — tudo em um turno único.
O baseline revela o piso: dado contexto suficiente e permissão para decidir, o agente completa a feature — mas o rastro das decisões fica invisível no código, não num documento.
Implementação completa: worktrees/00-baseline.
Ralph Loop
O Ralph não é um pacote — é uma técnica. A premissa: um loop bash de ~100 linhas chama
claude -p sem --continue. O contexto do modelo zera a cada iteração; todo estado
persiste no disco — src/, test/, um LEARNINGS.md que o agente mantém como memória
inter-iteração, e um sentinela .ralph-done. O loop encerra quando o sentinela existe e
npm test retorna zero. A ideia, conforme descrita pelo criador Geoffrey Huntley, é que
cada iteração seja um agente com contexto completamente zerado — a única continuidade é
o que está nos arquivos.
Neste teste, o loop convergiu em uma única iteração, em cerca de 2 minutos. A única
intervenção humana foi bash launch.sh. O container Docker subiu com apenas o worktree
montado, usuário não-root e HOME isolado — sem acesso a variáveis de ambiente do host ou
ao ~/.claude real.
O que aconteceu em seguida foi completamente autônomo: o agente leu o TASK.md, criou
DECISIONS.md com 6 decisões documentadas (as 4 ambiguidades do spec mais 2 extras sobre
estratégia de escape e representação do soft-delete), implementou src/comments.js com
store in-memory, rate-limit por sliding window e um parâmetro _now = Date.now()
injetável para testar janelas de tempo sem sleep, e escreveu 19 testes. Durante esse
passe, detectou que a checagem da janela de edição usava > onde devia ser >= — o
teste de fronteira falhou, o agente corrigiu num único Edit e rodou de novo. O mesmo bug
existe no GSD, onde nunca foi testado.
TDD: não em sentido estrito — o código veio antes dos testes dentro da mesma iteração,
confirmado pelo transcript. O que aconteceu foi detecção e correção dentro de um único
passe de ~2 minutos, não um ciclo RED→GREEN planejado. Um gap real persiste: nenhum dos
21 testes verifica o comportamento de rejeição 429, apesar de o rate limit estar
implementado e documentado em DECISIONS.md.
O trade-off do Ralph é que --dangerously-skip-permissions não vem de graça. O sandbox
nativo de bubblewrap falhou dentro do Docker — o próprio agente vivenciou isso: o
primeiro tool call retornou exit 1 com bwrap: No permissions to create new namespace.
Ele adicionou dangerouslyDisableSandbox: true em todas as 6 chamadas Bash seguintes.
A contenção real foi Docker + HOME override. O LEARNINGS.md escrito ao final com 4
notas para iterações futuras nunca foi relido — o loop não precisou de uma segunda volta.
Em tarefas onde a iteração 1 falha, é esse arquivo que evita que a iteração 2 repita os
mesmos erros.
O transcript completo tem 57 mensagens JSONL e 16 tool calls, com zero blocos de thinking. O BMAD produziu 976 mensagens para a mesma tarefa. Ralph usou cerca de 6% do volume de mensagens do framework mais pesado — com zero intervenção humana após o disparo.
Implementação completa: worktrees/06-ralph-loop.
OpenSpec
O OpenSpec decide sozinho — mas deixa rastro: cada escolha ambígua vai para um
design.md com racional, não fica invisível no código. É o primeiro framework do lote
com instalação real: npm install -g @fission-ai/openspec seguido de openspec init.
Ao selecionar "Claude Code" no init, cinco skills e cinco commands são criados no
.claude/ do worktree — nenhum toque no ~/.claude global.
A primeira diferença em relação ao baseline aparece logo na entrada: não bastou colar o
TASK.md e aguardar. O framework exige invocação explícita — /opsx:propose @TASK.md —
e impõe um pipeline de artefatos com bloqueios entre estágios. O proposal precisa existir
antes que design e specs sejam escritos; tasks só é possível depois; e a implementação
(/opsx:apply) só é desbloqueada quando todos estão completos.
O agente explorou a codebase antes de qualquer artefato — as mesmas leituras de
server.js, posts.js e package.json do baseline, mas aqui como parte do protocolo do
framework. O proposal.md declarou logo no campo Impact que o sistema seria in-memory e
sem dependências externas — sem perguntar. Em seguida, design.md e spec.md foram
gerados em paralelo. Foi no design.md que as 4 ambiguidades apareceram: numa seção
"Unspecified decisions resolved", com uma tabela que listava valor e racional para cada
uma — 2000 chars, janela de edição de 15 minutos, replies preservadas com o pai
soft-deletado, e 10 comentários por IP por 60 minutos para rate limit. Tudo decidido
unilateralmente. O framework tem uma instrução interna explícita: "prefer making
reasonable decisions to keep momentum."
TDD: não — os testes foram escritos depois de comments.js e server.js. 18/18 pass,
zero-deps mantido, zero intervenção humana além de confirmar o /opsx:apply.
O contraste com os outros frameworks é revelador. O GSD perguntou as quatro ambiguidades,
uma a uma com defaults recomendados. O baseline as decidiu implicitamente no código —
invisíveis sem ler a implementação. O OpenSpec ficou no meio: decidiu sozinho, como o
baseline, mas documentou cada escolha com justificativa no design.md. O usuário não foi
consultado, mas pode ler as razões depois. Com 2 comandos e 237 linhas de artefatos, é o
framework mais leve com alguma estrutura — e um dos que melhor separa a decisão da
implementação sem pedir aprovação.
Implementação completa: worktrees/01-openspec.
Superpowers
O Superpowers é o único dos sete que roda uma self-review autônoma antes de seguir
para o plano — o próprio agente relê e corrige o que acabou de escrever, sem input
humano. Não é uma CLI — é um plugin instalado de dentro da sessão, via
/plugin marketplace add obra/superpowers-marketplace seguido de
/plugin install superpowers@superpowers-marketplace. Com HOME override, ficou em
.claude/plugins/ do worktree sem tocar o ~/.claude real. O modelo de operação é uma
sequência explícita de skills com escopos delimitados: brainstorming → design →
self-review → plan → execute → finish. Cada transição é deliberada; cada skill sabe o
que pode e o que não pode fazer naquela fase.
A skill de brainstorming explorou a codebase antes de qualquer pergunta (5 arquivos
lidos, git log) e depois fez 2 perguntas — mas nenhuma delas era sobre as 4
ambiguidades do TASK.md. As perguntas foram de design técnico: como sanitizar (strip all
tags ou lib externa?) e qual convenção de rota (REST nested ou flat?). As 4 ambiguidades
vieram depois, compiladas numa tabela de aprovação com valores e racionais propostos, e
um único checkpoint foi pedido antes do design doc de 132 linhas. É o inverso do GSD,
que interrogou cada ambiguidade individualmente; o Superpowers consolidou tudo num bloco
e pediu um "yes".
Antes de gerar o plano, o framework rodou uma self-review autônoma do spec: o mesmo
agente que escreveu o design doc leu e corrigiu 3 problemas — contagem de rotas estava
errada (3→4), comportamento com parentId apontando para comentário soft-deletado não
estava especificado, e o DELETE precisava ser declarado idempotente. Corrigiu tudo num
commit separado, sem input humano.
TDD: sim — confirmado pelo transcript. Os testes foram escritos antes de src/comments.js,
e o ciclo RED→GREEN do unit test inicial foi executado: o agente confirmou
Cannot find module antes de criar o arquivo de implementação. O plano de 566 linhas
embutia passos de TDD com saída esperada de cada node --test, e a execução seguiu esse
script. 18/18 pass, zero dependências externas, cerca de 3 intervenções humanas ao longo
de toda a sessão.
O diferenciador do Superpowers é a self-review constitutiva — o agente edita seu próprio artefato antes de avançar. Que ele tenha identificado 3 problemas no spec que acabou de escrever, e corrigido autonomamente, diz algo sobre o quanto a estrutura de fases forçou uma releitura crítica que a execução linear não produziria.
Implementação completa: worktrees/03-superpowers.
BMAD-METHOD (BMAD)
O BMAD é o mais cerimonioso dos sete — e o único que esgotou a janela de uso de 5h do
Claude Code durante a run. O install (npx bmad-method install) cria 46 skills
localmente no .claude/skills/ do projeto, sem tocar o ~/.claude global. A estrutura
é de role-agents nomeados: John (PM), Winston (Architect) e Amelia (Dev) são invocados
em sequência, e o handoff entre eles acontece exclusivamente via arquivos em disco em
_bmad-output/. Não há sessão compartilhada; o próximo agente começa lendo o que o
anterior escreveu.
John tratou as 4 ambiguidades com uma abordagem específica: propôs cada valor com rationale em tabela formatada e aguardou um checkpoint único de aprovação antes de gravar no PRD. Um "ok" foi suficiente para mover. O PRD final tinha 166 linhas e 17 cenários com IDs estáveis (T-1..T-17).
Winston varreu o codebase existente antes de qualquer rascunho de arquitetura e fez
apenas 2 perguntas — nenhuma reabriu as ambiguidades do PRD. Um detalhe de AD-8 revelou
o valor do pipeline: o rascunho inicial assumia reset direto no Map; o usuário pediu
exports explícitos (resetComments(), resetRateLimit()). Winston atualizou, selou —
e essa decisão arquitetural viabilizou o backdating de timestamps nos testes T-8 e T-14.
O create-story funcionou como gate adversarial: antes de qualquer código, capturou 6
problemas na especificação — ?? {} no rate-limit perderia estado do primeiro request,
rateLimitStore ausente dos exports impediria T-14, colisão de parsed.body com a
variável HTTP, shadowing de match→postMatch, ausência de finally no teardown, IP
hardcoded. Todos corrigidos antes de Amelia começar.
TDD: não — Epic 1 foi código (src/comments.js, src/server.js), Epic 2 foram testes.
O primeiro npm test real do framework aconteceu na
Story 2.1, depois de toda a lógica implementada. 19/19 pass; cada test() nomeia o
cenário do PRD que verifica — T-1 até T-17, rastreabilidade 1:1.
O BMAD exigiu cerca de 25–30 interações humanas — 10 invocações de skill no ciclo dev (5× create-story + 5× dev-story, sem batch) mais os checkpoints de fase. Que a janela de 5h tenha sido esgotada antes do fim não é um bug: é a métrica mais honesta do custo de condução do framework.
Implementação completa: worktrees/04-bmad.
Open GSD (GSD)
O GSD fechou com a suíte de testes mais fina dos sete — 7/7, faltando exatamente o
caso mais importante do TASK.md — depois de ter sido o framework que mais perguntou e
mais documentou antes de codar. A instalação já dá a régua desse excesso: o GSD
(@opengsd/gsd-core) é o único dos sete que não instala no projeto — instala
globalmente em $HOME/.claude com paths hardcoded. Sem um HOME descartável, a
instalação contamina a config global real. A isolação por HOME foi usada em todos os sete
worktrees para isolamento genérico; o que é exclusivo do GSD é que ela passa de precaução
a requisito técnico do próprio instalador. Com 69 skills e hooks todos hardcoded em
$HOME/.claude/, não há como isolar por projeto.
Antes de qualquer spec, /gsd-explore gerou 7 arquivos de documentação em
.planning/codebase/ — stack, integrações, arquitetura, estrutura, convenções, testes e
um CONCERNS.md que já sinalizou risco de XSS antes de qualquer código ser escrito. Em
seguida, /gsd-new-project configurou preferências de workflow em 6 rodadas de perguntas
(modo de execução, granularidade de fases, paralelismo, git tracking de artefatos,
research por fase, verificação de planos), gerando PROJECT.md, REQUIREMENTS.md, ROADMAP.md
e CLAUDE.md — 12 artefatos, 1148 linhas antes da primeira linha de implementação.
As 4 ambiguidades foram perguntadas uma a uma, com default recomendado para cada uma.
Além disso, o GSD levantou uma quinta questão ausente do TASK.md: persistência. Isso
levou à adoção de better-sqlite3 via npm — o único framework entre os sete a quebrar a
convenção zero-deps do fixture, em vez de usar node:sqlite nativo do Node 24. O codebase
map que o próprio GSD havia gerado registrava zero-deps como característica do projeto,
mas não pesou na decisão de implementação.
Cada fase tinha um subagente plan-checker que validava o plano antes de um executor
rodar. TDD: não — código ao longo das fases 1 e 2, testes escritos na fase 3, cerca de
uma hora depois do último commit de implementação. O mecanismo que explica o principal
gap de cobertura: o plan-checker da fase 3 instruiu exportar resetRateLimit() para que
o beforeEach nunca atingisse o limite de rate. Com isso, RATE-01 — documentado em
REQUIREMENTS.md, implementado em server.js — nunca aparece em nenhum teste. A suíte
terminou com 7 casos e 7/7 pass.
O GSD gerou a especificação mais completa dos sete, perguntou mais do que qualquer outro, e produziu a menor suíte de testes — porque o mecanismo de isolamento que o próprio planejador criou para os testes também eliminou o caso mais importante a verificar.
Implementação completa: worktrees/05-open-gsd.
GitHub Spec Kit (Spec Kit)
O Spec Kit é o único dos sete onde TDD não é intenção de plano — é uma cláusula
"NON-NEGOTIABLE" na project constitution. O tasks.md instrui confirmar RED antes de
implementar cada user story. Antes de qualquer código: 9 artefatos, 1254 linhas — spec
de negócio, checklist de requisitos, plano técnico, modelo de dados, contrato HTTP
completo e tasks por user story.
As 4 ambiguidades foram resolvidas em silêncio pelo /speckit-specify, numa seção
"Assumptions" com justificativa de produto para cada uma. Um detalhe: o rate limit foi
definido como 5 por IP por 60 segundos — único framework que usou segundos em vez de
minutos, o que é mais restritivo. O usuário não foi consultado em nenhuma das quatro.
O /speckit-clarify fez um coverage scan e encontrou 2 pontos de ambiguidade — mas
nenhum era das 4 do TASK.md. Perguntou sobre o endpoint de listagem, authorName no
tombstone e formato de ID. O clarify encontra ambiguidades que o processo de spec criou,
não as que a tarefa intencionalmente omitiu.
TDD: sim — mandatado pela constitution. O implement confirmou 15/17 testes falhando antes
de qualquer código. Um bug surgiu nesse processo: stripHtml com só /<[^>]*>/g deixava
o conteúdo de <script> intacto — <script>alert(1)</script>Hi virava alert(1)Hi.
O fix adicionou dois passos anteriores à regex: remoção de blocos <script> completos,
depois <style>. Nenhum dos outros seis frameworks detectou esse comportamento — o TDD
por contrato forçou a verificação antes da implementação. Houve context compaction durante
a sessão; o agente retomou dos artefatos em disco sem intervenção humana.
19/19 pass, zero dependências externas, ~2 intervenções humanas. Com 1254 linhas de
artefatos pré-código, o Spec Kit fez mais verificação que o GSD, com menos papel que
qualquer um dos dois. A diferença não foi a quantidade de documentação — foi o que o tasks.md
mandava fazer com ela.
Implementação completa: worktrees/02-speckit.
Resultados
Rodados os sete testes, os números lado a lado deixam o contraste claro.
Contagens totais incluem artefatos gerados entre fases (GSD: 17 arquivos, 2483 linhas; BMAD: 11 arquivos, 2372 linhas). A ironia central do experimento: o GSD gerou o maior volume de planejamento e a suíte mais fina — 7/7 testes, nenhum verifica o RATE-01 documentado em três artefatos.
| Framework | Artefatos | Linhas de artefato | Turnos manuais | Zero-deps | Testes | TDD |
|---|---|---|---|---|---|---|
| Baseline | 0 | 0 | ~1 | ✅ | 12/12 | Não |
| Ralph Loop | 0 | 0 | 1 | ✅ | 21/21 | Não |
| OpenSpec | 4 | 237 | ~1 | ✅ | 18/18 | Não |
| Superpowers | 2 | 698 | ~2 | ✅ | 18/18 | Sim |
| BMAD-METHOD | 11 | 2.372 | ~25–30 | ✅ | 19/19 | Não |
| Open GSD | 17 | 2.483 | ~6 | ❌ | 7/7 | Não |
| Spec Kit | 9 | 1.254 | ~2 | ✅ | 19/19 | Sim |
Nenhum framework ficou no quadrante inferior direito (perguntou, sem rastro) — quem perguntou também documentou. A única entrada no inferior esquerdo é o Baseline: decidiu tudo e não deixou nenhum artefato além do código.
Mais papel não comprou mais verificação. O BMAD (2.372 linhas, 27 turnos) e o GSD (2.483 linhas, 6 turnos) produziram os maiores volumes de planejamento; o OpenSpec (237 linhas, 1 turno) ficou com a suíte mais ampla em cobertura relativa, e o Ralph (0 linhas, 1 turno) foi o único a testar a fronteira exata da janela de edição.
O que a pesquisa revelou na minha prática
Nos meus projetos mais recentes, venho usando minha própria abordagem dentro da pasta
.ai/, em vez de qualquer um dos sete frameworks acima. Essa convenção é anterior a esta
pesquisa; nada aqui foi "aplicado a partir do estudo". Foi o contrário: olhei para o que já
vinha fazendo à mão e reconheci, depois, os mesmos mecanismos que os frameworks formalizam.
E a sobreposição é real, ainda que não intencional. Meu runtime/current-state.md cumpre a
mesma função do status tracking do BMAD e da memória em disco do Ralph — o próprio agente o
atualiza a cada fase, seguindo uma instrução no CLAUDE.md, não um mecanismo embutido de
ferramenta. Meus .ai/decisions/*.md são ADRs informais: a mesma ideia das assumptions que
o Winston sela no AD-8 do BMAD, sem o template formal. E meus tasks/phase-*.md, com gating
por checkbox, são o mesmo phase-gating das fases de roadmap do GSD ou das sprint stories do
BMAD — só que garantido por convenção e prosa, não por um subagente plan-checker. Cheguei a
formas parecidas sozinho porque o problema por baixo é o mesmo: context drift e memória de
fase. Convergência, não cópia.
O que me interessou de verdade foi rodar a mesma régua da pesquisa nos meus próprios projetos — e ali apareceram lacunas concretas, não teóricas:
- Doc drift. Docs desatualizados, descrevendo uma fase antiga do projeto, ainda são auto-carregados como contexto antes do runtime doc correto. Nenhum dos sete tem exatamente essa falha: eles ou regeneram docs por fase (GSD) ou fazem gate em artefato fresco (OpenSpec, Spec Kit).
- Redundância. As mesmas regras de execução aparecem copiadas em alguns arquivos — um padrão pensado para loops sem acompanhamento, onde cada arquivo precisa
carregar contexto suficiente sozinho. Mas vira puro overhead no desenvolvimento
incremental, em que o
CLAUDE.mdjá está sempre carregado. - Gate só na prosa. Meu phase-gating existe como instrução escrita ("cheque o
current-state.mdantes de abrir um task file"), não como checagem imposta — diferente do plan-checker do GSD ou do IR gate do BMAD, que verificou 24/24 requisitos antes de liberar a implementação.
Nenhuma dessas lacunas é motivo para adotar um framework inteiro — a maioria é conserto
barato para quem mantém sozinho. Mas o padrão é claro: eu tinha dado autonomia aos agentes
sem construir os freios que os frameworks embutem. A pasta .ai/ me deu a autonomia; o que
a pesquisa expôs foi onde faltava o controle.
Desses controles, o único com lugar óbvio pra cair no que já tenho é um gate enforced entre planejar e codar: o fluxo que já uso barra cada commit com lint, typecheck e testes; falta o equivalente sobre o plano e o spec, não só sobre o código pronto. O resto é cerimônia que cobra caro adiantado: os role-agents nomeados do BMAD, o install global do GSD, as 1148 linhas de artefato antes da primeira linha de implementação — e se esse custo compensa depende do projeto e de quem está nele.
Num projeto de um mantenedor só, esse volume tende ao desperdício; num time, muda de
figura. Um arquivo de estado como o current-state.md já é, na prática, um handoff:
devolve o contexto quando o projeto é reaberto depois de dias, e cumpriria o mesmo papel
passando o bastão pra outra pessoa. É aí que o rastro pesado do BMAD e do GSD se paga —
continuidade entre execuções quando há um dev só, onboarding e histórico compartilhado
quando há mais gente. Vale lembrar de onde vem essa leitura: a pesquisa rodou sobre um
fixture descartável, tarefa única, um turno. O modo de falha que o gate enforced ataca —
doc drift, memória de fase perdida ao longo de semanas e muitas sessões — um fixture assim
não reproduz. Se fechar esse buraco compensa o atrito de mais uma engrenagem, um teste de
um turno não responde; um projeto real, de várias fases, responderia.
Fica uma lição atravessada nos sete: quantidade de spec não é sinônimo de rigor. Os dois maiores volumes de planejamento produziram a suíte de teste mais fina e a mais cara de conduzir. O que previu a qualidade da verificação foi uma coisa só — o processo exigir uma checagem entre o plano e o código; documentar mais, antes, não moveu esse ponteiro. Escolher um framework é decidir quanto controle se quer de volta e quanto atrito se aceita pagar por ele — conta que muda com a tarefa, sem resposta única.