O Modelo Corrigiu o Próprio Erro Antes de Você Ver. Agora Prove Que Estava Certo.

TV
Thiago Victorino
7 min de leitura
O Modelo Corrigiu o Próprio Erro Antes de Você Ver. Agora Prove Que Estava Certo.

O Figma lançou este mês um recurso que remove um checkpoint que a maioria dos times nem sabia que usava. No anúncio de julho de 2026 do GPT-5.6 no Figma Make, Gui Seiz, Diretor de Design de IA da empresa, escreve que o modelo pode “investigar e corrigir erros automaticamente durante a geração do protótipo, sem intervenção do usuário.” O exemplo é específico: “o GPT-5.6 identificou a origem de um build em branco e o corrigiu sozinho.” Um build quebrou. O modelo diagnosticou. O modelo reparou. Você não viu nada disso. Você viu um protótipo funcionando.

É uma capacidade real, e é útil. É também o momento em que a trilha de auditoria apaga.

O checkpoint que acabou de sumir

Antes disso, um erro durante a geração era um evento visível. O build voltava em branco, ou quebrado, ou errado, e um humano notava. Esse notar era um checkpoint, mesmo quando ninguém o chamava assim. Quem via a falha ganhava o direito de fazer a próxima pergunta: a ferramenta entendeu errado o que pedi ou esbarrou num bug passageiro? O build em branco era informação. Dizia algo sobre se o modelo tinha de fato entendido sua intenção ou apenas produzido algo com o formato de intenção.

A autocorreção tira o build em branco do seu campo de visão. A falha ainda acontece. O diagnóstico ainda acontece. O reparo ainda acontece. Tudo isso ocorre abaixo da superfície, e o que aflora é um resultado limpo. Você perde a chance de julgar o reparo porque nunca fica sabendo que um reparo ocorreu.

Veja o custo disso. Quando o modelo conserta uma falha passageira genuína, curá-la em silêncio é exatamente o certo e você não quer nenhuma interrupção. Quando o modelo encobre um sintoma que não entendeu, curá-lo em silêncio te entrega um protótipo que parece correto e se apoia num reparo que ninguém avaliou. De fora, os dois casos são idênticos. Ambos produzem um build funcionando, sem histórico visível. Você não consegue distinguir a cura boa do remendo de sorte, porque o mecanismo que produziu os dois apagou a evidência que você precisaria para separá-los.

O que a autocorreção de fato é

O mecanismo não é misterioso, e nomeá-lo com precisão importa para governá-lo. A Arthur AI, fornecedora de guardrails, descreveu o formato dele em junho de 2026: um loop de autocorreção detecta um problema com um verificador pós-saída, revisa a saída no lugar com um pedido de correção, depois tenta de novo e re-checa até o resultado passar ou um limite de tentativas parar o processo. Gerar, checar, corrigir, checar de novo. Fechar o loop quando passa.

A raiz acadêmica vem de antes. O Self-Refine, publicado por Madaan e colegas no NeurIPS 2023 e citado cerca de quatro mil e novecentas vezes, estabeleceu que um modelo pode alternar entre dar feedback a si mesmo e refinar a própria saída, repetindo até a qualidade cruzar uma barra. Variantes mais fortes juntam o gerador a um verificador separado, no nível do passo, que confere o trabalho em vez de confiar que o gerador se autoavalie. A técnica é bem estudada e funciona. É justamente por isso que ela agora chega dentro de uma ferramenta de design de uso amplo, sem nenhuma cerimônia.

Nada disso é o problema. A autocorreção é um mecanismo legítimo e poderoso. O problema é o que o loop emite quando roda em produção. Por padrão, ele emite o resultado final e nada mais. O gatilho que disparou, as tentativas que levou, se passou de forma limpa ou bateu no limite e desistiu: tudo isso fica dentro do loop. O design sai limpo. O raciocínio que o tornou limpo é irrecuperável.

A trilha de auditoria é a camada de governança

Já escrevemos que governar a saída de IA significa ser dono da revisão dela, e que alguém precisa ser nomeado como o revisor do que os agentes escrevem. A geração autocorretiva eleva a aposta nos dois. Você não pode revisar o que não pode ver. Quando o loop absorve a falha e o reparo, não sobra nada a que atribuir um revisor. O registro do qual a revisão depende nunca foi escrito.

