- O Claude Code lê codebases ativas diretamente na máquina do desenvolvedor por meio de exploração do sistema de arquivos e de
grepe rastreamento de referências, sem enviar índices - O desempenho depende muito não só do modelo, mas também do harness composto por
CLAUDE.md, hooks, skills, plugins e servidores MCP, além da ordem em que isso é montado - Em repositórios grandes, um
CLAUDE.mdenxuto e hierárquico, começar por subdiretórios, testes e lint com escopo definido e regras de exclusão aumentam a eficiência da exploração - A integração com LSP fornece rastreamento de definições e referências com base em símbolos, em vez de busca por strings, reduzindo navegações equivocadas em codebases grandes e multilíngues
- Para uma adoção bem-sucedida, é preciso revisar a configuração a cada 3–6 meses e ter um DRI ou agent manager para gerenciar plugins, permissões e regras
Como o Claude Code explora grandes codebases
- O Claude Code percorre o sistema de arquivos como um engenheiro de software: lê arquivos, usa
greppara encontrar o que precisa e segue referências por toda a codebase - Ele roda localmente na máquina do desenvolvedor, sem necessidade de criar, manter ou enviar para um servidor um índice da codebase
- Ferramentas de codificação com IA baseadas em RAG fazem embeddings da codebase inteira e recuperam chunks relevantes no momento da consulta, mas em ambientes grandes o pipeline de embeddings pode não acompanhar o ritmo acelerado de desenvolvimento
- Se o índice reflete o estado de semanas, dias ou horas atrás, ele pode retornar funções já renomeadas ou módulos removidos no sprint passado, sem sequer sinalizar que essa informação está desatualizada
- A busca orientada por agentes do Claude Code permite que cada instância do desenvolvedor trabalhe sobre a codebase viva, sem depender de pipeline de embeddings ou índice centralizado
- Há também um lado negativo: o Claude funciona melhor quando recebe contexto inicial suficiente para saber onde olhar
- Se você pedir para encontrar todas as ocorrências de um padrão ambíguo em uma codebase com bilhões de linhas, ele pode atingir o limite da janela de contexto antes mesmo de começar a tarefa
- Equipes que estruturam bem a codebase e organizam o contexto em camadas com arquivos
CLAUDE.mde skills obtêm resultados melhores
O harness é tão importante quanto o modelo
- O desempenho do Claude Code depende muito menos do modelo isolado e muito mais do harness construído ao redor dele
- O harness é composto por cinco pontos de extensão: CLAUDE.md, hooks, skills, plugins e servidores MCP
- Como cada camada se apoia na anterior, a ordem em que a equipe constrói isso também importa
- Integração com LSP e subagents funcionam como capacidades adicionais que complementam essa configuração
-
Arquivo
CLAUDE.md- O CLAUDE.md é um arquivo de contexto que o Claude lê automaticamente no início de toda sessão
- O arquivo da raiz traz a visão geral, e os arquivos em subdiretórios trazem regras locais
- Como ele é carregado em toda sessão, deve se concentrar no que se aplica de forma ampla para evitar queda de desempenho
-
Hooks
- Os Hooks não servem apenas como scripts para impedir comportamentos errados do Claude; o maior valor está em melhorar continuamente a configuração
- Um stop hook pode revisar o que aconteceu na sessão e sugerir atualizações no
CLAUDE.mdenquanto o contexto ainda está fresco - Um start hook pode carregar dinamicamente o contexto de cada equipe para que o desenvolvedor receba a configuração do seu módulo sem ajustes manuais
- Verificações automáticas como lint e formatação produzem resultados mais consistentes quando a regra é aplicada de forma determinística por hook, em vez de depender de o Claude lembrar da instrução
-
Skills
- As Skills permitem manter especializações sob demanda sem inflar todas as sessões
- Uma grande codebase pode ter dezenas de tipos de tarefa, mas nem toda especialização precisa entrar em toda sessão
- Skills usam divulgação progressiva (progressive disclosure) para manter workflows especializados e conhecimento de domínio fora do espaço de contexto, carregando-os apenas quando necessário
- Uma skill de revisão de segurança é carregada quando o Claude avalia vulnerabilidades, e uma skill de documentação é carregada quando é preciso atualizar docs após alterar código
- Também é possível definir escopo de skills por caminho, para que a skill de deploy da equipe de pagamentos fique vinculada apenas àquele diretório e não seja carregada automaticamente em outras áreas do monorepo
-
Plugins
- Os Plugins são o meio de distribuir configurações que funcionam bem, para que não fiquem como conhecimento tribal
- Um plugin reúne skills, hooks e configuração de MCP em um único pacote instalável
- Se um novo engenheiro instalar o plugin no primeiro dia, ele passa a ter imediatamente o mesmo contexto e as mesmas capacidades de quem já usava o Claude
- Atualizações de plugin podem ser distribuídas para toda a organização por meio de managed marketplaces
- Uma grande organização de varejo criou uma skill que conecta o Claude à sua plataforma interna de analytics, permitindo que analistas de negócio consultem dados de desempenho sem sair do workflow, e depois distribuiu isso como plugin antes do rollout para toda a empresa
-
Integração com Language Server Protocol
- A integração com Language Server Protocol (LSP) dá ao Claude a mesma capacidade de navegação de código do IDE do desenvolvedor
- A maioria dos IDEs para codebases grandes já executa LSP para viabilizar “go to definition” e “find all references”
- Ao expor isso ao Claude, ele passa a seguir chamadas de função até suas definições, rastrear referências entre arquivos e distinguir funções com o mesmo nome em linguagens diferentes, com precisão no nível de símbolo
- Sem LSP, o Claude depende de correspondência de padrões em texto e pode chegar ao símbolo errado
- Uma empresa de software corporativo distribuiu integração com LSP para toda a organização antes do rollout do Claude Code para estabilizar a navegação em C e C++ em larga escala
- Em codebases multilíngues, esse é um dos investimentos de maior valor
-
Servidores MCP
- Servidores MCP são a forma de conectar o Claude a ferramentas internas, fontes de dados e APIs às quais ele não consegue chegar diretamente
- As equipes mais maduras constroem servidores MCP que expõem busca estruturada como ferramentas que o Claude pode chamar diretamente
- Outras equipes conectam o Claude à documentação interna, sistemas de tickets e plataformas de analytics
-
Subagents
- Subagents separam exploração e edição
- Um subagent é uma instância isolada do Claude com sua própria janela de contexto, que recebe uma tarefa, a executa e devolve ao agente principal apenas o resultado final
- Depois que o harness está pronto, algumas equipes criam subagents somente leitura para mapear subsistemas e gravar o resultado em arquivos, deixando o agente principal editar com base nessa visão geral
-
Papel de cada componente e confusões comuns
CLAUDE.md: arquivo de contexto lido automaticamente pelo Claude e carregado em toda sessão. É adequado para regras por projeto e conhecimento da codebase, mas é fácil colocar nele especializações reutilizáveis que deveriam estar em skills- Hooks: scripts executados em momentos-chave e acionados por eventos. São adequados para automatizar comportamentos consistentes e capturar aprendizados da sessão, mas é comum tratar via prompt o que deveria rodar automaticamente
- Skills: instruções empacotadas para tipos específicos de tarefa e carregadas sob demanda quando relevantes. São adequadas para especializações reutilizadas entre sessões e projetos, mas é comum colocar tudo dentro de
CLAUDE.md - Plugins: bundles de skills, hooks e configuração de MCP, sempre disponíveis após a instalação. São adequados para distribuir configurações que funcionam em toda a organização, mas é fácil deixar boas configurações como conhecimento tribal
- LSP: inteligência de código em tempo real via servidores por linguagem, sempre disponível após a configuração. É adequado para navegação em nível de símbolo em linguagens tipadas e detecção automática de erros, mas é fácil presumir que isso já venha pronto
- Servidores MCP: conexão com ferramentas e dados externos, sempre disponível após a configuração. São adequados para acesso a ferramentas internas às quais o Claude não consegue acessar diretamente, mas é comum tentar criar conexões MCP antes de fazer o básico funcionar
- Subagents: instâncias separadas do Claude para tarefas específicas, executadas quando chamadas. São adequadas para separar exploração e edição e para trabalho paralelo, mas é comum tentar fazer exploração e edição na mesma sessão
- O LSP é acessado pela camada de plugin, e subagents não são um ponto de extensão configurado, mas uma capacidade de delegação
Três padrões de configuração recorrentes em implantações bem-sucedidas
-
Tornar a codebase navegável mesmo em grande escala
- A capacidade do Claude de ajudar em codebases grandes é limitada pela sua capacidade de encontrar o contexto certo
- Carregar contexto demais em toda sessão derruba o desempenho; carregar contexto de menos faz o Claude explorar às cegas
- Implantações eficazes investem desde cedo em tornar a codebase fácil de ler para o Claude
-
Mantenha os arquivos
CLAUDE.mdenxutos e hierárquicos- O Claude carrega de forma cumulativa os arquivos
CLAUDE.mdà medida que percorre a codebase - O arquivo da raiz fica com a visão geral, e os arquivos de subdiretórios ficam com as regras locais
- O arquivo da raiz deve conter apenas ponteiros e alertas críticos; o restante tende a virar ruído
- O Claude carrega de forma cumulativa os arquivos
-
Comece por um subdiretório, não pela raiz do repositório
- O Claude funciona melhor quando seu escopo fica limitado à parte da codebase realmente relevante para a tarefa
- Em monorepos, isso pode parecer contraintuitivo, já que muitas ferramentas partem do pressuposto de acesso à raiz
- O Claude sobe automaticamente pela árvore de diretórios e carrega todos os arquivos
CLAUDE.mdque encontrar, então o contexto de nível raiz não se perde
-
Dê escopo por subdiretório a comandos de teste e lint
- Se o Claude mudar apenas um serviço, mas executar a suíte inteira de testes, haverá timeout e desperdício de contexto com saídas irrelevantes
- Os arquivos
CLAUDE.mddos subdiretórios devem explicitar os comandos que se aplicam àquela parte da codebase - Isso funciona bem em codebases orientadas a serviços, nas quais cada diretório tem seus próprios comandos de teste e build
- Em monorepos de linguagens compiladas com dependências profundas entre diretórios, esse escopo por subdiretório é mais difícil e pode exigir configuração de build por projeto
-
Exclua arquivos gerados, artefatos de build e código de terceiros com arquivos
.ignore- Ao versionar regras
permissions.denyem.claude/settings.json, as regras de exclusão também ficam sob controle de versão - Todos os desenvolvedores da equipe ganham a mesma redução de ruído sem configuração extra
- Em algumas codebases, os próprios arquivos gerados podem ser alvo de desenvolvimento
- Quem trabalha com geradores de código pode sobrescrever regras de exclusão no nível do projeto com configurações locais, sem afetar o restante da equipe
- Ao versionar regras
-
Construa um mapa da codebase se a estrutura de diretórios não for suficiente
- Em organizações em que o código não está consolidado em uma estrutura de diretórios convencional, um arquivo Markdown leve na raiz ajuda
- Uma descrição de uma linha para cada pasta de topo e o que ela contém funciona como um índice que o Claude pode consultar antes de abrir arquivos
- Se houver centenas de pastas de topo, a melhor abordagem é hierárquica: o arquivo da raiz descreve apenas a estrutura de mais alto nível, e os
CLAUDE.mddos subdiretórios fornecem o próximo nível de detalhe sob demanda - Em casos mais simples, mencionar com
@arquivos ou diretórios específicos que o Claude deve consultar pode cumprir o mesmo papel
-
Use servidores LSP para buscar por símbolos, não por strings
- Em codebases grandes, usar
grepem um nome de função comum pode gerar milhares de ocorrências, e o Claude consome contexto abrindo arquivos para decidir o que importa - O LSP retorna apenas referências ao mesmo símbolo, então a filtragem acontece antes de o Claude ler qualquer coisa
- Para configurar isso, é preciso instalar o plugin de code intelligence da linguagem e o binário do language server correspondente
- A documentação do Claude Code inclui plugins disponíveis e formas de troubleshooting
- Em codebases grandes, usar
-
Exceções
- Há edge cases em que até a abordagem hierárquica com
CLAUDE.mdfalha - Isso inclui codebases com centenas de milhares de pastas e milhões de arquivos, além de sistemas legados em controle de versão que não seja Git
- Há edge cases em que até a abordagem hierárquica com
-
Manter arquivos
CLAUDE.mdao longo das mudanças de inteligência do modelo- À medida que os modelos evoluem, instruções escritas para o modelo atual podem atrapalhar modelos futuros
- Regras em
CLAUDE.mdcriadas para orientar padrões que antes eram difíceis para o Claude podem se tornar desnecessárias ou até restritivas em modelos novos - Por exemplo, uma regra que exige quebrar toda refatoração em alterações de um único arquivo pode ter ajudado um modelo anterior a manter o fluxo, mas pode impedir edições coordenadas em múltiplos arquivos que um modelo mais novo já consegue fazer bem
- Skills e hooks criados para compensar limitações específicas do raciocínio do modelo ou das ferramentas do Claude Code viram overhead quando essas limitações desaparecem
- Um hook que interceptava gravações de arquivo para forçar
p4 editem codebases com Perforce se torna redundante depois que o Claude Code adiciona modo nativo para Perforce - As equipes devem prever uma revisão significativa da configuração a cada 3–6 meses
- Também vale revisar a configuração quando, após um grande lançamento de modelo, parecer que o desempenho estagnou
-
Definir ownership para administração e adoção do Claude Code
- Só a configuração técnica não gera adoção
- Os rollouts que se espalharam mais rápido tiveram investimento em infraestrutura antes de um acesso amplo
- Uma equipe pequena, às vezes uma única pessoa, conectou as ferramentas para que, quando o desenvolvedor usasse o Claude pela primeira vez, ele já funcionasse de acordo com o workflow
- Em uma empresa, alguns engenheiros construíram desde o primeiro dia um bundle de plugin e MCP pronto para uso
- Em outra, uma equipe dedicada à gestão de ferramentas de codificação com IA preparou a infraestrutura antes do rollout
- Esse trabalho costuma ficar sob organizações de experiência do desenvolvedor ou produtividade do desenvolvedor, que já cuidam de onboarding de novos engenheiros e da construção de ferramentas internas
- Em várias organizações, está surgindo o papel de agent manager, um híbrido entre PM e engenheiro para gerenciar o ecossistema do Claude Code
- Se não houver equipe dedicada, a forma mínima viável é ter um único DRI
- Esse DRI deve ser responsável pela configuração do Claude Code, pelas decisões de configuração, pela política de permissões, pelo plugin marketplace e pela propriedade e atualização das regras em
CLAUDE.md - A adoção bottom-up gera entusiasmo, mas pode se fragmentar se ninguém centralizar o que funciona
- É necessário haver uma pessoa ou equipe para reunir e disseminar convenções do Claude Code, como uma hierarquia padronizada de
CLAUDE.mdou um conjunto curado de skills e plugins - Sem esse trabalho, o conhecimento continua tribal e a adoção estagna
Governança e rollout
- Em organizações grandes, especialmente em setores regulados, questões de governança surgem cedo
- Os principais pontos são: quem controla quais skills e plugins podem ser usados, como evitar que milhares de engenheiros recriem independentemente a mesma coisa e como garantir que código gerado por IA passe pelo mesmo processo de revisão que código escrito por humanos
- No início, recomenda-se uma abordagem com um conjunto definido de skills aprovadas, processo obrigatório de code review e acesso inicial limitado, ampliando conforme a confiança cresce
- As implantações mais suaves ocorreram em organizações que criaram logo cedo um grupo de trabalho multifuncional com representantes de engenharia, segurança da informação e governança, definindo em conjunto requisitos e roadmap de rollout
Premissas e limitações ao aplicar isso na organização
- O Claude Code foi projetado em torno de um ambiente tradicional de engenharia de software, em que engenheiros são os principais contribuidores da codebase, o repositório usa Git e o código segue uma estrutura padrão de diretórios
- A maior parte das grandes codebases se encaixa nesse modelo, mas engines de jogos com grandes ativos binários, ambientes de versionamento não tradicionais e ambientes em que pessoas não engenheiras contribuem para a codebase exigem trabalho adicional de configuração
- Os padrões apresentados partem de uma configuração tradicional e funcionaram em vários ambientes de clientes
- A complexidade restante precisa ser avaliada de acordo com a codebase, as ferramentas e a estrutura organizacional de cada empresa
- A equipe de Applied AI da Anthropic trabalha diretamente com equipes de engenharia para traduzir esses padrões nas necessidades específicas de cada organização
1 comentários
Comentários do Hacker News
A expressão de navegar pelo codebase “como um engenheiro de software” parece entrar em conflito com a conclusão
Autocomplete e LSP são sempre usados e úteis; isso também não é um tipo de indexação? Também fico me perguntando por que o Claude não consegue usar isso
Engenheiros de software também memorizam o codebase, o que na prática é bem próximo de RAG, e há muito de memória muscular para achar o arquivo necessário com CMD+P e autocomplete
Não precisa ser em tempo real para o codebase inteiro sendo alterado simultaneamente por milhares de engenheiros; basta enxergar bem a branch em que estou trabalhando
Raramente alguém explora um codebase percorrendo o sistema de arquivos desde o início; isso normalmente só acontece em um codebase novo, e mesmo nesse caso é difícil chamar isso de experiência ideal
Aprendi a navegar em codebases grandes desde a época em que não existia LSP, e por muitos anos usei vim e grep para encontrar arquivos relacionados
Quando usei Claude Code pela primeira vez no ano passado, a sensação foi “ué, ele está fazendo exatamente o que eu faria”
A premissa é que o Claude Code está sendo usado em monorepos com milhões de linhas, sistemas legados com décadas de idade e arquiteturas distribuídas espalhadas por dezenas de repositórios
Então ele é otimizado para o caso geral de usar ferramentas robustas que funcionem em qualquer lugar, especialmente em codebases grandes e bagunçados
Ainda assim, faz sentido dizer que em repositórios pequenos e bem organizados você pode — e deve — usar ferramentas melhores
Pelo menos o Codex funciona assim e, por exemplo, usa
go docantes de fazer grepQuando você trabalha nessa escala, percebe rápido que o Claude não usa as ferramentas criadas justamente para tornar a busca viável
Dizer “como um engenheiro de software” só é verdade em parte
Pessoas também usam busca de símbolos, mas procuram símbolos que já lembram dentro de um contexto específico de trabalho
A forma como o Claude Code hoje vasculha símbolos sem critério não é como engenheiros trabalham
Um erro de digitação pode levar o agente a concluir que precisa reimplementar algo, e mesmo que por sorte leia o arquivo certo, pode facilmente alucinar
Também não é assim que se trabalha em codebases grandes
A parte de “encontra exatamente o que precisa com grep” me incomoda especialmente
Para usar grep, você precisa saber o que vai procurar, e se vierem milhares de resultados, precisa revisar todos
Quando isso acontece, uma pessoa pensa em como restringir a saída em vez de varrer os resultados de forma bruta
A abordagem do texto parece mais uma explicação para justificar o método atual do que uma recomendação sólida
Dizer “não é preciso indexar o codebase” também é verdade, mas só no sentido de que, fazendo grep-read-grep e expandindo o contexto, em algum momento você talvez encontre a resposta
Soa parecido com dizer “não precisamos do Claude Code porque um desenvolvedor também poderia implementar isso manualmente sem Claude Code”
Acho errada essa mensagem de “não precisa”, porque ela passa para a comunidade uma decisão como se fosse um absoluto
No geral, o texto é honesto sobre o custo organizacional
Em várias organizações, está surgindo o papel de “gerente de agentes”, uma mistura de PM com engenheiro, para administrar o ecossistema do Claude Code, e as equipes precisam revisar configurações relevantes a cada 3 a 6 meses
Isso mostra com precisão a realidade de usar Claude Code em grande escala sem uma camada pré-construída de inteligência de código
A direção parece correta, mas ao terminar a leitura fica um gosto de “não resolvemos o problema e este é o nosso limite”
Um ponto em que eu vivo discutindo com o Claude é justamente fazê-lo explorar muito menos
Eu conheço melhor e sou mais rápido do que esse jeito lento e caro de vasculhar coisas que quase não mudam
Ainda assim, ele cai sempre nos mesmos tipos de buraco de coelho
Como anedota, eu estava projetando um projeto para onboarding e orquestração de LLM, e o Claude escolheu ler só as primeiras 40 linhas de cada arquivo
Depois, em outra sessão, ao investigar a causa da baixa qualidade, o Claude encontrou essa falha e alterou o código para fazer análise de AST usando como entrada linhas de documentação e entradas/saídas de assinaturas de funções
A abordagem inicial do Claude foi realmente muito ruim
Isso me faz questionar o quanto o Claude Code precisa ser corrigido e revisado para chegar a algo bom, e se ele consegue produzir um bom código desde o início
Generalizando, o Claude consegue corrigir decisões ruins locais e identificáveis, como “ler só as primeiras 40 linhas”
Isso porque o defeito está isolado e pode ser rastreado até um único trecho de código
Mas problemas reais de qualidade de software muitas vezes surgem quando pequenas decisões, individualmente razoáveis, se acumulam e produzem um resultado ruim
Nesses casos, nenhum ponto isolado é um “defeito” evidente, então uma ferramenta que gera aos pedaços os componentes de um código de baixa qualidade pode não convergir para um bom código, porque cada pedaço, visto separadamente, parece aceitável
Nesses casos, uma lógica auxiliar ou até subagentes completos podem se encaixar bem
Por exemplo, você delega a um subagente algo como “dê uma passada neste arquivo, resuma e marque o que se relaciona com X e Y; depois eu olho no contexto principal”
Também daria para ele observar periodicamente o fluxo principal de trabalho e intervir quando julgar que algo no arquivo que está analisando se relaciona com a tarefa atual ou pode mudar a direção
Como o Claude Code funciona em codebases grandes? Simples
Mesmo em projetos pequenos ele consome 35% do limite de uso de 5 horas no primeiro prompt, e se não responder em até 5 minutos o cache evapora e no prompt seguinte você paga mais 12% a 15%
Se você o soltar de forma ingênua em um codebase grande, faz sentido que ele queime muitos tokens enquanto procura
O Claude Code não poderia inspecionar o codebase e gerar automaticamente um harness eficaz?
Já defini
CLAUDE.md,AGENTS.md, skills e plugins, mas não estou vendo o efeito que outras pessoas relatamPor exemplo, mesmo com plugin de LSP, o Claude Code não usa renomeação de símbolo do LSP e vai editando os arquivos um por um lentamente; ou, mesmo especificando no prompt que deve chamar uma skill quando houver certo indício, ele não chama
Estou usando errado? Queria saber se existe algum exemplo de harness robusto que dê para copiar e usar
Você diz “se for A, faça X. Faça B, C, D. Faça A” e mesmo assim ele simplesmente não usa X
Porque ele “esqueceu”
Não dá para confiar que o tempo gasto criando regras realmente será recompensado; pelo contrário, dá para confiar que em algum momento vai falhar
RAG, harnesses e skills prometeram resolver isso, mas na prática não resolveram
/inite de manter um arquivoCLAUDE.mdouAGENTS.mddescrevendo o codebaseO que deixei foi só como explorar o codebase e a instrução de usar
git logdurante investigação, mas isso provavelmente também é redundanteEu também não sei a resposta
O codebase em que estou trabalhando tem algo em torno de 100 mil linhas, então não sei se isso conta como grande, mas para mim é o maior repositório em que já trabalhei
Para limitar o contexto, tive de remover algumas mensagens de linter desnecessárias
Instalar via repositório de pacotes do sistema operacional linters ou verificadores específicos da linguagem, que possam ser chamados por scripts, também ajuda
A combinação entre modelo e contexto de skill também pode fazer diferença
Uma skill que “funcionava” no 4.6 pode não se encaixar bem no 4.7; o 4.7 exige instruções mais explícitas, mas é relativamente mais estável que o 4.6
Atualizar a skill também pode ajudar, e é preciso comparar testes e execuções antes e depois
O Claude Code também coloca chamadas de ferramenta desnecessárias no contexto, então, por exemplo, se você gosta de beads, talvez precise conter o trabalho
Não concordo com a afirmação sobre indexação de codebase
No PHPStorm ou em outros IDEs da JetBrains, a indexação funciona muito bem
Muito raramente ela corrompeu, mas foi fácil corrigir, e nunca recebi resultados desatualizados
Se você já usou as ferramentas de busca do Claude, não vai se surpreender com a ideia de que aquele time não entende nada de indexação
Não faz sentido uma empresa cujo produto principal é um chat baseado em texto dificultar tanto que o usuário pesquise texto dentro desse chat
É texto lixo de IA? O GitHub Copilot também tem uma indexação local bem boa
Colocar código em um banco de dados vetorial não é um problema tão difícil assim
Esse texto claramente foi escrito pelo Claude
Tem muito enchimento e pouco conteúdo de fato
É estranho dizer que isso inclui linguagens como C, C++, C#, Java e PHP, que as equipes nem sempre associam a ferramentas de programação com IA
Por que deveríamos esperar que o Claude Code não funcione bem nessas linguagens? Que linguagens então deveríamos imaginar, Python e JavaScript?
Em um setor em que o cenário muda em meses, não em semanas, é interessante dizer que já houve tempo suficiente para aparecerem padrões claros e que esses padrões foram bem-sucedidos em codebases grandes
Qual é o critério de sucesso? Não apagar o banco de produção? A equipe ficou mais rápida? A vida útil do codebase aumentou? O time de operações ficou mais feliz?
Nunca trabalhei em uma empresa onde alguém recebesse esse nível de acesso irrestrito
Meu estresse hoje vem todo do Claude Code não seguir instruções, e isso piorou à medida que o codebase cresceu
Não me entenda mal: o Claude é incrível e eu gosto muito dele
Mas não dá, de jeito nenhum, para contratar só Claude Code e deixá-lo manter o codebase ou adicionar funcionalidades
Continuo adicionando itens de memória sobre erros passados, mas o problema de ignorar instruções importantes ainda acontece com probabilidade de cerca de 90%
A única forma de evitar isso é ficar observando cada tarefa do lado e revisar o resultado intensamente
O Claude Code é excelente para documentação ou para entender codebases grandes, mas é fraco em mudanças que exigem entendimento do todo
Por exemplo, há cerca de 10 padrões de registry usados para várias entidades ao longo do codebase, e mesmo existindo uma regra explícita de “use este único padrão de registry”, o Claude Code implementou separadamente 4 registries independentes, um para cada entidade
Passei metade do dia praticamente gritando com o Claude Code para fazê-lo acertar essa tarefa simples e, no fim, corrigi eu mesmo para economizar estresse e tempo
Nem explicam em termos concretos o que exatamente deve entrar em cada arquivo
CLAUDE.md, então não sei o quão importantes esses arquivos realmente sãoVara de pescar: 1) instale o
skill-creatoroficial 2) use o link acima para criar umclaude-md-improver3) peça para ele investigar o tópicoprogressive-disclosurena documentação oficial e melhorar a skill 4) aplique a nova skill ao arquivoCLAUDE.mde aceite as mudanças