Harness engineering: leveraging Codex in an agent-first world

• Source: https://openai.com/index/harness-engineering/

TL;DR: OpenAI описывает эксперимент, где команда построила внутренний продукт почти полностью через Codex: люди не писали код вручную, а задавали цели, строили окружение, правила, инструменты проверки и feedback loops. Главный вывод: в agent-first разработке инженерная работа смещается от «писать код» к проектированию системы, в которой агенту понятно, что делать, как проверять результат и как не разрушать архитектуру.

1. Ключевые мысли

1. Команда сознательно запретила ручное написание кода. Все — application logic, тесты, CI, документация, observability, внутренние инструменты — писалось Codex’ом. Люди управляли задачами, требованиями, проверками и архитектурными ограничениями.

2. Производительность резко выросла, но не “магически”. По оценке автора, продукт был собран примерно в 10 раз быстрее, чем при ручной разработке. За пять месяцев репозиторий вырос до порядка миллиона строк, было открыто и смержено около 1500 PR, но это стало возможным только после серьёзных инвестиций в tooling, структуру и проверки.

3. Роль инженера изменилась: не кодить, а строить среду для агента. Когда Codex не справлялся, команда не просила его “стараться сильнее”, а спрашивала: какой способности, контекста, инструмента или ограничения ему не хватает? Это важный сдвиг: человек проектирует систему исполнения, а агент выполняет работу.

4. Контекст должен жить в репозитории, а не в головах, чатах и Google Docs. Команда отказалась от огромного AGENTS.md. Вместо этого AGENTS.md стал короткой “картой”, а настоящая база знаний живёт в структурированном docs/: архитектура, продуктовые спеки, планы, quality score, reliability, security, design docs. Это делает знания доступными агенту и версионируемыми.

5. Agent legibility — центральный принцип. Если агент не может что-то увидеть, прочитать, проверить или воспроизвести в своём контексте, для него этого фактически не существует. Поэтому UI, логи, метрики, трейсы, DOM snapshots, screenshots и локальная observability-среда были сделаны доступными Codex’у.

6. Архитектура держится не на просьбах, а на механических ограничениях. Команда ввела строгие слои, допустимые зависимости, custom linters, structural tests, naming conventions, ограничения размера файлов, structured logging и “taste invariants”. Ошибки линтеров при этом написаны так, чтобы сразу давать агенту инструкции по исправлению.

7. Высокий throughput меняет философию merge/review. При большом количестве дешёвых agent-run’ов становится выгоднее быстро мержить маленькие PR и исправлять проблемы последующими проходами, чем блокировать всё человеческим review. Но автор прямо оговаривает: это разумно только в среде с сильными автоматическими проверками и высокой скоростью коррекции.

8. AI slop лечится не ручной уборкой, а “garbage collection”. Изначально команда тратила пятницы на чистку мусора, но это не масштабировалось. Затем они начали кодировать “golden principles” в репозиторий и запускать регулярные cleanup-задачи, которые сами находят отклонения, обновляют quality grades и открывают маленькие refactoring PR.

2. Что здесь действительно важно и почему

Главная ценность статьи не в тезисе “Codex написал миллион строк”. Важнее другое: агентная разработка требует гораздо более строгой инженерной операционной системы, чем обычная разработка.

Для твоего Codex/workflow-контекста это особенно применимо: статья фактически подтверждает, что лучший путь — не просто давать Codex большие промпты, а строить вокруг него репозиторную инфраструктуру:

AGENTS.md как карта, а не энциклопедия; docs/ как system of record; исполняемые планы в репозитории; линтеры и CI как носители вкуса и архитектуры; локальные проверки, которые агент может сам запускать; логи, метрики и UI-состояние, которые агент может сам читать; маленькие PR, много итераций, постоянная уборка технического долга.

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

3. Слабые места, натяжки и ограничения

Есть несколько важных caveat’ов.

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

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

В-третьих, “минимальные merge gates” могут быть опасны вне такой среды. Если нет сильных тестов, custom linters, observability, agent-readable QA и регулярной garbage collection, быстрые merge’и могут не ускорить разработку, а быстро размножить хаос.

В-четвёртых, статья честно признаёт, что пока неизвестно, как такая полностью agent-generated система будет вести себя на горизонте лет: сохранится ли архитектурная связность, где именно нужен человеческий judgment, и как это изменится с развитием моделей.

4. Итог

Это не столько статья про “Codex пишет код”, сколько статья про harness engineering: создание упряжи, направляющих, ограничений и feedback loops, в которых агент может безопасно и продуктивно работать.

Практическая формула такая: не просить агента быть умнее каждый раз, а строить репозиторий так, чтобы правильное поведение было для него самым лёгким, видимым и проверяемым путём.

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