Проектирование обвязки для длительной (автономной) разработки приложений

В выпуске №36 Александр Поломодов разбирает инженерный пост Притхви Раджасекарана из Anthropic Labs «Harness design for long-running application development». Автор соединяет две задачи: качественный фронтенд и работающее приложение по одному запросу. Проблемы контекста и снисходительной самооценки требуют разных механизмов. Идея из GAN помогает выделить критика; это аналогия разделения ролей, без обучения моделей.

В дизайне оценщик получает четыре критерия и разобранные примеры, проверяет страницу через Playwright MCP и возвращает критику. Последняя итерация не всегда оказывается лучшей. Для полного приложения планировщик готовит спецификацию, а генератор и оценщик согласуют контракт спринта до реализации. Прямой запуск конструктора ретро-игр на Opus 4.5 занял около двадцати минут и стоил девять долларов, но основные функции не работали. Полная обвязка потратила шесть часов и двести долларов, дав более полный результат. Бюджеты различаются, поэтому этот пример не доказывает универсальной экономической эффективности.

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

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