Principais destaques

• A OpenAI construiu cerca de 1 milhão de linhas de código usando agentes Codex, sem que os engenheiros escrevessem diretamente o código. O projeto levou cerca de cinco meses, reuniu aproximadamente 1.500 pull requests e começou com apenas três engenheiros conduzindo o trabalho.
• O maior aprendizado não foi sobre geração de código, mas sobre contexto. A equipe descobriu que um arquivo gigantesco com todas as instruções rapidamente se transforma em um acúmulo de regras antigas e passou a tratar a documentação como um mapa para o agente navegar.
• A mesma lógica pode ser aplicada por quem não está construindo um milhão de linhas de software. A ideia é separar instruções permanentes, estado atual do projeto, histórico e recursos disponíveis, criando um sistema de memória que permita à IA continuar o trabalho sem começar do zero.

---

Durante anos, a promessa dos assistentes de programação foi relativamente simples: você descreve uma função, a inteligência artificial escreve o código e um humano revisa o resultado. A experiência da OpenAI mostra que essa relação está mudando de escala.

Em um experimento interno revelado pela própria empresa, uma equipe construiu um produto de software praticamente inteiro com agentes Codex. O primeiro commit aconteceu no fim de agosto de 2025, em um repositório vazio. Cinco meses depois, o projeto já tinha aproximadamente 1 milhão de linhas de código, entre lógica da aplicação, infraestrutura, ferramentas, documentação e utilitários internos. Nesse período, cerca de 1.500 pull requests foram abertas e mescladas.

E há um detalhe ainda mais importante: os humanos não escreveram diretamente o código.

A própria OpenAI descreve a experiência com uma frase que resume a mudança de paradigma: humanos direcionam, agentes executam.

Isso não significa que os engenheiros ficaram parados observando uma IA trabalhar. O papel deles mudou. Em vez de gastar a maior parte do tempo digitando código, passaram a criar ferramentas, definir limites, melhorar documentação, estabelecer critérios de qualidade, observar resultados e construir mecanismos para que os agentes pudessem trabalhar de maneira cada vez mais autônoma.

É aí que começa a parte realmente interessante para quem quer aprender a trabalhar com agentes de IA.

A grande lição não é “deixe a IA programar tudo”.

A lição é: quanto mais autônomo o agente fica, mais importante se torna o ambiente que você constrói ao redor dele.

---

O experimento que começou com um repositório vazio

A história começou de maneira quase provocativa: um repositório Git vazio.

A estrutura inicial do projeto, incluindo organização dos arquivos, configuração de integração contínua, regras de formatação, gerenciador de pacotes e estrutura da aplicação, foi criada pelo Codex CLI usando GPT-5. Até o primeiro arquivo AGENTS.md, usado para orientar o comportamento dos agentes dentro do repositório, foi produzido pelo próprio Codex.

A restrição era deliberada.

Os engenheiros não deveriam simplesmente recorrer ao código manual quando encontrassem um problema. Se o agente não conseguisse realizar alguma tarefa, a pergunta passava a ser outra:

O que está faltando no ambiente para que o agente consiga fazer esse trabalho?

Essa mudança parece pequena, mas altera completamente a função de um engenheiro.

Imagine um programador tradicional encontrando uma dificuldade. Ele pode abrir o editor, escrever uma solução, testar, corrigir e seguir em frente.

Nesse modelo, o engenheiro precisa pensar:

“Como faço para que o agente seja capaz de resolver esse tipo de problema sozinho daqui para frente?”

A resposta pode ser uma nova ferramenta, uma documentação melhor, uma regra arquitetural, um teste automatizado, uma nova fonte de observabilidade ou uma instrução mais clara.

A equipe percebeu que o avanço inicial era mais lento não necessariamente porque o Codex era incapaz de programar, mas porque o ambiente ainda não fornecia ferramentas, abstrações e estruturas suficientes para transformar objetivos grandes em trabalho executável.

