Инженер будущего не пишет код. Он строит обвязку для агентов

OpenAI 5 месяцев строили продукт без единой строчки ручного кода. Миллион строк, 1500 PR, 7 инженеров. Я разобрал их подход и понял - я уже так работаю. И вы тоже можете.

Недавно OpenAI выложили статью Harness Engineering о том, как их команда построила и запустила внутренний продукт с нуля, где каждая строчка кода написана агентом (Codex на GPT-5). Не часть кода, не 80% - вообще все. Тесты, CI, документация, внутренние тулы, даже скрипты для управления самим репозиторием.

Когда я это прочитал, у меня было два чувства. Первое - "ничего себе, миллион строк за 5 месяцев тремя инженерами". Второе - "подождите, а я разве не этим же занимаюсь?"

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

Что случилось

В августе 2025 команда OpenAI завела пустой гит-репозиторий и поставила себе жесткое правило: ни одной строчки кода руками.

Вообще. Даже первый коммит - структура репо, CI, линтеры, package.json - все сгенерировал Codex.

Спустя 5 месяцев:

• ~1 000 000 строк кода

• ~1 500 pull requests

• Начинали 3 инженера, сейчас 7

• 3.5 PR на инженера в день

• Продуктом пользуются сотни людей внутри OpenAI ежедневно

По их оценке - ускорение примерно в 10 раз по сравнению с ручной разработкой.

И самое интересное - throughput не падал с ростом команды. Наоборот, увеличивался. Потому что каждый новый инженер не добавляет хаос, а улучшает среду для агентов.

Что делают инженеры, если не кодят?

Вот тут начинается самое интересное.

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

И тут случился ключевой сдвиг в мышлении. Когда что-то шло не так, правильный вопрос был не "как переписать код", а

1. Инженер описывает задачу промптом

2. Codex пишет код

3. открывает PR

4. другие агенты делают ревью

5. если все ок - сам мержит

Человек может вмешаться на любом этапе, но не обязан.

Один Codex run может работать 6+ часов подряд. Часто пока люди спят. Утром просыпаешься - а PR уже смержен.

Знакомо? Я последние месяцы работаю примерно так же через Claude Code. Ставлю задачу, агент пилит, я проверяю результат. Только у меня масштаб поменьше))

Почему большой AGENTS.md это плохая идея

Это один из самых контринтуитивных выводов. Мы все привыкли: чем больше инструкций дал агенту - тем лучше результат. OpenAI попробовали подход "один большой AGENTS.md на все случаи жизни". И он провалился.

Почему:

• Контекст ограничен. Огромный файл с инструкциями вытесняет из контекста сам код и задачу. Агент начинает оптимизировать не то.

• Когда важно все - не важно ничего. Агент не может отличить критичное правило от рекомендации. Начинает паттерн-матчить по ближайшему куску текста.

• Протухает мгновенно. Кто из вас обновляет свой CLAUDE.md каждый день? Вот и они не обновляли. А агент не знает что правило устарело и исправно следует ему.

• Невозможно проверить автоматически. Свежесть, покрытие, связность - для монолитного файла это не отследить.

Их решение:

Около 100 строк. Просто карта: "архитектура - смотри тут", "принципы - тут", "планы - тут". Все детали живут в структурированной папке docs/

И вот что круто - у них есть отдельный агент-"садовник", который периодически сканирует документацию, находит протухшие куски и сам открывает PR с исправлениями. Документация сама себя чинит.

Агент видит только то, что лежит в репо

Для агента все, что не в репозитории - не существует. Точка.

Обсуждение в Slack? Не существует. Решение в чьей-то голове? Не существует. Гугл-док? Не существует.

Как для нового сотрудника, которого наняли через 3 месяца после важного созвона - если решение не записали, он о нем не знает.

Команда OpenAI поняла это и начала переносить все в репо: архитектурные решения, принципы, планы, технический долг. Все версионировано, все в markdown, все доступно агенту в контексте.

Архитектура - это не роскошь, а необходимость

Обычно жесткую архитектуру вводят когда уже 100+ разработчиков. С агентами - это нужно с первого дня.

Почему? Агент копирует паттерны которые видит в коде. В том числе кривые. Без четких границ через неделю у тебя каша, которую не разгребешь.

Как устроено у OpenAI: каждый бизнес-домен разбит на слои (Types → Config → Repo → Service → Runtime → UI). Зависимости строго контролируются — нижние слои не знают о верхних. Все проверяется кастомными линтерами.

