Обвязка для долгой разработки

Четвёртый разбор обвязок продолжает историю передачи работы между сессиями. Его основа — мартовский инженерный пост Притхви Раджасекарана из Anthropic Labs «Harness design for long-running application development». Автор соединяет улучшение фронтенд-дизайна и создание приложения по одному запросу. В первом случае результат выглядел шаблонно, во втором приложение оставалось недоделанным. Дополнительные инструкции помогали, но не устраняли оба предела.

Автор выделяет проблемы контекста и самооценки. На длинной задаче модель теряет связность; некоторые модели сворачивают работу, ожидая исчерпания окна. Исполнитель склонен хвалить собственный результат, особенно при субъективных критериях. Идея из генеративно-состязательных сетей подсказывает разделить генератора и критика. Это организационная аналогия: готовые модели обмениваются результатом и замечаниями, их веса не обучают. Настроить оценщика на скептическую проверку оказалось проще, чем добиться такой же требовательности от исполнителя.

В прежней обвязке на Sonnet 4.5 инициализатор готовил список функций, способ запуска и журнал прогресса. Разработчик выполнял одну функцию за шаг и оставлял внешние артефакты следующей сессии. Сброс давал чистый контекст, но требовал оркестрации, повторного чтения состояния и времени на передачу. Сжатие устроено иначе: начало беседы пересказывается, а работа продолжается в той же сессии.

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

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

Генератор создаёт HTML, CSS и JavaScript, а оценщик через Playwright MCP изучает живую страницу и возвращает критику. Исполнитель может дорабатывать вариант или менять направление целиком. В примере сайта голландского музея аккуратный тёмный лендинг на девятой итерации сменяется трёхмерной галереей на десятой. Последний вариант не всегда нравился автору больше промежуточного; сложность могла расти. Ведущий обращает внимание на критерий остановки: рост оценки ещё не отвечает, какой вариант следует принять.

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

В версии на Opus 4.5 работа идёт спринтами. Перед первым изменением генератор предлагает, что построить и как проверить успех. Оценщик уточняет, соответствует ли предложение спецификации. Обмен через файлы продолжается до согласования контракта. После реализации оценщик проходит пользовательские сценарии в браузере, находит расхождения и возвращает описание ошибок. Критерии известны обеим сторонам заранее, поэтому проверка привязана к договорённости, а не к убедительному отчёту о завершении.

Показательный пример — конструктор ретро-игр. Прямой запуск Claude Code с Opus 4.5 занял около двадцати минут и стоил девять долларов, но базовые функции не работали. Полная обвязка работала шесть часов и потратила двести долларов; большая часть возможностей полученного приложения работала. Ведущий задаёт практический вопрос: что куплено за дополнительные время и деньги? Здесь сравнивается работоспособность результата при разных бюджетах, поэтому демонстрация не доказывает универсального выигрыша в экономике.

Траектории показывают, как оценщик удерживал реализацию в рамках контракта. Он проверял поведение через Playwright MCP и фиксировал нарушения. Однако такой проверяющий появился после настройки. По описанию автора, Claude без неё мог увидеть настоящую проблему, решить, что она несущественна, и одобрить работу. Анализ этих решений позволяет уточнять правила качества. Отдельный агент не становится надёжным тестировщиком автоматически; даже после настройки мелкие недостатки оставались.

После появления Opus 4.6 автор сначала резко сократил обвязку и добавил новые идеи. Воспроизвести прежнее качество не удалось, а несколько одновременных изменений мешали понять причину. Затем он вернулся к последовательной проверке: изменить или убрать один компонент, посмотреть на результат и решить, нужен ли он дальше. Ведущий связывает это с абляциями из разбора SWE-agent.

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

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

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

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

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