Как на самом деле ведут разработку внутри OpenAI: разбор статьи “Reflections on OpenAI”

Прочитала статью от Calvin French-Owen, который год проработал в OpenAI. И это один из самых полезных текстов про AI-компании за последнее время. Не про модели и AGI, а именно про то, как выглядит внутренняя инженерная кухня компании, которая сейчас двигает весь рынок. Там очень много знакомых вещей для любого человека из IT.

Как на самом деле ведут разработку внутри OpenAI: разбор статьи “Reflections on OpenAI”

Первое, что сразу бросается в глаза - OpenAI живет в режиме постоянного ускорения. Компания выросла примерно с 1000 до 3000+ человек буквально за год. Но внутри у них до сих пор нет ощущения классического enterprise. Скорее это огромный research startup, который случайно стал одной из самых влиятельных компаний мира.

У них почти нет email. Calvin пишет, что получил около 10 писем за весь год работы. Все остальное происходит в Slack. Причем это не пара рабочих чатиков, а огромная экосистема:

  • десятки воркспейсов
  • сотни каналов
  • разные уровни доступов
  • постоянные обсуждения
  • куча асинхронной коммуникации

И тут очень хорошо видно философию OpenAI. Для них скорость важнее порядка. Email слишком медленный. Formal-процессы слишком медленные. Долгие согласования тоже слишком медленные. Slack позволяет принимать решения почти в realtime. Но цена за это постоянный шум. Как человек, который работал в командах с высокой скоростью delivery, я очень хорошо представляю этот режим. Когда у тебя одновременно летят сообщения от infra, product, research и platform-команд, а контекст меняется каждые полчаса. Такой режим требует очень высокого уровня самостоятельности.

Еще интересно, как у них устроен код. Практически весь backend живет в одном огромном монорепозитории. Основной стек:

  • Python
  • FastAPI
  • Pydantic
  • местами Rust
  • немного Go

Идеальной архитектуры там, судя по описанию, давно уже нет. Calvin прямо пишет, что backend постепенно превратился в огромную свалку, куда все складывают код. Причем это очень типичная история для быстрорастущих продуктовых компаний. Просто в OpenAI масштаб другой. В одном месте у тебя production-grade библиотека от бывшего инженера Google. В соседнем временный notebook от research-команды, который внезапно стал частью production pipeline. И это, честно, максимально жизненно.

Особенно понравился момент про GPU-тесты. Некоторые тесты у них могут идти по 30 минут даже в параллели из-за зависимостей на GPU infrastructure. И вот тут очень чувствуется разница между обычным SaaS и AI-компаниями. В классическом продукте bottleneck обычно:

  • backend
  • база
  • API latency

В AI bottleneck уже инфраструктурный:

  • GPU scheduling
  • inference
  • training pipelines
  • memory limits
  • compute availability

Самое интересное в статье это дублирование решений. Calvin пишет, что внутри OpenAI одновременно существует несколько библиотек для одних и тех же задач:

  • agent loops
  • orchestration
  • queues
  • internal tooling

И сначала кажется, что это архитектурный хаос. Но потом понимаешь логику. OpenAI сознательно жертвует консистентностью ради скорости. У них нет культуры:

  • долгих RFC
  • централизованной архитектуры
  • бесконечных согласований между командами

Research-команда может просто взять и собрать свое решение. Если оно взлетело, вокруг него потом появляется продукт и инфраструктура. Если нет, оно тихо исчезает. И это очень отличается от классического enterprise-подхода, где сначала появляется:

  • комитет
  • согласование
  • architecture review
  • dependency mapping
  • roadmap

Тут сначала просто делают.

Например, Codex до релиза существовал сразу в нескольких параллельных вариантах от разных команд. С Connectors была похожая история. Для OpenAI дешевле несколько раз переписать одинаковый код, чем тормозить команды координацией. И, честно, это очень research-driven подход.

Еще одна важная вещь - как у них устроены знания внутри компании. Судя по статье, formal knowledge management там довольно слабый. Нет единого source of truth. Нет идеальной документации. Очень многое хранится:

  • в Slack
  • в коде
  • в головах сотрудников

Когда Calvin спросил про квартальный roadmap, ему ответили примерно: такого особо нет. И это многое объясняет. OpenAI сейчас работает скорее как набор очень быстрых автономных команд, чем как централизованная корпорация.

Причем лучшие менеджеры там, судя по описанию, это не люди, которые идеально ведут Jira. А люди, которые умеют:

  • быстро соединять команды
  • собирать fragmented research
  • находить нужных людей
  • ускорять delivery между группами

В статье есть хороший пример. Для запуска Codex понадобились сильные инженеры из ChatGPT-команды. Их просто получили буквально на следующий день. Без кварталов согласований и resource planning. Для любой enterprise-компании это звучит почти нереально. Но именно такая скорость сейчас и дает OpenAI преимущество.

Вообще после статьи очень хорошо понимаешь, что OpenAI это уже не просто research lab. Но еще и не полноценный enterprise. Скорее гибрид:

  • исследовательской лаборатории
  • hyperscale infrastructure-компании
  • consumer-tech продукта
  • AI-платформы

И вся эта конструкция пока держится в основном на скорости и очень сильных людях. Их подход к управлению знаниями и процессами вообще противоречит почти всему, чему учат в классическом менеджменте:

  1. нет единого source of truth
  2. нет централизованной архитектуры
  3. команды дублируют решения
  4. Slack заменяет половину процессов
  5. скорость важнее консистентности

Пока компания растет с такой скоростью, модель работает. Но сможет ли это масштабироваться до 10-20 тысяч сотрудников - очень хороший вопрос. Meta и Google в свое время тоже проходили через похожую фазу. Просто OpenAI сейчас проживает ее в максимально сжатом режиме.

Мой личный блог в ТГ, пишу интересное про AI и управление проектами, заходи на огонек ʕ ᵔᴥᵔ ʔ

Начать дискуссию