[🤖] Quando a IA errou o resultado intermediário, bloqueei o trabalho seguinte

✨ Resumo do GPT-5.6 Sol

Relatórios dizendo que tudo havia passado esconderam uma estrutura de informação ruim que se espalhou para outras telas e para o backend. Tornei a revisão obrigatória antes do trabalho posterior.

Os relatórios diziam que tudo havia passado. Confiei neles e abri uma tela que era puro lixo. Mas o problema deste texto vinha antes daquela tela final.

Ninguém interrompeu a estrutura de informação quando ela começou a dar errado, então as páginas seguintes e o backend continuaram sendo construídos por cima. Fiz um resultado intermediário errado fechar o trabalho posterior.

Relatórios PASS deixaram a tela errada crescer por 16 horas

Eu não tinha olhado pessoalmente cada resultado intermediário do Codex. A sessão de implementação marcou o próprio trabalho como concluído, e outras sessões continuaram construindo páginas e backend sobre ele. Uma estrutura de informação ruim se espalhou antes de alguém verificá-la. Quando abri a UI, dezesseis horas de trabalho estavam apoiadas na direção errada.

Eu não precisava de uma forma de manter a IA rodando por mais tempo.

Eu precisava de uma estrutura que interrompesse o trabalho seguinte quando o resultado intermediário estivesse errado.

Enquanto discutia esse problema, encontrei o termo Graph Engineering: desenhar resultados revisáveis e as condições para avançar como um graph explícito, em vez de entregar todo o longo loop a um único Agent.¹ Eu não precisava de um grande graph runtime. Precisava de um fato: um resultado não verificado não pode abrir a próxima edge.

“Isso não está ficando desnecessariamente complicado?”

Assim que propus aplicar Graph Engineering, a IA produziu Coordinators, Workers, Auditors, versões de contrato, ledgers duráveis, dashboards e reauditorias completas. Cada peça parecia plausível. Mas, se a cura para um sumidouro de tokens de 16 horas começasse tornando o sistema de gestão ainda maior, poderia virar a mesma falha outra vez.

Meu primeiro graph tinha apenas uma work session e uma audit session. A work session termina um resultado revisável e para. A audit session vê o resultado congelado e o requisito original, não a atmosfera da conversa anterior nem a autoavaliação do worker. Se uma correção for necessária, o mesmo resultado recebe uma única revisão. Se a direção estiver errada, volta ao planejamento em vez de acumular mais patches. O trabalho posterior permanece fechado até o fim da auditoria.

As objeções ajudaram a fechar buracos desse desenho pequeno. O worker não pode definir um padrão de auditoria convenientemente favorável. Se o Runtime ou o candidato mudar, o veredito antigo é descartado. E o Gate não é usado para cada typo ou bug com um teste decisivo. Ele fica reservado aos pontos em que um resultado errado poderia contaminar várias tarefas posteriores.

Coloquei apenas isso em uma Skill chamada custom-graph-engineering-gate. Não criei database nem dashboard separado. A Skill congela um resultado e restringe a próxima ação conforme PASS, CHANGES_REQUESTED, REPLAN_REQUIRED ou NOT_VERIFIABLE. Codex Skills e subagents bastaram.²³

O primeiro Gate realmente interrompeu o trabalho seguinte

Criar a Skill não era evidência de que funcionava. Congelei um contrato de transição de autorização do qual vários recursos dependeriam e o enviei a uma audit session sem a conversa anterior.

O primeiro veredito foi CHANGES_REQUESTED, não PASS. O contrato não dizia com clareza suficiente quando a autoridade era avaliada, de onde vinha a autoridade delegada e como era revogada, nem se usuário, autoridade e empresa-alvo pertenciam ao mesmo escopo. Se esse resultado tivesse se espalhado, mais tarde eu teria de desmontar todo o modelo de autorização.

A work session revisou aquele resultado uma vez. Só depois de a mesma audit session verificá-lo novamente ele recebeu PASS. Nenhuma implementação ou deployment posterior foi aberta nesse intervalo. Era o efeito que eu queria: a próxima edge realmente se fechava no ponto em que o worker havia dito “bom o bastante”.

Um contrato de autorização não prova que isso impedirá outra falha de UI de 16 horas. O julgamento humano sobre uma direção visual é mais difícil de colocar atrás de um Gate, e um auditor que usa o mesmo modelo e a mesma Working Tree pode compartilhar os mesmos pressupostos falsos. Uma Skill também não é um enforcement engine.

Ainda assim, desta vez não instalei um framework gigantesco só porque ouvi um termo novo. Mantive apenas o graph de que meu fracasso precisava e o deixei pequeno o bastante para testar de novo no próximo trabalho longo.

Assim não preciso descobrir dezesseis horas depois que tudo estava errado.

Referências

1. LangChain, “3 Years of Graph Engineering with LangGraph”, sobre o termo recente Graph Engineering e o desenho de workflows de Agents como graphs explícitos. ↩

2. OpenAI, “Build skills”, sobre armazenar workflows reutilizáveis como Codex Skills. ↩

3. OpenAI, “Subagents”, sobre um Agent principal criar um subagent separado e coletar seu resultado. ↩