Já venho escrevendo sobre desenvolvimento assistido por IA há algum tempo, mas queria ficar mais concreta. Então puxei meu relatório de uso do Claude Code — 282 mensagens em 56 sessões ao longo de 21 dias — e investiguei o que está funcionando, o que não está e o que eu diria para outro desenvolvedor que quer extrair valor real disso.
Isto não é uma resenha de produto. É um olhar sobre como uso o Claude Code no dia a dia como desenvolvedora frontend sênior trabalhando com React, TypeScript e Next.js.
Os números
Para contextualizar, alguns dados brutos do meu relatório de uso:
- 282 mensagens em 56 sessões em 21 dias
- +8.744 / −1.576 linhas de código alteradas
- 133 arquivos tocados
- TypeScript dominou com 505 interações com arquivos
- Tarefa mais comum: correção de bugs e debugging (35 de 56 sessões)
Esse último me surpreendeu. Eu achava que usava o Claude principalmente para construir features, mas os dados mostram que me apoio nele mais fortemente para caçar bugs. E, sinceramente? É onde ele brilha.
Workflow #1: o pipeline Jira-para-PR
Esse é o workflow do qual mais me orgulho. Construí um Skill customizado que automatiza o caminho inteiro de um ticket do Jira até um pull request. Funciona assim:
- Peço ao Claude para buscar um ticket do Jira via integração MCP
- O Claude lê a descrição e os critérios de aceite
- Cria uma branch de feature, implementa o código e faz commit
- Quando aprovo, ele abre o PR e transita o ticket no Jira
A grande virada foi escalar isso até execução em nível de épico. Numa sessão, o Claude trabalhou um épico inteiro — 5 tarefas separadas para uma feature CRUD — implementando cada uma, fazendo commits separados e movendo todas para Done. É o tipo de automação que faz você repensar como planeja a sprint.
Se você está construindo Skills customizados, trate os casos de borda de integração direto na definição do Skill. Minha integração com o Jira MCP às vezes retorna resultado vazio, então adicionei uma lógica de fallback que tenta de novo automaticamente com uma busca JQL. O Claude lida com isso em silêncio em vez de travar sua sessão.
Workflow #2: caça a bugs em múltiplos ângulos
Minhas sessões de debugging mais efetivas combinam a análise de código do Claude com ferramentas externas. O padrão é:
- Apontar o Claude para o bug (um ticket do Jira, um screenshot ou só uma descrição)
- Deixar ele ler e dar grep nos arquivos relevantes para entender o fluxo de dados
- Pedir para usar Playwright e reproduzir o problema no browser
- Aplicar uma correção e re-verificar imediatamente com Playwright
Uma sessão que se destaca: tinha um bug onde objetos não estavam salvando corretamente. O Claude passou por várias rodadas de debugging antes de finalmente rastrear até um descompasso entre PascalCase e camelCase entre os nomes de campos do frontend e a resposta da API do backend. O tipo de problema sutil que poderia levar horas para encontrar manualmente.
Adicione uma regra no seu CLAUDE.md que diga: "Ao corrigir bugs, sempre verifique a correção testando com Playwright ou rodando os testes relevantes — não espere o usuário pedir para testar." Essa única instrução melhorou dramaticamente o resultado das minhas sessões.
Workflow #3: refatoração exaustiva
Quando precisei trocar a lógica de seleção de um componente de nome para ID em toda a codebase, o Claude foi inestimável. Com 200 chamadas de edição nas minhas sessões e 15 sessões bem-sucedidas de mudança em múltiplos arquivos, esse é um padrão que uso com regularidade.
A lição que aprendi do jeito difícil: o Claude às vezes deixa referências escapar. Em uma refatoração, ele atualizou a maior parte dos usos mas deixou duas linhas referenciando o padrão antigo, causando um crash em runtime.
Em qualquer rename ou mudança de identificador, peça explicitamente para o Claude rodar grep em toda a codebase para encontrar TODOS os usos antes e depois da mudança. Inclua isto no seu prompt:
Dê grep em TODOS os usos do identificador alterado em toda a
codebase, incluindo tipos, testes e constantes. Liste todos os
arquivos. Depois faça TODAS as mudanças atomicamente e verifique
se nenhuma foi esquecida.
Adiciona alguns segundos, mas evita PRs de follow-up.
Onde as coisas dão errado
Eu não estaria fazendo um favor a você se só falasse das vitórias. Aqui está o que os dados mostram sobre atrito:
Esse foi o meu ponto de dor número um — 19 sessões tiveram atrito de "abordagem errada", em que o Claude começou a mexer no código antes de entender o problema. Em uma sessão de debugging de pipeline, tive que interromper duas vezes dizendo "cheque as MCPs primeiro!" antes dele parar de chutar e analisar de verdade.
A solução é definir regras claras no CLAUDE.md:
Antes de editar qualquer arquivo, analise totalmente o problema
primeiro. Leia os arquivos relevantes, rastreie o fluxo de dados
e confirme a causa raiz antes de fazer mudanças.
Integrações instáveis matam sessões. Várias sessões foram completamente bloqueadas por erros de API, falhas de auth e ferramentas MCP retornando dado vazio. Pelo menos 4 sessões não chegaram a nada por causa de problemas de infraestrutura. Não é um problema do Claude em si, mas é um custo real de trabalhar com ferramentas integradas.
Sessões acabam antes de concluir. Quase metade das minhas sessões terminou parcialmente concluída ou sem atingir o objetivo. O escopo costuma crescer além do que uma única sessão consegue lidar. Comecei a quebrar tarefas em marcos menores e explícitos antes de começar, e isso me ajuda a fechar mais delas.
O que eu configuraria no dia um
Se eu estivesse começando do zero com o Claude Code hoje, eis o que eu configuraria imediatamente:
Trabalho bastante com TypeScript, e muitas sessões envolveram iterar em erros de build que poderiam ter sido pegos antes. Configurar um hook pós-edição que rode npx tsc --noEmit automaticamente significa que o Claude pega erros de tipo antes que virem bola de neve.
Um CLAUDE.md com regras de debugging. As três regras que mencionei acima — analisar antes de editar, testar depois de corrigir, grep exaustivo em refatorações — teriam me poupado um tempo significativo em dezenas de sessões.
Skills customizados para workflows repetitivos. O Skill Jira-para-PR foi um divisor de águas. Qualquer workflow que você repete mais de três vezes vale a pena virar Skill. Não precisa ser perfeito — você itera nele como itera em código.
A avaliação honesta
Depois de 282 mensagens, minha distribuição de satisfação parece assim: 51 sessões em que provavelmente fiquei satisfeita, 19 totalmente concluídas, mas também 16 em que fiquei insatisfeita e 7 que não atingiram seu objetivo. Essa é a foto real — desenvolvimento assistido por IA não é mágica e nem sempre funciona.
Mas as sessões em que funciona? São transformadoras. Implementar um épico inteiro do Jira numa única sentada. Rastrear um bug sutil de casing em campos da API por cinco arquivos em minutos em vez de horas. Refatorar uma mudança de identificador em toda a codebase com confiança.
A chave é ser intencional sobre como você usa. Configure guardrails, codifique seus padrões em Skills reutilizáveis e não tenha medo de interromper quando estiver indo para o lado errado. O Claude Code é uma ferramenta poderosa, mas como qualquer ferramenta, o resultado depende de como você a conduz.