Voc\u00ea j\u00e1 revisou um pull request gerado por um agente de IA que passou em 100% da su\u00edte de testes existente e, ainda assim, introduziu uma regress\u00e3o sutil em produ\u00e7\u00e3o tr\u00eas semanas depois? O padr\u00e3o \u00e9 conhecido por quem trabalha com gera\u00e7\u00e3o autom\u00e1tica de c\u00f3digo em escala: os testes que voc\u00ea j\u00e1 tinha foram escritos para validar o comportamento que humanos costumavam implementar, n\u00e3o para capturar as formas espec\u00edficas \u2014 e recorrentes \u2014 pelas quais um modelo de linguagem erra. A su\u00edte “verde” deu falsa seguran\u00e7a porque nunca foi desenhada para pegar aquele tipo de falha.<\/p>\n
Esse \u00e9 o problema central que um harness de testes para c\u00f3digo gerado por IA precisa resolver, e \u00e9 diferente do problema que uma su\u00edte de testes tradicional resolve. N\u00e3o se trata apenas de “ter mais testes”. Trata-se de reconhecer que c\u00f3digo gerado por IA tem uma distribui\u00e7\u00e3o de erros distinta \u2014 alucina\u00e7\u00e3o de APIs inexistentes, edge cases plaus\u00edveis mas nunca testados, padr\u00f5es copiados de contextos incompat\u00edveis, depend\u00eancias impl\u00edcitas que o modelo assumiu sem verificar \u2014 e construir uma infraestrutura de verifica\u00e7\u00e3o desenhada especificamente para essa distribui\u00e7\u00e3o. Neste artigo, vamos al\u00e9m do “escreva mais testes” e entramos em decis\u00f5es de arquitetura: como estruturar camadas de conten\u00e7\u00e3o, que tipo de verifica\u00e7\u00e3o automatizada realmente pega o que review humano n\u00e3o pega, e onde o custo de manter esse harness supera o benef\u00edcio.<\/p>\n
A maioria dos times trata “testar c\u00f3digo gerado por IA” como sin\u00f4nimo de “rodar a su\u00edte existente contra o novo c\u00f3digo”. Isso \u00e9 necess\u00e1rio, mas est\u00e1 longe de ser suficiente, por um motivo estrutural: sua su\u00edte de testes atual foi constru\u00edda incrementalmente, ao longo do tempo, cobrindo os bugs que humanos historicamente introduziram naquele c\u00f3digo-base. Ela reflete o perfil de erro dos seus desenvolvedores, n\u00e3o o perfil de erro do modelo que est\u00e1 gerando c\u00f3digo agora.<\/p>\n
Segundo a NxCode, em seu guia sobre harness engineering<\/a>, a disciplina de projetar ambientes, restri\u00e7\u00f5es e loops de feedback \u00e9 o que efetivamente torna agentes de codifica\u00e7\u00e3o produtivos e seguros \u2014 n\u00e3o a qualidade isolada do modelo. Isso implica uma mudan\u00e7a de postura: o harness n\u00e3o \u00e9 um acess\u00f3rio de QA, \u00e9 parte da arquitetura do sistema de desenvolvimento assistido por IA.<\/p>\n Antes de desenhar qualquer harness, vale mapear as categorias de falha que efetivamente aparecem com gera\u00e7\u00e3o por IA, porque cada categoria exige uma estrat\u00e9gia de detec\u00e7\u00e3o diferente:<\/p>\n Um harness bem desenhado ataca essas categorias uma a uma, com ferramentas distintas \u2014 n\u00e3o com “mais testes unit\u00e1rios gen\u00e9ricos”.<\/p>\n A abordagem mais robusta que tenho visto funcionar em produ\u00e7\u00e3o \u00e9 tratar o harness como um pipeline de camadas de conten\u00e7\u00e3o, cada uma com uma responsabilidade \u00fanica e um custo de execu\u00e7\u00e3o crescente. A ideia \u00e9 que c\u00f3digo gerado por IA passe por filtros progressivamente mais caros e mais espec\u00edficos, e falhe o mais cedo poss\u00edvel.<\/p>\n Antes de qualquer teste de comportamento, valide que o c\u00f3digo gerado respeita os contratos est\u00e1ticos do projeto: tipagem, assinatura de interfaces, aus\u00eancia de s\u00edmbolos inexistentes. Isso pega alucina\u00e7\u00e3o de API antes mesmo de rodar qualquer coisa.<\/p>\n O mesmo princ\u00edpio se aplica em outras linguagens: em C#, o compilador com Testes unit\u00e1rios tradicionais verificam exemplos espec\u00edficos: “dado X, espero Y”. Isso \u00e9 fraco contra c\u00f3digo gerado por IA porque o modelo tende a acertar exatamente os exemplos \u00f3bvios e falhar nos casos que ningu\u00e9m pensou em escrever manualmente. Testes de propriedade (property-based testing) invertem a l\u00f3gica: voc\u00ea declara invariantes que devem valer para qualquer entrada, e a ferramenta gera centenas de casos, incluindo os patol\u00f3gicos.<\/p>\n Esse tipo de teste \u00e9 particularmente eficiente contra c\u00f3digo gerado por IA porque exp\u00f5e rapidamente os edge cases que o modelo simplesmente n\u00e3o considerou \u2014 no exemplo acima, valores negativos, separadores decimais inconsistentes ou entradas vazias tendem a quebrar implementa\u00e7\u00f5es geradas automaticamente que “parecem” corretas no caminho feliz.<\/p>\n \ud83d\udca1 Dica do Mestre:<\/strong> vale a pena assistir ao epis\u00f3dio Harness Engineering: O futuro da engenharia de software com IA<\/a>, que discute exatamente essa mudan\u00e7a de mentalidade \u2014 de “revisar o output” para “projetar o ambiente que restringe o output”.<\/p><\/blockquote>\n Property-based testing pega falhas de l\u00f3gica isolada, mas n\u00e3o pega falhas de comportamento em rela\u00e7\u00e3o ao sistema como um todo \u2014 regress\u00f5es de fluxo, quebra de contratos entre servi\u00e7os, efeitos colaterais inesperados. Para isso, a abordagem de “behaviour harness” ganhou tra\u00e7\u00e3o recentemente: voc\u00ea define especifica\u00e7\u00f5es de comportamento execut\u00e1veis, desacopladas da implementa\u00e7\u00e3o, e roda o c\u00f3digo gerado contra elas antes de aceitar o merge.<\/p>\n Conforme mostrado em este v\u00eddeo sobre behaviour harness para c\u00f3digo gerado por IA<\/a>, a velocidade de gera\u00e7\u00e3o de c\u00f3digo pela IA n\u00e3o \u00e9 o gargalo \u2014 o gargalo \u00e9 garantir que essa velocidade n\u00e3o introduza regress\u00f5es silenciosas em fluxos cr\u00edticos de neg\u00f3cio.<\/p>\n O ponto cr\u00edtico aqui: essas especifica\u00e7\u00f5es de comportamento devem ser escritas \u2014 ou pelo menos revisadas linha a linha \u2014 por humanos, antes de o c\u00f3digo ser gerado, seguindo l\u00f3gica de especifica\u00e7\u00e3o pr\u00e9via. Deixar a pr\u00f3pria IA gerar tanto o c\u00f3digo quanto os testes de comportamento que o validam cria um ciclo fechado onde os mesmos vieses e alucina\u00e7\u00f5es do modelo passam despercebidos dos dois lados.<\/p>\n A \u00faltima camada de conten\u00e7\u00e3o, e a mais cara operacionalmente, \u00e9 rodar o c\u00f3digo gerado em um ambiente isolado antes de qualquer merge \u2014 sem acesso a rede externa, com sistema de arquivos ef\u00eamero, limites de CPU e mem\u00f3ria, e captura completa de syscalls. Isso n\u00e3o substitui os testes anteriores; complementa-os, porque pega comportamentos que nenhuma asser\u00e7\u00e3o prev\u00ea, como uma chamada de rede n\u00e3o autorizada que o modelo “achou” que era necess\u00e1ria, ou um loop que consome recursos de forma desproporcional.<\/p>\n Ferramentas de orquestra\u00e7\u00e3o de CI como containers ef\u00eameros com pol\u00edticas de seccomp, ou solu\u00e7\u00f5es dedicadas de sandboxing, cumprem esse papel. O importante na decis\u00e3o arquitetural \u00e9: essa camada s\u00f3 deve rodar depois que as camadas 1 a 3 j\u00e1 filtraram o volume \u00f3bvio de falhas, porque o custo de infraestrutura de sandboxing isolado \u00e9 significativamente maior que rodar uma su\u00edte de testes unit\u00e1rios.<\/p>\n Al\u00e9m das quatro camadas de conten\u00e7\u00e3o, um harness maduro para c\u00f3digo gerado por IA incorpora verifica\u00e7\u00f5es que n\u00e3o fazem sentido em um pipeline tradicional, porque s\u00e3o desenhadas especificamente para os vieses do modelo.<\/p>\nO perfil de erro espec\u00edfico de c\u00f3digo gerado por IA<\/h3>\n
\n
Arquitetura em camadas: o modelo de conten\u00e7\u00e3o<\/h2>\n
Camada 1 \u2014 Verifica\u00e7\u00e3o est\u00e1tica e de contrato<\/h3>\n
\/\/ verify-contracts.ts\nimport ts from \"typescript\";\n\ninterface ContractViolation {\n file: string;\n message: string;\n line: number;\n}\n\nfunction verifyGeneratedFile(filePath: string): ContractViolation[] {\n const program = ts.createProgram([filePath], {\n strict: true,\n noImplicitAny: true,\n target: ts.ScriptTarget.ES2022,\n });\n\n const diagnostics = ts.getPreEmitDiagnostics(program);\n const violations: ContractViolation[] = [];\n\n for (const diag of diagnostics) {\n if (diag.file && diag.start !== undefined) {\n const { line } = diag.file.getLineAndCharacterOfPosition(diag.start);\n violations.push({\n file: diag.file.fileName,\n message: ts.flattenDiagnosticMessageText(diag.messageText, \"\\n\"),\n line: line + 1,\n });\n }\n }\n\n return violations;\n}\n\nconst violations = verifyGeneratedFile(process.argv[2]);\nif (violations.length > 0) {\n console.error(`Bloqueado: ${violations.length} viola\u00e7\u00e3o(\u00f5es) de contrato encontradas.`);\n violations.forEach(v => console.error(` ${v.file}:${v.line} \u2014 ${v.message}`));\n process.exit(1);\n}\n<\/code><\/pre>\nTreatWarningsAsErrors<\/code> e analisadores Roslyn customizados; em Java, checkers do Error Prone; em Delphi, a an\u00e1lise est\u00e1tica do compilador combinada com ferramentas como o Pascal Analyzer para detectar chamadas a m\u00e9todos inexistentes ou assinaturas incompat\u00edveis introduzidas por gera\u00e7\u00e3o autom\u00e1tica.<\/p>\nCamada 2 \u2014 Testes de propriedade, n\u00e3o apenas de exemplo<\/h3>\n
from hypothesis import given, strategies as st\n\n# C\u00f3digo gerado por IA a ser validado\ndef parse_currency(value: str) -> int:\n \"\"\"Converte string de moeda para centavos (inteiro).\"\"\"\n cleaned = value.replace(\"R$\", \"\").replace(\".\", \"\").replace(\",\", \".\").strip()\n return round(float(cleaned) * 100)\n\n@given(st.decimals(min_value=\"0.01\", max_value=\"999999.99\", places=2))\ndef test_parse_currency_is_reversible(amount):\n formatted = f\"R$ {amount:,.2f}\".replace(\",\", \"X\").replace(\".\", \",\").replace(\"X\", \".\")\n result = parse_currency(formatted)\n expected = round(float(amount) * 100)\n assert result == expected, f\"Falhou para {formatted}: esperado {expected}, obtido {result}\"\n\n@given(st.text())\ndef test_parse_currency_never_crashes_silently(garbage_input):\n try:\n parse_currency(garbage_input)\n except (ValueError, AttributeError):\n pass # Falha esperada e controlada\n except Exception as e:\n raise AssertionError(f\"Exce\u00e7\u00e3o n\u00e3o tratada para entrada '{garbage_input}': {type(e)}\")\n<\/code><\/pre>\nCamada 3 \u2014 Testes de comportamento (behaviour harness)<\/h3>\n
\/\/ BehaviourSpec.cs \u2014 especifica\u00e7\u00e3o execut\u00e1vel independente da implementa\u00e7\u00e3o\npublic class PedidoBehaviourSpec\n{\n [Theory]\n [InlineData(0, false)] \/\/ pedido sem itens n\u00e3o pode ser confirmado\n [InlineData(1, true)]\n public void PedidoSoPodeSerConfirmadoComItens(int quantidadeItens, bool esperado)\n {\n var pedido = new Pedido();\n for (int i = 0; i < quantidadeItens; i++)\n pedido.AdicionarItem(new ItemPedido("SKU-001", 1, 10.0m));\n\n var podeConfirmar = pedido.PodeSerConfirmado();\n\n Assert.Equal(esperado, podeConfirmar);\n }\n\n [Fact]\n public void ConfirmarPedidoDuasVezesDeveSerIdempotente()\n {\n var pedido = new Pedido();\n pedido.AdicionarItem(new ItemPedido("SKU-001", 1, 10.0m));\n\n pedido.Confirmar();\n var estadoAposConfirmarUmaVez = pedido.Status;\n\n pedido.Confirmar(); \/\/ c\u00f3digo gerado por IA \u00e0s vezes n\u00e3o trata reentr\u00e2ncia\n var estadoAposConfirmarDuasVezes = pedido.Status;\n\n Assert.Equal(estadoAposConfirmarUmaVez, estadoAposConfirmarDuasVezes);\n }\n}\n<\/code><\/pre>\nCamada 4 \u2014 Sandbox de execu\u00e7\u00e3o isolada<\/h3>\n
# harness-sandbox.yml \u2014 configura\u00e7\u00e3o de execu\u00e7\u00e3o isolada\nversion: \"1\"\nsandbox:\n network: none\n filesystem: ephemeral\n timeout_seconds: 30\n limits:\n cpu: \"1\"\n memory: \"512Mi\"\n capture:\n - syscalls\n - stdout\n - stderr\n - exit_code\n fail_conditions:\n - network_attempt_detected\n - filesystem_write_outside_tmp\n - exit_code_nonzero\n - timeout_exceeded\n<\/code><\/pre>\nOnde o harness ganha intelig\u00eancia: sinais espec\u00edficos de gera\u00e7\u00e3o por IA<\/h2>\n