40 Engenheiros, 1 PM: O Que a Equipe Codex da OpenAI Revela Sobre Organizações IA-Nativas

Gregor Ojstersek publicou uma entrevista com Thibault Sottiaux, líder de engenharia da equipe Codex na OpenAI. Os números que chamaram atenção: 40 engenheiros, 1 product manager, 2 designers. Essa proporção — 40:1 — seria negligência organizacional em qualquer equipe de engenharia tradicional.

Funciona. Mas não pelo motivo que a maioria assume.

A Proporção Não É a História

A reação instintiva a “40 engenheiros, 1 PM” é que a OpenAI contrata engenheiros excepcionais que não precisam de coordenação. Isso é parcialmente verdade — a compensação e a marca atraem talentos extraordinários. Mas densidade de talento sozinha não explica como uma equipe funciona com proporção 40:1.

A explicação está no que substitui a camada de coordenação. Durante um bug bash recente, o único PM triou mais de 100 issues em uma hora usando o Codex. A maioria das correções foi enviada em menos de 24 horas. O PM não digitou mais rápido nem trabalhou mais. A IA comprimiu o ciclo triagem-priorização-comunicação de dias para minutos.

“Assistir ele trabalhar é surreal, está em outro nível,” diz Sottiaux sobre o fluxo de trabalho do PM com Codex.

Quando você remove o gargalo de processamento de informação da função de PM, a proporção muda. O PM não coordena 40 engenheiros manualmente. O PM define prioridades, e a instrumentação propaga essas prioridades através de triagem automatizada, revisão automatizada e skills codificadas.

Centenas de Skills São a Infraestrutura

O detalhe operacionalmente mais significativo da entrevista não é o tamanho da equipe nem a velocidade de entrega. São as “centenas de skills customizadas” que a equipe construiu.

Skills, na terminologia do Codex, são conjuntos de instruções reutilizáveis que codificam melhores práticas para tarefas específicas. A equipe Codex construiu skills para executar QA, verificar funcionalidades, validar builds, aplicar padrões de revisão de código, respeitar fronteiras de módulos e manter correção semântica.

Isso é conhecimento organizacional tornado executável. Cada vez que um engenheiro sênior descobre a forma correta de fazer algo — revisar um PR, validar um deploy, verificar um refactoring — ele codifica como uma skill. Essa skill então se aplica a toda instância subsequente daquela tarefa, executada por qualquer membro da equipe ou pelo próprio Codex.

O equivalente tradicional é documentação. A diferença é que documentação exige que alguém a leia e escolha segui-la. Uma skill executa automaticamente. A distância entre “temos uma melhor prática” e “aplicamos uma melhor prática” cai a zero.

É isso que operar IA realmente significa. Não um modelo que escreve código. Uma infraestrutura de decisões codificadas que se compõe ao longo do tempo.

Entrega no Primeiro Dia e a Inversão do Onboarding

A equipe Codex tem uma norma cultural de entregar na primeira dia. Não na primeira semana — no primeiro dia. Novos contratados chegam sem contexto prévio, e a aspiração é que entreguem funcionalidades significativas antes do fim do expediente.

Funciona por causa de uma inversão no onboarding. O onboarding tradicional pressupõe que o novo contratado deve absorver contexto antes de ser produtivo. O modelo Codex pressupõe que o novo contratado pode ser produtivo imediatamente porque o contexto está disponível através da ferramenta.

O Codex configura o ambiente do engenheiro. Explica o codebase, projetos existentes e estrutura de funcionalidades. Age como o que Sottiaux chama de “um mentor de engenharia altamente qualificado” — não um documento para ler, mas um sistema interativo que responde perguntas em tempo real.

As centenas de skills customizadas amplificam isso. Um novo engenheiro não começa com um Codex em branco. Começa com uma versão “atualizada” pré-carregada com o conhecimento acumulado da equipe. O documento de onboarding está morto. O agente de onboarding está vivo.

