O que mudou no papel do desenvolvedor com a IA
Ha dois anos, o code review era uma das atividades mais técnicas e humanas do desenvolvimento de software. Um colega lia o seu pull request, questionava decisões de arquitetura, apontava bugs sutis e sugeria melhorias. Era um dialogo entre pessoas que conheciam o contexto do sistema.
Hoje, parte crescente das equipes usa IA para gerar o código e outra ferramenta de IA para revisar esse mesmo código antes do merge. O desenvolvedor aparece no final do fluxo para clicar em "Approve" ou "Merge". A pergunta que surgiu na comunidade dev e direta: se você não escreveu o código e não leu cada linha da revisão, o que exatamente você esta verificando?
Esse debate ganhou força em setembro de 2026 quando um artigo no Dev.to com mais de 28 reações colocou o dedo na ferida. Não e sobre ser contra IA - e sobre entender o que o desenvolvedor ainda precisa saber fazer quando as ferramentas automatizam cada vez mais etapas do ciclo.
Como funciona o fluxo IA-escreve + IA-revisa
O fluxo mais comum hoje funciona assim: o desenvolvedor descreve o que precisa em linguagem natural para uma ferramenta como GitHub Copilot, Cursor ou Claude. A IA gera o código. O desenvolvedor aceita, ajusta ou pede para refazer. Depois, antes do PR ser mergeado, uma IA de code review - como CodeRabbit, Sourcery ou o próprio GitHub Copilot no modo PR Review - varre o diff automaticamente e aponta problemas.
A revisão automática verifica coisas objetivas com muita eficiência: conformidade com padrões de estilo, dependências desatualizadas, erros óbvios de lógica, ausência de tratamento de erro, código duplicado. Para times com dezenas de PRs por dia, isso reduz o ruído nas revisões humanas de forma considerável.
O problema começa quando o desenvolvedor passa a tratar a aprovação da IA de code review como equivalente a uma revisão humana real. A IA que gerou o código e a IA que revisou compart ilham as mesmas limitações epistemicas: nenhuma delas conhece o contexto de negócio, a historia de decisões técnicas do sistema ou os requisitos não escritos que existem só na cabeça de quem esta no projeto ha meses.
Uma IA de code review aprova código tecnicamente correto que pode estar logicamente errado para o seu sistema específico. Ela não sabe que aquela tabela do banco e append-only por decisão de compliance ou que aquela API externa cobra por requisição.
O que a IA de code review não consegue verificar
A revisão automática e excelente para o que é mensurável e objetivo. Mas ha uma lista longa do que ela não alcança, e essa lista e exatamente onde mora o valor real do desenvolvedor humano.
- Contexto de negócio: a regra de que pedidos acima de R$ 5.000 precisam de aprovação manual não esta no código, esta na cabeça do gerente de produto.
- Efeitos colaterais em outros times: uma mudança no schema do banco pode quebrar o pipeline de dados do time de analytics sem aparecer em nenhum teste.
- Decisões de arquitetura de longo prazo: adicionar uma dependência nova pode ser a coisa certa agora e um problema de manutenção em dois anos.
- Segurança baseada em contexto: a IA pode não saber que aquele campo não deve ser exposto numa API pública por causa de um acordo contratual específico.
- Qualidade do prompt original: se o desenvolvedor pediu para a IA fazer a coisa errada, a revisão vai aprovar a implementação errada perfeita.
Esse último ponto e o mais crítico. O código gerado por IA e tao bom quanto a descrição que o desenvolvedor deu. A responsabilidade de especificar corretamente o que precisa ser feito continua sendo completamente humana.
Como começar a usar IA no fluxo sem perder o controle
O ponto de partida e mudar a mentalidade de "a IA fez, eu aprovo" para "a IA executou, eu verifico o resultado contra o objetivo real". Isso exige um passo que parece óbvio mas não e praticado: antes de aceitar o código gerado, pergunte a si mesmo o que esse código deveria fazer e se ele realmente faz isso.
Passo 1: Escreva o requisito em linguagem natural antes de pedir para a IA gerar qualquer coisa. Mesmo que você va jogar fora depois, o ato de escrever força clareza sobre o que você quer.
Passo 2: Leia o código gerado com foco no que ele faz, não em como esta escrito. A IA de code review cuida do estilo. Você precisa verificar se a lógica resolve o problema certo.
Passo 3: Use a IA de code review como um filtro de primeiro nível, não como substituto da revisão humana em mudanças críticas. PRs que tocam em autenticação, pagamentos, dados pessoais ou decisões de arquitetura importantes ainda merecem olho humano.
Configure sua ferramenta de code review por IA para marcar automaticamente como "precisa de revisão humana" qualquer PR que altere arquivos de autenticação, configuração de banco de dados ou integrações com APIs externas.
Exemplo prático: o PR que a IA aprovou e que não deveria
Imagine um sistema de e-commerce. O desenvolvedor pede para a IA gerar uma função que aplica desconto em pedidos com cupom. A IA gera um código correto: valida o cupom, calcula o desconto, atualiza o total. A IA de code review aprova porque não ha erros de sintaxe, o tratamento de erro esta presente e os testes unitários passam.
O que nenhuma das duas IAs sabia: cupons de porcentagem e cupons de valor fixo tinham uma regra de precedência definida numa reunião de produto seis meses atrás - primeiro aplica o de porcentagem, depois o fixo, nunca o contrario. Essa regra não estava documentada em código, estava num comentário num card do Jira fechado ha meses.
O PR foi mergeado. Clientes que tinham os dois tipos de cupom passaram a receber descontos menores do que o esperado. Não foi um bug técnico - foi um bug de contexto que só um desenvolvedor com histórico no projeto poderia ter capturado.
Lógica de negócios não documentada e o ponto cego mais perigoso no fluxo IA-escreve + IA-revisa. Se sua equipe não documenta regras de negócio em código (via testes de comportamento, comentários explicativos ou ADRs), o risco aumenta muito ao adotar esse fluxo.
Comparação com o modelo anterior
No modelo tradicional, o desenvolvedor escrevia o código, outro desenvolvedor revisava e o conhecimento sobre o sistema ficava distribuído entre as pessoas do time. Cada review era uma oportunidade de transferência de contexto.
No modelo atual com IA, a velocidade de produção aumenta bastante - times relatam ganhos de 30% a 50% em velocidade de entrega. Mas o acumulo de contexto no time diminui porque menos pessoas leem profundamente o código produzido. Com o tempo, o conhecimento sobre partes do sistema pode ficar concentrado num prompt bem feito, não numa pessoa que realmente entende o que aquele módulo faz.
- Modelo tradicional: mais lento, mais contexto distribuído, revisões ensinam e transferem conhecimento
- Modelo IA completo: mais rápido, risco de contexto centralizado em poucos ou perdido, revisões são filtros, não conversas
- Modelo híbrido recomendado: IA cuida do objetivo, humano verifica o contexto - o melhor dos dois
Pontos positivos e limitações do fluxo atual
Os ganhos são reais e não devem ser ignorados. Times que adotaram o fluxo de IA para geração e revisão reportam menos tempo gasto em feedback de estilo e formatação, code reviews mais focados no que importa e onboarding mais rápido de novos membros em codebases grandes.
As limitações também são reais. A principal e a ilusão de cobertura: o desenvolvedor pode sentir que o código foi "revisado" porque a ferramenta passou sem apontar problemas, quando na verdade só o que é verificável automaticamente foi verificado. O resto - contexto, decisão, consequência - continua sendo responsabilidade humana.
Outra limitação importante: a qualidade da revisão por IA varia muito dependendo do tamanho do PR. Diffs pequenos e focados recebem feedback muito mais preciso do que PRs grandes com muitas mudanças espalhadas.
Casos de uso reais
Time de startup com 3 devs: usar IA para geração e revisão automática de PRs de features simples libera tempo para os revisores humanos focarem nas mudanças de infraestrutura e integração, onde o risco e maior.
Desenvolvedor solo em projeto próprio: a IA de code review funciona como um segundo par de olhos para erros óbvios que o próprio autor não ve depois de horas na mesma lógica.
Time grande com centenas de PRs por semana: a revisão automática funciona como triagem - ela prioriza quais PRs precisam de mais atenção humana, reduzindo o custo de revisão sem eliminar o julgamento humano onde ele é necessário.
Desenvolvedor em área nova: quando você esta trabalhando numa parte do sistema que não conhece bem, a IA de code review ajuda a garantir que pelo menos os padrões básicos da codebase foram seguidos enquanto você ainda aprende o contexto.
Dicas e boas práticas
Regras que não estão em código podem ser perdidas quando a IA assume a geração. Escreva testes de comportamento (BDD) que descrevem as regras de negócio em linguagem natural - a IA de code review consegue verificar que os testes existem mesmo que não saiba se a regra e correta.
Antes de mergear, releia o prompt que você deu para a IA gerar o código. Se o prompt estava impreciso, o código esta implementando a imprecisão corretamente. A revisão mais importante e a do requisito, não do código.
A eficácia da revisão automática cai muito em PRs com mais de 400 linhas alteradas. Quebre PRs grandes em partes menores - isso melhora tanto a revisão humana quanto a automática.
Documente decisões técnicas importantes num arquivo simples no próprio repositório. Quando a IA gerar código que contradiz uma decisão anterior, fica mais fácil de perceber na revisão - e a IA de code review pode até ser configurada para verificar consistência com esses documentos.
Vale a pena adotar esse fluxo?
Vale a pena, com consciência. O fluxo de IA gerando e revisando código aumenta a velocidade de entrega de forma mensurável e e especialmente útil para tarefas repetitivas, código boilerplate e ajustes incrementais. Para um desenvolvedor solo ou um time pequeno, o ganho de produtividade pode ser transformador.
A ressalva e que o fluxo exige que o desenvolvedor evolua o que ele verifica, não que ele pare de verificar. O foco muda de "esse código esta sintaticamente correto?" para "esse código resolve o problema certo, da forma certa, com as consequências certas para o nosso sistema?".
Para quem não deve adotar sem muito cuidado: times trabalhando em sistemas críticos (financeiro, saúde, segurança) onde um bug de contexto pode ter consequências graves, ou equipes que já tem dificuldade de documentar e disseminar conhecimento sobre o sistema. Nesses casos, o fluxo amplifica um problema que já existe.
Comentários