O resultado foi uma espécie de inversão da engenharia de software.

O código deixou de ser o principal lugar onde o conhecimento da equipe era armazenado.

O ambiente passou a ser parte do próprio sistema de inteligência.

Uma forma simples de visualizar a mudança

Modelo tradicional

Humano → escreve código → testa → corrige → entrega

Modelo orientado por agentes

Humano → define intenção → agente executa → ferramentas observam → testes avaliam → agente corrige → humano decide

A diferença parece apenas operacional. Na prática, ela muda onde está concentrado o trabalho intelectual.

---

O problema invisível: quanto mais a IA trabalha, mais contexto ela acumula

Existe uma armadilha que aparece quando um agente passa de alguns minutos para várias horas de trabalho.

No começo, quase tudo é simples.

Você fornece uma tarefa, explica o objetivo e entrega os arquivos necessários. O agente analisa o contexto e começa a executar.

Depois de algumas horas, a situação muda.

Agora existem decisões tomadas, arquivos criados, testes que falharam, abordagens abandonadas, novas restrições, problemas descobertos e hipóteses que já não são válidas.

A reação mais intuitiva é colocar tudo em um único documento.

Mais regras.

Mais instruções.

Mais contexto.

Mais histórico.

Mais explicações.

Até que surge um arquivo enorme que supostamente deveria ajudar a IA, mas começa a fazer exatamente o contrário.

A OpenAI testou esse caminho com um AGENTS.md gigantesco e concluiu que a estratégia não funcionava bem. O problema era que o contexto é um recurso limitado. Quando informações demais são colocadas na mesma camada, as instruções importantes podem perder espaço para detalhes que já não são relevantes.

A empresa descreveu o resultado como uma espécie de cemitério de regras antigas.

Uma regra criada no começo do projeto pode ter sido correta naquele momento e estar completamente errada semanas depois.

Para um humano, isso pode parecer óbvio.

Para um agente, uma instrução antiga ainda presente no contexto continua sendo uma informação potencialmente relevante.

É por isso que a solução encontrada pela OpenAI foi bastante diferente.

Em vez de criar um manual gigantesco, o AGENTS.md passou a funcionar como um índice.

O arquivo principal teria aproximadamente 100 linhas e apontaria para outras fontes de informação dentro do repositório. A estrutura incluía documentos de arquitetura, planos de execução, especificações de produto, documentação de frontend, segurança, confiabilidade, qualidade e outros materiais.

Em outras palavras:

não entregue a biblioteca inteira para o agente.

Dê a ele um mapa da biblioteca.

Isso permite o que a OpenAI chama de divulgação progressiva de contexto. O agente começa com uma quantidade pequena e estável de informação e aprende onde procurar o restante conforme a tarefa exige.

---

A arquitetura de contexto que você pode copiar

Uma das ideias mais úteis desse experimento pode ser aplicada fora de grandes equipes de engenharia.

Pense no contexto de um agente como quatro camadas.

01. Instruções estáveis

São as regras que mudam pouco.

Exemplos:

• como o agente deve trabalhar;
• quais arquivos deve consultar;
• quais ações exigem aprovação;
• padrões de qualidade;
• restrições de segurança;
• convenções do projeto.

02. Estado atual

É a parte mais importante para tarefas longas.

Ela responde:

Onde estamos agora?

Deve conter:

• objetivo atual;
• decisões já tomadas;
• problemas abertos;
• próxima ação;
• critérios de conclusão;
• bloqueios;
• informações que mudaram recentemente.

03. Mapa de recursos

É o índice.

Em vez de colocar todas as informações no contexto, ele informa ao agente onde encontrá-las.

Pode apontar para:

• documentação;
• pesquisas;
• especificações;
• exemplos;
• APIs;
• relatórios;
• código;
• decisões anteriores.

04. Histórico

É o registro do que aconteceu.

