Reflexões sobre a OpenAI · iamferraz

Pessoal, acabei de ler um depoimento muito interessante de alguém que deixou a OpenAI.

O relato mostra, de forma bem transparente, que mesmo uma empresa vista como referência mundial em inovação também enfrenta desafios internos — afinal, nenhuma organização é perfeita.

Achei curioso como a OpenAI cresceu de forma exponencial apostando em uma stack relativamente simples, sem tanto “gueri-gueri”, mas com muita velocidade, pragmatismo e foco no que realmente gera impacto.

Vale a leitura para quem gosta de refletir sobre cultura organizacional, crescimento acelerado e os bastidores de empresas de tecnologia.

Segue o depoimento orignal https://calv.info/openai-reflections

Traduzi pra facilitar

Saí da OpenAI há três semanas. Entrei na empresa em maio de 2024.
Quero compartilhar minhas reflexões porque há muita fumaça e barulho sobre o que a OpenAI está fazendo, mas poucos relatos em primeira mão sobre como realmente é a cultura de se trabalhar lá.

Nabeel Qureshi tem um post incrível chamado Reflections on Palantir, no qual ele reflete sobre o que tornava a Palantir especial. Quis fazer o mesmo para a OpenAI, enquanto isso ainda está fresco na minha memória. Não há segredos comerciais aqui — são apenas reflexões sobre esta versão atual de uma das organizações mais fascinantes da história, em um momento extremamente interessante.

Para começar: não houve nenhum drama pessoal na minha decisão de sair — na verdade, eu estava profundamente dividido sobre isso. É difícil passar de fundador da sua própria iniciativa para empregado em uma organização com 3.000 pessoas. Agora, sinto vontade de começar algo do zero.

É totalmente possível que a qualidade do trabalho me atraia de volta. É difícil imaginar construir algo tão impactante quanto a AGI, e os LLMs (modelos de linguagem extensiva) são, sem dúvida, a inovação tecnológica da década. Sinto-me com sorte por ter visto algumas dessas evoluções de perto e por ter participado do lançamento do Codex.

Obviamente, estas não são as opiniões da empresa — como observações, são minhas. A OpenAI é um lugar grande, e esta é a minha pequena visão sobre ela.

Cultura

A primeira coisa a saber sobre a OpenAI é o quão rápido ela cresceu. Quando entrei, a empresa tinha um pouco mais de 1.000 pessoas. Um ano depois, ultrapassou 3.000, e eu estava entre os 30% com mais tempo de casa. Quase todos na liderança estão fazendo um trabalho drasticamente diferente do que faziam há 2–3 anos.

Claro que tudo dá errado quando se escala tão rápido: comunicação interna, estruturas hierárquicas, lançamento de produtos, gestão de pessoas, processos de contratação etc. As equipes variam muito em cultura: algumas estão em sprint o tempo todo, outras lidam com grandes rotinas, e outras mantêm um ritmo mais constante. Não existe uma única experiência OpenAI; pesquisa, aplicação e go-to-market operam em horizontes de tempo bem distintos.

Algo incomum na OpenAI é que tudo, e realmente tudo, funciona via Slack. Não existe e-mail. Recebi talvez umas 10 mensagens por e-mail em todo o tempo que estive lá. Se você não for organizado, achará isso incrivelmente dispersivo. Mas, se souber gerenciar seus canais e notificações, pode até funcionar bem.

A OpenAI é incrivelmente bottoms-up, especialmente em pesquisa. Quando entrei, perguntei sobre o roadmap para o próximo trimestre. A resposta que recebi foi: “isso não existe” (embora agora exista). Boas ideias podem vir de qualquer lugar, e muitas vezes não fica claro quais serão promissoras. Em vez de um grande “plano mestre”, o progresso é iterativo e emerge conforme novas pesquisas surgem.

