Do Commit Inicial ao Ar: Um Roteiro de Produção com Claude Code
Você já passou pela seguinte situação: abre o terminal, invoca uma IA para gerar um trecho de código, cola no projeto, testa manualmente, ajusta um pouco, esquece de rodar os testes automatizados, sobe para o repositório e só descobre que quebrou algo quando o cliente reclama em produção. O código até funcionava na sua máquina — mas o caminho entre “funciona aqui” e “está no ar, estável, monitorado” ficou cheio de buracos, porque cada etapa foi feita de forma isolada, sem um fio condutor.
Esse problema não é da IA. É de processo. Ferramentas como o Claude Code entregam muito valor quando usadas para gerar trechos pontuais, mas o ganho real de produtividade só aparece quando existe um fluxo de trabalho estruturado — do primeiro commit até o deploy — no qual a IA participa de forma consistente em cada etapa, e não apenas na hora de “escrever a função”. Neste artigo, vou apresentar um roteiro prático, testado no dia a dia, para conduzir um projeto inteiro com o Claude Code como parceiro de desenvolvimento, cobrindo planejamento, implementação, testes, revisão, CI/CD e deploy.
Por que pensar em “fluxo” e não em “prompts soltos”
A maioria dos tutoriais sobre IA no desenvolvimento foca em prompts isolados: “peça isso e receba aquilo”. Isso é útil para tarefas pontuais, mas gera uma armadilha: o desenvolvedor trata a IA como uma calculadora de código, sem integrá-la ao ciclo de vida do software. O resultado é um acúmulo de trechos gerados que ninguém revisou com critério, testes que não cobrem os casos reais e um deploy manual, feito no improviso.
Um fluxo de trabalho bem desenhado resolve isso porque define o que a IA faz em cada fase, o que você valida antes de avançar e onde ficam os pontos de controle. É a diferença entre usar uma furadeira sem plano de obra e seguir uma planta com etapas de fundação, estrutura e acabamento — a ferramenta é a mesma, mas o resultado depende de como o trabalho foi organizado.
As cinco fases do roteiro
- Planejamento e especificação — definir o que será construído antes de gerar qualquer linha de código.
- Implementação assistida — o Claude Code gera e edita código dentro do contexto do repositório.
- Testes e validação — garantir que o que foi gerado realmente funciona, com evidência automatizada.
- Revisão e integração — checar qualidade, segurança e aderência ao padrão do projeto antes do merge.
- Deploy e observação — publicar com pipeline automatizado e acompanhar o comportamento em produção.
Vamos percorrer cada uma delas com exemplos concretos.
Fase 1: Planejamento — antes de codificar, escrever a especificação
O primeiro erro comum é pedir ao Claude Code para “criar uma API de pedidos” sem contexto. O resultado tende a ser genérico, desalinhado com as convenções do seu projeto. O ponto de partida deveria ser um arquivo de especificação, versionado junto ao código, descrevendo requisitos, regras de negócio e restrições técnicas.
Uma prática eficaz é manter um arquivo CLAUDE.md na raiz do repositório — o Claude Code lê esse arquivo automaticamente ao iniciar uma sessão, e ele funciona como a “planta baixa” do projeto:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
# CLAUDE.md ## Stack - Backend: Node.js 20 + TypeScript + Fastify - Banco: PostgreSQL via Prisma - Testes: Vitest + Supertest - Padrão de commits: Conventional Commits ## Regras de negócio - Todo pedido precisa ter ao menos um item. - Pedidos acima de R$ 500 exigem aprovação manual (status "pending_review"). - Nunca expor o campo "custo_interno" nas respostas da API. ## Convenções de código - Controllers não acessam o banco diretamente; sempre via camada de repositório. - Erros de negócio lançam classes que estendem AppError. - Toda rota nova precisa de teste de integração correspondente. |
Com esse arquivo em vigor, cada solicitação feita ao Claude Code já carrega o contexto do projeto, reduzindo a necessidade de repetir instruções e aumentando a aderência do código gerado aos padrões estabelecidos.
💡 Dica do Mestre: a documentação oficial do Claude Code detalha como o arquivo de contexto do projeto é carregado e como estruturar instruções permanentes para a ferramenta. Vale a leitura antes de montar o seu: docs.claude.com/en/docs/claude-code.
Especificando a funcionalidade da vez
Além do contexto geral, cada nova funcionalidade merece uma especificação curta, em linguagem natural, que sirva de prompt estruturado:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
Implemente o endpoint POST /orders seguindo as regras do CLAUDE.md. Requisitos: - Receber { customerId, items[] } no corpo da requisição. - Validar que items não está vazio. - Calcular o total somando price * quantity de cada item. - Se total > 500, status inicial deve ser "pending_review"; caso contrário, "confirmed". - Persistir via OrderRepository (não acessar o Prisma diretamente no controller). - Retornar 201 com o pedido criado, sem o campo custo_interno. Gere também o teste de integração cobrindo os dois cenários de status. |
Esse nível de detalhe evita ambiguidade e faz o modelo produzir algo alinhado ao que você realmente precisa, em vez de uma implementação plausível, porém genérica.
Fase 2: Implementação assistida no terminal
Com a especificação pronta, o Claude Code entra em ação diretamente no terminal, com acesso de leitura e escrita ao repositório. A instalação é simples via npm:
|
1 2 3 4 5 |
npm install -g @anthropic-ai/claude-code claude |
A partir daí, você conversa com a ferramenta dentro do próprio projeto. Um ponto importante do fluxo é usar o modo de planejamento antes de deixar a IA alterar arquivos, para revisar a abordagem sem risco:
|
1 2 3 4 5 |
/plan Implemente o endpoint POST /orders conforme a especificação abaixo: [cole a especificação] |
O Claude Code responde com um plano de mudanças — quais arquivos serão criados ou alterados, qual a ordem de execução — antes de tocar em qualquer linha de código. Isso é equivalente a revisar a planta antes de começar a obra: você identifica decisões questionáveis (por exemplo, um novo pacote desnecessário, ou uma abstração fora do padrão) e corrige a rota antes do trabalho ser feito.
Depois de aprovar o plano, a execução segue com edições reais nos arquivos, e o Claude Code mostra o diff de cada alteração para aprovação incremental — nada é aplicado silenciosamente.
Trabalhando com múltiplas linguagens no mesmo fluxo
O roteiro não muda de acordo com a linguagem; muda o contexto informado. Em um projeto Delphi legado, por exemplo, o mesmo princípio de especificação clara se aplica:
|
1 2 3 4 5 6 7 8 |
Refatore a unit UOrderService.pas para extrair a regra de cálculo de desconto (atualmente dentro de TOrderService.CalcularTotal) para uma classe separada TDiscountCalculator, seguindo o padrão Strategy. Mantenha a assinatura pública de CalcularTotal inalterada e gere testes com DUnitX cobrindo desconto por volume e por cliente fidelidade. |
O mesmo vale para times que trabalham com Python, Go, Java ou qualquer outra stack: o diferencial não é a linguagem, é a clareza da instrução e o contexto de projeto disponível para o modelo.
Fase 3: Testes e validação — a IA não substitui evidência
Um código gerado por IA sem teste automatizado é uma promessa, não uma entrega. O fluxo precisa incluir, obrigatoriamente, a geração e execução dos testes como parte do mesmo ciclo — nunca como etapa posterior e opcional.
|
1 2 3 4 5 6 7 8 9 10 11 |
Gere testes de integração para o endpoint POST /orders usando Vitest e Supertest, cobrindo: 1. Pedido válido com total abaixo de 500 -> status "confirmed" 2. Pedido válido com total acima de 500 -> status "pending_review" 3. Requisição sem items -> 400 com mensagem de erro clara 4. Verificar que a resposta nunca contém o campo custo_interno Depois de gerar, rode os testes e corrija até todos passarem. |
Um detalhe relevante do Claude Code é a capacidade de executar comandos no terminal e reagir ao resultado — ele roda npm test, lê a saída, identifica falhas e ajusta o código, em um ciclo iterativo, sem que você precise copiar e colar mensagens de erro manualmente.
Checklist de saída da fase de testes
- Todos os testes novos e existentes passam localmente.
- Cobertura de casos de borda (entradas vazias, valores-limite, permissões).
- Nenhum teste foi apenas comentado ou marcado como
skippara “passar por enquanto”. - Testes de regressão da funcionalidade anterior continuam íntegros.
💡 Dica do Mestre: para aprofundar como estruturar uma rede de segurança de testes especificamente pensada para código gerado por IA, vale revisitar a lógica de harness de testes, que trata desse tema em detalhe — um bom complemento a este roteiro de deploy.
Fase 4: Revisão e integração — o portão de qualidade
Antes do merge, o código passa por revisão humana e, idealmente, por uma revisão automatizada adicional. O próprio Claude Code pode atuar como um segundo revisor, analisando o diff antes de você abrir o pull request:
|
1 2 3 4 5 6 7 8 9 10 |
Revise o diff atual em busca de: - Vazamento de dados sensíveis nas respostas da API - Tratamento de erros ausente ou genérico demais - Duplicação de lógica já existente em outro módulo - Aderência às convenções descritas em CLAUDE.md Aponte os problemas encontrados, sem aplicar correções ainda. |
Esse passo funciona como uma segunda opinião antes da opinião definitiva, que continua sendo humana. A IA é ótima para apontar inconsistências óbvias e desvios de padrão; a decisão final sobre arquitetura e trade-offs de negócio permanece com o time.
Integração contínua como rede de segurança
O pull request deve disparar um pipeline de CI que rode de forma independente do que foi validado localmente. Um exemplo de workflow do GitHub Actions:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
name: CI on: pull_request: branches: [main] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npm run lint - run: npm test -- --coverage - run: npm run build |
Nenhum código gerado por IA — ou por humano — deve chegar à branch principal sem passar por esse portão. Documentação completa do GitHub Actions está disponível em docs.github.com/pt/actions.
Fase 5: Deploy — do merge ao ar
Com o código revisado e integrado, o deploy deve ser automatizado, disparado pelo merge na branch principal. O Claude Code pode ajudar inclusive a escrever ou ajustar esse pipeline de deploy, mas a execução em produção nunca deve depender de um comando manual disparado por conveniência.
Um exemplo simplificado de job de deploy, complementando o pipeline de CI anterior:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
deploy: needs: test if: github.ref == 'refs/heads/main' runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npm run build - name: Deploy run: npm run deploy env: DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }} |
Se o projeto usa contêineres, o mesmo princípio se aplica com uma etapa adicional de build e push de imagem, seguida de atualização do serviço em produção — seja via Kubernetes, um provedor gerenciado ou uma plataforma como a Fly.io.
Observação pós-deploy: o fluxo não termina no “publicado”
Depois do deploy, o trabalho ainda não acabou. É necessário observar métricas, logs e alertas para confirmar que o comportamento em produção corresponde ao esperado. Aqui, o Claude Code também pode ser útil na fase de investigação, analisando logs colados no terminal e sugerindo hipóteses de causa raiz, mas a decisão de rollback ou hotfix deve seguir um processo claro, com critérios objetivos — por exemplo, taxa de erro acima de um limiar predefinido ou aumento anormal de latência.
💡 Dica do Mestre: “You build it, you run it” — a máxima atribuída à cultura de engenharia da Amazon, popularizada por Werner Vogels, resume bem o espírito dessa fase: quem escreve o código, com ou sem IA, também acompanha o que acontece depois do deploy.
Consolidando o roteiro em um só lugar
Para tornar esse fluxo repetível, vale registrar as etapas como um checklist dentro do próprio repositório, em um arquivo como WORKFLOW.md:
|
1 2 3 4 5 6 7 8 9 10 11 |
1. Escrever ou atualizar a especificação da funcionalidade. 2. Rodar `claude` e usar /plan antes de qualquer edição. 3. Implementar com revisão incremental dos diffs. 4. Gerar e rodar testes; nenhum PR sem cobertura correspondente. 5. Pedir revisão automatizada de qualidade antes do PR. 6. Abrir PR; aguardar CI (lint, testes, build). 7. Merge dispara deploy automatizado. 8. Observar métricas e logs por, no mínimo, o período crítico definido pelo time. |
Esse documento vivo evita que o uso da IA vire uma prática informal e dependente de quem está no teclado naquele dia — ele transforma o fluxo em um processo de equipe, reproduzível por qualquer pessoa do time.
Leve esse fluxo para dentro da sua rotina com apoio de quem já passou por isso
Montar esse roteiro sozinho, por tentativa e erro, consome tempo que poderia ser investido em entregar valor. Na Comunidade Dev’s AI compartilhamos fluxos de trabalho testados, templates de CLAUDE.md, pipelines de CI/CD prontos para adaptar e discussões práticas sobre como integrar IA em cada etapa do desenvolvimento — do planejamento ao deploy. Se você quer parar de reinventar processo a cada projeto, entre na comunidade: adrianosantos.link/ComunidadeDevAI.
Conclusão
O Claude Code, como qualquer ferramenta de IA aplicada ao desenvolvimento, entrega o seu maior valor quando inserido em um fluxo de trabalho bem definido, e não quando usado de forma isolada para gerar trechos avulsos de código. Planejamento com especificação clara, implementação assistida com revisão incremental, testes automatizados como critério de aceite, revisão de qualidade antes do merge e deploy automatizado com observação pós-produção formam um ciclo que reduz retrabalho e aumenta a confiança em cada entrega. O ganho não está apenas na velocidade de escrever código — está na consistência de todo o caminho até o software estar, de fato, no ar e funcionando como esperado.