И вот деталь которая меня зацепила: ошибки линтеров содержат инструкции для агента. Не просто "error: dependency violation", а развернутое объяснение что пошло не так и как исправить. Линтер буквально учит агента в момент ошибки.

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

"Скучные" технологии побеждают

Еще один контринтуитивный вывод. Агентам проще работать с технологиями, которые:

• Стабильны и хорошо задокументированы

• Широко представлены в обучающих данных моделей

• Имеют предсказуемое поведение

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

Это прям сильно перекликается с тем что я вижу на практике. Когда работаешь с Claude Code - простой понятный стек всегда лучше модного фреймворка.

Сборка мусора вместо пятничных чисток

Агент реплицирует паттерны. В том числе кривые. Со временем накапливается мусор - лишние абстракции, дублирующийся код, странные имена переменных.

Сначала команда тратила каждую пятницу - 20% рабочего времени! - на ручную уборку "AI-слопа". Знакомо? Вот это "код работает но читать его потом больно" - это оно.

Решение не масштабировалось. Вместо этого они сделали "сборку мусора": набор фоновых агентов на регулярном расписании сканят код, сравнивают с принципами проекта, находят отклонения и сами открывают мелкие рефакторинг-PR.

Кстати, code-simplifier плагин от Бориса Черного (создателя Claude Code) делает примерно то же самое - проходится по изменениям и причесывает. Только локально и после сессии, а не как CI.

Уровень автономии

Вот что может один промпт у них сейчас:

1. Проверить текущее состояние кодовой базы

2. Воспроизвести баг

3. Записать видео бага

4. Написать фикс

5. Проверить фикс через UI

6. Записать видео что все работает

7. Открыть PR

8. Ответить на ревью-комменты

9. Обработать фейлы билда

10. Позвать человека только если нужно решение, а не код

11. Замержить

    
    Codex валидирует UI через Chrome DevTools: snapshot → фикс → проверка в цикле

Один промпт. Весь цикл.

Да, это специфично для их настройки - у них куча кастомных инструментов, skills, встроенный Chrome DevTools Protocol, локальный стек мониторинга. Но направление понятно.

Что это значит для нас

Давайте без иллюзий - большинство из нас далеко не OpenAI и у нас нет команды из 7 инженеров которые только и делают что строят среду для агентов. Но вот что можно забрать уже сейчас:

• AGENTS.md/CLAUDE.md - карта, а не энциклопедия. Держи его коротким. 100-150 строк максимум. Ссылки на детали, а не сами детали.

• Все знание - в репо. Решил что-то архитектурное? Запиши в docs/. Нашел баг и понял причину? Запиши. Агенту доступно только то, что лежит рядом с кодом.

• Линтеры > инструкции. Вместо "не делай X" в документации - линтер который не даст сделать X. И ошибка которая объяснит агенту почему.

• Скучный стек. Если выбираешь между модным фреймворком и проверенным решением - для AI coding проверенное почти всегда лучше.

• Автоматическая уборка. Не жди пока "потом почищу". Настрой code-simplifier или аналог - пусть чистит после каждой сессии.

• Спрашивай "чего не хватает агенту?" Когда что-то идет не так - не переписывай код руками. Подумай какой инструмент, абстракция или документация нужна, чтобы агент сам справился в следующий раз.

Harness engineering - это уже реальность

OpenAI назвали это "harness engineering" - инженерия обвязки (моя интерпретация). Как с лошадьми: ты не бежишь сам, ты строишь обвязку которая позволяет лошади тянуть максимально эффективно.

Мне кажется, многие из нас уже этим занимаются - просто не знают что это так называется. Каждый раз когда ты пишешь CLAUDE.md, настраиваешь skills, создаешь шаблоны для агента - ты строишь обвязку.

Разница между тем кто "юзает ИИ" и тем кто реально ускоряется в 10 раз - именно в качестве этой обвязки. Не в том какая модель, не в том сколько платишь за подписку. А в том насколько хорошо ты подготовил среду для агента.

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

Интересно, кто из вас уже перестроил процесс под агентов — и что из этого реально работает?

P.S. Это моя первая статья на Хабре — буду рад любой обратной связи.

Больше про AI coding и вайбкодинг — в моем тг канале "атлант расправил плечи"

Оригинальная статья OpenAI: Harness engineering: leveraging Codex in an agent-first world