Когда инженер становится продакт-менеджером своего кода

Nextdoor — социальная платформа, обслуживающая более 110 миллионов пользователей в 11 странах. Это огромная нагрузка на platform team (команду платформы): тысячи движущихся частей, несколько мобильных и веб-платформ, сложная серверная инфраструктура. Именно здесь OpenAI Codex — агентная система автоматического написания кода — превратился из удобного инструмента в принципиально новый способ работы.

Для Кори Долфина (Cory Dolphin), руководителя инженерной службы Nextdoor, Codex означает смену парадигмы: переход от итеративного диалога с агентом к outcome engineering («инжинирингу результатов»), когда инженер думает не о том, как строить, а о том, что он хочет получить на выходе, и работает с агентом ради достижения этого результата.

«Инженеры тратят значительно меньше времени на обдумывание того, как именно они строят, и больше — на обдумывание результата.»
— Кори Долфин, Head of Engineering, Nextdoor

ℹ Что такое Outcome Engineering?
Outcome Engineering — это подход, при котором инженер описывает желаемый конечный результат (скриншот интерфейса, показатель производительности, сценарий теста), а AI-агент самостоятельно выбирает путь реализации. Это принципиально отличается от классического программирования, где разработчик контролирует каждый шаг.

От специалиста к full-stack владельцу продукта

Это означает, что отдельные инженеры поднимаются «выше по стеку» — они больше не заперты как узкие специалисты в определённой системе или фреймворке и способны полностью владеть продуктовым опытом, охватывая сразу несколько платформ.

Результатом может быть скриншот или видео, на которые агент ориентируется при разработке. «Когда инженеры начинают смещаться выше по стеку, они берут на себя больше ответственности за продукт, который создают. Начинаешь видеть, как отдельные инженеры начинают двигать продукты».

Реальный пример: функция Opportunity Alerts

Недавно Nextdoor выпустил функцию Opportunity Alerts, позволяющую пользователям находить поставщиков услуг поблизости. Один из инженеров понял, что было бы полезно показывать этих поставщиков на карте. Исторически такая фича потребовала бы совместной работы трёх команд — мобильной, фронтендной и бэкендной — и, скорее всего, надолго зависла бы в беклоге.

С Codex один инженер смог разработать эту функцию самостоятельно, одновременно ускорив разработку и глубже погрузившись в пользовательский опыт.


flowchart TD
    A["Идея: карта поставщиков услуг"] --> B{"Раньше"}
    A --> C{"С Codex"}
    B --> D["Команда мобильной разработки"]
    B --> E["Команда фронтенда"]
    B --> F["Команда бэкенда"]
    D --> G["Долгое согласование → беклог"]
    E --> G
    F --> G
    C --> H["Один инженер"]
    H --> I["Функция в проде"]
    style G fill:#ff6b6b,color:#fff
    style I fill:#51cf66,color:#fff

Отладка невоспроизводимых ошибок: суперсила Codex

Одна из самых сложных задач в разработке — воспроизвести редкую ошибку, которая проявляется только в специфических условиях гонки (race condition) или при работе с «живой» базой данных.

Работая с встроенными базами данных на языке Rust и системами с жёсткими условиями гонки, Nextdoor обращается к Codex для отладки самых сложновоспроизводимых проблем. Команда предоставляет агенту чистую среду и инструменты для исследования, используя его для всего — от выяснения причин, по которым не запускаются поды Kubernetes, до поиска нужного тренда в анализе данных.

💡 Как настроить Codex для дебаггинга

Для эффективной отладки с Codex команда Nextdoor рекомендует:

  1. Изолированная среда — предоставьте агенту чистый sandbox без лишних зависимостей.
  2. Чёткий harness — опишите, как воспроизвести условия сбоя.
  3. Конкретная цель — сформулируйте, что именно нужно найти (root cause, не просто «что-то сломалось»).

«Мы видим, как Codex проявляет исключительную настойчивость и пытается найти правильное решение, глубоко погружаясь в, казалось бы, эзотерические технические детали, чтобы добраться до первопричины», — объясняет Долфин.

GPT-5.5 в Codex: ощутимый скачок

«С GPT-5.4 и 5.5 это был действительно впечатляющий апгрейд. Мы видим, как Codex проявляет исключительную настойчивость в поиске правильного решения, углубляясь в, казалось бы, эзотерические технические детали».

С GPT-5.5 в Codex трансформация, ранее охватившая разработку ПО, начинает распространяться на научные исследования и более широкий круг задач. GPT-5.5 не просто умнее — он эффективнее в решении задач, нередко достигая более высокого качества при меньшем количестве токенов и повторных попыток.

GPT-5.5 обеспечивает этот скачок интеллекта без потери скорости: более крупные и мощные модели обычно медленнее, но GPT-5.5 соответствует задержке GPT-5.4 на реальных задачах, при этом работая на значительно более высоком уровне. Кроме того, он использует значительно меньше токенов для выполнения тех же задач в Codex, будучи одновременно более эффективным и более мощным.

Режим Fast Mode: «команда подсела на него»

О Fast Mode в Codex с GPT-5.5 Долфин говорит прямо: «Буду честен — большая часть команды уже подсела на него».

Fast Mode — это режим работы Codex, в котором агент выдаёт быстрые итерации без глубокого многошагового размышления. Идеален для быстрой проверки гипотез и прототипирования.

Сравнение подходов: классическая разработка vs. Outcome Engineering с Codex

ПараметрКлассическая разработкаС Codex (Outcome Engineering)
Владелец фичиНесколько командОдин инженер
Фокус инженераРеализация (как?)Результат (что?)
КроссплатформенностьТребует специалистовОдин человек, все платформы
Дебаггинг race conditionsЧасы/дни вручнуюАгент исследует автоматически
Bottleneck (узкое место)Скорость разработкиСтратегические решения
Скорость от идеи до продаНеделиДни

Когда bottleneck сместился

Производительность ускорилась настолько, что узким местом стала уже не инженерия, а сложные стратегические вопросы о том, что строить дальше. «Codex фундаментально изменил наш подход к инженерии — до такой степени, что мы уже не можем представить себе разработку без него».

Возросшая автономность и эффективность ускорили производительность до такой степени, что узким местом стала уже не инженерная реализация, а стратегическое принятие решений.

⚠ Важный сдвиг для команд
Если раньше главным вопросом был «как мы это построим?», то с Codex он превращается в «что именно стоит строить следующим?». Это требует от инженеров развития новых компетенций: продуктового мышления, понимания пользователей и стратегического приоритезирования.

Что это значит для всей отрасли

Внутри самой OpenAI 95% инженеров используют Codex еженедельно, и эти инженеры выпускают примерно на 70% больше pull request’ов (запросов на слияние кода) с момента внедрения Codex.

История Nextdoor — это не просто кейс об одном инструменте. Это сигнал о том, куда движется вся индустрия разработки программного обеспечения. Когда AI-агент берёт на себя роль реализатора, инженер поднимается на уровень архитектора продукта. Специализация уступает место широкому владению. Беклог перестаёт пугать.

Codex открывает возможность для одного инженера провести концепцию от начальной идеи до продакшена, охватив все платформы Nextdoor одновременно. Это радикально ускоряет жизненный цикл разработки, делая итерации и развёртывание значительно более быстрыми.

Для русскоязычных команд разработки это прямой сигнал: изучение работы с AI-агентами вроде Codex — это уже не «интересная возможность», а базовый навык инженера нового поколения.