Aqui entram:

• decisões antigas;
• tentativas fracassadas;
• logs;
• alterações;
• versões anteriores;
• justificativas.

O histórico é importante, mas não deveria competir com o estado atual.

Essa separação também aparece no trabalho da Anthropic com agentes de longa duração. Em seus experimentos com Claude para computação científica, a empresa utilizou um arquivo de progresso que funciona como uma memória portátil entre sessões. Ele registra o que foi concluído, o estado atual, abordagens que falharam, motivos das falhas e limitações conhecidas.

A lógica é poderosa:

O passado deve explicar o presente, mas não substituir o presente.

---

Prompt para criar seu próprio sistema de contexto

Se você usa ChatGPT, Claude ou outro agente para um projeto que vai durar vários dias, experimente este prompt:

Quero transformar este projeto em um trabalho de longa duração com IA.

Crie uma estrutura de contexto dividida em quatro partes:

1. INSTRUÇÕES ESTÁVEIS
Regras que provavelmente permanecerão válidas durante todo o projeto.

2. ESTADO ATUAL
Objetivo atual, decisões tomadas, questões em aberto, bloqueios, próxima ação e critérios para considerar a etapa concluída.

3. MAPA DE RECURSOS
Liste os documentos, arquivos, pesquisas, referências e fontes que existem e explique quando cada um deve ser consultado.

4. HISTÓRICO
Registre decisões anteriores, tentativas que falharam e mudanças de direção.

Não misture informações históricas com instruções atuais.

Sempre que uma decisão antiga for substituída, marque explicitamente a informação anterior como obsoleta.

No final de cada etapa, gere uma versão atualizada do ESTADO ATUAL que possa ser usada por uma nova sessão de IA sem depender da conversa anterior.

Esse prompt não transforma automaticamente qualquer chatbot em um agente autônomo. O objetivo é outro: criar uma memória operacional mais organizada para trabalhos que atravessam várias sessões.

---

O que acontece quando o agente esquece o que estava fazendo?

Esse problema aparece de maneira ainda mais clara nos experimentos da Anthropic.

Em trabalhos de longa duração, uma sessão pode chegar ao limite de contexto no meio de uma implementação. Quando uma nova sessão começa, o agente pode encontrar um projeto parcialmente modificado e não saber exatamente o que aconteceu.

Isso cria um efeito curioso.

A IA parece inteligente durante uma sessão, mas pode parecer perdida quando começa outra.

O problema não necessariamente está no modelo.

Está na transferência de estado.

A Anthropic passou a recomendar uma estrutura com um agente inicializador, um arquivo de progresso e agentes subsequentes responsáveis por fazer avanços incrementais e deixar o ambiente em uma condição limpa ao terminar.

É uma ideia muito parecida com o trabalho de uma equipe humana.

Imagine contratar uma pessoa para continuar um projeto que outra pessoa abandonou ontem.

Você não entregaria apenas uma pasta com milhares de arquivos.

Provavelmente daria:

o objetivo + o estado atual + as decisões + o que já foi tentado + o que deve acontecer agora.

É exatamente essa transferência de conhecimento que os agentes precisam.

---

Prompt para manter um arquivo de progresso

Você pode usar algo assim ao final de cada sessão:

Antes de encerrar esta sessão, atualize o estado do projeto.

Crie ou atualize um arquivo chamado PROGRESSO.md com:

## Objetivo atual
Explique em poucas linhas o que estamos tentando alcançar.

## Concluído
Liste apenas as tarefas realmente concluídas e verificadas.

## Em andamento
Liste o que começou, mas ainda não foi finalizado.

## Próxima ação
Defina a próxima tarefa concreta que outro agente deve executar.

## Decisões
Registre decisões que não devem ser revertidas sem uma nova avaliação.

## Tentativas que falharam
Explique o que foi tentado, por que não funcionou e qual alternativa foi escolhida.

