Quando a IA Constrói Suas Próprias Ferramentas: O Problema Recursivo de Confiança

Em 1984, Ken Thompson subiu ao palco para receber o Prêmio Turing e fez uma demonstração que deveria ter mudado a engenharia de software para sempre. Mostrou que um compilador C comprometido podia injetar backdoors no código compilado, inclusive em si mesmo, de forma invisível. A conclusão da palestra, intitulada “Reflections on Trusting Trust”, era simples e devastadora: você não pode confiar em código que não criou inteiramente.

Quarenta anos depois, a OpenAI afirma que o Codex escreve mais de 90% do próprio código. Nenhum humano “criou inteiramente” essa base de código. O problema que Thompson descreveu não desapareceu. Ele se multiplicou.

A Cadeia de Confiança Que Existia

O bootstrapping de compiladores é uma prática antiga. O compilador C original foi escrito em assembler, depois reescrito em C e compilado por si mesmo. Cada etapa desse processo era determinística e reproduzível. Se você alimentasse o mesmo código-fonte, obteria o mesmo binário. Auditores podiam verificar cada passo. A cadeia de confiança existia porque cada elo era visível.

A autogeração por modelos de linguagem é fundamentalmente diferente. LLMs são não-determinísticos. O mesmo prompt produz respostas diferentes. A mesma instrução, executada duas vezes, gera código distinto. Não existe “elo” para auditar porque não existe cadeia. O que existe é uma função probabilística que produz artefatos plausíveis.

Quando Thompson demonstrou seu ataque, a comunidade acadêmica respondeu com diverse bootstrapping, compilação reproduzível e verificação formal. Essas defesas funcionam porque o processo subjacente é determinístico. Contra geração probabilística, nenhuma dessas ferramentas se aplica.

O Paradoxo: Desconfiança Cresce, Verificação Não

Se a ausência de confiança fosse o problema, a solução seria simples: verificar mais. Os dados mostram que isso não está acontecendo.

A pesquisa Sonar State of Code 2026, com 1.149 desenvolvedores, encontrou que 96% não confiam plenamente em código gerado por IA. Ao mesmo tempo, menos de 48% verificam antes de fazer commit. A Developer Survey do Stack Overflow 2025, com mais de 49 mil respondentes, registrou queda na confiança em precisão de IA de 43% para 33% ano a ano. Dois terços dos desenvolvedores relatam gastar mais tempo corrigindo código “quase certo” do que gastariam escrevendo do zero.

A desconfiança existe. A verificação correspondente, não.

Existe uma explicação prática para essa contradição. Verificar código de IA é mais trabalhoso do que verificar código humano. O estudo da METR mediu que engenheiros seniores gastam 4,3 minutos revisando cada sugestão de IA, contra 1,2 minutos para código escrito por colegas. O código humano carrega contexto: estilo reconhecível, convenções da equipe, histórico de commits. O código de IA chega sem contexto. Cada trecho precisa ser compreendido do zero.

Multiplicar o tempo de revisão por 3,5x enquanto o volume de código gerado cresce exponencialmente produz um resultado previsível: a revisão não acompanha.

Geração Ultrapassou Revisão

Os dados da LinearB 2026, baseados em 8,1 milhões de pull requests de 4.800 organizações, quantificam o desequilíbrio. PRs gerados por IA têm taxa de aceitação de 32,7%. Para PRs escritos manualmente, a taxa é 84,4%. Antes mesmo de chegar à revisão, PRs de IA esperam 4,6 vezes mais na fila.

O volume compensa? Parcialmente. Equipes com alta adoção de IA fazem merge de 98% mais PRs. Mas o tempo de revisão por PR aumenta 91%. A CodeRabbit, em parceria com a Ox Security, documentou que código gerado por IA produz 1,7 vez mais problemas do que código escrito por humanos.

