Вот уже пять месяцев наша команда проводит эксперимент: мы создаем и выпускаем внутреннюю бета-версию программного продукта, не написав ни строчки кода вручную.
У продукта есть и внутренние пользователи, которые пользуются им каждый день, и внешние альфа-тестеры. Он выпускается, разворачивается, ломается и чинится. Отличие в том, что весь код — логика приложения, тесты, конфигурация CI, документация, observability, внутренние инструменты — написан Codex. По нашей оценке, мы сделали это примерно в десять раз быстрее, чем если бы писали код вручную.
Люди задают направление. Агенты выполняют.
Мы специально ввели это ограничение, чтобы построить то, что было нужно для роста темпа разработки на порядки. У нас были недели, чтобы выпустить то, что в итоге оказалось миллионом строк кода. А чтобы это сделать, нам понадобилось понять, что меняется, когда основная задача команды разработки ПО — уже не писать код, а проектировать окружения, формулировать намерение и строить петли обратной связи, которые позволяют агентам Codex работать надежно.
Этот пост о том, чему мы научились, создавая совершенно новый продукт с командой агентов: что ломалось, что накапливалось и как максимально использовать наш единственный по-настоящему дефицитный ресурс — человеческое время и внимание.
Мы начали с пустого git-репозитория
Первый коммит в пустой репозиторий был сделан в конце августа 2025 года.
Начальная заготовка — структура репозитория, конфигурация CI, правила форматирования, настройка менеджера пакетов и фреймворк приложения — была сгенерирована Codex CLI на базе GPT-5, с опорой на небольшой набор существующих шаблонов. Даже исходный файл AGENTS.md, который определяет, как агентам работать в репозитории, был написан самим Codex.
Никакого заранее написанного людьми кода, который мог бы стать опорой для системы, не было. С самого начала репозиторий формировался агентом.
Через пять месяцев в репозитории содержится уже порядка миллиона строк кода: логика приложения, инфраструктура, инструменты, документация и внутренние утилиты для разработчиков. За этот период небольшой командой всего из трех инженеров, управлявших Codex, было открыто и замерджено примерно 1 500 пулл-реквестов. В среднем это 3,5 PR на инженера в день, и неожиданно этот показатель рос по мере того, как команда увеличилась до семи инженеров. Важно, что это был не объем ради объема: продуктом пользовались внутренних пользователей внутри компании, в том числе, на ежедневной основе, и внутренние продвинутые пользователи.
На протяжении всего процесса разработки люди ни разу напрямую не вносили код. Это стало базовой философией команды: никакого рукописного кода.
Переосмысление роли инженера
Отсутствие ручного кодинга со стороны людей привело к появлению иного типа инженерной работы, ориентированной на системы, структуру и использование ресурсов.
На раннем этапе прогресс шел медленнее, чем мы ожидали, но не потому, что Codex не справлялся, а потому что среда была недостаточно хорошо описана. Агенту не хватало инструментов, абстракций и внутренней структуры, необходимых для движения к целям высокого уровня. Основной задачей нашей инженерной команды стало дать агентам возможность делать полезную работу.
На практике это означало идти «вглубь»: разбивать большие цели на более мелкие строительные блоки (дизайн, код, ревью, тест и так далее), просить агента собирать эти блоки и использовать их, чтобы открыть путь к более сложным задачам. Когда что‑то не получалось, исправление почти никогда не сводилось к «постараться сильнее». Поскольку единственный способ двигаться вперед — добиться, чтобы работу выполнил Codex, инженеры‑люди каждый раз входили в задачу и спрашивали: «какой возможности ��е хватает и как сделать ее одновременно понятной агенту и поддающейся принудительному соблюдению?»
Люди взаимодействуют с системой почти полностью через промпты: инженер описывает задачу, запускает агента и позволяет агенту открыть пулл-реквест (PR). Чтобы довести PR до завершения, мы просим Codex провести локальное саморевью своих изменений, запросить дополнительные точечные ревью у агентов локально и в облаке, ответить на любые замечания от людей или агентов и повторять эти действия раз за разом, пока все агенты-ревьюеры не будут удовлетворены результатом (по сути это Ralph Wiggum Loop). Codex напрямую использует наши стандартные инструменты разработки (gh, локальные скрипты и skill-ы, встроенные в репозиторий), чтобы собирать контекст без того, чтобы людям приходилось копировать и вставлять его в CLI.
Люди могут ревьюить пулл-реквесты, но это не обязательно. Со временем мы переложили почти всю нагрузку на взаимное ревью агентов.
Повышаем понятность приложения для агента
По мере роста скорости разработки нашим узким местом стали предельные возможности QA-команды. Поскольку фиксированным ограничением остается человеческое время и внимание, мы начали добавляли агенту возможности контроля, делая UI приложения, логи и метрики напрямую понятными и интерпретируемыми для Codex.
Например, мы сделали приложение запускаемым отдельно для каждого рабочего дерева Git (worktree), чтобы Codex мог поднимать и управлять одним экземпляром на каждое изменение. Мы также встроили Chrome DevTools Protocol в среду выполнения агента и создали skills для работы со снимками DOM, скриншотами и навигацией. Это позволило Codex воспроизводить баги, валидировать исправления и напрямую рассуждать о поведении UI.
То же самое мы сделали для observability. Логи, метрики и трейсы доступны Codex через локальный observability-стек, который поднимается временно для каждого конкретного рабочего дерева Git (worktree). Codex работает с полностью изолированной версией этого приложения — включая его логи и метрики, которые удаляются после завершения задачи. Агенты могут запрашивать логи через LogQL, а метрики — через PromQL. При наличии такого контекста промпты вроде «убедись, что запуск сервиса завершается менее чем за 800 мс» или «ни один span (trace span, участок трассировки) в этих четырех критичных пользовательских сценариях не превышает две секунды» становятся реализуемыми.
Мы регулярно видим, как в рамках одного запуска Codex работает над одной задачей более шести часов (часто пока люди спят).
Мы сделали репозиторий источником истины (system of record)
Управление контекстом — один из самых больших вызовов в том, чтобы сделать агентов эффективными на крупных и сложных задачах. Один из самых ранних уроков был прост: дайте Codex карту, а не руководство на 1 000 страниц.
Мы попробовали подход «один огромный AGENTS.md». Это предсказуемо оказалось плохим вариантом:
Контекст — дефицитный ресурс. Огромный файл с инструкциями вытесняет саму задачу, код и релевантную документацию — поэтому агент либо пропускает ключевые ограничения, либо начинает оптимизировать не то, что нужно.
Слишком много указаний превращается в отсутствие указаний. Когда «важно» всё, важным не является ничего. В итоге агенты начинают локально искать по шаблонам вместо осознанной навигации.
Это быстро становится неактуальным. Монолитный мануал превращается в кладбище устаревших правил. Агенты не могут понять, что все еще актуально, люди перестают его поддерживать, и файл незаметно становится привлекательным для использования, но всё же источником проблем.
Его трудно верифицировать. Один большой блок плохо поддается тупым механическим проверкам (покрытие, свежесть, владельцы, кросс-ссылки), поэтому дрейф неизбежен.
Поэтому вместо того, чтобы считать AGENTS.md некой энциклопедией, мы относимся к нему как к оглавлению.
База знаний репозитория живет в структурированном каталоге docs/, который мы считаем источником истины. Короткий AGENTS.md (примерно 100 строк) добавляется в контекст, и в первую очередь служит «картой» с указателями на файлы-источники истины, находящиеся более глубокие в других местах.
AGENTS.md
ARCHITECTURE.md
docs/
├── design-docs/
│ ├── index.md
│ ├── core-beliefs.md
│ └── ...
├── exec-plans/
│ ├── active/
│ ├── completed/
│ └── tech-debt-tracker.md
├── generated/
│ └── db-schema.md
├── product-specs/
│ ├── index.md
│ ├── new-user-onboarding.md
│ └── ...
├── references/
│ ├── design-system-reference-llms.txt
│ ├── nixpacks-llms.txt
│ ├── uv-llms.txt
│ └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md
Схема хранилища знаний внутри репозитория.
Дизайн-документация каталогизирована и проиндексирована, включая статус верификации и набор ключевых убеждений, определяющих принципы работы в агент-ориентированном режиме. Документация по архитектуре дает верхнеуровневую карту доменов и слоения пакетов. Документ качества присваивает уровень качества каждому продуктовому домену и архитектурному слою, отслеживая пробелы со временем.
Планы рассматриваются как артефакты первого класса. Временные легковесные планы используются для небольших изменений, а сложная работа фиксируется в планах выполнения с логами прогресса и решений, которые коммитятся в репозиторий. Активные планы, завершенные планы и известный технический долг — все это версионируется и хранится рядом, что позволяет агентам работать без опоры на внешний контекст.
Это обеспечивает прогрессивное раскрытие (деталей по мере необходимости): агенты начинают с небольшой стабильной точки входа и получают указания, где смотреть дальше, вместо того чтобы быть перегруженными с самого начала.
Мы обеспечиваем это механическим образом. Специальные линтеры и задачи CI проверяют, что база знаний актуальна, связана кросс-ссылками и корректно структурирована. Регулярный агент «doc-gardening» сканирует устаревшую или неактуальную документацию, которая не отражает реальное поведение кода, и открывает исправляющие пулл-реквесты.
Понятность для агента — как цель
По мере эволюции кодовой базы должен был эволюционировать и подход Codex к проектным решениям.
Поскольку репозиторий полностью сгенерирован агентом, он в первую очередь оптимизирован под понятность для Codex. Так же, как команды улучшают удобство навигации по коду для новых инженерных сотрудников, целью наших инженеров-людей было сделать возможным для агента рассуждать о полном бизнес-домене напрямую из самого репозитория.
С точки зрения агента всё, к чему он не может получить доступ в контексте во время работы, фактически не существует. Знания, которые живут в Google Docs, чат-тредах или в головах людей, для системы недоступны. Все, что он видит, — это локальные для репозитория версионируемые артефакты (например, код, markdown, схемы, исполняемые планы).
Мы поняли, что со временем нам нужно переносить в репозиторий все больше и больше контекста. Пример: дискуссия в Slack, которая синхронизировала команду по архитектурному паттерну — если агент не может ее обнаружить, она для него так же недоступна, как была бы неизвестна новому сотруднику, пришедшему через три месяца.
Дать Codex больше контекста — значит организовать и сделать доступной правильную информацию, чтобы агент мог рассуждать на ее основе, а не перегружать его ad-hoc инструкциями. Так же, как вы вводите в курс нового коллегу по принципам продукта, инженерным нормам и командной культуре (включая даже предпочтения по emoji) — предоставление этой информации агенту приводит к более согласованному и ожидаемому результату.
Такая рамка прояснила многие компромиссы. Мы отдавали предпочтение зависимостям и абстракциям, которые можно полностью интернализовать и анализировать внутри репозитория. Технологии, которые часто называют «скучными», обычно проще моделировать агентам благодаря композиционности, стабильности API и представленности в обучающей выборке. В некоторых случаях агенту было дешевле переимплементировать подмножества функци��нальности, чем обходить непрозрачное поведение внешних публичных библиотек. Например, вместо подключения универсального пакета в стиле p-limit мы реализовали собственный helper map-with-concurrency: он плотно интегрирован с нашей инструментализацией OpenTelemetry, имеет 100% покрытие тестами и ведет себя ровно так, как ожидает наша среда выполнения.
Перенос всё большей части системы в форму, которую агент может напрямую инспектировать, валидировать и модифицировать, увеличивает отдачу — не только для Codex, но и для других агентов (например, Aardvark), которые тоже работают с этой кодовой базой.
Принудительное соблюдение архитектуры и инженерного вкуса
Одной документации недостаточно, чтобы поддерживать целостность полностью агентно-сгенерированной кодовой базы. Принудительно соблюдая инварианты, а не микроменеджеря реализации, мы позволяем агентам быстро поставлять изменения, не подрывая фундамент. Например, мы требуем от Codex парсить формы данных на границе, но не предписываем, как именно это должно быть реализовано (модели, похоже, нравится Zod, но мы не указывали эту библиотеку явно).
Агенты наиболее эффективны в средах со строгими границами и предсказуемой структурой, поэтому мы построили приложение вокруг жесткой архитектурной модели. Каждый бизнес-домен разделен на фиксированный набор слоев со строго верифицируемыми направлениями зависимостей и ограниченным набором допустимых ребер. Эти ограничения механически обеспечиваются кастомными линтерами (разумеется, сгенерированными Codex!) и проверками структуры.
Диаграмма ниже показывает правило: внутри каждого бизнес-домена (например, App Settings) код может зависеть только «вперед» по фиксированному набору слоев (Types → Config → Repo → Service → Runtime → UI). Сквозные аспекты (auth, connectors, telemetry, feature flags) входят через один явный интерфейс: Providers. Все остальное запрещено и принудительно контролируется механически.
Это тот тип архитектуры, который обычно откладывают до момента, когда у вас уже сотни инженеров. С агентами, пишущими код, это ранняя необходимая предпосылка: именно ограничения поз��оляют сохранять скорость без деградации и архитектурного дрейфа.
На практике мы обеспечиваем эти правила кастомными линтерами и проверками структуры, плюс небольшим набором «инвариантов вкуса». Например, мы статически обеспечиваем структурированное логирование, соглашения об именовании схем и типов, лимиты размера файлов и платформенно-специфичные требования надежности с помощью кастомных линтов. Поскольку линты кастомные, мы пишем тексты ошибок так, чтобы внедрять в контекст агента инструкции по исправлению.
В человеко-ориентированном процессе эти правила могли бы показаться педантичными или ограничивающими. С агентами они становятся мультипликаторами: будучи однажды закодированными, они применяются везде сразу.
При этом мы явно разделяем, где ограничения важны, а где нет. Это похоже на управление крупной платформенной инженерной организацией: границы обеспечиваются централизованно, локально допускается автономия. Вам крайне важны границы, корректность и воспроизводимость. Внутри этих границ вы даете командам — или агентам — значительную свободу в том, как выражены решения.
Получающийся код не всегда совпадает с человеческими стилистическими предпочтениями, и это нормально. Пока результат корректен, поддерживаемый и читабельный, он соответствует планке.
Человеческий вкус непрерывно возвращается в систему. Комментарии ревью, рефакторинговые пулл-реквесты и пользовательские баги фиксируются как обновления документации или кодируются непосредственно в инструментарий. Если одной документации недостаточно, мы закрепляем правило в коде.
Пропускная способность меняет подход к мерджу
По мере роста пропускной способности Codex многие привычные инженерные нормы стали контрпродуктивными.
Репозиторий работает с минимальным числом блокирующих проверок перед слиянием. Пулл-реквесты живут недолго. Нестабильные (flaky) тесты часто устраняются последующими прогонами, вместо того чтобы бесконечно блокировать прогресс. В системе, где пропускная способность агентов намного превышает человеческое внимание, исправления дешевы, а ожидание дорого.
В среде с низкой пропускной способностью это было бы безответственно. Здесь это часто правильный компромисс.
Что на самом деле означает «сгенерировано агентом»
Когда мы говорим, что кодовая база сгенерирована агентами Codex, мы имеем в виду всё в этой кодовой базе.
Агенты создают:
Продуктовый код и тесты
Конфигурацию CI и инструменты релиза
Внутренние инструменты для разработчиков
Документацию и историю проектных решений
Обвязки для оценки качества
Комментарии ревью и ответы на них
Скрипты, управляющие самим репозиторием
Файлы определений продакшен-дашбордов
Люди всегда остаются в контуре, но работают на другом уровне абстракции, чем раньше. Мы расставляем приоритеты, переводим пользовательский фидбек в критерии приемки и валидируем результаты. Когда агент испытывает трудности, мы воспринимаем это как сигнал: определяем, чего не хватает — инструментов, ограничителей, документации, — и возвращаем это в репозиторий, всегда поручая Codex самому написать исправление.
Агенты напрямую используют наши стандартные инструменты разработки. Они подтягивают фидбек ревью, отвечают inline, пушат обновления и часто сами сквошат и мержат собственные пулл-реквесты.
Рост уровней автономности
По мере того как все больше этапов цикла разработки кодировалось прямо в систему — тестирование, валидация, ревью, обработка фидбека и восстановление, — репозиторий недавно пересек значимый порог, на котором Codex может сквозно (E2E) вести разработку новой фичи.
Получив один промпт, агент теперь может:
Валидировать текущее состояние кодовой базы
Воспроизвести зарегистрированный баг
Записать видео с демонстрацией сбоя
Реализовать исправление
Валидировать исправление, управляя приложением
Записать второе видео с демонстрацией устранения проблемы
Открыть пулл-реквест
Ответить на фидбек от агентов и людей
Обнаружить и исправить сбои сборки
Эскалировать к человеку только там, где требуется суждение
Замерджить изменение
Это поведение сильно зависит от конкретной структуры и инструментов этого репозитория, и не стоит считать, что оно обобщается без сопоставимых инвестиций — по крайней мере, пока.
Энтропия и сборка мусора
Полная автономность агентов также приносит новые проблемы. Codex воспроизводит паттерны, которые уже есть в репозитории, — даже неровные или неоптимальные. Со временем это неизбежно ведет к дрейфу.
Изначально люди решали это вручную. Наша команда раньше тратила каждую пятницу (20% недели) на уборку «ИИ-мусора». Предсказуемо, это не масштабировалось.
Вместо этого мы начали кодировать то, что называем «золотыми принципами», прямо в репозиторий и построили регулярный процесс очистки. Эти принципы — принципиальные, но механически проверяемые правила, которые сохраняют читабельность и консистентность кодовой базы для будущих запусков агентов. Например: (1) мы предпочитаем общие utility-пакеты самописным helper’ам, чтобы инварианты оставались централизованными, и (2) мы не исследуем данные «в стиле YOLO» — мы валидируем границы или опираемся на типизированные SDK, чтобы агент не мог случайно строить логику на предположительно угаданных формах. На регулярной основе у нас есть набор фоновых задач Codex, которые сканируют отклонения, обновляют уровни качества и открывают целевые рефакторинговые пулл-реквесты. Большинство из них можно отревьюить менее чем за минуту и замерджить автоматически.
Это работает как сборка мусора (GC). Технический долг — как кредит с высокой процентной ставкой: почти всегда лучше гасить его непрерывно маленькими шагами, чем позволять ему накапливаться и разбирать его болезненными рывками. Человеческий вкус фиксируется один раз, а затем непрерывно применяется к каждой строке кода. Это также позволяет ежедневно находить и исправлять плохие паттерны, вместо того чтобы позволять им распространяться в кодовой базе днями или неделями.
Чему мы все еще учимся
Эта стратегия пока хорошо сработала вплоть до внутреннего запуска и внедрения в OpenAI. Создание реального продукта для реальных пользователей помогло заземлить наши инвестиции в реальности и направить их к долгосрочной поддерживаемости.
Чего мы пока не знаем: как архитектурная целостность будет эволюционировать годами в полностью агентно-сгенерированной системе. Мы все еще учимся, где человеческое суждение дает наибольший рычаг и как закодировать это суждение так, чтобы оно давало накопительный эффект. Мы также не знаем, как будет эволюционировать эта система по мере того, как модели со временем становятся все более способными.
Стало ясно следующее: разработка ПО по-прежнему требует дисциплины, но дисциплина все чаще проявляется в каркасе, а не в самом коде. Инструменты, абстракции и циклы обратной связи, которые удерживают кодовую базу целостной, становятся все важнее.
Наши самые сложные задачи сейчас сосредоточены на проектировании сред, циклов обратной связи и систем контроля, которые помогают агентам достигать нашей цели: создавать и поддерживать сложное, надежное ПО в масштабе.
По мере того как такие агенты, как Codex, берут на себя все большие части жизненного цикла ПО, эти вопросы будут становиться только важнее. Мы надеемся, что эти ранние уроки помогут вам понять, куда инвестировать усилия, чтобы вы могли просто создавать вещи.
