[🤖] Testei Graph Engineering no Codex

✨ Resumo do GPT-5.6 Sol

Depois que uma tarefa de 16 horas no Codex terminou em desastre, questionei se Graph Engineering era mesmo a solução, reduzi a ideia a uma Gate Skill mínima e a testei em um contrato real de autorização.

Ontem, depois de uma longa discussão, terminei especificações página por página para uma reformulação completa de UI/UX e defini um Goal no Codex para desenvolver com base nelas. O Goal rodou por 16 horas.

Hoje abri a tela cheio de expectativa, mas o resultado era simplesmente um lixo.

Dois dias antes eu já tinha escrito que precisava abandonar a fantasia da mágica de uma tentativa só com IA. Desta vez não parei em uma instrução de uma linha. Defini trabalhos por função e especificações por página, incluindo calendário, table view, busca, filtros e recuperação de falhas. Depois de protótipos fracassados, eu ainda tinha criado critérios separados para auditoria da UI.

Mesmo assim, vários workers passaram a noite escrevendo código e dizendo que tests e auditorias tinham passado, e o que encontrei foi uma antiga tela administrativa tão difícil de entender que eu mal sabia o que ela queria dizer. Onde estavam o calendário e a table view sobre os quais eu tanto tinha falado?

Foram consumidos tokens demais, código demais foi alterado e relatórios PASS demais se acumularam. Mas o resultado que eu realmente queria não existia.

Fiquei humilde. De novo.

Por isso decidi testar Graph Engineering no Codex. Não queria apenas estudar a palavra da moda mais recente nem começar instalando um framework gigantesco. Queria reduzi-la à menor forma capaz de evitar a falha que eu acabara de sofrer.

Surgiu um motivo para testar Graph Engineering

Pedi à IA que analisasse por que isso tinha acontecido. As regras compartilhadas faziam parte do problema, e a auditoria de UI tinha se concentrado demais em itens fáceis de medir, como tamanho da fonte e altura dos botões. Mas o maior problema estava em outro lugar.

Eu não verificava cada resultado intermediário do Codex. A sessão de implementação declarava o próprio trabalho concluído, e outras sessões herdavam esse resultado e continuavam criando mais páginas e backend. A arquitetura de informação errada do início se espalhou por várias telas antes de ser verificada. Quando abri o produto real, 16 horas de trabalho já estavam empilhadas sobre aquela direção equivocada.

O que eu precisava não era uma forma de deixar a IA trabalhar por mais tempo.

Eu precisava de uma estrutura que impedisse o próximo trabalho de começar quando um resultado intermediário estivesse errado.

Enquanto continuava discutindo o problema com a IA, conheci o termo Graph Engineering. Era uma abordagem que, em vez de entregar tudo ao longo loop de um único Agent, conectava vários Agents, verificadores e decisões humanas como nodes e edges, definindo explicitamente qual resultado permitia avançar. Parecia menos uma tecnologia inteiramente nova e mais um nome recente para ideias conhecidas de workflow e state machine.¹

O importante não era decorar outra buzzword. Agora uma sessão do Codex consegue assumir um trabalho bastante longo; portanto, o próprio resultado dessa sessão pode ser tratado como um node, com condições explícitas para passar à sessão seguinte.

No meu experimento, Graph Engineering foi mapeado assim:

• node: um resultado intermediário que o usuário consegue revisar de forma independente
• edge: a condição que leva à correção ou ao próximo trabalho de acordo com o veredito
• state: o registro de qual resultado foi auditado, com qual critério e o que agora é permitido
• cycle: o loop que corrige apenas o mesmo resultado e o verifica novamente quando a auditoria encontra um defeito

Chamar vários Agents não é, por si só, Graph Engineering. O núcleo do teste era projetar primeiro a topologia e as transições de estado para que um node não verificado não abrisse seus edges posteriores.

Meu primeiro graph tinha apenas uma sessão de trabalho e uma de auditoria

Quando falei em aplicar Graph Engineering ao problema, a IA começou imediatamente a aumentar a estrutura. Separou Coordinator, Worker e Auditor e adicionou aprovação humana da direção, versão do contrato, durable ledger e auditoria final em cold start.

Separadamente, nada disso era absurdo. Ainda assim, fiquei preocupado.

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

Se, para impedir que 16 horas consumissem todos os tokens sem resultado, eu abrisse vários Agents e acumulasse estados e relatórios, o que realmente mudaria? Se aplicar Graph Engineering virasse outro grande projeto, ele poderia voltar a consumir tokens sem entregar valor.

Minha ideia era muito mais simples.

A sessão de trabalho conclui um resultado revisável.
→ Entrega à sessão de auditoria e espera.
→ A auditoria retorna PASS ou alterações solicitadas.
→ Só então a sessão de trabalho continua.

Perguntei se esse fluxo poderia virar uma Skill reutilizável. Mas a IA continuava falando da estrutura de sessões e dos limites da imposição mecânica, tornando tudo complexo. Cheguei a trazer a resposta de outra sessão e perguntar novamente.

“Transformar isso em Skill é mesmo ineficiente? Você está falando sério ou inventando por conta própria?”

Também exigi repetidamente que ela não apenas concordasse comigo, mas criticasse a ideia. Eu não queria ouvir que estava certo; queria saber se isso realmente evitaria outro fracasso de 16 horas ou se eu só estava criando um novo brinquedo sofisticado.

Reduzi o experimento por meio de críticas sucessivas

Depois de várias revisões críticas, reconheci que meu plano simples também tinha falhas.

Se a sessão de trabalho define até os critérios de auditoria, ela pode favorecer o próprio resultado. Se todo o reasoning e a autoavaliação do worker forem enviados à auditoria, o reviewer talvez apenas releia a explicação, em vez de avaliar de forma independente. Se o próximo trabalho começar durante a auditoria, o PASS gate perde o sentido. Também seria possível aprovar uma tela antiga depois de uma mudança no Runtime ou lembrar de forma errada um PASS após uma compaction da conversa.

Por outro lado, eu não precisava aceitar todas as sugestões da IA. Descartei três sessões permanentes, um graph runtime separado, banco de dados, dashboard, auditoria de todas as páginas e revisão total sempre que o contrato mudasse. Com tudo isso, o sistema de gestão ficaria maior que o produto.

No fim, mantive apenas estes princípios:

• A sessão principal coordena e também trabalha.
• Uma sessão separada de auditoria só é aberta para resultados que realmente precisam de Gate.
• A auditoria não recebe toda a conversa anterior.
• O resultado auditado fica congelado, e nem ele nem o trabalho diretamente posterior mudam até o fim da auditoria.
• Um erro de implementação é separado de um erro na própria direção do trabalho.
• Se um problema importante permanecer após uma correção e nova auditoria, os patches param e o plano é reaberto.
• Quando o contrato muda, apenas os trabalhos afetados são reavaliados.
• O PASS da auditoria não substitui minha aprovação da direção do produto nem autoriza deploy.

Acima de tudo, decidi não aplicar a estrutura a todo trabalho. Um erro de digitação, um bug resolvido por um test decisivo ou uma exploração livre sem caminho conhecido não justificam outra sessão. O Gate só entra onde um resultado errado pode contaminar vários trabalhos posteriores.

Também não transformei automaticamente cada página em uma unidade. Se a tarefa real é pesquisar uma lista, entrar no detalhe, agir e voltar ao mesmo filtro, esse journey inteiro é a unidade revisável. Em contrapartida, telas que apenas repetem o mesmo pattern não precisam de auditoria separada.

Assim preservei o graph simples que eu queria, mas deixei claro por que parar e o que verificar.

Transformei o graph mínimo em uma Codex Skill

Por fim, pedi ao Codex uma Skill compartilhada chamada custom-graph-engineering-gate. A OpenAI já oferece o caminho para salvar workflows repetidos como Skills e fazer o Agent principal chamar um subagent separado e recolher seu resultado.²³ Não era necessário criar outro serviço para organizar a troca entre a sessão de trabalho e a de auditoria.

Também pedi que o trabalho não crescesse. Não criei script de execução, outro banco de dados nem graph dashboard. Foram criados apenas o corpo da Skill e os metadados mínimos para exibi-la no Codex.

A Skill faz três coisas principais.

Primeiro, avalia se o trabalho é importante o bastante para precisar de Gate. Ela só é usada quando um resultado intermediário errado poderia prejudicar vários resultados posteriores.

Segundo, congela em uma frase o resultado a ser auditado. Registra o resultado para o usuário, o critério entre sucesso e falha, o candidate exato, a rota normal de verificação e o trabalho posterior direto liberado pelo PASS. Quantidade de arquivos ou tests não substitui o resultado do usuário.

Terceiro, restringe as transições entre trabalho e auditoria.

PASS              → avançar apenas para o trabalho diretamente posterior
CHANGES_REQUESTED → corrigir uma vez o mesmo resultado e auditar novamente
REPLAN_REQUIRED   → rever o contrato ou a divisão do trabalho, não continuar implementando
NOT_VERIFIABLE    → não aprovar sem evidência

A sessão de auditoria não herda a conversa anterior. Minha raiva, o esforço da sessão de trabalho e as partes que o implementador considera boas não são evidências. O reviewer examina diretamente o requisito original e o resultado atual.

Se o source ou o Runtime mudar durante a auditoria, o veredito anterior é descartado. Se uma interrupção ou compaction impedir reconstruir qual candidate recebeu qual veredito, a Skill não presume que ele passou.

Isso não é muito diferente da estrutura que propus no começo. A Skill apenas preserva as condições de transição fáceis de esquecer, para que a ideia de “manter uma sessão de auditoria” seja executada com a mesma topologia nas próximas sessões.

Testei o graph em um contrato real

Se eu confiasse na Skill apenas porque ela tinha sido criada, repetiria o mesmo erro. Por isso entreguei a própria Skill nova a um reviewer separado que não herdou a conversa anterior.

Primeiro confirmei que ela não deveria ser usada numa simples mudança de texto. Não usá-la quando não é necessária foi o primeiro teste contra o desperdício de tokens.

Depois escolhi como primeiro node real um contrato de transição de autorização do qual vários recursos dependeriam. Congelei o candidate e o enviei à auditoria. O primeiro veredito não foi PASS, mas CHANGES_REQUESTED. Não estava claro o bastante em qual momento a autorização era avaliada, de onde vinha a autoridade delegada e como sua revogação se propagava, nem se usuário, permissão e empresa-alvo estavam vinculados ao mesmo scope.

Se o contrato tivesse sido expandido para vários recursos, mais tarde seria necessário reconstruir toda a fronteira de autorização. A sessão de trabalho corrigiu apenas esse escopo, e a mesma auditoria o verificou novamente antes de devolver PASS. Durante todo esse período, a implementação posterior e o deploy permaneceram fechados.

Foi um teste pequeno, mas mostrou o efeito de Graph Engineering que eu queria. O edge posterior continuou fechado em um node que o worker considerava “bom o bastante”, e o problema foi corrigido antes de se espalhar. Apenas depois que a mesma auditoria examinou o candidate corrigido e retornou PASS o próximo passo pôde ser aberto.

O primeiro experimento passou, mas ainda não resolveu a falha de UI

O graph funcionou como esperado no primeiro teste. Mas ainda não posso dizer que esta Skill teria impedido o desastre de UI de 16 horas. Auditar um contrato de autorização com source relativamente explícito é diferente de interromper uma direção visual errada. Ainda não testei se ela reduz tempo e tokens totais em um grande trabalho real de UI. A auditoria usa o mesmo modelo e vê o mesmo Working Tree, portanto pode compartilhar as premissas erradas do worker. Uma Skill é uma instrução, não um mecanismo de enforcement.

Por isso o próximo trabalho longo não deve ser avaliado pelo número de PASS.

• A primeira direção errada foi detectada antes da expansão?
• O retrabalho evitado custou mais do que os tokens da auditoria?
• O momento em que vi o primeiro resultado provisório ficou mais distante?
• As sessões de trabalho e auditoria foram enganadas pelo mesmo contrato errado?

Se o experimento não compensar, devo usar menos Gates, não adicionar mais regras. Se a mesma falha se repetir, antes de criar outra etapa de auditoria devo rever o que agrupei como um resultado e quais evidências mostrei ao reviewer.

Conhecer o termo Graph Engineering não me tornou subitamente bom em usar IA. Mas desta vez não instalei um framework enorme assim que ouvi uma palavra da moda. Mantive apenas o graph necessário para a falha que vivi, continuei contestando as propostas exageradas da IA e o transformei em uma Skill pequena que posso testar novamente em sessões futuras.

Para não descobrir, só depois de 16 horas, que toda a direção estava errada.

Referências

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

2. OpenAI, “Build skills”. O caminho oficial para salvar workflows repetíveis como Codex Skills. ↩

3. OpenAI, “Subagents”. Explica como um Agent principal pode criar subagents separados e recolher seus resultados. ↩