## Problemas conhecidos
Liste bugs, limitações ou dúvidas ainda abertas.

## Critério de conclusão
Explique objetivamente o que precisa ser verdadeiro para considerar esta etapa concluída.

Escreva o arquivo para que uma nova sessão de IA consiga continuar o trabalho sem depender desta conversa.
Não inclua informações irrelevantes apenas para aumentar o histórico.

O detalhe mais importante está na última frase.

Não transforme memória em diário.

Memória útil é aquela que ajuda a tomar a próxima decisão.

---

O agente não precisa de mais contexto. Precisa do contexto certo.

Essa talvez seja a principal lição para quem está aprendendo a trabalhar com IA agentiva.

Existe uma tendência natural de acreditar que um agente ficará melhor quanto mais informações receber.

Nem sempre.

Imagine alguém chegando para trabalhar em uma empresa e recebendo 2 mil páginas de documentação antes de receber uma tarefa.

Isso pode parecer extremamente completo.

Também pode ser extremamente inútil.

O agente precisa saber qual informação importa agora.

A OpenAI passou a organizar o repositório como uma espécie de sistema de conhecimento. O AGENTS.md serve como entrada, enquanto documentos específicos carregam detalhes conforme a tarefa exige. A empresa também automatizou verificações para detectar documentação desatualizada e abriu pull requests para corrigir esse material.

Esse ponto é especialmente interessante porque cria uma conexão entre documentação e execução.

A documentação deixa de ser algo produzido apenas para humanos.

Ela passa a ser uma interface para agentes.

Se uma decisão arquitetural existe apenas em uma conversa antiga do Slack, o agente pode não conhecê-la.

Se uma regra existe apenas na cabeça de um engenheiro, o agente não consegue aplicá-la.

Se uma restrição está escrita no código, em um teste ou em um linter, ela pode ser aplicada automaticamente.

Isso leva a uma conclusão importante:

Para um agente, aquilo que não está acessível ou verificável no ambiente praticamente não existe.

---

Prompt para transformar uma documentação bagunçada em um mapa

Analise toda a documentação abaixo e NÃO tente memorizar tudo.

Seu trabalho é criar um MAPA DE CONHECIMENTO.

Organize os materiais nas categorias:

1. Arquitetura
2. Regras permanentes
3. Estado atual
4. Decisões
5. Produto
6. Operação
7. Testes e qualidade
8. Segurança
9. Histórico
10. Referências externas

Para cada documento, informe:

- nome;
- finalidade;
- quando deve ser consultado;
- se contém informação atual ou histórica;
- quais outros documentos dependem dele.

Depois, crie um índice curto que possa ser colocado no início de uma sessão de agente.

O índice deve apontar para as fontes corretas sem reproduzir o conteúdo delas.

Priorize navegação e relevância.
Não transforme o índice em uma nova documentação gigantesca.

---

A próxima fronteira é fazer a IA enxergar o próprio trabalho

Há outra parte do experimento da OpenAI que merece atenção.

Quando os agentes começaram a produzir código em velocidade muito alta, o problema deixou de ser simplesmente gerar software.

O gargalo passou a ser verificar o software produzido.

Se uma pessoa precisa revisar cada alteração manualmente, existe um limite físico para a quantidade de trabalho que pode ser supervisionada.

A equipe então passou a tornar o próprio aplicativo mais legível para os agentes.

O Codex recebeu acesso a instâncias isoladas do aplicativo, integração com o Chrome DevTools Protocol, snapshots do DOM, capturas de tela e ferramentas de navegação. Também passou a consultar logs e métricas.

Com isso, o agente não precisava apenas escrever código.

Ele podia executar a aplicação, observar o comportamento, reproduzir um problema, implementar uma correção e verificar novamente.

A OpenAI relata que algumas execuções do Codex trabalharam por mais de seis horas em uma única tarefa, inclusive durante períodos em que os humanos estavam dormindo.

