Harness-инженерия: как OpenAI построила продукт без единой строки ручного кода

OpenAI опубликовала Harness engineering: leveraging Codex in an agent-first world — отчёт команды из семи инженеров, которые за пять месяцев построили внутренний продукт на миллион строк кода, не написав ни одной строки вручную. Всё — от CI до документации и обсервабилити — сгенерировал Codex. Люди рулят, агенты исполняют.

Цифры эксперимента

Первый коммит — конец августа 2025 года. С тех пор:

• около миллиона строк кода;
• ~1500 смерженных pull request;
• средняя пропускная способность — 3,5 PR на инженера в день, и она растёт по мере роста команды;
• продукт уже используется сотнями сотрудников OpenAI ежедневно.

Оценка авторов: руками этот код писали бы в десять раз дольше. Главный вывод — когда ИИ пишет код, работа инженера смещается с написания кода на проектирование среды, спецификацию намерений и построение обратных связей.

Роль инженера переопределяется

Первые недели были медленнее ожиданий. Не потому что Codex слабый, а потому что среда была недоопределена: не хватало инструментов, абстракций, внутренней структуры, чтобы агент мог продвигаться к высокоуровневым целям. Работа команды свелась к тому, чтобы сделать агенту возможным делать полезные вещи.

Подход depth-first: декомпозировать крупную цель на строительные блоки (дизайн, код, ревью, тесты), попросить агента собрать каждый блок и собрать из них более сложные задачи. Когда что-то ломалось, ответ почти никогда не был «попробуй ещё раз». Инженер заходил в задачу и спрашивал: «какой способности не хватает и как сделать её одновременно видимой и принудительной для агента?»

Люди общаются с системой почти целиком через промпты: описывают задачу, запускают агента, позволяют открыть PR. Дальше Codex ревьюит свои изменения локально, запрашивает ревью у других агентов локально и в облаке, отвечает на обратную связь и итерирует, пока все ревьюеры не удовлетворены — авторы называют это Ralph Wiggum Loop. Со временем почти весь ревью-трафик ушёл в общение агент-к-агенту.

Application legibility

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

• Приложение запускается per git worktree, чтобы Codex мог поднимать и прогонять по одному инстансу на каждое изменение.
• В runtime встроен Chrome DevTools Protocol и skills для работы со снимками DOM, скриншотами и навигацией — агент воспроизводит баги, валидирует фиксы, рассуждает о UI напрямую.
• Обсервабилити-стек (логи, метрики, трейсы) развёрнут локально и эфемерен для каждого worktree. Codex запрашивает логи через LogQL, метрики через PromQL. После этого промпт вроде «обеспечь старт сервиса меньше 800 мс» или «ни один span в этих четырёх критических user journey не должен превышать две секунды» становится выполнимым.

Типичный одиночный прогон Codex над одной задачей длится больше шести часов — часто пока люди спят.

AGENTS.md — карта, а не энциклопедия

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

Решение: AGENTS.md — это оглавление на ~100 строк, а system of record живёт в структурированной директории docs/:

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
│   └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md

Дизайн-документы каталогизированы и проиндексированы, у каждого есть статус верификации и набор core beliefs, описывающих agent-first принципы. Планы — first-class артефакты: лёгкие для мелких изменений, execution plans для крупных, всё версионируется и лежит в репозитории. Это даёт progressive disclosure — агент стартует с маленькой стабильной точки входа и знает, куда смотреть дальше.

Поддерживается это механически: выделенные линтеры и CI проверяют, что база знаний актуальна, кросс-ссылки работают, структура не разваливается. Отдельный агент периодически сканирует устаревшую документацию и открывает PR на исправление.

Agent legibility как цель

Когда кодовая база полностью агент-сгенерированная, её оптимизируют сначала под читаемость Codex. Если знание живёт в Google Docs, Slack или головах сотрудников — для агента этого не существует. Репозиторий — единственное, что агент видит, поэтому контекст про архитектурные решения, принципы команды и инженерные нормы нужно протаскивать в docs/.

Этот фрейминг прояснил многие компромиссы: авторы предпочитают зависимости и абстракции, которые агент может полностью осмыслить в репозитории. «Скучные» технологии проще для модели из-за композируемости, стабильности API и хорошего покрытия в тренировочных данных. В одном случае было дешевле переписать подмножество функциональности локально, чем работать вокруг непрозрачного поведения публичной библиотеки: вместо p-limit-style пакета написали свой map-with-concurrency хелпер — он плотно интегрирован с OpenTelemetry, имеет 100% покрытие тестами и ведёт себя ровно так, как требует рантайм.

Инварианты вместо микроменеджмента