A pergunta para outras organizações não é se conseguem replicar entrega no primeiro dia. É se conseguem identificar que conhecimento organizacional precisariam codificar para torná-la possível.

Sub-Agentes como Infraestrutura de Qualidade

A equipe usa múltiplos sub-agentes para revisar pull requests antes de qualquer humano vê-los. Engenheiros executam um comando local de “revisão”, e múltiplos agentes automatizados examinam o código de diferentes ângulos — estrutura, semântica, fronteiras de módulos, cobertura de testes.

É o mesmo padrão que vemos no sistema Signals da Factory: infraestrutura automatizada de qualidade que opera continuamente e em escala. A diferença é que a Factory monitora sessões de agentes para fricção do usuário, enquanto a OpenAI monitora código para padrões de engenharia. O padrão arquitetural é idêntico: múltiplos validadores automatizados examinando o produto do trabalho antes do julgamento humano.

Sottiaux nota que esse processo “regularmente revela pequenos problemas e melhorias que teriam passado despercebidos.” A palavra-chave é “teriam.” Sem revisão automatizada em escala, esses problemas se acumulariam como dívida técnica. Os sub-agentes comprimem o ciclo de feedback de “descoberto durante incidente” para “capturado antes do merge.”

A Comparação com Bell Labs e Seus Limites

Sottiaux descreve a estrutura da equipe como “mais próxima de uma versão moderna do Bell Labs.” A comparação é instrutiva no que acerta e no que erra.

O que acerta: equipes pequenas de 2-3 pessoas com ownership ponta a ponta. Ideação bottom-up onde as melhores ideias vêm de contribuidores individuais, não de comitês de produto. Alta autonomia com reuniões mínimas. Liderança “extremamente disponível” para que decisões aconteçam em minutos.

O que erra: o Bell Labs operava em horizontes de pesquisa de múltiplos anos. A equipe Codex entrega diariamente, às vezes várias vezes por dia. Pesquisadores do Bell Labs exploravam ciência fundamental. A equipe Codex constrói produtos para uso imediato. A autonomia é similar; o horizonte temporal é oposto.

A resolução é que a IA comprime o ciclo de experimentação. “O custo de cometer erros é muito menor porque o Codex está sempre disponível,” explica Sottiaux. Quando experimentação é barata, você pode ter autonomia estilo Bell Labs com velocidade de iteração de startup.

O Que Não Pode Ser Replicado

Antes de tirar conclusões para outras organizações, as ressalvas importantes.

Primeiro, a OpenAI é a empresa de IA mais bem financiada do mundo usando seu próprio produto flagship. A equipe Codex construindo Codex com Codex é inerentemente circular. Seus números de produtividade não são transferíveis para equipes usando Codex em problemas diferentes.

Segundo, a equipe explicitamente reteve seu percentual de geração de código. A ausência desse dado significa que não podemos avaliar quanto da produtividade é atribuível à IA versus talento excepcional.

Terceiro, a entrevista contém zero casos de falha. Nenhuma menção ao que não funciona, onde sub-agentes produzem revisões ruins, ou quais tarefas ainda exigem trabalho inteiramente manual.

O Padrão Transferível

Remova as vantagens específicas da OpenAI e três padrões permanecem:

Conhecimento codificado se compõe. Skills customizadas criam um ativo de conhecimento que cresce com cada problema resolvido. Funciona em qualquer escala e com qualquer ferramenta de IA.

Infraestrutura automatizada de qualidade substitui coordenação. Quando revisão de código, QA e triagem são parcialmente automatizadas, você precisa de menos pessoas coordenando e mais pessoas construindo.

Disponibilidade de contexto substitui documentação. Quando um sistema de IA pode explicar o codebase, navegar projetos e aplicar práticas específicas da equipe, a barreira para produtividade cai. Onboarding vira conversa, não lição de casa.

A pergunta para sua organização não é “como nos tornamos a OpenAI?” É “quantas das nossas melhores práticas existem apenas na cabeça das pessoas, e o que aconteceria se as tornássemos executáveis?”