Voc\u00ea pede para a IA implementar uma fun\u00e7\u00e3o de valida\u00e7\u00e3o de CPF. Ela responde em segundos, o c\u00f3digo parece limpo, tem at\u00e9 coment\u00e1rios explicando cada etapa. Voc\u00ea copia, cola no projeto, roda uma vez com um CPF de teste, funciona, e segue para a pr\u00f3xima tarefa. Duas semanas depois, um cliente reporta que o sistema aceitou um CPF inv\u00e1lido no cadastro. Voc\u00ea abre o c\u00f3digo, olha para aquela fun\u00e7\u00e3o “pronta” e percebe que ela nunca validou o c\u00e1lculo dos d\u00edgitos verificadores de verdade \u2014 apenas checava se a string tinha onze caracteres num\u00e9ricos.<\/p>\n
Essa cena se repete todos os dias em equipes de desenvolvimento que adotaram assistentes de IA como Claude Code, GitHub Copilot ou ChatGPT. O problema n\u00e3o \u00e9 a IA escrever c\u00f3digo ruim \u2014 na maioria das vezes ela escreve c\u00f3digo plaus\u00edvel, bem formatado e com apar\u00eancia de correto. O problema \u00e9 que “parecer correto” e “estar correto” s\u00e3o coisas diferentes, e sem um processo de valida\u00e7\u00e3o, o desenvolvedor s\u00f3 descobre a diferen\u00e7a quando o erro j\u00e1 causou dano.<\/p>\n
Este artigo apresenta, do zero, um roteiro b\u00e1sico para voc\u00ea testar e validar qualquer c\u00f3digo gerado por IA antes de integr\u00e1-lo ao seu projeto. Vamos explicar cada conceito, mostrar exemplos de c\u00f3digo completos e funcionais, e construir junto um checklist que voc\u00ea pode aplicar j\u00e1 na pr\u00f3xima tarefa.<\/p>\n
Quando um colega de equipe escreve c\u00f3digo, voc\u00ea tem um contexto impl\u00edcito: sabe o n\u00edvel de experi\u00eancia dele, sabe se ele testou localmente, pode perguntar “por que voc\u00ea fez assim?” e receber uma resposta fundamentada. Com a IA, esse contexto n\u00e3o existe da mesma forma. O modelo gera a resposta mais prov\u00e1vel estatisticamente para o seu pedido, n\u00e3o necessariamente a mais correta para o seu caso espec\u00edfico.<\/p>\n
Segundo o guia da GitLab sobre gera\u00e7\u00e3o de c\u00f3digo com IA<\/a>, os desenvolvedores devem trabalhar em conjunto com os sistemas de IA para validar o c\u00f3digo gerado, apresentar contexto adicional e requisitos, em vez de simplesmente aceitar a primeira resposta como definitiva. Essa ideia \u00e9 o ponto central deste artigo: a IA \u00e9 uma colaboradora que precisa de revis\u00e3o, n\u00e3o uma fonte de verdade.<\/p>\n \ud83d\udca1 Dica do Mestre:<\/strong> Existe at\u00e9 discuss\u00e3o sobre se \u00e9 poss\u00edvel identificar que um trecho de c\u00f3digo foi escrito por IA. Uma thread da comunidade r\/learnpython no Reddit<\/a> discute exatamente isso, e ferramentas como o detector de c\u00f3digo de IA da Pangram<\/a> tentam automatizar essa identifica\u00e7\u00e3o. Mas isso \u00e9 uma curiosidade lateral: o que realmente importa para voc\u00ea, desenvolvedor, n\u00e3o \u00e9 saber quem escreveu o c\u00f3digo, e sim se ele funciona corretamente.<\/p><\/blockquote>\n Antes de qualquer teste automatizado, existe uma etapa manual e obrigat\u00f3ria: a leitura cr\u00edtica. Muitos desenvolvedores pulam essa etapa porque o c\u00f3digo “parece certo” \u00e0 primeira vista. Mas ler o c\u00f3digo com aten\u00e7\u00e3o \u00e9 o que revela decis\u00f5es escondidas, como usar uma biblioteca desatualizada, ignorar um caso de borda ou simplificar demais uma regra de neg\u00f3cio.<\/p>\n Vamos usar um exemplo simples em Python. Suponha que voc\u00ea pediu \u00e0 IA uma fun\u00e7\u00e3o para calcular o desconto de um pedido:<\/p>\n \u00c0 primeira vista, parece razo\u00e1vel: pedidos com mais de dez itens recebem 10% de desconto. Mas ao ler com aten\u00e7\u00e3o, surgem perguntas que s\u00f3 um humano que conhece o neg\u00f3cio consegue responder: e se Ler o c\u00f3digo ajuda a levantar suspeitas, mas testes automatizados confirmam ou refutam essas suspeitas com evid\u00eancia concreta. Um teste automatizado<\/strong> \u00e9 um trecho de c\u00f3digo que executa outro trecho de c\u00f3digo e verifica se o resultado \u00e9 o esperado, sem que voc\u00ea precise repetir esse processo manualmente toda vez.<\/p>\n Continuando o exemplo anterior, vamos escrever testes usando a biblioteca padr\u00e3o de testes do Python, o unittest<\/a> \u2014 mas se voc\u00ea preferir, o mesmo racioc\u00ednio vale para pytest, Jest, JUnit ou qualquer framework de testes da sua linguagem.<\/p>\n Ao rodar esses testes, o terceiro caso \u2014 Com essa evid\u00eancia em m\u00e3os, voc\u00ea corrige a fun\u00e7\u00e3o \u2014 sozinho ou pedindo \u00e0 pr\u00f3pria IA que ajuste, agora com o requisito expl\u00edcito:<\/p>\n Rodando os testes novamente, todos passam. Esse ciclo \u2014 escrever teste, rodar, corrigir, rodar de novo \u2014 \u00e9 a base de qualquer processo de valida\u00e7\u00e3o s\u00e9rio, e funciona da mesma forma seja o c\u00f3digo escrito por voc\u00ea, por um colega ou por uma IA.<\/p>\n Um erro comum de quem est\u00e1 come\u00e7ando \u00e9 testar apenas o “caminho feliz” \u2014 o cen\u00e1rio em que tudo d\u00e1 certo. Mas a maioria dos bugs em produ\u00e7\u00e3o acontece nos casos de borda: entradas vazias, valores extremos, tipos inesperados, condi\u00e7\u00f5es de rede inst\u00e1veis.<\/p>\n Vamos ilustrar isso com um exemplo em JavaScript, uma fun\u00e7\u00e3o que a IA poderia gerar para validar um e-mail:<\/p>\n Perceba que os tr\u00eas primeiros casos funcionam bem, e \u00e9 f\u00e1cil parar por a\u00ed, satisfeito com o resultado. Mas o quarto caso \u2014 passar A corre\u00e7\u00e3o \u00e9 simples, mas s\u00f3 aparece quando voc\u00ea pensa deliberadamente nos casos de borda:<\/p>\n C\u00f3digo gerado por IA quase sempre compila, roda e n\u00e3o gera erro de sintaxe \u2014 afinal, o modelo foi treinado com enormes volumes de c\u00f3digo sintaticamente correto. O problema real est\u00e1 no comportamento: a l\u00f3gica de neg\u00f3cio implementada \u00e9 a l\u00f3gica que voc\u00ea realmente precisa?<\/p>\n Para validar comportamento, \u00e9 \u00fatil escrever os testes antes<\/strong> de pedir o c\u00f3digo \u00e0 IA, ou logo em seguida, descrevendo em termos concretos o que o sistema deveria fazer. Essa pr\u00e1tica se aproxima do conceito de especifica\u00e7\u00e3o antes da implementa\u00e7\u00e3o, algo que j\u00e1 discutimos aqui no blog em outro artigo sobre desenvolvimento orientado por especifica\u00e7\u00e3o, e que se aplica muito bem \u00e0 valida\u00e7\u00e3o de c\u00f3digo de IA: voc\u00ea define o comportamento esperado em forma de teste, e s\u00f3 depois confirma se a implementa\u00e7\u00e3o atende a esse contrato.<\/p>\n Veja um exemplo em Delphi, \u00fatil para quem trabalha com sistemas legados ou aplica\u00e7\u00f5es desktop, mostrando como validar o comportamento de uma fun\u00e7\u00e3o que a IA poderia ter sugerido para calcular juros simples:<\/p>\n Rodar esse teste confirma se a f\u00f3rmula implementada corresponde \u00e0 f\u00f3rmula financeira correta de juros simples. Sem esse teste, a \u00fanica forma de descobrir um erro na f\u00f3rmula seria um relat\u00f3rio financeiro incorreto chegando \u00e0s m\u00e3os de um cliente \u2014 um custo muito mais alto do que alguns segundos rodando um teste automatizado.<\/p>\n Voc\u00ea n\u00e3o precisa construir sua pr\u00f3pria infraestrutura de testes do zero. Existem ferramentas maduras, algumas delas j\u00e1 incorporando intelig\u00eancia artificial para gerar e validar testes automaticamente. O material da TestSprite sobre testes de ponta a ponta com IA<\/a> lista op\u00e7\u00f5es como Testim, Functionize, Katalon e Applitools, voltadas justamente para validar aplica\u00e7\u00f5es inteiras, incluindo c\u00f3digo gerado por IA, de forma automatizada.<\/p>\n \ud83d\udca1 Dica do Mestre:<\/strong> Se voc\u00ea est\u00e1 come\u00e7ando agora, n\u00e3o precisa adotar essas ferramentas de teste de ponta a ponta imediatamente. Comece pelo b\u00e1sico: testes unit\u00e1rios simples, como os exemplos deste artigo, usando o framework de testes nativo da sua linguagem. Ferramentas mais sofisticadas fazem sentido quando o projeto cresce e o volume de cen\u00e1rios a testar manualmente se torna invi\u00e1vel.<\/p><\/blockquote>\n Vale destacar tamb\u00e9m que essa preocupa\u00e7\u00e3o n\u00e3o \u00e9 exclusiva de quem escreve c\u00f3digo sozinho. Em um v\u00eddeo sobre o ritmo acelerado da gera\u00e7\u00e3o de c\u00f3digo por IA, dispon\u00edvel no canal do YouTube sobre IA e testes de software<\/a>, \u00e9 discutida a ideia de manter uma biblioteca de valida\u00e7\u00e3o pr\u00f3pria, reutiliz\u00e1vel entre projetos, exatamente para n\u00e3o depender de testar tudo manualmente toda vez que a IA gera um novo trecho de c\u00f3digo.<\/p>\n Reunindo tudo o que vimos at\u00e9 aqui, este \u00e9 um checklist simples que voc\u00ea pode aplicar sempre que a IA gerar c\u00f3digo para o seu projeto:<\/p>\n Validar c\u00f3digo gerado por IA \u00e9 uma habilidade que se desenvolve com pr\u00e1tica e com troca de experi\u00eancias reais entre desenvolvedores que enfrentam os mesmos desafios todos os dias. Se voc\u00ea quer discutir casos concretos, compartilhar scripts de teste e aprender com quem j\u00e1 passou por situa\u00e7\u00f5es parecidas com as deste artigo, participe da Comunidade Dev’s AI<\/a>. \u00c9 um espa\u00e7o para quem desenvolve software no dia a dia e quer usar IA de forma respons\u00e1vel, sem abrir m\u00e3o da qualidade.<\/p>\n A intelig\u00eancia artificial mudou a velocidade com que o c\u00f3digo \u00e9 escrito, mas n\u00e3o mudou a responsabilidade de quem assina o commit. Um c\u00f3digo gerado em segundos pode economizar horas de trabalho, ou pode custar dias de corre\u00e7\u00e3o em produ\u00e7\u00e3o \u2014 a diferen\u00e7a est\u00e1 inteiramente no processo de valida\u00e7\u00e3o que voc\u00ea aplica antes de integr\u00e1-lo ao projeto.<\/p>\n Comece pelo b\u00e1sico: leia com aten\u00e7\u00e3o, escreva testes automatizados simples, pense nos casos de borda e confirme se o comportamento implementado \u00e9 realmente o comportamento que voc\u00ea precisa. Esse h\u00e1bito, praticado de forma consistente, transforma a IA de uma fonte de risco silencioso em uma ferramenta genuinamente produtiva \u2014 exatamente o papel que ela deveria cumprir no seu fluxo de trabalho.<\/p>\n","protected":false},"excerpt":{"rendered":" Voc\u00ea pede para a IA implementar uma fun\u00e7\u00e3o de valida\u00e7\u00e3o de CPF. Ela responde em segundos, o c\u00f3digo parece limpo, tem at\u00e9 coment\u00e1rios explicando cada etapa. Voc\u00ea copia, cola no projeto, roda uma vez com um CPF de teste, funciona, e segue para a pr\u00f3xima tarefa. Duas semanas depois, um cliente reporta que o sistema […]<\/p>\n","protected":false},"author":127,"featured_media":1234,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1233","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/posts\/1233","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/users\/127"}],"replies":[{"embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/comments?post=1233"}],"version-history":[{"count":1,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/posts\/1233\/revisions"}],"predecessor-version":[{"id":1235,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/posts\/1233\/revisions\/1235"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/media\/1234"}],"wp:attachment":[{"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/media?parent=1233"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/categories?post=1233"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/tags?post=1233"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}O primeiro passo: leia o c\u00f3digo antes de rodar<\/h2>\n
def calcular_desconto(valor_total, quantidade_itens):\n if quantidade_itens > 10:\n return valor_total * 0.9\n return valor_total\n<\/code><\/pre>\nvalor_total<\/code> for negativo? E se quantidade_itens<\/code> for zero ou negativo? O desconto deveria ser aplicado apenas sobre parte do valor, ou sobre o total? Essas perguntas n\u00e3o aparecem no c\u00f3digo \u2014 elas aparecem na sua cabe\u00e7a, durante a leitura cr\u00edtica.<\/p>\nPerguntas que voc\u00ea deve se fazer ao ler c\u00f3digo de IA<\/h3>\n
\n
O segundo passo: escreva testes automatizados para o c\u00f3digo gerado<\/h2>\n
import unittest\n\ndef calcular_desconto(valor_total, quantidade_itens):\n if quantidade_itens > 10:\n return valor_total * 0.9\n return valor_total\n\nclass TestCalcularDesconto(unittest.TestCase):\n\n def test_sem_desconto_com_poucos_itens(self):\n resultado = calcular_desconto(100, 5)\n self.assertEqual(resultado, 100)\n\n def test_desconto_aplicado_com_muitos_itens(self):\n resultado = calcular_desconto(100, 11)\n self.assertEqual(resultado, 90)\n\n def test_valor_total_negativo_deveria_ser_rejeitado(self):\n with self.assertRaises(ValueError):\n calcular_desconto(-50, 15)\n\n def test_quantidade_zero_nao_gera_erro(self):\n resultado = calcular_desconto(100, 0)\n self.assertEqual(resultado, 100)\n\nif __name__ == \"__main__\":\n unittest.main()\n<\/code><\/pre>\ntest_valor_total_negativo_deveria_ser_rejeitado<\/code> \u2014 vai falhar, porque a fun\u00e7\u00e3o original da IA n\u00e3o lan\u00e7a nenhuma exce\u00e7\u00e3o para valores negativos. Isso \u00e9 exatamente o ponto: o teste automatizado transformou uma suspeita (“ser\u00e1 que isso trata valores negativos?”) em um fato verific\u00e1vel (“n\u00e3o trata, e aqui est\u00e1 a prova”).<\/p>\ndef calcular_desconto(valor_total, quantidade_itens):\n if valor_total 10:\n return valor_total * 0.9\n return valor_total\n<\/code><\/pre>\nO terceiro passo: teste os casos de borda, n\u00e3o apenas o caminho feliz<\/h2>\n
function validarEmail(email) {\n const regex = \/^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$\/;\n return regex.test(email);\n}\n\n\/\/ Testes manuais r\u00e1pidos no console\nconsole.log(validarEmail(\"adriano@exemplo.com\")); \/\/ true\nconsole.log(validarEmail(\"email-invalido\")); \/\/ false\nconsole.log(validarEmail(\"\")); \/\/ false\nconsole.log(validarEmail(null)); \/\/ ERRO: Cannot read properties of null\n<\/code><\/pre>\nnull<\/code> como argumento \u2014 quebra a aplica\u00e7\u00e3o inteira com um erro n\u00e3o tratado. Se essa fun\u00e7\u00e3o receber dados de um formul\u00e1rio onde o campo de e-mail pode chegar vazio ou nulo, o sistema vai falhar silenciosamente ou, pior, derrubar a aplica\u00e7\u00e3o inteira.<\/p>\nfunction validarEmail(email) {\n if (typeof email !== \"string\" || email.trim() === \"\") {\n return false;\n }\n const regex = \/^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$\/;\n return regex.test(email);\n}\n<\/code><\/pre>\nUma checklist pr\u00e1tica de casos de borda<\/h3>\n
\n
O quarto passo: valide o comportamento, n\u00e3o apenas a sintaxe<\/h2>\n
function CalcularJurosSimples(Capital, Taxa: Double; Periodo: Integer): Double;\nbegin\n Result := Capital * (Taxa \/ 100) * Periodo;\nend;\n\n\/\/ Teste usando DUnit ou DUnitX\nprocedure TestCalcularJurosSimples;\nbegin\n Assert(CalcularJurosSimples(1000, 5, 12) = 600,\n 'Juros de 5% ao m\u00eas sobre 1000 por 12 meses deveria ser 600');\n\n Assert(CalcularJurosSimples(0, 5, 12) = 0,\n 'Capital zero deveria gerar juros zero');\nend;\n<\/code><\/pre>\nO quinto passo: use ferramentas de teste que j\u00e1 existem, n\u00e3o reinvente tudo<\/h2>\n
Montando seu checklist b\u00e1sico de valida\u00e7\u00e3o<\/h2>\n
\n
Convite para aprofundar o assunto<\/h2>\n
Conclus\u00e3o<\/h2>\n