Документация одна не удерживает полностью агент-сгенерированный код согласованным. Принцип: enforce invariants, не implementations. Например, требуется парсить data shapes на границе, но как именно — не диктуется (модель сама предпочитает Zod).

Агенты лучше работают в средах со строгими границами и предсказуемой структурой, поэтому приложение построено вокруг жёсткой архитектурной модели. Каждая бизнес-область делится на фиксированный набор слоёв с валидируемыми направлениями зависимостей. Сквозные вещи (auth, коннекторы, телеметрия, feature flags) заходят через единственный явный интерфейс — Providers. Всё остальное механически запрещено.

В обычной разработке такие правила откладывают до сотен инженеров. С coding-агентами они становятся ранним prerequisite — ограничения и есть то, что позволяет скорости не приводить к архитектурному распаду.

Вкус не теряется: review-комментарии, рефакторинг-PR и баги с пользователей превращаются в обновления документации или кодифицируются прямо в инструменты. Когда документации не хватает — правило повышается до кода.

Философия merge меняется с пропускной способностью

В репозитории минимум блокирующих merge-гейтов. PR короткоживущие. Test flakes часто решаются повторным прогоном, а не блокировкой прогресса. В системе, где пропускная способность агента намного превышает человеческое внимание, исправления дёшевы, а ожидание — дорого. В low-throughput среде это было бы безответственно, но здесь это правильный trade-off.

Что значит «agent-generated» на самом деле

Агенты пишут:

• продуктовый код и тесты;
• CI и release-инструменты;
• внутренние dev-tools;
• документацию и историю дизайна;
• eval-харнесы;
• review-комментарии и ответы;
• скрипты, которые управляют самим репозиторием;
• определения продакшен-дашбордов.

Люди остаются в петле, но работают на другом слое абстракции: приоритизируют работу, переводят обратную связь пользователей в acceptance criteria, валидируют результат. Когда агент спотыкается, это сигнал: чего не хватает — инструмента, guardrail, документации — и это снова фиксится тем, что Codex сам пишет патч.

Агенты используют стандартные dev-tools напрямую: тянут review-обратную связь, отвечают в PR, пушат апдейты, часто сами сквошат и мержат свои pull request.

Новые уровни автономии

Когда тестирование, валидация, ревью, обработка фидбэка и восстановление были закодированы в саму систему, репозиторий недавно пересёк значимый порог — Codex теперь может end-to-end вести новую фичу по одному промпту:

• проверить текущее состояние кодовой базы;
• воспроизвести зарегистрированный баг;
• записать видео с демонстрацией сбоя;
• реализовать фикс;
• провалидировать фикс, прогнав приложение;
• записать второе видео с подтверждением;
• открыть PR;
• ответить на фидбек от людей и агентов;
• обнаружить и исправить сбой сборки;
• эскалировать к человеку только когда нужно суждение;
• смёржить изменение.

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

Энтропия и сборка мусора

Codex реплицирует паттерны, которые уже есть в репозитории — даже неровные и субоптимальные. Со временем это неизбежно ведёт к дрифту.

Сначала люди чистили «AI slop» вручную по пятницам (20% рабочего времени). Это не масштабировалось. Решение — «golden principles», зашитые в репозиторий, плюс регулярный cleanup-процесс. Принципы — opinionated механические правила, которые держат код читаемым и консистентным для будущих прогонов: предпочитать shared utility packages вместо локальных хелперов; не пробировать данные «YOLO-стилем» — валидировать границы или опираться на typed SDK. На регулярной основе фоновые Codex-задачи сканируют отклонения, обновляют quality grades и открывают точечные refactoring PR. Большинство таких PR ревьюится меньше минуты и автомёрджится.

Это работает как сборка мусора: техдолг — это кредит под высокий процент, лучше гасить его непрерывно мелкими частями, чем давать ему накапливаться и разгребать болезненными залпами. Человеческий вкус захватывается один раз и применяется к каждой строке кода постоянно.

Что ещё предстоит выяснить

Стратегия сработала до internal launch и adoption внутри OpenAI, но авторы открыто признают неизвестное:

• как архитектурная согласованность будет эволюционировать годами в полностью агент-сгенерированной системе;
• где человеческое суждение даёт наибольший leverage и как его закодировать так, чтобы оно компаундилось;
• как система будет меняться по мере того, как модели становятся способнее.

Главный сдвиг: дисциплина в разработке софта никуда не делась, но переместилась из кода в scaffolding — инструменты, абстракции и обратные связи, которые держат кодовую базу связной. Самые сложные задачи теперь — это дизайн окружений, обратных связей и контрольных систем, которые помогают агентам достигать цели: строить и поддерживать сложный надёжный софт в масштабе.