Harness engineering: как экспериментальная команда внутри OpenAI перестраивала разработку вокруг агентов для одного из внутренних продуктов(Рубрика #AI4SDLC)
Готовясь к 35-му выпуску Research Insights, изучал статью OpenAI про harness engineering. Вышла она 11 февраля 2026 года, и для того момента здесь очень много интересных и прорывных мыслей о работе инженера. Особенно если читать её через вопрос: что нужно сохранить о системе, когда сам код становится всё дешевле?
Команда Райана Лопополо строила внутренний продукт, сознательно запретив себе писать код руками. По их данным, за пять месяцев получилось около миллиона строк, включая документацию и инфраструктуру, и примерно 1500 принятых PR. Инженеры занимались средой, в которой Codex мог выполнять работу.
Из статьи я бы выделил четыре вещи:
1️⃣ Знание должно быть доступно агенту. Короткий AGENTS.md служит картой документации. Требования и причины решений живут в репозитории.
2️⃣ Архитектуру нужно проверять. Допустимые зависимости и границы слоёв закреплены линтерами и структурными тестами.
3️⃣ Агенту нужны глаза. Доступ к интерфейсу, логам и метрикам позволяет ему воспроизводить ошибки и проверять исправления.
4️⃣ Сложность требует регулярной работы над ее снижением. Фоновые задачи ищут отклонения и предлагают небольшие рефакторинги. Ошибки становятся поводом улучшать правила и инструменты.
Мне здесь нравится перенос инженерного суждения в среду: сформулированное требование можно многократно применять и проверять. Очень рифмуется с темой моего keynote на DotNext — знание о системе должно переживать её реализацию.
А у этой истории оказалось занятное продолжение. В апрельском интервью Лопополо рассказал, что работал в Frontier Product Exploration, команде корпоративных агентных продуктов. И первые полтора месяца такой разработки, по его оценке, были примерно в десять раз медленнее ручной работы. Пришлось вложиться в инструменты и контекст, прежде чем эксперимент начал окупаться.
Следующим узким местом стало переключение между сессиями агентов (мы про эту проблему говорили в выпуске Research Insights #34). Так появился Symphony: он забирает задачи из Linear, запускает агентов в отдельных рабочих пространствах и доводит работу до приёмки. Человек задаёт работу и оценивает результат. Интересно, что в репозитории Symphony есть спецификация SPEC.md и экспериментальная реализация на Elixir. Можно попросить агента построить свою версию по этой спецификации. Получается вполне предметный шаг к восстановлению реализации из сохранённого знания.
К сентябрю Лопополо уже работал в Google Cloud и в новом разговоре советовал вкладываться прежде всего в инструменты и контекст: переносить исправления из разовых подсказок в документацию, линтеры и тесты. При этом исходный эксперимент начинался с пустого репозитория. В апреле автор уточнял, что перед выпуском приложения оставался человеческий smoke-тест. Переносить такой процесс в зрелую систему нужно с пониманием её рисков.
Приходите на 35-й выпуск Research Insights в эту пятницу: про статью поговорим подробнее — где здесь воспроизводимая инженерная практика и что нужно уметь проверять, прежде чем отдавать агентам больше работы.
P.S. Не смог приложить PDF, так как просто Ctrl + P на сайте OpenAI приводит к сохранению PDF, в котором теряется часть текста - пришлось читать статью по старинке, из браузера:)
#AI4SDLC #AI #Agents #Engineering #Architecture #PlatformEngineering