Você já entrega código que não entende

A discussão mais movimentada do Hacker News hoje é um engenheiro perguntando como lidar com entregar código escrito por IA que ele não entende. Na mesma manhã, a chefe de segurança da Microsoft disse que modelos de fronteira "independentemente da origem, não podem ser confiados" e que empresas deveriam tratar agentes em produção como risco interno.

Os dois descrevem a mesma coisa por pontas opostas. E a resposta incômoda pra pergunta do engenheiro é: você já entrega código que não entende, e faz isso a carreira inteira. O que mudou não foi a compreensão. Foi a contenção.

O que a Microsoft disse de fato

O enquadramento do Satya Nadella é a parte útil, e não é peça de marketing: separar o fornecimento de inteligência da autoridade para agir.

O raciocínio, segundo Hayete Gallot, chefe do negócio de segurança da empresa, não é que os modelos sejam maliciosos. É que eles são treinados para atingir resultado — o que convida ao reward hacking — e não são otimizados em torno das normas ou do julgamento de uma organização, embora tenham acesso aos dados e sistemas dela em velocidade de máquina. Um agente não precisa estar comprometido pra ser perigoso. Basta estar sem supervisão e ser capaz.

A cobertura se concentrou nos produtos que vieram junto — Guardian Agents, o Defender detectando dezenas de tipos de agente, o consórcio da indústria. Isso importa. Mas tudo trata o agente em tempo de execução: o que ele alcança enquanto roda, e quem está olhando.

Essa é metade da superfície.

A outra metade roda depois

Um agente que escreve código também está exercendo autoridade. Ela só está adiada.

O código que ele produz roda em produção, com os seus privilégios, contra os dados dos seus clientes, muito depois de a sessão que o gerou ter terminado e de todo guarda-corpo de runtime ter sido desligado. Ninguém está monitorando aquele agente, porque aquele agente não existe mais. O que sobrou foi a saída dele, agora indistinguível de todo o resto do repositório.

A gente escreveu na sexta sobre agentes alcançando sistemas em produção com credenciais esquecidas — essa é a história de runtime. Esta aqui é a outra, e é mais lenta, mais silenciosa e mais difícil de detectar, porque autoridade adiada não dispara alerta. Ela só mergeia.

Você já entrega código que não entende

Aqui está a parte que deveria aliviar a ansiedade antes de criar outra.

Ninguém no seu time leu o código-fonte do framework web que usa. Ninguém audita a árvore de dependências transitivas — centenas de pacotes, a maioria nunca lida por quem os coloca em produção. Isso é normal há vinte anos, e não é imprudência.

Funciona porque a indústria resolveu esse problema, e não resolveu lendo o código. Resolveu com contenção:

• Uma interface versionada, pra que aquilo que você não entende só seja alcançável por uma superfície que você entende.
• Um changelog e um número de versão, pra que mudança se anuncie.
• Granularidade de revert — dá pra remover uma dependência sem desfazer três decisões não relacionadas.
• Um rastro de procedência: você sabe de onde veio e quem mais usa.
• Um canal de aviso, pra quando aquilo se revelar perigoso alguém te contar.

Código de terceiro não lido é seguro não por ser compreendido, mas por ser delimitado. Esse é o controle de verdade, e é ele que vem fazendo o trabalho esse tempo todo.

Por que código escrito por IA escapa de tudo isso

Agora repare como o código gerado por IA se comporta diante dessa lista.

Ele cai dentro do seu repositório, no meio da sua lógica de domínio. Não tem interface em volta, nem versão, nem changelog. Não dá pra reverter como unidade porque está espalhado num commit junto com coisas que você quer manter. Seis semanas depois, nada no código registra que aquilo foi gerado — e ninguém consegue te dizer quais partes do seu sistema vieram de um modelo que, nas palavras da Microsoft, não era otimizado em torno do julgamento da sua organização.

O problema nunca foi você não entender. O problema é você não entender e aquilo não ter nenhuma das contenções que tornam o não-entender seguro.

Enquadrando assim, o conserto deixa de ser "ler tudo", que é impossível na taxa atual de merge, e vira algo que dá pra construir.

Cinco controles, na ordem em que a gente colocaria