Graças a essa cultura bottoms-up, a OpenAI também é muito meritocrática. Historicamente, os líderes da empresa eram promovidos com base na capacidade de gerar boas ideias e executá-las. Muitos líderes extremamente competentes não eram bons em apresentações em all-hands ou em manobras políticas — isso importa menos na OpenAI porque as melhores ideias tendem a vencer.

Há uma forte predisposição para agir (bias to action), ou seja, você pode simplesmente iniciar algo. Não era incomum equipes similares, mas independentes, convergirem para ideias semelhantes. Comecei a trabalhar num esforço paralelo (interno) semelhante aos “ChatGPT Connectors”. Devia haver de 3 a 4 protótipos diferentes do Codex antes de decidirem lançar. Essas iniciativas geralmente eram conduzidas por um pequeno grupo de pessoas sem pedir permissão. Equipes formam-se rapidamente ao redor do que mostra resultado.

Andrey (líder do Codex) costumava dizer que pesquisadores deveriam se enxergar como “mini-executivos”. Há uma forte inclinação a trabalhar em sua própria ideia e ver no que dá. Uma consequência é que a maioria da pesquisa acontece atraindo um pesquisador até um problema específico. Se algo é considerado entediante ou “resolvido”, provavelmente não será revisitado.

Bons gerentes de pesquisa são extremamente impactantes, mas também muito limitados. Os melhores conseguem conectar pontos entre vários esforços de pesquisa e reunir algo maior para treinar modelos. O mesmo vale para excelentes PMs.

Os gerentes de engenharia (EMs) do ChatGPT com quem trabalhei (Akshay, Rizzo, Sulman) foram alguns dos gestores mais incríveis que já vi. Parecia que tinham visto de tudo. A maioria era relativamente hands-off, mas contratava bons profissionais e trabalhava para garantir que tivessem condições de vencer.

A OpenAI muda de direção em um piscar de olhos. Isso era algo valorizado desde meus tempos no Segment — é muito melhor tomar a decisão certa conforme novas informações chegam do que insistir num plano só por já existir. É notável que uma empresa do tamanho da OpenAI ainda mantenha esse espírito — o Google claramente não.

Há enorme escrutínio público sobre a empresa. Vindo de um background B2B/enterprise, isso me chocou. Frequentemente via notícias impulsionadas pela imprensa antes mesmo de serem anunciadas internamente. Ao dizer que trabalho na OpenAI, as pessoas já tinham uma opinião formada sobre a empresa. Alguns perfis no Twitter até usam bots automáticos para identificar novos lançamentos.

Isso torna a OpenAI um lugar muito secreto. Não podia contar em detalhes no que estava trabalhando. Há vários workspaces no Slack com permissões diferentes. Números de receita e gastos são bastante protegidos.

Também é um lugar mais sério do que você imaginar. Isso se deve, em parte, aos altos riscos. Por um lado, há o objetivo de construir AGI — o que implica em fazer muitas coisas corretamente. Por outro, você está construindo um produto apoiado por centenas de milhões de pessoas para tudo, desde aconselhamento médico até terapia. E de outro lado, a empresa compete no maior palco do mundo. A OpenAI acompanha de perto Meta, Google e Anthropic — e certamente eles fazem o mesmo. Governos ao redor do mundo observam esse espaço com atenção aguçada.

Por mais que a OpenAI seja criticada pela imprensa, todos que conheci lá realmente tentavam fazer o que era certo. Por ser a empresa com maior foco no consumidor, é a mais visível dentre os grandes laboratórios — e, por isso mesmo, sofre mais difamações.

Dito isso, você não deve ver a OpenAI como um monólito. Eu a vejo como uma organização que começou como Los Alamos — um grupo de cientistas e experimentadores investigando o limite da ciência. Esse grupo acabou gerando acidentalmente o aplicativo de consumo mais viral da história — e depois cresceu com ambições de vender para governos e empresas. Pessoas com diferentes tempos de casa e níveis hierárquicos têm objetivos e perspectivas muito distintos. Quanto mais tempo você está lá, mais tende a ver a empresa como “laboratório de pesquisa” ou “não-profit para o bem”.

