Инженерия обвязки: среда для агентов

После разбора интерфейса SWE-agent и передачи работы между сессиями ведущий переходит к целой среде разработки. Основа выпуска — инженерный пост Райана Лопополо «Harness engineering: leveraging Codex in an agent-first world», опубликованный OpenAI в феврале 2026 года. Команда сознательно отказалась писать код руками. Если Codex не справлялся, люди искали недостающую возможность и меняли окружение; исправления для самой среды тоже писал агент. Просьба стараться лучше не заменяла инструмента или понятного правила.

Это был новый внутренний продукт, начатый с пустого репозитория в конце августа 2025 года. По отчёту команды, за пять месяцев число инженеров выросло с трёх до семи, появилось около миллиона строк кода и 1500 PR, в среднем 3,5 PR на инженера в день. Продуктом пользовались сотни сотрудников; к ним присоединились внешние альфа-тестировщики. Люди определяли приоритеты, потребности пользователей и критерии приёмки, а Codex создавал код, тесты, конфигурацию и документацию. Время разработки авторы оценили примерно в десятую часть времени ручной работы.

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

К каждому экземпляру добавили собственную наблюдаемость: логи, метрики и трассировки, доступные через LogQL, PromQL и TraceQL. Требования вроде запуска сервиса за 800 миллисекунд или ограничения длительности участков трассировки двумя секундами в критических сценариях стали измеримыми. Агент мог проверить их сам и продолжить исправление. Подключение браузера и телеметрии здесь отвечает на конкретный вопрос: откуда исполнитель узнает, что его изменение действительно работает и не нарушает заданные условия?

Документы в Google Docs, решения из Slack и знания в головах сотрудников не помогают агенту, если он не может до них добраться. Ведущий сравнивает это с приходом нового инженера: проблема возникает ещё до реализации, когда неизвестно, где искать объяснение системы. Явно записанные договорённости и понятное место хранения полезны обоим. Перенос знаний в репозиторий расширял область того, что Codex мог прочитать, проверить и изменить.

Однако один огромный AGENTS.md работал плохо. Он вытеснял из контекста задачу, код и нужные документы; одинаково важные инструкции теряли приоритет, а сам файл устаревал и плохо поддавался машинной проверке. Команда разделила архитектурное описание, проектные решения, планы исполнения и продуктовые спецификации. AGENTS.md стал навигационной картой. Такой порядок позволяет получать нужные сведения по мере работы и проверять отдельные документы по понятным правилам.

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

Контроль сосредоточен на инвариантах: границах, корректности и воспроизводимости. Например, форма входных данных должна проверяться на границе приложения. Александр приводит знакомый ему противоположный пример из Android: непроверенный объект попадал внутрь, а отсутствие поля обнаруживалось поздним падением. Внутреннюю реализацию агент может выбирать свободнее. Код при этом способен не совпадать с человеческим вкусом; существеннее, работает ли он и сможет ли следующий агент разобраться в нём и продолжить изменения.

В описанном цикле Codex изучает состояние проекта, воспроизводит баг и записывает видео, делает исправление, проверяет приложение и записывает результат. Затем открывает PR, получает агентное ревью, отвечает на замечания и исправляет сбои. Человек может подключиться или принять решение при эскалации, но его участие в каждом ревью не обязательно. Такой процесс стал возможен после первоначальных вложений в среду; быстрый поток изменений появился не сразу.

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

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

Миллион строк и количество PR показывают масштаб кейса, но не объясняют эффект каждого элемента обвязки. В публикации нет размера PR, доли дефектов и откатов, распределения человеческих часов или затрат токенов. Десятикратное ускорение — оценка авторов. Неясно и то, как архитектурная связность сохранится годами, где человеческое суждение приносит больше пользы и что изменят более сильные модели. Опыт нового продукта нельзя автоматически перенести на двадцатилетний монолит.

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

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