Learn why Claude Code takes an unopinionated approach and how this benefits developers as AI models evolve, grounded in Brandon's own working practice.
A escolha central de design do Claude Code é permanecer sem opinião. Ele expõe as capacidades do modelo diretamente, em vez de envolvê-las em fluxos de trabalho prescritivos.
Pense nisso como pipes Unix. O comando cat não sabe em o que você vai direcioná-lo. O grep não se importa com o que produziu sua entrada. Essa ignorância do contexto ao redor é uma funcionalidade — é o que torna essas ferramentas composáveis. Você pode encadeá-las de maneiras que os autores jamais imaginaram, porque não fizeram suposições sobre onde se encaixam no seu fluxo de trabalho.
O Claude Code aplica a mesma lógica. Ele não prescreve como você revisa código, gera docs ou gerencia releases. Ele dá acesso ao modelo e sai do caminho.
Primitiva vs. produto: Uma primitiva se compõe com tudo que você já tem. Um produto assume que você quer o que ele pré-construiu. Produtos envelhecem à medida que suas suposições se deterioram. Primitivas melhoram à medida que a capacidade subjacente melhora.
Essa distinção importa especialmente em ferramentas de IA, porque os modelos melhoram mais rápido do que as suposições de produto. Quando construí automação inicial com Aider, qualquer coisa que eu codificava rigidamente em torno das limitações do modelo se tornava dívida técnica dentro de dois ciclos de release. O modelo melhorava além das barreiras que eu havia estabelecido para contornar suas limitações. Uma ferramenta sem opinião evita esse problema ao não construir sobre suposições específicas do modelo desde o início.
A outra propriedade chave é a composabilidade. Ferramentas sem opinião se compõem com ferramentas que existiam antes delas e com ferramentas que ainda não existem. Você não precisa de um plugin Claude para seu sistema de CI, sua ferramenta de revisão de código ou seu pipeline de deploy — você direciona para e do Claude da mesma forma que direciona entre quaisquer ferramentas Unix.
Por que isso envelhece bem: Quando o modelo subjacente melhora, uma ferramenta sem opinião melhora com ele automaticamente. Nada no seu fluxo de trabalho precisa mudar — os mesmos comandos simplesmente funcionam melhor.
Pense em uma ferramenta que você usa diariamente e que te frustrou por não suportar um fluxo de trabalho que você queria. A limitação estava nas suposições de design da ferramenta ou na capacidade subjacente que ela expõe? Como uma versão sem opinião dessa ferramenta se comportaria de forma diferente?
O melhor lugar para ver a filosofia em ação é com o caso mínimo viável: direcionar algo para dentro, obter algo útil de volta.
Sem configuração. Sem setup de projeto. Sem instalação de plugin. O modelo lê o que você dá a ele e responde. Agora adicione contexto real do seu ambiente:
Essas duas linhas representam toda a interface. Todo o resto é composição.
O teste de composabilidade: Se uma ferramenta funciona em um pipeline com outras ferramentas que você não escreveu, ela está se comportando como uma primitiva. O Claude Code passa nesse teste: lê stdin, escreve stdout e não tem opiniões sobre o que vem antes ou depois.
Agora estenda — Claude Code como uma etapa em um pipeline mais longo:
Observe que o Claude Code ocupa a mesma posição que qualquer utilitário Unix ocuparia. Você não está aprendendo um novo paradigma — está adicionando um participante mais capaz em um pipeline que você já conhece.
Certifique-se de que pode responder a estas perguntas antes de continuar:
Se a pergunta três não estiver clara, execute git diff --cached | claude "review this" em um repositório real e observe o resultado. A simplicidade da invocação é o ponto.
A filosofia se torna concreta quando você conecta o Claude Code a fluxos de trabalho que você já possui. Aqui está como o uso no meu harness SDLC — um pipeline multi-agente que roda num Mac Mini atrás de um Cloudflare Tunnel.
O harness lança agentes Claude Code paralelos em worktrees git isolados, cada um trabalhando em um branch separado. Quando terminam, um orquestrador de merge sequencia os resultados em main. O Claude Code é uma primitiva naquele pipeline, não o pipeline inteiro.
O orquestrador trata a saída do Claude como qualquer saída de processo. Ele não precisa entender o que o Claude disse — apenas direciona o resultado para a próxima etapa. É a primitiva dando resultado: o orquestrador se compõe com o Claude Code da mesma forma que se comporia com grep ou jq.
Ensine o Claude sobre seu projeto, não o contrário. Meu harness SDLC inclui um arquivo CLAUDE.md em cada worktree descrevendo as convenções do repositório. O Claude lê esse arquivo e se adapta ao projeto. O projeto não se adapta às suposições integradas do Claude.
O mesmo padrão escala para baixo em fluxos de trabalho do dia a dia. Um hook de pré-commit que revisa mudanças em stage, um gerador de descrição de PR que resume commits, um script de atualização de docs que lê arquivos-fonte e reescreve comentários desatualizados — todos tratam o Claude Code como uma etapa composável em uma cadeia que você controla.
Delimite cada chamada com precisão. O Claude Code funciona melhor quando a entrada é específica. Despejar toda uma base de código em uma única chamada produz resultados mais fracos do que direcionar o contexto relevante. O modelo de composabilidade naturalmente encoraja entradas focadas — e entradas focadas são o que produz saídas úteis.
A filosofia não é abstrata — é uma aposta em longevidade. Um fluxo de trabalho construído sobre primitivas do Claude Code absorve melhorias do modelo automaticamente. Um fluxo de trabalho que codifica rigidamente o comportamento do modelo (formatos de saída fixos, limiares ajustados, respostas analisadas com regex) precisa de manutenção toda vez que o modelo muda.
Reconstruí partes do meu harness SDLC duas vezes à medida que os modelos melhoraram, mas a integração com o Claude Code permaneceu idêntica cada vez. O modelo melhorou; a interface não mudou.
1. Você quer adicionar revisão de código baseada em Claude ao seu pipeline de CI sem instalar plugins específicos do Claude. Qual abordagem melhor se encaixa no modelo de primitiva sem opinião?
Correct Answer: B
Direcionar o diff diretamente para o claude em uma etapa shell é a abordagem primitiva: sem plugins, sem wrappers, apenas compondo ferramentas existentes. Continuará funcionando à medida que os modelos melhoram porque nada é codificado rigidamente em torno do comportamento atual do modelo.
2. Seu time construiu um fluxo de trabalho Claude Code que analisa a saída do Claude com uma regex para extrair itens de ação. Após uma atualização do modelo, o formato de saída muda e a regex quebra. O que esse fracasso ilustra?
Correct Answer: C
Codificar rigidamente suposições sobre o formato de saída do modelo cria acoplamento ao comportamento atual do modelo. O modelo primitivo diz: trate a saída do Claude como trataria qualquer saída de programa — analise-a de forma flexível, ou solicite explicitamente saída estruturada. O fracasso está no design do fluxo de trabalho, não no Claude Code.
3. Você inclui um arquivo CLAUDE.md no seu projeto descrevendo as convenções do repositório. Como isso se encaixa na filosofia de ferramenta sem opinião?
Correct Answer: C
CLAUDE.md permite que você ensine ao Claude as regras do seu projeto fornecendo-as como contexto — usando a mesma interface de entrada de texto que já existe. A primitiva permanece primitiva; você está adicionando contexto, não configuração.
4. Dois engenheiros usam o Claude Code para resumos de PR. Engenheiro A executa: git log | claude 'summarize'. Engenheiro B construiu um sumarizador dedicado que chama a API do Claude com um prompt ajustado e um esquema de saída JSON fixo. Qual exigirá menos manutenção à medida que os modelos melhoram?
Correct Answer: B
A abordagem do Engenheiro A permanece próxima à primitiva. À medida que o modelo melhora, os resumos ficam melhores sem nenhuma mudança no código. A abordagem do Engenheiro B precisará de re-ajuste do prompt e atualizações de esquema à medida que o comportamento de saída do modelo evolui. O custo de manutenção escala com o número de suposições integradas.
5. Qual das seguintes NÃO é uma propriedade de uma ferramenta sem opinião?
Correct Answer: B
Prescrever um fluxo de trabalho é a definição de uma ferramenta *com opinião*. Ferramentas sem opinião ficam fora das decisões de fluxo de trabalho — elas fornecem capacidade e deixam você decidir o fluxo de trabalho. As outras três opções são todas propriedades de primitivas composáveis.
6. Você quer que o Claude Code use os alvos Makefile do seu projeto em vez de executar comandos diretamente. Qual é a abordagem mais alinhada com a primitiva?
Correct Answer: C
A abordagem mais simples alinhada com a primitiva é ensinar o Claude através de contexto — em conversa ou no CLAUDE.md. Você está usando a interface de texto que já existe, não adicionando uma nova camada de configuração. O Claude lê a instrução e se adapta.