Esse é um detalhe que muda a conversa.

O agente deixa de ser apenas um gerador de código.

Ele começa a funcionar como um operador de um ambiente de desenvolvimento.

O ciclo começa a ficar assim:

Problema → investigação → implementação → execução → observação → teste → correção → revisão → PR

Quanto mais etapas desse ciclo podem ser realizadas pela própria IA, menos o humano precisa atuar como operador manual.

Mas isso não significa que a supervisão deixa de existir.

Ela sobe de nível.

---

Agentes precisam de limites tão claros quanto precisam de liberdade

Existe um paradoxo no trabalho com agentes.

Para serem úteis, eles precisam de autonomia.

Para não destruírem o projeto, precisam de limites.

A solução encontrada pela OpenAI foi estabelecer invariantes arquiteturais e fazer com que essas regras fossem verificadas mecanicamente.

Em vez de dizer ao agente exatamente como escrever cada função, a equipe estabeleceu limites sobre como as partes do sistema poderiam se relacionar. A arquitetura foi organizada em camadas com dependências permitidas e regras aplicadas por linters e testes estruturais.

Isso é muito diferente de microgerenciar.

A regra é: controle o limite, não cada movimento.

Um exemplo simples: Você pode dizer que uma determinada camada do sistema não pode acessar diretamente outra camada.

Não precisa dizer exatamente como o agente deve implementar cada função.

Essa combinação permite liberdade dentro de uma estrutura previsível.

A própria OpenAI relata que, conforme a quantidade de código aumentava, passou a codificar princípios de qualidade diretamente no repositório e criou processos recorrentes de limpeza para combater o que chamou de “entropia” do código.

Isso é especialmente importante porque agentes tendem a reproduzir padrões existentes.

Se um projeto contém uma solução ruim, o agente pode copiar essa solução dezenas ou centenas de vezes.

Portanto, um agente não apenas produz código. Ele também amplifica a cultura técnica existente no ambiente.

Se a arquitetura é boa, isso pode ser excelente.

Se a arquitetura é ruim, o problema pode crescer muito mais rápido.

---

Prompt para pedir uma auditoria de qualidade a um agente

Atue como um agente de manutenção de longo prazo.

Analise o projeto procurando sinais de degradação arquitetural.

Não altere o código imediatamente.

Primeiro produza um relatório contendo:

1. Padrões inconsistentes encontrados.
2. Código duplicado.
3. Abstrações que estão sendo utilizadas de forma incorreta.
4. Violações das regras arquiteturais.
5. Documentação desatualizada.
6. Testes ausentes ou frágeis.
7. Problemas de observabilidade.
8. Dívida técnica que pode se espalhar se não for corrigida.

Para cada problema, informe:

- evidência;
- impacto;
- prioridade;
- quantidade aproximada de arquivos afetados;
- risco de propagação;
- correção recomendada.

Não faça alterações até que o relatório esteja concluído.

Depois, proponha uma sequência de correções pequenas e independentes, priorizando aquelas que impedem que o mesmo problema apareça novamente.

---

O que tudo isso significa para quem não trabalha com programação?

É aqui que o conceito fica ainda mais interessante.

Você não precisa ter um repositório com um milhão de linhas para aplicar a ideia.

Imagine um profissional usando IA para conduzir uma pesquisa durante duas semanas.

Na primeira conversa, ele reúne fontes.

Na segunda, organiza dados.

Na terceira, percebe que uma hipótese inicial estava errada.

Na quarta, precisa produzir um relatório.

Se ele simplesmente continuar acumulando tudo na mesma conversa, o contexto começa a ficar confuso.

Uma alternativa é manter:

INSTRUCOES.md

Regras permanentes sobre o trabalho.

ESTADO.md

O que já foi descoberto e o que precisa acontecer agora.

FONTES.md

Mapa das pesquisas e documentos disponíveis.