O que mais aprecio é que a empresa realmente “pratica o que prega” ao distribuir os benefícios da IA. Modelos de ponta não são exclusivos de contratos empresariais. Qualquer pessoa pode acessar o ChatGPT e obter respostas, mesmo sem estar logada. Há uma API que você pode usar — e a maioria dos modelos, mesmo os avançados e proprietários, rapidamente chegam à API para que startups os utilizem. Você poderia imaginar um regime alternativo muito diferente — a OpenAI merece muito crédito por isso, é parte do DNA da empresa.

Segurança é mais presente do que você imaginaria, mesmo se seguir leituras como Zvi ou Lesswrong. Há muitas pessoas trabalhando para desenvolver sistemas de segurança. Dado o contexto da empresa, vi muito mais foco em riscos práticos (discurso de ódio, abuso, manipulação política, criação de armas biológicas, automutilação, prompt injection) do que em riscos teóricos (explosão de inteligência, busca por poder). Isso não quer dizer que ninguém trabalha nos riscos teóricos — existem sim —, mas, ao menos do meu ponto de vista, não é o foco. A maioria do trabalho não é publicada, e a OpenAI deveria fazer mais para divulgar isso.

Ao contrário de outras empresas que distribuem brindes à vontade em feiras de recrutamento, a OpenAI não dá muito swag (nem mesmo para novos empregados). Em vez disso, há “drops” nos quais se pode pedir produtos em estoque. O primeiro foi tão demandado que derrubou a loja no Shopify. Houve até um post interno ensinando como enviar a payload JSON correta para contornar isso.

Quase tudo é insignificante perto dos custos com GPU. Para dar uma ideia: um recurso nichado desenvolvido para o Codex tinha a mesma pegada de custo de GPU que toda a nossa infraestrutura do Segment (não na mesma escala do ChatGPT, mas ainda assim com tráfego considerável).

A OpenAI é talvez a organização mais assustadoramente ambiciosa que já vi. Você pode pensar que ter um dos maiores aplicativos de consumo do planeta seria o bastante, mas há o desejo de competir em dezenas de arenas: produto API, pesquisa profunda, hardware, agentes de codificação, geração de imagens, e várias outras que ainda não foram anunciadas. É um terreno fértil para pegar ideias e levá-las adiante.

A empresa presta muita atenção ao Twitter. Se você tweetar algo sobre a OpenAI que se tornar viral, há grandes chances de alguém por lá ler e considerar internamente. Um amigo brincou: “essa empresa funciona com base nas vibes do Twitter”. Como empresa de consumo, talvez isso nem esteja tão errado. Ainda existe muita análise de uso, crescimento e retenção — mas as vibes são igualmente importantes.

As equipes na OpenAI são muito mais fluidas do que em outros lugares. No lançamento do Codex, precisávamos de ajuda de alguns engenheiros experientes do ChatGPT para cumprir a data. Conversamos com alguns EMs do ChatGPT e, no dia seguinte, tínhamos duas pessoas incríveis prontas para ajudar. Não houve “esperar pelo planejamento trimestral” ou “realocar headcount”. As coisas acontecem muito rápido.

A liderança é bastante visível e engajada. Isso pode parecer óbvio numa empresa como a OpenAI, mas todo executivo parecia estar bem conectado. Você via gdb, ṣama, kw, mark, dane etc. comentando regularmente no Slack — não havia líderes ausentes.

Código

A OpenAI usa um monorepo gigante, composto principalmente por Python (embora haja um crescimento de serviços em Rust e alguns em Golang, como proxies de rede). Isso gera muito código com estilos diversos — de bibliotecas escaláveis feitas por ex-Google de 10 anos com soluções improvisadas em Jupyter notebooks por PhDs recém-formados. Quase tudo opera via FastAPI (para APIs) e Pydantic (para validação), mas não há guias de estilo amplamente aplicados.