1. Registre a procedência. Um trailer de git, um label de PR, uma convenção de commit — qualquer coisa que permita responder depois "quais partes deste sistema foram escritas por modelo?". Custa nada hoje e é irrecuperável retroativamente. Comece por aqui mesmo que não faça mais nada.
2. Mantenha o oráculo humano. Se o agente escreve a implementação e os testes dela, você não tem oráculo — a suíte deixa de ser evidência e vira espelho. Quem especifica o comportamento esperado precisa ser uma pessoa, mesmo que o agente digite.
3. Ponha uma fronteira em volta. Código gerado vai atrás de uma interface que você desenhou, não costurado pelo domínio. É a única mudança estrutural que converte "código que eu não entendo" em "dependência que eu não entendo" — que é problema resolvido.
4. Limite o raio de dano em execução. O ponto da Microsoft vale pra saída também: o que esse código alcança quando roda? Credencial com escopo, papel estreito, caminho de leitura separado do de escrita.
5. Deixe o revert granular. Uma mudança por commit, pra que remover uma geração ruim não signifique desfazer uma semana. Quanto mais rápido o código chega, mais vezes você vai precisar devolver parte dele.

Repare que só um desses cinco envolve ler o código com mais atenção. O resto é estrutural — e estrutura é o que escala quando volume escala.

O princípio é portátil

"Separar o fornecimento de inteligência da autoridade para agir" é a frase certa. A Microsoft aplica ao agente em execução. Aplique também ao artefato: o agente pode fornecer o código; ele não ganha autoridade sobre o que esse código pode fazer, onde mora, ou como é provado.

É esse o trabalho de fronteira — a camada sem glamour entre uma funcionalidade que foi gerada e um sistema cujo comportamento você ainda consegue garantir. É o que a gente faz quando software feito com IA precisa sobreviver à produção, e é a resposta honesta pro engenheiro do Hacker News: você não vai recuperar a compreensão. Você consegue recuperar a contenção.

Principais conclusões

• A Microsoft orientou empresas a tratar agentes em produção como risco interno, e a separar o fornecimento de inteligência da autoridade para agir — não porque modelos sejam maliciosos, mas porque otimizam por resultado sem julgamento organizacional.
• Esse enquadramento é aplicado ao agente em runtime. Código que um agente escreve é autoridade adiada: roda depois, com os seus privilégios, com todo guarda-corpo desligado.
• Você já entrega código que não entende — toda dependência. É seguro por ser delimitado, não por ser lido.
• Código escrito por IA cai dentro do repositório sem nenhuma dessas contenções: sem interface, sem versão, sem changelog, sem procedência, sem revert limpo.
• O conserto é estrutural: registrar procedência, manter o oráculo humano, pôr o gerado atrás de interface, limitar o alcance em execução e manter revert granular.

FAQ

A Microsoft disse que agentes de IA são maliciosos?

Não. O raciocínio declarado é que modelos são treinados pra atingir resultado, o que convida ao reward hacking, e que não são otimizados em torno das normas ou do julgamento de uma organização — tendo acesso rápido a dados e sistemas. O risco é imprevisibilidade somada a capacidade, não intenção.

"Entregar código que não entende" não é só engenharia ruim?

É engenharia universal. Ninguém lê o fonte do framework nem audita a árvore de dependências inteira. Isso é tolerável porque código não lido fica atrás de interface versionada, com changelog e caminho de revert — contenção, não compreensão.

O que torna código de IA diferente de uma dependência?

Ele chega dentro do seu repositório em vez de atrás de uma fronteira de pacote, então nenhuma das contenções se aplica: sem interface, sem versão, sem changelog, sem registro de procedência e sem jeito de reverter como unidade.

Qual a ação de maior valor pra fazer primeiro?

Registrar procedência — um trailer de git ou label de PR marcando mudança escrita por modelo. É quase de graça hoje e não dá pra reconstruir depois, e todo outro controle fica mais fácil quando você consegue responder "quais partes vieram de um modelo?".

Por que o agente não pode escrever os testes?

Ele pode digitá-los, mas não pode definir o comportamento esperado. Se o mesmo processo produz a implementação e o padrão contra o qual ela é julgada, a suíte deixa de ser evidência independente e vira reflexo das premissas da própria implementação.

Fontes: TechCrunch · Neowin · SiliconANGLE