A guerra dos frameworks do Claude Code
(shmck.substack.com)- Os desenvolvedores agora estão na fase de aprender como colaborar com IA, e o valor do Claude é maximizado quando ele é usado não como um simples chatbot, mas como um framework
- Na comunidade, seguem surgindo várias tentativas sobre como configurar e usar o Claude, a ponto de isso ser chamado de Claude Code Framework Wars, tamanho o nível de experimentação
- Com isso, está se formando um fluxo em que o Claude é usado em vários papéis, como gerente de projeto, arquiteto, desenvolvedor e revisor
- O design de um framework exige 8 decisões principais, incluindo gestão de tarefas, fornecimento de diretrizes, colaboração entre agentes, operação de sessões, acesso a ferramentas, desenvolvimento de código, entrega e preservação de contexto
- A principal lição é que a IA não substitui o desenvolvedor, mas se consolida como uma colega de equipe que multiplica a produtividade por meio de regras e papéis estruturados
Introdução
- Ideia central: considerar o Claude não como uma simples ferramenta de conversa, mas como um framework, gerando resultados previsíveis e valiosos por meio de regras claras e fluxos de trabalho
- O desenvolvedor deixa de focar em codificação e passa para papéis de maior valor agregado (gestão de projeto, design, arquitetura)
- O framework do Claude Code funciona com prompts estruturados sem necessidade de escrever código
- Claude Code Framework Wars: a comunidade de desenvolvedores está experimentando várias abordagens para usar IA de forma produtiva
- Dezenas de projetos open source competem definindo fluxos de trabalho e estruturas de papéis
- Ex.: Agent OS, Claude-Flow
Principais escolhas a considerar ao projetar um framework
1. Onde gerenciar as tarefas
- É necessário definir a fonte de tarefas que o Claude poderá consultar
- Backlog em Markdown: gerenciar tarefas como listas de afazeres em Markdown
- Ex.: Backlog.md, ReqText
- Texto estruturado: converter especificações de produto em tarefas
- Ex.: Agent OS
- Issues/tickets: armazenar especificações em GitHub Issues ou tickets do Jira, conectando com revisão de código
- Ex.: ccpm
- Backlog em Markdown: gerenciar tarefas como listas de afazeres em Markdown
- Essencial: as tarefas precisam estar armazenadas em um local acessível e rastreável pelo Claude
2. Como fornecer guias ao Claude
- Em vez de prompts vagos, fornecer instruções ao Claude com uma estrutura clara
- Biblioteca de comandos: comandos slash predefinidos, como /create-tasks e /review
- Padrões de codificação: explicitar a stack técnica e as diretrizes de código
- Definição de concluído: codificar os critérios de conclusão de uma tarefa
- Hooks de validação por gatilho: forçar lint e testes em toda mudança
- Claude como revisor: o Claude executa desenvolvimento e revisão ao mesmo tempo
- Essencial: regras claras e repetíveis melhoram a qualidade do trabalho do Claude
3. Estrutura de colaboração entre agentes
- Ao usar vários agentes Claude, a coordenação acontece por meio de papéis e planejamento
- Simulação de papéis: a IA atua como PM, arquiteto, desenvolvedor e testador
- Ex.: Agent OS
- Processamento paralelo em swarm: execução simultânea de vários agentes em um fluxo estruturado que vai de especificação → pseudocódigo → código → testes
- Ex.: Claude-Flow
- Artefatos nativos do repositório: armazenar tarefas, logs e registros de decisão (ADR) no codebase para manter a memória
- Ex.: Roo Commander
- Simulação de papéis: a IA atua como PM, arquiteto, desenvolvedor e testador
- Essencial: a coordenação evita conflitos entre vários trabalhadores de IA
4. Como operar sessões
- Para evitar confusão na saída da IA, definir sessões como ambiente de trabalho
- Orquestração de terminal: o Claude controla comandos, janelas e logs
- Ex.: Symphony, Claude-Squad
- Worktrees em paralelo: executar várias branches em paralelo com Git Worktrees
- Ex.: Crystal
- Containers em paralelo: executar o Claude em containers independentes para evitar conflitos
- Ex.: ClaudeBox
- Orquestração de terminal: o Claude controla comandos, janelas e logs
- Essencial: o trabalho paralelo maximiza a produtividade sem conflitos
4. Como executar sessões
- Para evitar confusão na saída da IA, definir sessões como ambiente de trabalho
- Orquestração de terminal: o Claude controla comandos, janelas e logs
- Ex.: Symphony, Claude-Squad
- Worktrees em paralelo: executar várias branches em paralelo com Git Worktrees
- Ex.: Crystal
- Containers em paralelo: executar o Claude em containers independentes para evitar conflitos
- Ex.: ClaudeBox
- Orquestração de terminal: o Claude controla comandos, janelas e logs
- Essencial: o trabalho paralelo maximiza a produtividade sem conflitos
5. Acesso do Claude a ferramentas
- Configurar o Claude para aproveitar conhecimento sobre toda a stack técnica
- Integração MCP: conectar navegador, banco de dados, runner de testes e framework de automação de UI
- Biblioteca de ferramentas personalizadas: construída com shell scripts e comandos
- Ex.: Symphony
- Acessor de banco de dados: ferramenta poderosa de acesso a banco de dados
- Ex.: Claudable with Supabase
- Hooks de teste e validação: executar testes com Vitest, Jest etc. antes de concluir a tarefa
- Ex.: Agent OS
- Essencial: a integração com ferramentas transforma o Claude de simples autocompletar em um membro ativo da equipe
6. Como desenvolver código
- O Claude pode assumir diferentes papéis conforme a necessidade
- Gerente de projeto (PM): converter especificações de produto em tarefas e backlog
- Arquiteto: projetar a estrutura geral, definir interfaces e estabelecer regras antes da codificação
- Implementador: escrever código de acordo com testes e padrões
- QA: revisar problemas nas tarefas
- Ex.: BMAD-code
- Revisor: auditar qualidade do PR, legibilidade e riscos
- Essencial: usar IA em todo o ciclo de vida do software
7. Como entregar o código
- Definir como o código chega ao repositório
- Essencial: escolher entre iteração segura para produção ou scaffold para protótipos
8. Como preservar contexto
- Resolver o problema de esquecimento do Claude com memória do framework
- Documentos e diário: manter atualizados CLAUDE.md, notas de arquitetura e diário do projeto
- Ex.: Claude Conductor
- Memória persistente e checkups: resumir trabalhos recentes, verificar a saúde do projeto e salvar decisões
- Ex.: Claude-Flow
- Documentos e diário: manter atualizados CLAUDE.md, notas de arquitetura e diário do projeto
- Essencial: sem memória, a IA repete erros; com memória, o progresso se torna cumulativo
Caminhos de integração
- Tratar as opções como um menu, sem necessidade de configurar tudo de uma vez
- Configuração iniciante: backlog em Markdown + diffs por ticket
- Equipe estruturada: especificações de produto + padrões + simulação de papéis
- Foco em experimentação: artefatos no repositório + sessões paralelas
- Modo protótipo: app builder + scaffold de documentação
Conclusão e implicações
- Lição principal: o Claude entrega seu melhor desempenho em um ambiente estruturado
- Em vez de substituir o papel do desenvolvedor, ele reduz trabalho boilerplate e permite foco em definição de especificações, revisão de design e definição de arquitetura
- Se o trabalho sai dos trilhos, pode descarrilar rapidamente; gestão estrutural é essencial
- Ainda estamos em estágio inicial, mas os frameworks fazem a IA convergir de uma caixa mágica para um conjunto de membros de equipe gerenciáveis
- Quanto mais estrutura se fornece, maior o valor retornado
- Por meio de projetos open source, a comunidade experimenta vários frameworks e busca formas produtivas de usar IA
- Os desenvolvedores podem usar o Claude de forma sistemática para focar em trabalhos de maior valor agregado e integrar a IA como membro da equipe, maximizando a produtividade
1 comentários
Comentários do Hacker News
Testei vários "frameworks" para o Claude Code, mas objetivamente não sei dizer se o desempenho realmente melhorou
Parece mais um ritual em torno de um processo complicado tratado como fórmula, e fico na dúvida sobre o motivo real disso
Tenho a sensação de que essa abordagem de framework não combina com o objetivo de treinamento do modelo
Na prática, isso acaba jogando informações desnecessárias no modelo e poluindo o contexto à força para encaixá-lo no "processo que eu defini"
Acho importante eliminar a poluição de contexto e melhorar de forma gradual, fornecendo apenas as informações realmente necessárias para a tarefa
Esse tipo de colaboração mais tradicional parece fazer mais sentido quando acontece fora do contexto de agentes com contexto limitado
Este texto nem menciona subagents, então fiquei curioso sobre quando foi escrito
Eu delego a subagents tarefas como "buscar no memory bank apenas as informações relevantes para o trabalho atual" e "rodar testes e retornar apenas falhas e cobertura"
Isso ajudou a evitar que o contexto do agente principal lotasse muito rápido
https://docs.anthropic.com/en/docs/claude-code/sub-agents
Minha vida ficou bem mais fácil depois que adotei algumas práticas úteis, como dev containers e worktrees
Também criei meu próprio "framework" em shell script para gerenciar arquivos do projeto e criar worktrees, e terminei isso em uns dois dias
Gosto da liberdade de não ficar preso a uma ferramenta específica
Concordo que poluição de contexto é um problema real com o qual precisamos nos preocupar
Principalmente depois de ver definições de endpoint MCP ocupando uma parte significativa do meu contexto, algo em torno de 20 mil tokens, passei a considerar obrigatoriamente a questão de contexto ao escolher MCPs
Pareceu uma situação muito parecida com a de um gerente de projeto de verdade
O que eu gostaria é que, ao usar o Claude, houvesse uma etapa incluída na elaboração da proposta para perguntar antes sobre os pontos que não estão claros
Se você passar para um engenheiro de verdade apenas os requisitos e o resultado esperado, ele naturalmente vai fazer perguntas adicionais antes de executar para alinhar melhor
Espero que o Claude também consiga automatizar esse processo de validação
Frequentemente vejo muitos erros acontecendo porque ela simplesmente não considera perguntas que não foram esclarecidas
Ao aplicar esse tipo de framework, fico curioso sobre quanta autonomia vocês dão na prática e em que tipo de ambiente usam isso (greenfield/brownfield)
Também queria saber se alguém já conectou o Claude Code a software corporativo e conseguiu entregar resultados com confiança
Na empresa eu tenho acesso relativamente livre ao Claude Code, mas na minha codebase os resultados ficam inconsistentes, especialmente quando entra frontend UI ou Playwright
Queria entender melhor as práticas reais de uso: quanto lixo de código fica para trás, quanto desgaste isso gera na colaboração com colegas, o tamanho dos pull requests, o custo de inferência, como vocês gerenciam isso em paralelo etc.
Documentos README às vezes parecem material de marketing para venda, cheios de termos específicos do sistema, emojis e formas excessivamente personalizadas de organizar a caixa de ferramentas
No fim, imagino que Anthropic e outras acabem incorporando esses recursos ao próprio CLI
Pessoalmente, faço um modelo de reasoning lidar com uma especificação de 10 páginas, lint/type check/formatter/hook rígidos, checklist de trabalho e até TDD red/green, e com um único “go” para o GPT-5 ele gera automaticamente o que preciso
Com as mesmas ferramentas, qualquer pessoa pode facilmente montar seu próprio sistema
Uso o plano Max de $200, então o custo de inferência também fica fixo
Os resultados foram especialmente claros em cenários greenfield, como adição de novas funcionalidades
Para refatorações complexas ou mudanças profundas no sistema, ele até avança bem se houver boa documentação de design, mas funciona mal onde a documentação é fraca
No começo saía muito "código ruim" — implementações fracas em estilo, reutilização ou manutenibilidade —, mas depois que reforçamos o arquivo CLAUDE.md e fizemos a persona de desenvolvedor usar obrigatoriamente o subagent "elixir-code-reviewer", a qualidade do código melhorou visivelmente
Nossa plataforma é open source, então compartilho aqui nossa configuração atual de comandos e subagents do Claude
https://github.com/Simon-Initiative/oli-torus/tree/master/.claude
O texto do blog passou bastante uma sensação de estilo típico de LLM
A informação é útil, mas é curioso estar aprendendo sobre IA com a própria IA
Hoje em dia muitos textos sobre IA passam essa sensação
Na prática, a menos que seja trabalho não especializado, você precisa monitorar o Claude Code diretamente e intervir na hora se ele começar a seguir na direção errada
Também não dá para dar permissões demais por questões de segurança nem deixar de verificar que comandos ele está de fato executando
Os "frameworks" atuais ainda têm um longo caminho pela frente e, por enquanto, o mais realista é pensar neles como “um estagiário júnior que cospe código numa velocidade absurda”
O autor pode não ter verificado o repo direito, ou talvez o resultado de pesquisa tenha sido limitado
Por exemplo, superClaude não é um servidor MCP, e metaGPT aparentemente não é compatível com Claude Code
Sempre me pergunto por que não deixam o agent gerenciar o próprio contexto como um humano faria
Não entendo por que todo o histórico de trabalho anterior precisa ser incluído toda vez
Se deixassem o agent decidir qual contexto vale a pena manter e aprender por conta própria as vantagens e desvantagens do gerenciamento de contexto, acho que a capacidade dele de executar cada tarefa melhoraria
No fim, parece que aqui também se repete a textbook "bitter lesson"
As pessoas criam todo tipo de "framework", mas a próxima geração de modelos torna tudo isso inútil
http://www.incompleteideas.net/IncIdeas/BitterLesson.html
Fiquei bem surpreso de BMAD-method não ter sido mencionado
Pela minha experiência, BMAD-method é o melhor complemento para Claude Code
Fiquei curioso sobre o que é BMAD-method
Queria saber se é só algo no nível de system prompt e por que parece tão útil
https://github.com/bmad-code-org/BMAD-METHOD
O sistema BMAD parece parecido com o AgentOS apresentado no post
Esse tipo de engenharia de contexto funcionou bem para mim, e eu mesmo fiz o Claude gerar comandos e agents para depois ajustar conforme a necessidade
Recentemente também tenho usado bastante json e markdown para compartilhar contexto
taskmaster também é assim, mas não está na lista
Gerenciar contexto parece programação de baixo nível
Acho parecido com ter de colocar os valores exatos nos registradores da CPU para a operação correta acontecer
A diferença é que temos muito menos controle sobre quais permissões de contexto adicionar ou remover em cada tarefa
Testei o B-MAD Framework e a diferença de resultado foi tão grande que agora não consigo mais trabalhar sem essa ferramenta
Espero que apareçam ainda mais frameworks desse tipo no futuro
Queria saber se alguém aqui já usou esses frameworks de verdade
Eles trazem resultado prático ou são só hype de momento?
O resultado é o esperado: recursos despejados sem validação, documentação ruim e cheio de Claude-isms
Na prática, acabam servindo só para alguns poucos projetos de interesse de quem os criou