A OpenAI roda tudo na Azure. Curiosamente, há apenas três serviços que considero confiáveis: Azure Kubernetes Service, CosmosDB (armazenamento de documentos) e BlobStore. Não existem equivalentes a Dynamo, Spanner, Bigtable, BigQuery, Kinesis ou Aurora. É menos comum pensar em unidades auto-escaláveis. As implementações de IAM (gerenciamento de identidade e acesso) são mais limitadas do que o que você encontraria na AWS — e há uma forte tendência a construir soluções internas.

No que diz respeito ao pessoal de engenharia, há um pipeline significativo de talentos vindos do Meta → OpenAI. Em muitos aspectos, a OpenAI se assemelha ao Meta dos primeiros tempos: um aplicativo de consumo de blockbuster, infraestrutura emergente e desejo de agir rapidamente. A maioria dos talentos de infraestrutura trazida do Meta + Instagram é bastante forte.

Combinando isso, você percebe muitas partes centrais da infra que lembram o Meta. Havia uma reimplementação interna do TAO, um esforço para consolidar autenticação na borda (edge). E certamente há outras iniciativas que desconheço.

Chat está profundamente integrado. Desde que o ChatGPT explodiu, grande parte da base de código está estruturada em torno da ideia de mensagens de chat e conversas. Esses conceitos são tão fundamentais hoje que é melhor não ignorá-los.

O código vence. Em vez de haver um comitê de arquitetura ou planejamento central, as decisões são geralmente tomadas pela equipe que planeja executar o trabalho. Isso resulta numa forte bias para ação, mas também frequentemente gera partes duplicadas da base de código. Eu devo ter visto meia dúzia de bibliotecas para coisas como gerenciamento de filas ou loops de agentes.

Existem algumas áreas onde ter equipe de engenharia altamente escalada e pouca ferramenta própria gera problemas. O sa-server (backend monolítico) era um pouco um depósito de código. O CI quebrou com mais frequência do que você esperaria no master. Executar casos de teste em paralelo (considerando algumas dependências) podia levar cerca de 30 minutos para rodar em GPUs. Esses problemas não são insolúveis, mas lembram que esse tipo de desafio existe em toda organização e tende a piorar quando há rápido crescimento. A equipe interna está muito focada em melhorar essa situação.

Outras lições que aprendi

Como é uma grande marca de consumo: até eu não tinha internalizado isso até trabalhar no Codex. Tudo é medido em termos de "pro users". Mesmo para um produto como o Codex, o onboarding foi pensado principalmente para uso individual em vez de equipes. Isso me deixou meio desnorteado, vindo de um background predominantemente B2B/enterprise. Você ativa algo e o tráfego aparece instantaneamente.
Como modelos grandes são treinados (visão macro): há um espectro entre "experimentação" e "engenharia". Muitas ideias começam como experimentos em pequena escala. Se os resultados parecerem promissores, são incorporadas a um run maior. Experimentação envolve tanto ajustes em algoritmos quanto na mistura de dados e estudo cuidadoso dos resultados. Em grande escala, executar um grande run parece engenharia de sistemas distribuídos — surgem casos extremos e coisas inesperadas. Cabe a você depurá-los.
Como lidar com matemática em GPU: durante o lançamento do Codex, tivemos que prever a capacidade de carga; foi a primeira vez que fiz algum benchmarking de GPUs. A essência é começar pelos requisitos de latência necessários (tempo total de resposta, número de tokens, tempo até o primeiro token), em vez de análise bottoms-up do que uma GPU pode suportar. Cada nova iteração do modelo pode alterar radicalmente os padrões de carga.
Como trabalhar numa base de código Python grande: no Segment, eu lidava com microservices em Golang e Typescript. Não tínhamos a abrangência de código que a OpenAI tem. Aprendi sobre como escalar uma base de código com muitos contribuintes. É preciso criar muitos guardrails para coisas como "funciona por padrão", "mantenha o master limpo" e "difícil de usar incorretamente".

Lançando o Codex

