Claude Code e o fim do desenvolvimento como conhecemos
Sou programador há mais de 20 anos e não lembro a última vez que fiquei tão empolgado com uma nova ferramenta. (Não estou mais escrevendo código na mão! O QUE ESTÁ ACONTECENDO!?)
O Claude Code, da Anthropic, é daquelas tecnologias que funcionam sem que você precise de nenhuma instrução. "É só sair usando!"
Contudo, vejo muita gente se frustrando. Ainda que seja fácil de usar (basta escrever um prompt), a ferramenta brilha quando você investe um tempinho para aprendê-la.
Sendo bem direto: não é perfeita, não é mágica e não vai te substituir — precisa de dedicação sua!
Mas se você souber usar do jeito certo, os resultados são realmente empolgantes!
Neste artigo, quero compartilhar com você o que aprendi sobre o Claude Code nas últimas semanas.
Espero que você fique tão empolgado quanto eu!
1 - Começe sempre com o modo "plan"
Por mais que você se esforce, aceite que seu prompt vai ser ruim.
O motivo: você não sabe, de cabeça, todos os detalhes da sua base de código. Mas o Claude Code pode acessar toda a sua base (mais a internet... mais servidores MCP...) e buscar informações muito mais rápido do que você.
Porém, por mais que o Claude Code "se esforce", ele também tem seus limites de contexto, de compreensão, de acesso, etc.
E se você puder juntar o melhor de você com o melhor dessa ferramenta?
É para isso que serve o modo plan. Pense que aqui você e o Claude Code vão trabalhar juntos para montar o "prompt inicial perfeito".
No modo plan, o Claude Code é somente leitura, ou seja, ele não vai modificar nada no seu código — mas vai atrás do máximo de informação possível, com base no que você pedir, e vai te apresentar um plano de ação.
Gaste um tempo lendo esse plano em detalhes. Se não estiver de acordo, continue refinando até fazer sentido. Se achar que faltou algo, escreva, detalhe, explique! Peça para analisar, considerar outro ângulo.
Não confie no plano inicial. Na minha experiência, geralmente falta alguma coisa ali como atualizar testes, atualizar documentação, algum edge case, alguma nuance, etc.
Só libere o Claude Code para atuar e fazer as modificações no código quando o plano estiver sólido.
E, desde o início, mantenha sua conversa em inglês (leia esse outro artigo para entender o motivo).
2 - Use arquivos CLAUDE.md com "divulgação progressiva"
Assim como um bom desenvolvedor, o Claude Code pode descobrir muita coisa sozinho só olhando a sua base de código, como por exemplo:
- stack completa (linguagens, frameworks, dependências externas...)
- decisões arquiteturais
- coding style
- como rodar testes
- como rodar a aplicação
Contudo, para ele descobrir isso custa tempo, processamento e consome seus créditos. Além disso, novamente como um bom desenvolvedor, tem coisas que é simplesmente impossível — ou muito difícil — para ele sacar só olhando o código.
É pra isso que serve o arquivo CLAUDE.md: fazer o Claude Code entender o seu projeto e dar para ele, de maneira rápida, as informações que ele precisa para trabalhar.
Para criar automaticamente um arquivo CLAUDE.md na raiz do seu projeto, basta usar o comando /init.
Esse comando vai fazer um trabalho inicial ok. Mas talvez você note que o arquivo CLAUDE.md fique muito grande — e isso é um problema!
Lembre-se que o Claude Code vai ler esse arquivo várias vezes (pelo menos toda vez que você iniciar uma conversa). Talvez ele não precise "desperdiçar contexto" com toda a informação que existe ali.
Lembre-se também: por baixo do Claude Code existe uma LLM. E essa tecnologia tem atenção e contexto limitados! Como escrevi em outro artigo:
"Cada token ocupa espaço na janela de contexto (...) Por isso, cada token que você envia pra dentro da LLM conta para determinar a qualidade do próximo token que ela irá gerar."
Você, desenvolvedor, também tem atenção limitada: você não mantém todos os detalhes do backend na sua cabeça enquanto está resolvendo um bug no front. Você, geralmente, não vai olhar a implementação dos seus testes de unidade enquanto está arrumando algo no banco de dados.
Você só olha QUANDO você precisa!
E o mesmo é válido para o Claude Code! Ele performa melhor se você escrever seu CLAUDE.md considerando fazer "divulgação progressiva" (progressive disclosure) de informação: diga onde está a informação, caso ele precise (em outro arquivo de documentação ou em outro arquivo CLAUDE.md numa subpasta), mas não deixe seu CLAUDE.md na raiz do projeto ficar grande demais!
Gastei algum tempo aperfeiçoando minhas habilidades de escrever um bom CLAUDE.md e coloquei esse conhecimento em uma skill, pra automatizar esse trabalho para mim:
Basta clonar esse repositório em ~/.claude/skills, reiniciar sua sessão do Claude Code e digitar /bootstrap.
Tenho tido ótimos resultados em monorepos com vários CLAUDE.md aninhados. E rodo /bootstrap regularmente para atualizar esses arquivos e documentação.
3 - Testes de unidade e zelo pela qualidade do código
Guardadas as devidas proporções, bateu um leve "AGI feeling" em mim quando eu me dei conta de quanto o Claude Code se parece com um colega de time.
Na seção anterior, comparei algumas vezes o Claude com um "bom desenvolvedor". Permita-me fazer isso mais uma vez: quando você, um bom desenvolvedor humano, entra num projeto novo, o que você precisa para conseguir performar bem?
Vou citar pelo menos três coisas:
- Uma boa cobertura de testes de unidade (para você fazer alterações no código com segurança de que não quebrou nada)
- Um código de boa qualidade (arquitetura bem definida, abstrações coesas, bons nomes para classes, métodos e variáveis)
- Alguma documentação para te contar decisões não óbvias
Preciso dizer que exatamente tudo isso também ajuda o Claude Code a performar bem?
Lembre-se: essa ferramenta é capaz de fazer no seu console (quase) tudo o que você, humano, consegue fazer. Inclusive rodar testes de unidade e verificar a saída — e se corrigir automaticamente caso tenha quebrado alguma coisa!
É muito legal ver os agentes do Claude Code pensando, fazendo alterações no código, rodando testes, quebrando testes, iterando e tentando resolver tudo sozinho! Porém, se testes não existem, ou se a cobertura é baixa, a ferramenta tem menos chances de se autocorrigir.
Por isso, insisto: tenha testes de unidade, informe que eles existem e como rodá-los na documentação (README.md ou CLAUDE.md), e mantenha uma cobertura de testes alta!
E sobre a qualidade do código? Já ouvi algumas vezes a pergunta:
"Por que se preocupar com código legível se quem vai ler e modificar o código é uma IA, e não um humano?"
O motivo talvez já tenha ficado claro, mas não custa reforçar: o que faz um desenvolvedor humano performar bem numa base de código, também faz o Claude Code performar bem!
Não está convencido? Lembre-se novamente de que por baixo do Claude Code existe uma LLM: um modelo estatístico de linguagem treinado para aprender e repetir padrões!
Então, note, por exemplo, o seguinte:
-
O que acontece quando você aplica DRY (Don't Repeat Yourself)? Resposta: você evita desperdício de contexto da LLM (mesmo princípio do CLAUDE.md que expliquei antes);
-
O que acontece quando nomes (de módulos, classes, métodos, variáveis) são significativos? Resposta: você dá melhor contexto para a LLM, potencialmente obtendo melhores respostas.
Portanto, peça para o Claude Code refatorar! Peça para usar bons nomes. Peça para quebrar funções grandes, reusar funcionalidades existentes antes de reinventar a roda. Criar abstrações robustas com alta coesão e baixo acoplamento. Tenha uma arquitetura bem definida. Use padrões de projeto. Reforce princípios SOLID, DRY, KISS, YAGNI, clean code... tenha atenção aos detalhes! Não transforme sua base de código em puro ruído sem padrões!
O desempenho de qualquer desenvolvedor (seja ele humano ou IA/LLM) será seriamente comprometido numa base de código odiosa!
Ainda não está convencido? Veja este artigo.
4 - Não escreva mais código na mão
Essa é a parte mais controversa, e deve ser lida com ponderação.
O disclaimer completo: o que escrevo aqui é com base na minha experiência até então — que é limitada. Usei o Claude Code em alguns poucos projetos, envolvendo algumas poucas linguagens e frameworks (C#/.NET, Typescript/Angular e Python, na maior parte).
Por isso, não sei se é realmente possível "nunca mais escrever código na mão". Contudo, com a experiência que tive, considerando os projetos e tecnologias que usei, e considerando que 100% das linhas de código que commitei nas últimas semanas não foram escritas diretamente por mim... não sei se vou mais escrever código na mão — e eu acho isso incrível!
É por causa dessa experiência que não consigo deixar de pensar na frase clickbait que está no título desse artigo: "é o fim do desenvolvimento como conhecemos".
Porém, eu vejo muitas vantagens nisso. Citando algumas:
-
A IA preenche os "gaps" da minha mente: eu não sei de cabeça todos detalhes da minha base de código, muito menos de libs e APIs externas. Mas a IA busca tudo isso rapidinho.
-
Usando arquivos CLAUDE.md versionados e compartilhados com todo o time — e assumindo que todos os desenvolvedores também só escrevem código via IA — conseguimos "forçar" boas práticas e padrões de código que vão além do que era possível com ferramentas de lint, por exemplo.
-
Eu me sinto mais "audacioso" para atacar os problemas, usar novas tecnologias e explorar caminhos que antes, sem a IA, eu nem cogitaria.
No geral, eu sempre gostei de criar coisas — e a IA está me permitindo fazer mais disso. Talvez seja esse o real motivo de toda a minha empolgação com o Claude Code.
O que escrevi aqui é o que considero essencial para começar a usar bem essa ferramenta. Mas existem muitas outras dicas importantes (e.g. MCPs, skills, plugins...), além de nuances e detalhes que você só vai sacar colocando a mão na massa. Nada difícil. É só começar!
E se você quiser saber minha opinião sobre como o Claude Code e ferramentas desse tipo impactam nossa profissão, já escrevi outro artigo sobre isso.