Time da OpenAI lançou um produto de um milhão de linhas sem nenhuma linha de código escrita por humano

A restrição que moldou tudo: nenhum código escrito manualmente

O primeiro commit chegou em um repositório vazio no final de agosto de 2025. Cinco meses depois, segundo o post, o repositório tem aproximadamente um milhão de linhas de código, e nenhuma delas foi digitada por um humano. Até o scaffold inicial — estrutura do repositório, configuração de CI, regras de formatação, setup de pacotes — foi gerado pelo Codex CLI rodando GPT-5, e o primeiro AGENTS.md, que diz aos agentes como trabalhar no repositório, foi escrito pelo próprio agente.

O time relata cerca de 1.500 pull requests mesclados, uma média de 3,5 PRs por engenheiro por dia, e um quadro que cresceu de três para sete engenheiros enquanto o throughput aumentava em vez de cair. O produto tem centenas de usuários internos e usuários avançados diários, então isso não é produção por produção.

A regra de 'nenhum código escrito manualmente' parece um golpe de efeito, mas o post é explícito: foi escolhida deliberadamente como um mecanismo de força. Se humanos não podem corrigir as coisas digitando, toda falha se torna uma pergunta sobre o ambiente em vez do código: qual capacidade está faltando, e como tornamos isso legível e aplicável para o agente?

Tornando a aplicação em execução legível para o agente

O gargalo que o time encontrou não foi a capacidade do Codex de escrever código — foi a capacidade humana de QA. A resposta deles foi dar ao agente acesso direto às coisas que um humano normalmente observaria. Eles fizeram o app inicializável por git worktree para que o Codex pudesse lançar sua própria instância a cada mudança, conectaram o Chrome DevTools Protocol ao runtime do agente, e construíram skills para snapshots do DOM, screenshots e navegação.

Fizeram o mesmo para observabilidade. Cada worktree recebe uma stack local efêmera de logs, métricas e traces que é desmontada quando a tarefa termina. Como o agente pode consultar logs com LogQL e métricas com PromQL, prompts como 'garanta que a inicialização do serviço leve menos de 800ms' ou 'nenhum span nessas quatro jornadas críticas do usuário deve passar de dois segundos' se tornam instruções executáveis, não aspirações.

Essa é a ideia central do post: como o autor coloca, do ponto de vista do agente, qualquer coisa que ele não consiga acessar no contexto praticamente não existe. Conhecimento em threads do Slack, Google Docs ou na cabeça das pessoas é invisível. Por isso o time trata um diretório docs/ estruturado como a fonte oficial de verdade e mantém o AGENTS.md com cerca de 100 linhas — um sumário, não uma enciclopédia — com um agente recorrente de 'jardinagem de documentação' que abre PRs de correção quando a documentação se distancia do comportamento real.

Arquitetura rígida como acelerador, não como freio

O time envolveu o código-base em restrições que a maioria das organizações posterga até ter centenas de engenheiros. Cada domínio de negócio é dividido em camadas fixas — Types, Config, Repo, Service, Runtime, UI — com dependências fluindo apenas para frente, e questões transversais como autenticação e telemetria forçadas a passar por uma única interface de Providers. Todo o resto é proibido e verificado mecanicamente por linters personalizados, que, claro, também são gerados pelo Codex.

O raciocínio inverte o trade-off usual. Limites rígidos parecem pedantes em um fluxo de trabalho humano; aqui, funcionam como multiplicadores, porque, uma vez que uma regra é codificada, ela se aplica em tudo de uma vez. As mensagens de erro de lint personalizadas até injetam instruções de correção de volta no contexto do agente, então uma violação se torna um loop autocorretivo em vez de um PR bloqueado.

É o tipo de arquitetura que normalmente se posterga até ter centenas de engenheiros. Com agentes de código, é um pré-requisito precoce: as restrições são o que permite velocidade sem decadência ou desvio arquitetural.Montana Labs

Vale notar que o time aplica limites de forma centralizada, mas deixa a implementação livre. Eles exigem o parsing dos formatos de dados na fronteira, mas não determinam uma biblioteca específica — o modelo gravitou naturalmente para o Zod. Também optaram por reimplementar pequenos utilitários, como um helper de concorrência, em vez de importar um pacote genérico, porque uma versão dentro do próprio repositório é totalmente inspecionável e integrada à instrumentação deles. Tecnologia 'chata' vence aqui porque é estável, composável e bem representada nos dados de treinamento.

Entropia é o custo recorrente, e a limpeza agora é automatizada

A autonomia total criou um novo tipo de falha: o Codex replica fielmente os padrões existentes, incluindo os ruins, e o código-base vai se desviando. Inicialmente, o time gastava toda sexta-feira — um quinto da semana — limpando o que chamam de 'AI slop' (lixo gerado por IA). Isso obviamente não escalava.

A solução foi codificar 'princípios de ouro' bem definidos diretamente no repositório e rodar tarefas em segundo plano do Codex em uma cadência regular para escanear desvios, atualizar notas de qualidade e abrir PRs de refatoração direcionados — a maioria revisável em menos de um minuto e mesclada automaticamente. Eles enxergam dívida técnica como um empréstimo com juros altos, melhor pago em pequenas parcelas diárias. O bom senso humano é capturado uma vez e depois aplicado continuamente em cada linha.

A filosofia de merge muda de acordo. Os bloqueios são mínimos, os PRs têm vida curta, e falhas instáveis em testes são tratadas com novas execuções em vez de bloqueio indefinido. O time admite abertamente que isso seria irresponsável em um ambiente de baixo throughput; funciona só porque as correções são baratas e esperar é o que sai caro.

A lição específica: o harness é o produto que os engenheiros constroem agora

A OpenAI é cuidadosa ao limitar a afirmação. Eles dizem que a autonomia ponta a ponta em features — reproduzir um bug, gravar um vídeo da falha, corrigi-la, validar rodando o app, gravar um vídeo da resolução, abrir e mesclar o PR — 'depende fortemente da estrutura e das ferramentas específicas deste repositório e não deve ser assumida como generalizável sem investimento semelhante.' Também admitem que ainda não sabem como a coerência arquitetural se sustenta ao longo dos anos em um sistema totalmente gerado por agentes.

O aprendizado que vale levar para outros contextos não é o milhão de linhas. É que o esforço de engenharia desse time se deslocou quase inteiramente para construir o ambiente em que o agente opera: instâncias de app por worktree, observabilidade efêmera, documentação estruturada e versionada, camadas aplicadas mecanicamente e mensagens de lint autocorretivas. Toda vez que o Codex tinha dificuldade, a resposta era adicionar uma ferramenta, guardrail ou documento que faltava — e fazer o próprio Codex escrever essa correção.

Para qualquer time avaliando o desenvolvimento agent-first, o sinal de custo real nesse post está na estrutura de suporte, não no prompting. O gargalo era a atenção humana, e tudo que construíram foi uma tentativa de gastar menos dela. A pergunta que vale levar adiante é quanto desse investimento em harness um time menor consegue pagar antes que o throughput comece a compensar.