Parte significativa dos meus últimos três meses na OpenAI foi dedicada ao lançamento do Codex — e foi, sem dúvidas, um dos destaques da minha carreira.

Em novembro de 2024, a OpenAI definiu como meta para 2025 lançar um agente de codificação. Em fevereiro de 2025 já tínhamos algumas ferramentas internas usando modelos com eficácia. E sentíamos a pressão por um agente específico para codificação. Claramente, os modelos estavam em um ponto de utilidade para programação.

Voltei cedo da minha licença paternidade para ajudar no lançamento. Uma semana depois de voltar, houve uma fusão (ligeiramente caótica) de duas equipes e começou uma corrida frenética. Desde a primeira linha de código até o lançamento público, o produto foi construído em apenas 7 semanas.

O sprint do Codex foi provavelmente o trabalho mais intenso dos últimos quase 10 anos. A maioria das noites terminava às 23h ou meia-noite. Acordava com o bebê às 5h30, chegava ao escritório às 7h, trabalhando quase todos os finais de semana. Nos esforçamos bastante como equipe — cada semana contava. Muitos momentos me lembravam os dias de YC.

É difícil exagerar quão incrível foi esse ritmo. Nunca vi organizações, grandes ou pequenas, irem de uma ideia até um produto plenamente lançado e disponível de forma gratuita num período tão curto. E o escopo não era pequeno: construímos runtime em contêiner, otimizamos download de repos, ajustamos modelos customizados para lidar com edição de código, gerenciamos operações de Git, introduzimos uma nova interface, habilitamos acesso à internet — e ainda resultou num produto que foi um verdadeiro prazer de usar.

Ainda existe essa cultura de lançamento rápido na OpenAI.

A boa notícia é que as pessoas certas conseguem fazer mágica acontecer. Éramos uma equipe sênior composta por: ~8 engenheiros, ~4 pesquisadores, 2 designers, 2 profissionais de go-to-market (GTM) e um PM. Sem aquele grupo, talvez tivéssemos falhado. Ninguém precisava de muita direção, mas exigia bastante coordenação. Se tiver a chance de trabalhar com alguém do time do Codex, saiba que todos são excepcionais.

Na noite anterior ao lançamento, cinco de nós ficamos acordados até às 4h tentando fazer o deploy do monólito principal (que levava várias horas). Depois, voltamos ao escritório para o anúncio e livestream às 8h. Ativamos flags e vimos o tráfego disparar. Nunca vi um produto obter um aumento tão imediato só por aparecer na barra lateral esquerda — mas esse é o poder do ChatGPT.

Quanto ao formato do produto, optamos por uma interface totalmente assíncrona. Diferente de ferramentas como Cursor (na época; hoje já suporta modo similar) ou Claude Code, nossa aposta era que os usuários tratassem o agente de codificação como um colega de trabalho: enviariam mensagens, o agente receberia algum tempo para trabalhar, e depois retornaria com um PR (pull request).

Foi um pouco um risco: estamos num estado em que os modelos são bons, mas não excelentes. Podem trabalhar por minutos, mas ainda não por horas. Os usuários têm variados níveis de confiança nas capacidades do modelo. E ainda não temos clareza sobre o real alcance dessas capacidades.

No longo prazo, acredito que a maior parte da programação será parecida com o Codex. Enquanto isso, será interessante acompanhar como os produtos vão evoluir.

O Codex (não surpreendentemente) é muito bom de trabalhar em bases de código grandes, sabe navegar bem nelas. O diferencial mais marcante que vi em relação a outras ferramentas é a capacidade de iniciar múltiplas tarefas simultaneamente e comparar os resultados.

Recentemente, vi números públicos comparando PRs gerados por diferentes agentes LLM. Só nos números públicos, o Codex já gerou 630.000 PRs. Isso representa cerca de 78 mil PRs públicos por engenheiro nos primeiros 53 dias após o lançamento. Dá para imaginar quantos PRs privados foram feitos. Acho que nunca trabalhei em algo tão impactante na minha vida