Voc\u00ea revisou o pull request. O c\u00f3digo compilou de primeira, os testes unit\u00e1rios passaram em verde, a cobertura subiu dois pontos percentuais e a fun\u00e7\u00e3o resolve exatamente o que o ticket pedia. Voc\u00ea aprova, faz o merge, segue para a pr\u00f3xima tarefa. Tr\u00eas semanas depois, em produ\u00e7\u00e3o, um cliente relata que valores de desconto acumulado est\u00e3o sendo calculados errado em pedidos com mais de um cupom aplicado \u2014 um caso de borda que ningu\u00e9m testou porque ningu\u00e9m pensou nele, nem voc\u00ea, nem a IA que escreveu a fun\u00e7\u00e3o.<\/p>\n
O problema n\u00e3o \u00e9 que a IA errou. O problema \u00e9 que o seu processo de valida\u00e7\u00e3o foi desenhado para pegar os erros que um humano cansado comete \u2014 esquecer um ponto e v\u00edrgula, inverter uma condi\u00e7\u00e3o, ignorar um null \u2014 e n\u00e3o os erros que uma IA comete: c\u00f3digo sintaticamente impec\u00e1vel, estilisticamente consistente, que resolve o caso feliz com perfei\u00e7\u00e3o e ignora silenciosamente os casos que n\u00e3o foram explicitados no prompt.<\/p>\n
Este artigo n\u00e3o \u00e9 sobre como usar IA para escrever c\u00f3digo. \u00c9 sobre o que muda no seu processo de garantia de qualidade<\/strong> quando uma fra\u00e7\u00e3o relevante do c\u00f3digo que passa pelo seu review n\u00e3o foi pensada por um humano linha a linha. A resposta n\u00e3o \u00e9 “revisar com mais aten\u00e7\u00e3o” \u2014 isso n\u00e3o escala e n\u00e3o \u00e9 onde o risco realmente mora. A resposta \u00e9 um protocolo de valida\u00e7\u00e3o estruturado, com camadas espec\u00edficas para os tipos de falha que modelos de linguagem produzem com mais frequ\u00eancia.<\/p>\n Code review humano foi otimizado, ao longo de d\u00e9cadas, para detectar um padr\u00e3o espec\u00edfico de erro: o erro de distra\u00e7\u00e3o<\/em> ou de desconhecimento parcial<\/em>. Um desenvolvedor j\u00fanior esquece de tratar exce\u00e7\u00e3o, um s\u00eanior apressado copia um trecho de outro lugar sem adaptar o contexto, algu\u00e9m n\u00e3o sabia que aquela API tinha um efeito colateral documentado. Revisores humanos s\u00e3o bons em pegar isso porque reconhecem os “cheiros” de quem estava com pressa ou com informa\u00e7\u00e3o incompleta.<\/p>\n C\u00f3digo gerado por IA tem uma assinatura de erro completamente diferente. O modelo n\u00e3o est\u00e1 com pressa, n\u00e3o est\u00e1 cansado, n\u00e3o esqueceu nada \u2014 ele simplesmente n\u00e3o sabe o que voc\u00ea n\u00e3o perguntou. Ele produz a solu\u00e7\u00e3o estatisticamente mais prov\u00e1vel para o prompt dado, e essa solu\u00e7\u00e3o costuma ser gen\u00e9rica, plaus\u00edvel e sintaticamente perfeita, mas frequentemente m\u00edope em rela\u00e7\u00e3o a:<\/p>\n Esse ponto aparece com for\u00e7a em uma publica\u00e7\u00e3o do desenvolvedor Guilherme Lima no LinkedIn, que resume bem o risco: a quest\u00e3o n\u00e3o \u00e9 se a IA escreveu c\u00f3digo seguro, \u00e9 medir o que o desenvolvedor deixa de verificar quando a IA est\u00e1 no loop. Governan\u00e7a, no caso, n\u00e3o significa bloquear o uso da ferramenta \u2014 significa desenhar checkpoints que compensem exatamente esse ponto cego.<\/p>\n \ud83d\udca1 Dica do Mestre:<\/strong> vale a leitura completa da publica\u00e7\u00e3o de Guilherme Lima sobre o tema, dispon\u00edvel em seu perfil no LinkedIn<\/a>. O argumento central \u2014 que governan\u00e7a de IA no desenvolvimento \u00e9 sobre medir lacunas de verifica\u00e7\u00e3o, n\u00e3o sobre proibir a ferramenta \u2014 deveria estar na abertura de qualquer pol\u00edtica interna de uso de IA para c\u00f3digo.<\/p><\/blockquote>\n O que proponho aqui n\u00e3o substitui seus testes unit\u00e1rios nem seu pipeline de CI\/CD existente. \u00c9 uma camada adicional, espec\u00edfica para c\u00f3digo de origem IA, que ataca os quatro pontos cegos descritos acima. Trate isso como um checklist de PR, n\u00e3o como burocracia extra \u2014 cada camada tem um objetivo claro e um custo de execu\u00e7\u00e3o baixo quando automatizada.<\/p>\n Antes de qualquer teste, escreva (ou pe\u00e7a \u00e0 pr\u00f3pria IA que escreva, sob sua supervis\u00e3o) as invariantes de dom\u00ednio como asser\u00e7\u00f5es execut\u00e1veis, n\u00e3o como coment\u00e1rios. Se a regra \u00e9 “o desconto total nunca pode exceder 100% do valor do pedido, mesmo com m\u00faltiplos cupons empilhados”, essa regra precisa existir como um teste que falha explicitamente se violada \u2014 e voc\u00ea precisa confirmar que ela nunca foi mencionada no prompt original.<\/p>\n Esse teste n\u00e3o veio “de gra\u00e7a” da IA porque ela nunca soube que essa invariante existia. \u00c9 trabalho humano, insubstitu\u00edvel, e \u00e9 exatamente aqui que a experi\u00eancia s\u00eanior do revisor vale mais do que qualquer prompt mais elaborado.<\/p>\n Testes unit\u00e1rios tradicionais verificam exemplos espec\u00edficos. C\u00f3digo gerado por IA tende a passar em todos os exemplos que voc\u00ea pensou em escrever \u2014 porque, no fundo, tanto voc\u00ea quanto a IA est\u00e3o ancorados nos mesmos casos “\u00f3bvios”. Property-based testing inverte a l\u00f3gica: voc\u00ea declara propriedades que devem valer para qualquer<\/em> entrada v\u00e1lida, e a ferramenta gera centenas de casos aleat\u00f3rios tentando quebrar essa propriedade.<\/p>\n Em Python, a biblioteca de refer\u00eancia \u00e9 o Hypothesis<\/a>. Em outras linguagens voc\u00ea tem equivalentes maduros: FsCheck<\/a> para .NET, jqwik<\/a> para a JVM, e o cl\u00e1ssico QuickCheck<\/a> que originou a t\u00e9cnica. O ganho real aqui \u00e9 que esses geradores encontram exatamente os casos de borda que tanto voc\u00ea quanto a IA teriam ignorado por estarem ancorados no mesmo espa\u00e7o de exemplos mentais.<\/p>\n Um risco espec\u00edfico do fluxo com IA \u00e9 gerar testes e implementa\u00e7\u00e3o no mesmo prompt, ou em prompts sequenciais do mesmo contexto. Isso cria um vi\u00e9s perigoso: os testes tendem a validar exatamente o comportamento que a implementa\u00e7\u00e3o tem, n\u00e3o o comportamento que deveria ter. Cobertura de linha sobe, mas a su\u00edte n\u00e3o pega regress\u00f5es reais.<\/p>\n Mutation testing resolve isso introduzindo pequenas altera\u00e7\u00f5es (muta\u00e7\u00f5es) no c\u00f3digo de produ\u00e7\u00e3o \u2014 trocar um Ferramentas de refer\u00eancia por ecossistema: mutmut<\/a> e Cosmic Ray<\/a> em Python, PIT (Pitest)<\/a> na JVM, Stryker<\/a> para JavaScript\/TypeScript e .NET. Rodar mutation testing em todo o codebase \u00e9 caro computacionalmente \u2014 a recomenda\u00e7\u00e3o pr\u00e1tica \u00e9 aplic\u00e1-lo de forma seletiva, nos m\u00f3dulos cr\u00edticos que passaram por gera\u00e7\u00e3o assistida de IA, n\u00e3o no reposit\u00f3rio inteiro a cada commit.<\/p>\n \ud83d\udca1 Dica do Mestre:<\/strong> um bom indicador de maturidade de su\u00edte de testes n\u00e3o \u00e9 a cobertura de linha, \u00e9 o mutation score<\/em> \u2014 a porcentagem de muta\u00e7\u00f5es que sua su\u00edte efetivamente detecta. Cobertura de 100% com mutation score baixo \u00e9 o retrato exato de “testes que s\u00f3 confirmam o que o c\u00f3digo j\u00e1 faz”, o padr\u00e3o mais comum em c\u00f3digo gerado e testado pela mesma IA no mesmo contexto.<\/p><\/blockquote>\n Ferramentas de an\u00e1lise est\u00e1tica (linters, type checkers, SAST) sempre fizeram parte de pipelines maduros, mas ganham peso adicional aqui porque capturam categorias de erro que revis\u00e3o manual apressada deixa passar: inje\u00e7\u00e3o de SQL sutil, uso incorreto de criptografia, exposi\u00e7\u00e3o de segredos, depend\u00eancias vulner\u00e1veis introduzidas por sugest\u00e3o do pr\u00f3prio assistente.<\/p>\n Ferramentas como Semgrep<\/a>, CodeQL<\/a> e Bandit<\/a> (para Python) devem rodar automaticamente em todo PR, com regras espec\u00edficas para os padr\u00f5es que assistentes de c\u00f3digo costumam reproduzir de forma insegura \u2014 por exemplo, concatena\u00e7\u00e3o de strings em queries quando o contexto do prompt n\u00e3o deixou expl\u00edcito que aquela vari\u00e1vel vem de entrada do usu\u00e1rio.<\/p>\n Existe uma tenta\u00e7\u00e3o \u2014 vis\u00edvel em discuss\u00f5es acad\u00eamicas e corporativas \u2014 de tentar identificar se um trecho de c\u00f3digo foi gerado por IA, como se isso por si s\u00f3 fosse um sinal de risco. A Pangram publicou uma an\u00e1lise t\u00e9cnica<\/a> sobre os limites desses detectores de c\u00f3digo de IA, mostrando o que eles conseguem identificar e onde falham. Vale a leitura, mas o ponto pr\u00e1tico para o seu time \u00e9 outro: mesmo que a detec\u00e7\u00e3o fosse perfeita, ela n\u00e3o te diria nada sobre a corretude<\/em> do c\u00f3digo.<\/p>\n Um trecho escrito por IA e validado pelas quatro camadas acima \u00e9 mais confi\u00e1vel do que um trecho escrito por um humano s\u00eanior sem nenhum teste de propriedade ou mutation testing. A origem do c\u00f3digo \u00e9 irrelevante para a decis\u00e3o de merge; o que importa \u00e9 o rigor da valida\u00e7\u00e3o aplicada. Esse debate aparece de forma recorrente em threads como a do r\/learnpython sobre detec\u00e7\u00e3o de c\u00f3digo gerado por IA<\/a>, geralmente motivado por contextos de integridade acad\u00eamica \u2014 um problema real, mas categoricamente diferente do problema de engenharia que voc\u00ea resolve em produ\u00e7\u00e3o.<\/p>\n H\u00e1 uma categoria de problema que nenhuma das quatro camadas acima resolve sozinha: deriva arquitetural. Um agente de IA, ao resolver uma tarefa isolada, otimiza para aquela tarefa \u2014 n\u00e3o para a coer\u00eancia do sistema como um todo. Ele pode introduzir uma nova forma de acessar o banco de dados que ignora a camada de reposit\u00f3rio j\u00e1 estabelecida, ou duplicar uma regra de valida\u00e7\u00e3o que j\u00e1 existe em outro m\u00f3dulo, porque simplesmente n\u00e3o tinha esse contexto no momento da gera\u00e7\u00e3o.<\/p>\n Rodrigo de Toledo levanta exatamente esse ponto em uma publica\u00e7\u00e3o sobre como lidar com gera\u00e7\u00e3o de c\u00f3digo por IA em escala: a necessidade de os times conseguirem visualizar a evolu\u00e7\u00e3o da arquitetura do sistema mesmo quando a velocidade de gera\u00e7\u00e3o de c\u00f3digo aumenta \u2014 porque revis\u00e3o linha a linha n\u00e3o escala para detectar esse tipo de eros\u00e3o estrutural.<\/p>\n \ud83d\udca1 Dica do Mestre:<\/strong> leia a publica\u00e7\u00e3o completa de Rodrigo de Toledo em seu perfil no LinkedIn<\/a>. O ponto central \u00e9 que ferramentas de visualiza\u00e7\u00e3o e mapeamento de arquitetura (dependency graphs, fitness functions arquiteturais) deixam de ser “nice to have” e passam a ser mecanismo de defesa ativo quando o volume de c\u00f3digo gerado cresce r\u00e1pido.<\/p><\/blockquote>\nPor que o code review tradicional falha com c\u00f3digo gerado por IA<\/h2>\n
\n
O protocolo: quatro camadas de valida\u00e7\u00e3o<\/h2>\n
Camada 1 \u2014 Verifica\u00e7\u00e3o de invariantes expl\u00edcitas<\/h3>\n
import pytest\nfrom decimal import Decimal\nfrom pricing import apply_coupons\n\ndef test_desconto_total_nunca_excede_valor_do_pedido():\n \"\"\"\n Invariante de neg\u00f3cio que N\u00c3O estava no prompt original.\n A IA implementou apply_coupons() pensando em um \u00fanico cupom;\n este teste for\u00e7a o comportamento correto com m\u00faltiplos.\n \"\"\"\n valor_pedido = Decimal(\"100.00\")\n cupons = [\n {\"tipo\": \"percentual\", \"valor\": 60},\n {\"tipo\": \"percentual\", \"valor\": 50},\n ]\n resultado = apply_coupons(valor_pedido, cupons)\n assert resultado.total_desconto = Decimal(\"0.00\")\n<\/code><\/pre>\nCamada 2 \u2014 Testes baseados em propriedades (property-based testing)<\/h3>\n
from hypothesis import given, strategies as st\nfrom pricing import apply_coupons\nfrom decimal import Decimal\n\n@given(\n valor=st.decimals(min_value=\"0.01\", max_value=\"1000000\", places=2),\n percentuais=st.lists(st.integers(min_value=1, max_value=100), min_size=1, max_size=10)\n)\ndef test_propriedade_desconto_nunca_negativo(valor, percentuais):\n cupons = [{\"tipo\": \"percentual\", \"valor\": p} for p in percentuais]\n resultado = apply_coupons(valor, cupons)\n assert resultado.valor_final >= Decimal(\"0.00\")\n assert resultado.valor_final <= valor\n<\/code><\/pre>\nCamada 3 \u2014 Mutation testing para validar a qualidade da su\u00edte, n\u00e3o s\u00f3 do c\u00f3digo<\/h3>\n
<<\/code> por <=<\/code>, inverter um booleano, remover uma chamada \u2014 e verificando se ao menos um teste falha para cada muta\u00e7\u00e3o. Se uma muta\u00e7\u00e3o sobrevive sem quebrar nenhum teste, isso significa que sua su\u00edte tem um buraco.<\/p>\n# Exemplo com mutmut, para Python\npip install mutmut\nmutmut run --paths-to-mutate=pricing.py\nmutmut results\n<\/code><\/pre>\nCamada 4 \u2014 An\u00e1lise est\u00e1tica e SAST focada no que a IA costuma errar<\/h3>\n
# .github\/workflows\/sast.yml\nname: SAST\non: [pull_request]\njobs:\n semgrep:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n - uses: semgrep\/semgrep-action@v1\n with:\n config: >-\n p\/security-audit\n p\/owasp-top-ten\n<\/code><\/pre>\nDetectar se o c\u00f3digo “\u00e9 de IA” \u00e9 a pergunta errada<\/h2>\n
O risco arquitetural que os testes unit\u00e1rios n\u00e3o pegam<\/h2>\n