HISTORICO.md

Decisões e hipóteses descartadas.

O princípio é exatamente o mesmo.

E isso pode ser usado para pesquisa, marketing, análise de dados, planejamento de produto, criação de conteúdo, desenvolvimento de software, automação e até projetos pessoais complexos.

---

Uma estrutura de projeto para quem quer começar hoje

Se você quiser experimentar a abordagem sem construir uma infraestrutura sofisticada, comece pequeno.

/projeto
│
├── INSTRUCOES.md
├── ESTADO.md
├── FONTES.md
├── HISTORICO.md
│
├── /documentacao
│   ├── arquitetura.md
│   ├── produto.md
│   └── requisitos.md
│
├── /planos
│   ├── atual.md
│   └── concluidos/
│
└── /resultados
    ├── pesquisas/
    └── entregas/

O princípio é simples:

INSTRUCOES.md diz como trabalhar.

ESTADO.md diz onde estamos.

FONTES.md diz onde procurar.

HISTORICO.md explica como chegamos aqui.

Essa divisão reduz uma das maiores fontes de confusão em projetos com agentes: misturar o que é permanente com o que é temporário.

---

O prompt mestre para iniciar um projeto de longa duração

Você será o agente responsável por executar este projeto ao longo de múltiplas sessões.

Antes de realizar qualquer tarefa:

1. Leia INSTRUCOES.md.
2. Leia ESTADO.md.
3. Consulte FONTES.md.
4. Consulte documentos adicionais somente quando forem relevantes para a tarefa atual.
5. Não trate informações históricas como instruções atuais.
6. Se encontrar uma contradição, priorize o ESTADO.md e sinalize o conflito.
7. Não invente informações ausentes.
8. Quando uma decisão importante for tomada, registre-a.
9. Ao concluir uma etapa, atualize ESTADO.md.
10. Ao abandonar uma abordagem, registre o motivo em HISTORICO.md.

Sua prioridade é produzir progresso verificável, não simplesmente gerar texto ou código.

Antes de executar uma ação importante, explique:

- o objetivo;
- o que você entendeu;
- quais arquivos ou fontes pretende consultar;
- qual será o resultado esperado.

Ao terminar, informe:

- o que foi concluído;
- o que foi validado;
- o que ainda está pendente;
- qual deve ser a próxima ação.

Nunca considere o projeto concluído apenas porque uma tarefa foi executada.
Considere uma etapa concluída somente quando o resultado puder ser verificado.

Esse tipo de prompt funciona melhor quando combinado com arquivos reais de estado e documentação. Um prompt sozinho não resolve o problema de memória.

---

A grande mudança: de prompt engineering para context engineering

Talvez seja essa a expressão mais importante para guardar.

Durante o primeiro ciclo da IA generativa, grande parte da discussão girava em torno de prompt engineering.

Como formular a pergunta?

Como definir o papel do modelo?

Como pedir uma resposta melhor?

Como incluir exemplos?

Isso continua sendo importante.

Mas agentes de longa duração adicionam outra camada.

Context engineering.

A questão deixa de ser apenas:

“Qual é o melhor prompt?”

E passa a ser:

“Qual é o melhor ambiente de informação para que o agente consiga tomar boas decisões continuamente?”

Essa mudança aparece tanto no trabalho da OpenAI quanto nos experimentos da Anthropic com agentes que precisam sobreviver a múltiplas sessões. A Anthropic também observa que agentes de longa duração precisam de uma forma explícita de manter estado e fazer progresso incremental, justamente porque uma sessão isolada não consegue carregar indefinidamente todo o histórico necessário.

Isso ajuda a explicar por que alguns agentes parecem extraordinariamente competentes em um projeto e surpreendentemente ruins em outro.

Às vezes, o problema não é o modelo.

É o ambiente.

---

O que a experiência da OpenAI realmente ensina