A aritmética é direta. Se uma equipe produz o dobro de PRs, cada um com quase o dobro de problemas, e cada revisão leva quase o dobro do tempo, a carga total sobre os revisores humanos quadruplica. Nenhuma organização que conheço quadruplicou sua capacidade de revisão.

Sandboxing Resolve Metade do Problema

A resposta padrão da indústria para IA escrevendo código é sandboxing: isolar o ambiente de execução, cortar acesso à rede, limitar permissões. O Codex roda sem acesso à rede. Outras plataformas adotam contenção similar.

Sandboxing previne que código malicioso exfiltre dados ou acesse recursos não autorizados. Isso é segurança, e funciona bem para o que se propõe.

O que sandboxing não resolve: erros lógicos, drift arquitetural, complexidade acumulada, suposições incorretas sobre o domínio, e o comportamento emergente quando múltiplos agentes paralelos modificam a mesma base de código. Um agente de IA dentro de um sandbox pode produzir código perfeitamente seguro e completamente errado. As duas dimensões são independentes.

Tratar sandboxing como solução completa confunde segurança com governança. São disciplinas complementares, não sinônimos.

A Armadilha dos 30/70

Sottiaux, líder de engenharia da equipe Codex na OpenAI, descreveu um modelo de trabalho onde engenheiros gastam 30% do tempo pensando e 70% executando com assistência de IA. É uma divisão racional. O problema está no que as organizações medem.

Os 70% são visíveis. PRs abertos, commits feitos, features entregues. Métricas de throughput capturam essa fatia com precisão. Os 30% são invisíveis. Decisões arquiteturais, avaliação de trade-offs, julgamento sobre o que não construir. Nenhum dashboard mostra a qualidade do pensamento que antecede a execução.

Quando pressão por resultados aumenta, os 30% encolhem primeiro. São intangíveis. Não aparecem em sprint reviews. Não geram tickets fechados. Mas a qualidade dos 30% determina 100% da qualidade do output. IA não corrige premissas erradas. Amplifica.

O relatório Veracode de 2025, testando mais de 100 modelos de linguagem, encontrou que 40% a 48% do código gerado contém vulnerabilidades de segurança. Não são bugs de lógica. São falhas que um invasor pode explorar. Quando a fase de pensamento é comprimida, essas vulnerabilidades passam despercebidas até produção.

Precedentes Que Ignoramos

A história da engenharia documenta com precisão o que acontece quando automação supera supervisão humana.

O Therac-25, máquina de radioterapia dos anos 1980, matou pacientes porque os engenheiros confiaram na verificação por software e removeram os interlocks de hardware que existiam no modelo anterior. A Knight Capital perdeu 440 milhões de dólares em 45 minutos quando código automatizado de trading executou uma estratégia abandonada sete anos antes, reativada acidentalmente durante um deploy. O MCAS da Boeing contribuiu para dois acidentes fatais do 737 MAX porque o sistema automatizado operava com dados de um único sensor, sem redundância que um engenheiro teria exigido.

O padrão é o mesmo em todos os casos. Automação funciona. Supervisão é reduzida porque “funciona.” Falha ocorre em condições que a automação não previu. Consequências são desproporcionais porque ninguém estava verificando.

Código gerado por IA em 2026 está na fase “funciona.” A redução de supervisão já é mensurável nos dados da Sonar: menos de metade dos desenvolvedores verifica. A fase seguinte é previsível.

Revisão em Camadas: Honestidade Necessária

Algumas organizações respondem ao problema com revisão em camadas: IA revisa o código de IA primeiro, humanos revisam apenas caminhos críticos ou decisões de alto risco. É uma abordagem pragmática.

Funciona, com uma condição. A organização precisa reconhecer que isso é estratificação de risco, não verificação completa. Quando um engenheiro sênior revisa apenas os 20% de maior risco e delega 80% para revisão automatizada, a organização está aceitando que parte do código chegará a produção sem olhos humanos. Pode ser uma decisão racional. Precisa ser uma decisão consciente, documentada e monitorada.

