Agente de código acelera quando o dev revisa cada mudança
Agente de código dá velocidade quando quem desenvolve desenha a solução, direciona o agente e revisa cada mudança antes do teste.
Agente de código dá velocidade quando quem desenvolve desenha a solução, direciona o agente e revisa cada mudança antes do teste. Sem isso, vira retrabalho.
Uso agentes de código, com o Claude Code, em todo o meu fluxo de trabalho como desenvolvedor full stack e mobile.
Meu papel é desenhar a solução, direcionar o agente, revisar e validar cada mudança e garantir a qualidade antes de seguir para testes.
O objetivo é mais velocidade de entrega sem abrir mão de segurança e manutenibilidade.
Velocidade sem esse papel é ilusão. O agente produz código rápido, mas não sabe sozinho o que o sistema precisa nem o que não pode quebrar.
Neste texto, mostro como esse papel funciona num projeto real de pagamento, e por que ele não é opcional.
Não é um texto contra a ferramenta. O ponto é outro: quem decide o que o agente faz e quem responde pelo que ele entrega.
Um checkout de varejo com cartão novo
Em 2026, trabalho como full stack no app de e-commerce de uma empresa de varejo, num novo cartão de crédito no checkout.
No back-end, o BFF em Java e Spring Boot expõe o cartão como meio de pagamento, identifica o cliente e simula o parcelamento.
A simulação cobre as modalidades fatura e carnê, com e sem juros.
O BFF trata os erros dos serviços de origem e tem testes unitários em JUnit e Mockito.
No app em React Native, com TypeScript e Redux-Saga, fiz a jornada no checkout: exibição do cartão, identificação, simulação e escolha de parcelas.
A jornada também pede o CVV e mostra juros e total no detalhe do pedido. Ela é liberada por feature flag no Firebase Remote Config.
É código que mexe com o dinheiro do cliente. Um erro de juros ou de total não é detalhe visual: é uma cobrança errada.
Nesse tipo de jornada, a pressa sem revisão custa mais do que economiza.
Onde o agente entra
Nesse projeto, uso Claude Code e o MCP do Figma no dia a dia. Cada entrega passa por revisão e validação antes dos testes.
O agente escreve rápido. O que ele não sabe sozinho é qual solução cabe naquele sistema, com aquelas regras de parcelamento e aqueles serviços.
Por isso o desenho vem antes: decidir onde a regra mora, no BFF ou no app, e que contrato os dois vão seguir.
Com o desenho pronto, direcionar o agente fica simples. A tarefa vira pequena, com começo, fim e um teste que diz se deu certo.
O MCP do Figma aproxima a tela desenhada do código. Mesmo assim, a revisão confere se o resultado seguiu o design system.
Tarefa vaga gera código vago. Quanto mais claro o pedido ao agente, menos tempo vai para desfazer o que ele inventou.
O agente acelera a escrita. Quem garante que o código está certo continua sendo quem o revisa.
Revisar cada mudança antes do teste
Nem todo trabalho nesse projeto foi tela nova. Corrigi um loop de re-renderização no checkout e um estado inconsistente ao voltar da tela de pagamento.
Também integrei a biblioteca React Native de gestão do cartão, mantida por outro time, com o app como hospedeiro.
Essa integração teve contrato de tema e de sessão, alinhamento ao design system, configuração nativa Android e iOS e correção de navegação na biometria.
Problemas assim aparecem na leitura atenta, não na velocidade. O agente gera a mudança, mas o efeito no estado do app pede alguém que veja o todo.
Revisar antes do teste também ajuda o time que testa. O teste passa a confirmar o comportamento, não a caçar erro que a leitura do código já pegaria.
Se você vai usar agente de código no seu produto, defina antes quem desenha a solução e quem revisa. A velocidade aparece quando esses papéis estão claros.