A equipa Codex da OpenAI lançou um produto com um milhão de linhas sem uma única linha de código escrita por humanos

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

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

A equipa reporta cerca de 1500 pull requests integrados, uma média de 3,5 PRs por engenheiro por dia, e um efetivo que cresceu de três para sete engenheiros enquanto o throughput aumentou em vez de diminuir. O produto tem centenas de utilizadores internos e utilizadores intensivos diários, portanto não se trata de produção pela produção.

A regra de 'nenhum código escrito manualmente' parece um golpe de efeito, mas o artigo é explícito ao afirmar que foi escolhida deliberadamente como mecanismo de força. Se os humanos não podem corrigir problemas escrevendo código, cada falha transforma-se numa questão sobre o ambiente e não sobre o código: que capacidade está em falta, e como a tornamos legível e verificável para o agente?

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

O estrangulamento com que a equipa se debateu não foi a capacidade do Codex para escrever código — foi a capacidade humana de QA. A resposta foi dar ao agente acesso direto às coisas que um humano normalmente observaria. Tornaram a aplicação arrancável por cada git worktree, para que o Codex pudesse lançar a sua própria instância por cada alteração, integraram o Chrome DevTools Protocol no runtime do agente, e construíram competências para captura de estado do DOM, screenshots e navegação.

Fizeram o mesmo para a observabilidade. Cada worktree recebe uma stack local efémera de logs, métricas e traces que é desmontada quando a tarefa termina. Como o agente consegue consultar logs com LogQL e métricas com PromQL, instruções como 'garantir que o arranque do serviço ocorre em menos de 800ms' ou 'nenhum span nestas quatro jornadas críticas do utilizador excede dois segundos' tornam-se instruções exequíveis em vez de meras aspirações.

Esta é a ideia estrutural do artigo: como o autor coloca, do ponto de vista do agente, tudo o que este não conseguir aceder no contexto essencialmente não existe. O conhecimento em threads do Slack, em Google Docs ou na cabeça das pessoas é invisível. Por isso a equipa trata um diretório docs/ estruturado como o sistema de registo oficial e mantém o AGENTS.md com cerca de 100 linhas — um índice, 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 desvia do comportamento real.

Arquitetura rígida como facilitador de velocidade, não como travão

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

O raciocínio inverte a habitual troca de compromissos. Fronteiras rígidas parecem pedantes num fluxo de trabalho humano; aqui funcionam como multiplicadores porque, uma vez codificada, uma regra aplica-se em todo o lado simultaneamente. As mensagens de erro dos linters personalizados chegam a injetar instruções de correção diretamente no contexto do agente, tornando uma violação um ciclo autocorretivo em vez de um PR bloqueado.

Este é o tipo de arquitetura que normalmente se adia até se ter centenas de engenheiros. Com agentes de programação, é um pré-requisito precoce: são as restrições que permitem velocidade sem degradação ou deriva arquitetónica.Montana Labs

É de notar que a equipa impõe fronteiras de forma centralizada mas deixa a implementação livre. Exigem a validação da estrutura dos dados na fronteira, mas não impõem uma biblioteca específica — o modelo gravitou naturalmente para o Zod. Também optaram por reimplementar pequenos utilitários, como um auxiliar de concorrência, em vez de recorrer a um pacote genérico, porque uma versão interna ao repositório é totalmente inspecionável e integrada com a sua instrumentação. A tecnologia 'aborrecida' vence aqui porque é estável, composável e bem representada nos dados de treino.

A entropia é o custo recorrente, e a limpeza está agora automatizada

A autonomia total criou um novo modo de falha: o Codex replica fielmente os padrões existentes, incluindo os maus, pelo que a base de código vai derivando. A equipa passou inicialmente todas as sextas-feiras — um quinto da semana — a limpar aquilo a que chamam 'AI slop'. Isso, obviamente, não era escalável.

A solução foi codificar diretamente no repositório 'princípios de ouro' bem definidos e correr tarefas Codex em segundo plano com regularidade para detetar desvios, atualizar classificações de qualidade e abrir PRs de refatoração direcionados — a maioria revisável em menos de um minuto e integrada automaticamente. Encaram a dívida técnica como um empréstimo com juros elevados que é melhor pagar em pequenos incrementos diários. O gosto humano é capturado uma vez e depois aplicado continuamente a cada linha.

A filosofia de integração muda em conformidade. As barreiras bloqueantes são mínimas, os PRs têm vida curta, e as falhas instáveis em testes são resolvidas com execuções de repetição em vez de bloqueio indefinido. A equipa admite abertamente que isto seria irresponsável num ambiente de baixo throughput; só funciona porque as correções são baratas e esperar é que é dispendioso.

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

A OpenAI tem o cuidado de delimitar a afirmação. Dizem que a autonomia ponta a ponta de funcionalidades — reproduzir um bug, gravar um vídeo da falha, corrigi-lo, validar através da utilização da aplicação, gravar um vídeo da resolução, abrir e integrar o PR — 'depende fortemente da estrutura e das ferramentas específicas deste repositório e não deve ser assumida como generalizável sem um investimento semelhante'. Também admitem que ainda não sabem como a coerência arquitetónica se mantém ao longo de anos num sistema totalmente gerado por agentes.

A lição transferível não é o milhão de linhas. É que o esforço de engenharia desta equipa se deslocou quase inteiramente para a construção do ambiente em que o agente opera: instâncias de aplicação por worktree, observabilidade efémera, documentação estruturada e versionada, camadas aplicadas mecanicamente e mensagens de linting autocorretivas. Cada vez que o Codex tinha dificuldades, a resposta era adicionar uma ferramenta, salvaguarda ou documento em falta — e fazer com que fosse o próprio Codex a escrever essa correção.

Para qualquer equipa que esteja a ponderar o desenvolvimento centrado em agentes, o verdadeiro sinal de custo neste artigo é o scaffolding, não o prompting. O estrangulamento era a atenção humana, e tudo o que construíram foi uma tentativa de a gastar menos. A questão que vale a pena levar em conta é quanto desse investimento em harness uma equipa mais pequena pode suportar antes que o throughput o compense.