O perigo é tratar revisão em camadas como se fosse equivalente a revisão completa. Não é. É um trade-off de governança. Organizações que o adotam sem reconhecê-lo como tal perdem visibilidade sobre o risco que estão aceitando.

O Que Muda Quando IA Constrói IA

Voltemos a Thompson. O ataque dele funcionava porque o compilador comprometido se perpetuava: cada versão compilada herdava o backdoor da anterior. A defesa era possível porque o processo era determinístico. Compilação reproduzível, verificação formal, auditoria de cada etapa.

Quando IA escreve 90% de si mesma, o mesmo padrão de perpetuação existe. Vieses, suposições incorretas, vulnerabilidades no código gerado pela versão N são herdados pela versão N+1, que foi construída pelo mesmo sistema. Mas a defesa que funcionava contra compiladores não se aplica. O processo é não-determinístico. Não existe “mesmo código-fonte, mesmo resultado.” Cada geração é diferente. Auditar cada artefato individualmente é inviável na escala em que esses sistemas operam.

Isso não é argumento contra IA escrevendo código. É argumento por um tipo de governança que a engenharia de software ainda não construiu. Verificação estatística em vez de determinística. Monitoramento contínuo de propriedades emergentes. Redundância deliberada entre gerações. Métricas que meçam confiança, não velocidade.

Três Perguntas Para Sua Organização

Antes de tratar essa discussão como abstrata, aplique-a ao seu contexto.

Qual percentual do seu código é gerado por IA, e qual percentual é verificado por humanos? Se a diferença entre esses dois números está crescendo, sua dívida de verificação está se acumulando. A pesquisa Sonar sugere que essa é a norma, não a exceção.

Suas métricas de produtividade capturam a fase de pensamento? Se os únicos indicadores que chegam à liderança são PRs abertos, commits por dia e velocidade de entrega, os 30% que determinam a qualidade do output estão invisíveis. Medir throughput sem medir a qualidade da entrada que o alimenta é medir o motor ignorando o combustível.

Quando a IA erra, quanto tempo leva para descobrir? O Therac-25 matou três pacientes antes que alguém conectasse os incidentes ao software. A Knight Capital perdeu 440 milhões em 45 minutos. O tempo entre falha e detecção é a métrica que separa incidente de catástrofe.

O problema recursivo de confiança não se resolve com modelos melhores. Modelos melhores geram mais código, mais rápido, com menos atrito. O que resolve é governança: estruturas que meçam, monitorem e verifiquem o que a IA produz, com a mesma disciplina que a engenharia aplicou aos compiladores depois que Thompson mostrou como quebrá-los.

A diferença é que Thompson nos deu quarenta anos para construir as defesas. Os LLMs não estão oferecendo esse prazo.

Para uma análise técnica detalhada de como o Codex é construído, recomendo a edição de Gergely Orosz no The Pragmatic Engineer. É o melhor breakdown disponível da arquitetura e das decisões de engenharia por trás do sistema.

Na Victorino Group, ajudamos organizações a construir governança para código gerado por IA antes que a dívida de verificação se torne irreversível. Se sua organização está escalando adoção de IA no desenvolvimento e precisa de estrutura para manter confiança no que chega a produção, vamos conversar: contato@victorino.com.br | www.victorino.com.br

Fontes: Ken Thompson, “Reflections on Trusting Trust” (Turing Award Lecture, 1984); Sonar State of Code 2026 (1.149 desenvolvedores); Stack Overflow Developer Survey 2025 (49K+ respondentes); METR — estudo independente de produtividade com IA; LinearB Engineering Benchmarks 2026 (8,1M PRs, 4.800 organizações); CodeRabbit/Ox Security — dados de qualidade de código; Veracode — análise de segurança de código gerado por IA (100+ modelos); Therac-25 — Leveson & Turner, IEEE Computer, 1993; Knight Capital — SEC filing, agosto 2012; Boeing MCAS — Joint Authorities Technical Review, outubro 2019.