4 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O Claude Code lê codebases ativas diretamente na máquina do desenvolvedor por meio de exploração do sistema de arquivos e de grep e 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.md enxuto 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 grep para 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.md e 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.md enquanto 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.md enxutos 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
    • 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.md que 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.md dos 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.deny em .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
    • 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.md dos 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 grep em 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
    • Exceções

      • Há edge cases em que até a abordagem hierárquica com CLAUDE.md falha
      • 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
  • Manter arquivos CLAUDE.md ao 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.md criadas 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 edit em 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.md ou 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

 
GN⁺ 3 시간 전
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

    • É exatamente assim que eu trabalho
      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 resposta está na introdução do texto
      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 doc antes de fazer grep
    • Em codebases realmente grandes, grep e find dão timeout
      Quando você trabalha nessa escala, percebe rápido que o Claude não usa as ferramentas criadas justamente para tornar a busca viável
    • Há muitas frases plausíveis em um parágrafo curto, mas na prática isso parece mais uma afirmação esperançosa
      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”
    • Mesmo quando se explora uma parte do codebase desde o começo, existem áreas que nunca mudam, e revisitá-las toda vez é um grande desperdício de tokens
      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

    • Parece ter sido treinado para enxergar o código-fonte por um buraco estreito para preservar contexto
      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%

    • O texto linkado explica como evitar isso
      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 relatam
    Por 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

    • Esse é um ponto de dor de anos e ainda não foi resolvido de verdade
      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
    • Eu parei de usar /init e de manter um arquivo CLAUDE.md ou AGENTS.md descrevendo o codebase
      O que deixei foi só como explorar o codebase e a instrução de usar git log durante investigação, mas isso provavelmente também é redundante
      Eu 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
    • Em alguns casos, hooks com scripts parecem funcionar bem para injetar informações na janela de contexto
      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

    • A indexação do PHPStorm é excelente
      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
    • O Claude Code pode usar essa indexação via MCP do JetBrains
    • É uma afirmação estranha
      É 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?

    • Se um banco de produção foi apagado por causa de uma ferramenta de IA, continuo querendo dizer que isso é falha sua e da sua organização por dar aos desenvolvedores permissões de produção capazes de apagar recursos operacionais
      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ão

    • Peixe: dá para ler aqui https://code.claude.com/docs/en/best-practices#write-an-effe...
      Vara de pescar: 1) instale o skill-creator oficial 2) use o link acima para criar um claude-md-improver 3) peça para ele investigar o tópico progressive-disclosure na documentação oficial e melhorar a skill 4) aplique a nova skill ao arquivo CLAUDE.md e aceite as mudanças