Claude Code, da Anthropic, é comparado a um desenvolvedor júnior e rende 5 regras para produção

O Claude Code pode dar a um desenvolvedor solo o ritmo de uma equipe pequena, mas em produção só funciona sob controle rígido. Essa é a conclusão do autor de um estudo de caso que, em um mês, montou um sistema de análise recorrente de preços e ofertas de produtos de concorrentes. Pela experiência dele, o modelo se comporta como um júnior proativo: escreve muito código rápido, propõe soluções nada triviais e não contesta, mas perde contexto entre sessões com facilidade e, sem disciplina externa, começa a reinventar a arquitetura, romper os limites entre módulos e fazer alterações incoerentes.

O projeto não parece uma demo, e sim um sistema completo em operação. Ele já tem cerca de 25 fontes em diferentes engines, de sites estáticos a aplicações SPA, e o autor planeja chegar a cerca de 60 até o fim do ano. O conjunto de dados atual tem cerca de 6000 itens de produto, e a amostra completa deve chegar a cerca de 15 000.

No desenvolvimento, foram usados SQLite e PostgreSQL. O parsing combina requests, BeautifulSoup, lxml e Playwright, com abordagem API-first onde os dados podem ser obtidos diretamente. Por cima, há uma camada analítica para benchmark de preços, gap analysis e comparação de características de produtos, e o matching acontece em várias etapas: pré-filtro, embeddings e LLM-as-judge para casos limítrofes.

O autor ressalta que esse volume exige não só velocidade para escrever código, mas disciplina de engenharia. Por isso, o tema central do texto são cinco regras de controle.

Primeira, TDD antes da primeira linha de implementação: sem testes escritos antecipadamente, o modelo pode fazer não o que é necessário, mas apenas o que parece plausível.

Segunda, documentação como memória externa, porque um novo chat equivale, na prática, a um novo funcionário que desconhece as decisões passadas. O projeto usou documentos de arquitetura separados, um registro de decisões com milhares de entradas, descrições de pipelines e planos de sprint.

Terceira, verificações de regressão obrigatórias com golden data, para comparar após cada mudança a qualidade do matching com pares de referência e não deixar passar uma degradação silenciosa.

Quarta, code review manual sem concessões só porque o código foi gerado rápido: se a pessoa não entende por que a solução foi construída daquele jeito, ela não pode ser mergeada.

Quinta, limites firmes de iniciativa nos prompts, para que o modelo não comece a refatorar módulos vizinhos, alterar interfaces ou adicionar lógica desnecessária sob o pretexto de melhorias.

O texto traz ainda um episódio técnico revelador. Ao otimizar o matching, o Claude Code paralelizou o trabalho com `sqlite3.Connection` por meio de `ThreadPoolExecutor`, o que aumentou a velocidade, mas causou falhas sob carga no macOS. O problema só foi notado graças a uma revisão atenta e a testes de carga, e foi corrigido com a adoção de uma conexão separada por thread via `threading.local()`. Depois disso, foi possível manter a estabilidade e obter um ganho de desempenho de várias vezes. O exemplo importa não por si só, mas como ilustração da ideia central: o modelo pode propor uma solução que parece funcionar, mas na verdade carrega um risco oculto para produção.

O autor também traça os limites da abordagem. Na opinião dele, um engenheiro experiente e com bom entendimento de arquitetura pode, com o Claude Code, trabalhar como duas ou três pessoas, especialmente em parsing, automações e sistemas internos aplicados. Já quem não tem uma base sólida provavelmente obterá só um MVP que se passa por produção: os testes serão escritos para o código atual, a documentação ficará desatualizada rápido e o custo de manutenção começará a subir em poucas semanas.

A principal conclusão para o mercado é simples: ferramentas de IA não eliminam o desenvolvimento sênior, elas elevam as exigências sobre ele. O Claude Code acelera a implementação, mas não assume a responsabilidade pela arquitetura, pela qualidade e pela longevidade do sistema. Quanto mais tempo um produto precisa viver, mais importam a memória externa, as barreiras de regressão e o controle manual de engenharia. Sem isso, não se tem um sistema de produção maduro, apenas a impressão convincente de que ele já está pronto para uma operação de longo prazo.