É tentador olhar para os números e concluir que o futuro do desenvolvimento de software será simplesmente uma IA escrevendo milhões de linhas de código.

Essa seria provavelmente a interpretação menos interessante.

O verdadeiro avanço está em outro lugar.

A OpenAI descobriu que, quando o custo de gerar código cai drasticamente, outros problemas ficam mais importantes.

Como organizar conhecimento?

Como verificar resultados?

Como manter arquitetura?

Como impedir que erros se espalhem?

Como transmitir decisões entre sessões?

Como saber quando o agente deve continuar e quando precisa chamar um humano?

Como transformar uma preferência humana em uma regra que possa ser aplicada automaticamente?

Essas perguntas são muito maiores do que programação.

Elas fazem parte de uma nova maneira de trabalhar com inteligência artificial.

O caso da OpenAI também precisa ser interpretado com cuidado. A própria empresa ressalta que o nível de autonomia alcançado depende fortemente das ferramentas e da estrutura específicas daquele repositório e não deve ser considerado automaticamente reproduzível em qualquer projeto.

A experiência, portanto, não significa que qualquer pessoa poderá pedir “construa um milhão de linhas” e voltar algumas horas depois com um produto pronto.

Significa que estamos aprendendo quais condições tornam esse tipo de autonomia possível.

E uma dessas condições parece cada vez mais clara:

agentes melhores precisam de ambientes melhores.

---

Para levar para a prática

Se você quiser começar a experimentar essa abordagem hoje, não comece tentando construir um sistema complexo de agentes.

Comece com quatro arquivos.

INSTRUCOES.md

O que nunca deve mudar sem uma decisão consciente.

ESTADO.md

O que está acontecendo agora.

FONTES.md

Onde estão as informações necessárias.

HISTORICO.md

O que aconteceu antes e quais caminhos não devem ser repetidos.

Depois, estabeleça uma regra simples:

Toda sessão deve terminar deixando o projeto em um estado que outra sessão consiga entender.

Essa regra sozinha já muda bastante a forma de trabalhar.

Em vez de depender de uma conversa interminável, você começa a construir uma espécie de memória operacional externa.

E talvez seja esse o passo mais importante para sair do uso casual da IA e começar a trabalhar de verdade com agentes.

O experimento de um milhão de linhas da OpenAI mostra que o futuro da engenharia assistida por IA não depende apenas de modelos que sabem programar.

Depende de sistemas capazes de lembrar, verificar, navegar, corrigir, aprender com falhas e continuar de onde pararam.

O código pode ser gerado em segundos.

O desafio agora é construir o ambiente que ensina a máquina o que fazer com ele.

---

Checklist do Learning

• Separar instruções permanentes do estado atual.
• Criar um arquivo de progresso para projetos longos.
• Manter um mapa das fontes e documentos.
• Registrar decisões importantes.
• Registrar abordagens que falharam.
• Criar critérios objetivos para validar resultados.
• Automatizar testes sempre que possível.
• Transformar regras importantes em verificações mecânicas.
• Revisar periodicamente documentação e arquitetura.
• Fazer o agente terminar cada sessão deixando o projeto pronto para a próxima.

---

Fontes consultadas

A análise foi complementada principalmente com a publicação oficial da OpenAI sobre o experimento de engenharia com Codex e com materiais da Anthropic sobre agentes de longa duração, memória entre sessões e arquivos de progresso.

A OpenAI informa que o experimento começou em agosto de 2025 e, cinco meses depois, havia chegado a aproximadamente um milhão de linhas e 1.500 pull requests. A empresa também relata execuções individuais superiores a seis horas e descreve a evolução do AGENTS.md de um manual para um índice de conhecimento.

A Anthropic, por sua vez, documenta uma abordagem com arquivo de progresso para transportar estado entre sessões e destaca a necessidade de agentes fazerem avanços incrementais, deixarem o ambiente em condições limpas e registrarem o que foi feito e o que falhou.