Considere o que um designer perde ao longo de uma semana assim. Dez protótipos são gerados. Três deles se autocorrigiram em silêncio durante o build. O designer entrega os dez, sem saber que três carregavam um defeito reparado. Um desses reparos foi um conserto genuíno. Dois foram remendos sobre uma intenção lida errado que vai ressurgir a jusante, num handoff para engenharia ou num componente que se comporta errado sob uma condição que ninguém testou. Não há log a consultar, nem diff a inspecionar, nem contagem de tentativas para sinalizar os dois builds arriscados entre os três. A informação que os teria separado foi gerada e descartada dentro do mesmo segundo.

Repare que a própria orientação da Arthur já nomeia o conserto. Limite as tentativas, eles aconselham, e emita cada gatilho e cada tentativa como telemetria. Essa é exatamente a camada de governança que a autocorreção em produção tende a omitir. Uma fornecedora que vende guardrails está te dizendo que o loop precisa de uma superfície de auditoria, no mesmo mês em que uma fornecedora que vende ferramentas de design lançou o loop sem anunciar nenhuma. O post do Figma descreve a cura como um benefício. Não reivindica um log, um diff, nem uma contagem de tentativas. Leia o anúncio pelo que promete e pelo que silencia. O silêncio é a camada de governança.

Como é um gerador autocorretivo governado

O conserto não é desligar a autocorreção. A recuperação silenciosa de falhas passageiras é genuinamente boa, e um designer interrompido a cada tentativa ficaria pior. O conserto é fazer o loop deixar um rastro. Três propriedades transformam um autocorretor opaco num governado.

Telemetria emitida. Toda vez que o loop dispara, ele registra o que o disparou, quantas tentativas levou e se passou ou esgotou o limite. Isso não interrompe o designer. Escreve uma linha que o designer, um revisor ou uma auditoria posterior podem ler. Um autoconserto que não emite nada é uma decisão tomada pela sua ferramenta que ninguém consegue revisitar.

Tentativas limitadas com um teto visível. Um loop que tenta de novo sem limite rígido pode queimar custo e, pior, pode convergir para uma saída que passa no verificador sem satisfazer a intenção. Limite, e mostre quando o teto for atingido. Um build que se curou na sétima tentativa é um build que merece um segundo olhar, e você só sabe que levou sete se a contagem for emitida.

Diffs de antes e depois retidos. A saída defeituosa original e a saída reparada devem ser recuperáveis. O diff entre elas é o artefato mais útil para julgar uma cura. Ele mostra se o modelo corrigiu um erro real ou remodelou um sintoma. Descarte o estado pré-cura e você jogou fora a única coisa que permite a um humano avaliar o conserto.

Um gerador com essas três propriedades ainda se cura em silêncio no caso comum. A diferença é que o silêncio agora é recuperável. Quando um design entregue se revela errado, alguém pode puxar a trilha e ver que o build se autocorrigiu duas vezes, que o diff mostra um sintoma remodelado em vez de uma causa consertada, e que a contagem de tentativas ficou fixada no teto. Essa é a diferença entre uma saída limpa e uma explicável.

Faça isto agora

Para qualquer gerador autocorretivo que seu time entregue ou adote, exija três coisas antes que ele toque em trabalho de produção. Primeiro, telemetria em cada cura: gatilho, contagem de tentativas, passou ou falhou, emitida para um log que um humano possa ler. Segundo, um teto rígido de tentativas com um sinal visível quando o teto for atingido. Terceiro, diffs de antes e depois retidos, para que o estado pré-cura seja recuperável na revisão.

Se uma ferramenta se autocorrige e não consegue te mostrar nenhum dos três, trate a saída limpa dela como não verificada. O build parece correto. Se ele é correto, e se o modelo entendeu você ou remendou ao seu redor, é uma pergunta que a ferramenta respondeu e depois escondeu. Governança é trazer a resposta de volta para o registro.


Fontes

A Victorino ajuda times a manter trilha de auditoria sobre IA autocorretiva, para que um resultado limpo seja também explicável: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa