25 Horas, 13 Milhões de Tokens: O Que uma Maratona Codex Revela Sobre Memória de Agentes

Derrick Choi da OpenAI publicou um artigo no cookbook esta semana sobre um experimento que a maioria dos engenheiros consideraria implausível. O GPT-5.3-Codex, rodando com raciocínio máximo, construiu uma ferramenta completa de design do zero. Sem interrupção. Por 25 horas. Consumindo aproximadamente 13 milhões de tokens e gerando cerca de 30.000 linhas de código.

A aplicação entregue inclui edição de canvas, colaboração ao vivo, gerenciamento de camadas, guias de alinhamento, histórico com replay, modo protótipo com navegação por hotspots, comentários com threads e exportação para JSON e React+Tailwind. Dez categorias principais de funcionalidade, ponta a ponta.

Os números impressionam. São também, por si sós, insignificantes. Uma única execução experimental por um funcionário da OpenAI usando o modelo mais recente em configuração máxima não estabelece um benchmark. O que estabelece é uma metodologia — e essa metodologia merece estudo cuidadoso.

Horizonte Temporal É a Nova Métrica

A mudança conceitual que Choi identifica é sutil mas importante. “Codificação agêntica é cada vez mais sobre horizonte temporal, não apenas inteligência one-shot.” O avanço não é que modelos ficaram mais inteligentes em um dado momento. O avanço é que agentes conseguem manter coerência por mais tempo, completar segmentos maiores de trabalho ponta a ponta e se recuperar de erros sem perder o fio.

A pesquisa do METR quantifica isso: aproximadamente sete meses de tempo de duplicação para a duração de tarefas de software que agentes frontier conseguem completar com confiabilidade. Essa trajetória — se se mantiver — significa que no início de 2027, agentes lidarão com tarefas que levam dias, não horas.

Mas coerência ao longo do tempo não emerge apenas da capacidade do modelo. Requer infraestrutura operacional. E essa infraestrutura é o que torna o experimento de Choi interessante.

O Sistema de Memória com 4 Documentos

A metodologia que manteve o Codex coerente por 25 horas não é uma técnica de engenharia de prompts. É uma arquitetura de memória externa composta por quatro documentos markdown que o agente revisita ao longo da sessão.

Prompt.md congela o alvo. Contém objetivos, não-objetivos, restrições rígidas, entregáveis explícitos e critérios “feito quando.” O propósito é direto: “Congele o alvo para que o agente não construa algo impressionante mas errado.” Cada restrição que existe apenas na cabeça do operador é uma especificação que o agente não pode seguir.

Plan.md transforma trabalho aberto em uma sequência de checkpoints. Marcos dimensionados para completação em loop único. Cada marco tem critérios de aceite pareados com comandos de validação. A regra crítica: “Se a validação falhar, conserte antes de avançar.” Notas de decisão são registradas para prevenir raciocínio circular.

Implement.md é o runbook de execução. Designa o Plan.md como fonte autoritativa e exige validação pós-marco. Contenção de escopo é explícita: as mudanças de cada marco devem permanecer focadas e revisáveis. A diretriz é direta: “Siga o plano, mantenha diffs contidos, execute validações, atualize docs.”

Documentation.md é a memória compartilhada e o log de auditoria. Status do marco atual, racional das decisões, instruções operacionais, problemas conhecidos. Este documento permite que um humano verifique após horas de ausência e entenda exatamente onde o agente está e por que tomou as decisões que tomou.

Por Que Funciona

Os quatro documentos resolvem problemas diferentes.

Prompt.md resolve desvio de especificação. Sem um alvo congelado, o agente otimiza para impressionar localmente — cada passo parece bom, mas a direção geral se perde. Em uma tarefa de 5 minutos, isso se manifesta como desalinhamento menor. Em uma tarefa de 25 horas, manifesta-se como uma aplicação completamente errada.

Plan.md resolve o problema de coerência. Um agente operando sem marcos não tem como medir progresso. Não consegue distinguir entre “avançando” e “gerando tokens.” Marcos com critérios de validação criam checkpoints objetivos: ou o build passa ou não passa.

Implement.md resolve disciplina de execução. A distância entre “ter um plano” e “seguir um plano” é real mesmo para agentes autônomos. Sem instruções explícitas, o agente pode tomar atalhos que comprometem a arquitetura geral.

Documentation.md resolve inspecionabilidade. Uma sessão autônoma de 25 horas só é prática se o operador pode verificar periodicamente, entender o estado e corrigir o curso se necessário.

Verificação por Marcos como Governança

O padrão operacionalmente mais significativo do experimento é a porta de verificação. Após cada marco, o agente executa lint, typecheck, build e testes. Nenhum avanço sem passar todas as portas.

Quando falhas de lint ocorreram, o agente identificou violações e as corrigiu antes de avançar. Para uma sessão de 25 horas, um bug introduzido na hora dois e capturado apenas na hora vinte produz falhas em cascata potencialmente irrecuperáveis.

Esse padrão mapeia diretamente ao que o sistema Signals da Factory faz no nível de sessão: verificação automatizada prevenindo acúmulo de erros. A implementação difere — Factory monitora fricção do usuário; Codex monitora qualidade de código — mas o princípio arquitetural é idêntico: verificação contínua previne que desvio se acumule.

O Modelo de Delegação

Choi enquadra a mudança como passando de pair programming para delegação com guardrails. O humano escreve a especificação, define os marcos e verifica nos limites. O agente executa, valida e documenta. Direcionamento acontece nos marcos, não em cada linha.

O facilitador prático são os git worktrees. O agente trabalha em um branch isolado. O desenvolvedor continua seu trabalho normal no branch principal. Quando o agente completa, o desenvolvedor revisa o diff e decide o que mergear. Trabalho autônomo longo não bloqueia nada.

O Que Isso Não Prova

Ressalvas importantes antes de aplicar o padrão.

Primeiro, é uma aplicação greenfield. Construir do zero é o caso mais fácil para geração autônoma. Modificar um codebase existente com dependências legadas e decisões arquiteturais implícitas é um problema fundamentalmente mais difícil.

Segundo, 30.000 linhas de código gerado não são 30.000 linhas prontas para produção. O artigo confirma que lint, typecheck e build passam. Não confirma revisão de segurança, benchmarks de performance ou manutenibilidade.

Terceiro, o custo não é divulgado. Treze milhões de tokens no raciocínio máximo do GPT-5.3 não é barato.

Quarto, a proporção token-por-código é alta. Treze milhões de tokens para 30.000 linhas resulta em aproximadamente 433 tokens por linha de código — overhead enorme de raciocínio e contexto.

O Padrão Que Se Transfere

Remova os detalhes específicos do GPT-5 e um padrão geral permanece.

Para qualquer tarefa de agente autônomo mais longa que alguns minutos:

Congele o alvo em um documento de especificação. Tudo que o agente precisa saber sobre o que “feito” significa deve estar escrito.

Decomponha em marcos verificáveis. Cada marco deve ter critérios de aceite verificáveis automaticamente. Nenhum avanço sem passar as portas.

Crie um runbook de execução. Instruções explícitas sobre como seguir o plano e o que fazer quando validação falha.

Mantenha um log de status. O operador deve poder verificar a qualquer momento, entender o estado atual e decidir se corrige o curso.

Esse framework funciona para 25 minutos ou 25 horas. Funciona com GPT-5 ou com um modelo local. O modelo fornece a capacidade. Os documentos fornecem a governança. Nenhum é suficiente sem o outro.

É isso que operar IA autônoma realmente exige: não um modelo melhor, mas um contrato melhor entre intenção humana e execução do agente.