Архитектура обвязки (harness design) играет ключевую роль в производительности на переднем крае агентной разработки. В этой статье расскажу о том, как мы смогли расширить возможности Claude в проектировании фронтенда и длительной автономной разработке ПО.
Последние несколько месяцев я работал над двумя взаимосвязанными задачами: научить Claude создавать качественный дизайн фронтенда и собирать полноценные приложения без вмешательства человека.
Эта работа выросла из наших более ранних экспериментов с навыком проектирования фронтенда и обвязкой длительно работающего агента для программирования, где мы с коллегами смогли значительно повысить производительность Claude относительно базового уровня с помощью проектирования промптов и архитектуры обвязки. Однако в обоих случаях мы со временем уперлись в потолок возможностей.
Чтобы преодолеть это ограничение, я начал искать новые подходы к инженерии ИИ, которые работали бы сразу в двух совершенно разных областях: одна определяется субъективным вкусом, другая — проверяемой корректностью и удобством использования.
Вдохновившись генеративно-состязательными сетями (GAN), я спроектировал мультиагентную архитектуру с агентом-генератором и агентом-оценщиком. Чтобы создать оценщика, способного надежно и со вкусом оценивать результаты, сначала пришлось разработать набор критериев, превращающих субъективные суждения вроде «хороший ли это дизайн?» в конкретные параметры, пригодные для оценки.
Затем я применил эти техники к длительной автономной разработке кода, сохранив два урока из нашей предыдущей работы над обвзязкой: разбиение сборки на управляемые части и использование структурированных артефактов для передачи контекста между сессиями. В результате появилась архитектура из трех агентов — планировщика, генератора и оценщика — способная создавать насыщенные full-stack-приложения в ходе многочасовых автономных сессий разработки.
Почему наивные реализации не работают
Ранее мы уже показывали, что архитектура обвязки существенно влияет на эффективность длительной агентной разработки. В одном из ранних экспериментов мы использовали агента-инициализатора, который разбивал спецификацию продукта на список задач, и агента-разработчика, реализующего их по одной функции за раз, после чего передавались артефакты для сохранения контекста между сессиями.
Более широкое сообщество разработчиков пришло к похожим выводам, используя подходы вроде метода «Ralph Wiggum», где хуки и скрипты поддерживают непрерывные циклы итераций агентов.
Но некоторые проблемы оставались устойчивыми. При работе над более сложными задачами агент со временем всё равно начинал терять направление. Анализируя эту проблему, мы обнаружили два типичных сценария отказа у агентов, выполняющих подобные задачи.
Во-первых, модели склонны терять связность на длинных задачах по мере заполнения контекстного окна. Некоторые модели также демонстрируют «контекстную тревожность» — они начинают преждевременно завершать работу, когда приближаются к тому, что считают пределом контекста. Сброс контекста — полная очистка контекстного окна и запуск нового агента в сочетании со структурированной передачей состояния предыдущего агента и списка следующих шагов — позволяет решить обе проблемы.
Это отличается от сжатия контекста, при котором ранние части диалога суммируются прямо внутри текущей сессии, чтобы тот же агент мог продолжить работу с сокращенной историей. Хотя сжатие сохраняет непрерывность контекста, оно не дает агенту «чистого листа», поэтому контекстная тревожность всё равно может сохраняться.
Сброс контекста, напротив, предоставляет полностью чистое состояние, но требует, чтобы артефакт передачи содержал достаточно информации для корректного продолжения работы следующим агентом.
В наших ранних тестах мы обнаружили, что Claude Sonnet 4.5 демонстрировал настолько выраженную контекстную тревожность, что одного лишь сжатия контекста было недостаточно для качественной работы над длинными задачами. Поэтому сбросы контекста стали обязательной частью архитектуры обвязки. Это решает основную проблему, но увеличивает сложность обвязки, расход токенов и задержку при каждом запуске системы.
Вторая проблема, которую мы ранее не рассматривали, — самооценка. Когда агентов просят оценить собственную работу, они обычно уверенно хвалят результат — даже если для человека качество выглядит откровенно посредственным. Особенно заметно это проявляется в субъективных задачах вроде дизайна, где нет бинарной проверки, аналогичной проверяемому программному тесту. Насколько интерфейс выглядит «отполированным» или шаблонным — вопрос интерпретации, и агенты почти всегда склонны завышать оценки собственных результатов.
Однако даже в задачах с проверяемым результатом агенты всё равно иногда демонстрируют слабое качество суждений, что мешает им эффективно выполнять работу. Разделение агента, который выполняет задачу, и агента, который её оценивает, оказалось мощным способом борьбы с этой проблемой.
Само по себе такое разделение не устраняет излишнюю снисходительность: оценщик всё равно остается LLM-моделью, склонной благожелательно относиться к результатам, созданным другими LLM. Но настроить отдельного оценщика на более скептический подход оказалось значительно проще, чем заставить генератор критически оценивать собственную работу.
А когда появляется внешний контур обратной связи, у генератора возникает конкретная основа для последующих итераций.
Проектирование фронтенда: как сделать субъективное качество измеримым
Я начал с экспериментов над дизайном фронтенда, поскольку именно там проблема самооценки проявлялась наиболее явно. Без дополнительных вмешательств Claude обычно тяготеет к безопасным и предсказуемым макетам, которые технически работают, но визуально ничем не выделяются.
На архитектуру обвязки для проектирования фронтенда повлияли два ключевых наблюдения.
Во-первых, хотя эстетику невозможно полностью свести к числовой оценке — и вкусы у людей всегда различаются — качество можно улучшать с помощью критериев оценки, отражающих принципы и предпочтения в дизайне. На вопрос «красив ли этот дизайн?» трудно отвечать последовательно и объективно, а вот вопрос «соответствует ли этот дизайн нашим принципам хорошего дизайна?» уже дает Claude конкретную основу для оценки.
Во-вторых, разделив генерацию фронтенда и его оценку, можно построить цикл обратной связи, который будет постепенно подталкивать генератор к более сильным результатам.
С учетом этого я сформулировал четыре критерия оценки и включил их в промпты как генератора, так и оценщика:
Качество дизайна: воспринимается ли дизайн как целостная система, а не как набор разрозненных элементов? Сильная работа в этом аспекте означает, что цвета, типографика, компоновка, изображения и другие детали объединяются в узнаваемую атмосферу и визуальную идентичность.
Оригинальность: заметны ли в работе собственные дизайнерские решения, или перед нами шаблонные макеты, настройки библиотек по умолчанию и типичные паттерны, сгенерированные ИИ? Профессиональный дизайнер должен видеть осознанные творческие решения. Неизмененные стандартные компоненты — или характерные признаки ИИ-генерации вроде фиолетовых градиентов поверх белых карточек — здесь считаются провалом.
Качество исполнения: техническая реализация — иерархия типографики, согласованность отступов, гармония цветов, коэффициенты контрастности. Это проверка компетентности, а не креативности. Большинство адекватных реализаций по умолчанию проходят этот критерий; провал означает проблемы с базовыми принципами.
Функциональность: удобство использования вне зависимости от эстетики. Может ли пользователь понять, как работает интерфейс, найти основные действия и выполнить задачу без догадок?
Приоритет я отдавал качеству дизайна и оригинальности, а не качеству исполнения и функциональности. Claude и без того хорошо справлялся с исполнением и функциональностью, поскольку необходимый уровень технической компетенции модели обычно давался естественно.
А вот в плане дизайна и оригинальности результаты Claude часто оказывались, в лучшем случае, безликими. Критерии напрямую штрафовали чрезмерно шаблонные паттерны «ИИ-слопа», а повышенный вес дизайна и оригинальности подталкивал модель к более смелым эстетическим решениям.
Для настройки оценщика я использовал few-shot-примеры с подробным разбором оценок. Это позволило привести суждения оценщика в соответствие с моими предпочтениями и уменьшить дрейф оценок между итерациями.
Сам цикл я построил на Claude Agent SDK, что позволило сохранить архитектуру обвязки достаточно простой. Сначала агент-генератор создавал фронтенд на HTML/CSS/JS на основе пользовательского запроса. Затем я предоставил оценщику доступ к Playwright MCP, чтобы он мог напрямую взаимодействовать с работающей страницей перед выставлением оценок по каждому критерию и написанием подробной критики.
На практике оценщик самостоятельно перемещался по странице, делал скриншоты и внимательно изучал реализацию перед тем, как вынести итоговую оценку. После этого обратная связь передавалась генератору как входные данные для следующей итерации.
Для каждой генерации я запускал от 5 до 15 итераций, и почти каждая следующая итерация делала результат всё более самобытным по мере того, как генератор реагировал на замечания оценщика. Поскольку оценщик активно взаимодействовал со страницей, а не анализировал статичный скриншот, каждый цикл занимал реальное время выполнения. Полный прогон мог растягиваться до четырех часов.
Кроме того, я дал генератору инструкцию после каждой оценки принимать стратегическое решение: либо дорабатывать текущее направление, если оценки росли, либо полностью менять визуальную концепцию, если выбранный подход не срабатывал.
От запуска к запуску оценки оценщика постепенно улучшались с каждой итерацией, пока не выходили на плато, хотя запас для дальнейшего роста всё ещё оставался. В одних случаях генерации улучшались постепенно и последовательно. В других между итерациями происходили резкие эстетические повороты.
Формулировки критериев влияли на генератор сильнее, чем я ожидал. Например, фразы вроде «лучшие дизайны достойны музея» подталкивали результаты к определенной визуальной конвергенции. Это указывало на то, что сам текст промптов, связанный с критериями, напрямую формировал характер итогового результата.
Хотя оценки в целом росли от итерации к итерации, зависимость была не всегда строго линейной. Более поздние реализации обычно оказывались лучше в совокупности, однако я регулярно сталкивался с ситуациями, когда промежуточная итерация нравилась мне больше финальной.
Кроме того, с каждым раундом обычно возрастала сложность реализации: генератор, реагируя на замечания оценщика, начинал пробовать всё более амбициозные решения. Даже результаты первой итерации заметно превосходили базовый вариант без каких-либо промптов, что говорит о том, что сами критерии и используемые в них формулировки уже изначально уводили модель от шаблонных решений ещё до того, как оценщик начинал давать обратную связь.
В одном особенно показателном примере я попросил модель создать сайт для голландского художественного музея. К девятой итерации она выдала аккуратный лендинг в темной цветовой гамме для вымышленного музея. Страница выглядела визуально «вылизанной», но в целом соответствовала моим ожиданиям.
Однако на десятой итерации модель полностью отказалась от прежнего подхода и переосмыслила сайт как пространственный опыт: появился трехмерный зал с шахматным полом, построенным через CSS perspective, картины свободно размещались на стенах, а навигация между галереями происходила через дверные проемы вместо привычной прокрутки или кликов.
Это был тот уровень творческого скачка, которого я раньше не видел при одноразовой генерации.
Масштабирование до full-stack-разработки
Вооружившись этими выводами, я перенес подход, вдохновленный GAN, на full-stack-разработку. Цикл «генератор–оценщик» естественным образом ложится на жизненный цикл разработки программного обеспечения, где код-ревью и QA выполняют ту же структурную роль, что и оценщик дизайна.
Архитектура
В нашей предыдущей архитектуре для длительной работы агентов мы уже решили проблему согласованной многосессионной разработки с помощью агента-инициализатора, агента-разработчика, работающего по одной функции за раз, и сбросов контекста между сессиями.
Сброс контекста стал ключевым прорывом: в той архитектуре использовался Sonnet 4.5, который демонстрировал упомянутую ранее «контекстную тревожность». Возможность построить систему, стабильно работающую после сбросов контекста, оказалась критически важной для удержания модели в рамках задачи. Opus 4.5 в значительной степени устранил это поведение самостоятельно, поэтому в новой архитектуре я смог полностью отказаться от сбросов контекста.
Агенты работали как единая непрерывная сессия на протяжении всей сборки, а автоматическое сжатие контекста в Claude Agent SDK управляло ростом контекста по мере выполнения задачи.
Для этой работы я взял за основу исходную архитектуру обвязки и построил систему из трех агентов, где каждый агент закрывал конкретный пробел, который я наблюдал в предыдущих запусках. Система включала следующие роли агентов:
Планировщик: в нашей предыдущей архитектуре длительной работы агенту требовалось, чтобы пользователь заранее предоставлял подробную спецификацию. Я хотел автоматизировать этот этап, поэтому создал агента-планировщика, который принимал короткий промпт из 1–4 предложений и разворачивал его в полноценную продуктовую спецификацию.
Я инструктировал его мыслить амбициозно с точки зрения масштаба и концентрироваться на продуктовом контексте и высокоуровневой технической архитектуре, а не на детальной технической реализации. Такой акцент был связан с опасением, что если планировщик начнет заранее задавать низкоуровневые технические детали и ошибется, то ошибки из спецификации каскадно перейдут в последующую реализацию.
Более разумным казалось ограничивать агентов ожидаемыми результатами работы и позволять им самостоятельно находить путь к реализации в процессе выполнения задачи. Кроме того, я просил планировщика искать возможности органично встроить ИИ-функции в продуктовые спецификации. (Пример приведен в приложении в конце статьи.)
Генератор: подход «по одной функции за раз» из предыдущей архитектуры хорошо показал себя для управления масштабом задачи. Здесь я применил похожую модель, поручив генератору работать спринтами, реализуя по одной функции из спецификации за раз. В каждом спринте приложение собиралось на стеке React, Vite, FastAPI и SQLite (позже PostgreSQL), а генератор должен был самостоятельно оценить свою работу в конце спринта перед передачей результата в QA. Для контроля версий также использовался git.
Оценщик: приложения из предыдущих архитектур часто выглядели впечатляюще, но при реальном использовании всё равно содержали ошибки. Чтобы выявлять такие проблемы, оценщик использовал Playwright MCP и взаимодействовал с работающим приложением так же, как это делал бы пользователь: проверял функции интерфейса, API-эндпоинты и состояние базы данных.
Затем он оценивал каждый спринт как по найденным ошибкам, так и по набору критериев, основанных на эксперименте с фронтендом, но адаптированных под глубину продукта, функциональность, визуальный дизайн и качество кода. Для каждого критерия был установлен жесткий порог, и если хотя бы один показатель опускался ниже него, спринт считался проваленным, а генератор получал подробную обратную связь с описанием проблем.
Перед каждым спринтом генератор и оценщик согласовывали «контракт спринта»: они определяли, что именно будет считаться завершенной работой для данного этапа ещё до написания кода. Это было необходимо, потому что продуктовая спецификация намеренно оставалась высокоуровневой, а мне требовался промежуточный этап, соединяющий пользовательские сценарии с проверяемой реализацией.
Генератор предлагал, что именно он собирается реализовать и как будет проверяться успешность результата, а оценщик анализировал это предложение, чтобы убедиться, что генератор движется в правильном направлении. Они продолжали итерации, пока не приходили к согласию.
Обмен данными происходил через файлы: один агент записывал файл, другой его читал и отвечал либо внутри этого же файла, либо создавал новый файл, который затем снова читался предыдущим агентом. После этого генератор реализовывал функциональность в соответствии с согласованным контрактом и только затем передавал результат в QA. Это позволяло сохранять соответствие реализации исходной спецификации, не перегружая процесс чрезмерной детализацией на слишком раннем этапе.
Запуск архитектуры обвзяки
Для первой версии этой архитектуры я использовал Claude Opus 4.5, прогоняя пользовательские запросы как через полную систему обвязки, так и через одноагентную систему для сравнения. Я выбрал Opus 4.5, поскольку на момент начала экспериментов это была наша лучшая модель для программирования.
Я использовал следующий промпт для генерации конструктора ретро-видеоигр:
Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode.
В таблице ниже показаны тип архитектуры, продолжительность работы и итоговая стоимость.
Архитектура | Длительность | Стоимость |
Solo | 20 мин | $9 |
Полная архитектура обвязки | 6 ч | $200 |
Полная система оказалась более чем в 20 раз дороже, однако разница в качестве результата была заметна сразу.
Я ожидал увидеть интерфейс, в котором можно собирать уровень и его составные части — спрайты, сущности и раскладку тайлов — а затем запускать уровень в игровом режиме. Сначала я открыл результат одноагентного запуска, и на первый взгляд приложение выглядело соответствующим этим ожиданиям.
Однако по мере взаимодействия начали проявляться проблемы. Макет неэффективно использовал пространство: панели фиксированной высоты оставляли большую часть области просмотра пустой. Пользовательский сценарий оказался слишком негибким.
При попытке наполнить уровень приложение требовало сначала создать спрайты и сущности, но интерфейс никак не подсказывал, что действия нужно выполнять именно в такой последовательности.
И главное — сама игра была сломана. Сущности отображались на экране, но не реагировали на ввод. Анализ кода показал, что связь между описанием сущностей и игровым движком была нарушена, при этом в интерфейсе не было никаких признаков того, где именно возникала проблема.
После оценки одноагентного запуска я переключился на результат полной архитектуры обвязки. Этот запуск начинался с того же однострочного промпта, однако на этапе планирования запрос был развёрнут в спецификацию из 16 функций, распределенных по десяти спринтам.
Масштаб оказался значительно шире того, что пыталась реализовать одноагентная система. Помимо базовых редакторов и игрового режима, спецификация включала систему анимации спрайтов, шаблоны поведения, звуковые эффекты и музыку, ИИ-генератор спрайтов и уровней, а также экспорт игры с возможностью делиться ссылками.
Я предоставил планировщику доступ к нашему модулю проектирования фронтенда, который он использовал для создания визуального языка приложения как части спецификации. Для каждого спринта генератор и оценщик согласовывали контракт, определяющий конкретные детали реализации и проверяемые сценарии, по которым затем подтверждалось завершение работы.
Приложение сразу стало выглядеть более отполированным и плавным по сравнению с одноагентным запуском. Рабочая область занимала весь экран, размеры панелей были выбраны разумно, а интерфейс обладал целостной визуальной идентичностью, соответствующей дизайн-направлению из спецификации.
Часть неуклюжести, которую я заметил в одноагентной версии, всё же сохранилась: пользовательский сценарий по-прежнему не подсказывал, что перед наполнением уровня сначала нужно создать спрайты и сущности, и мне пришлось разбираться с этим методом проб и ошибок. Скорее это выглядело как недостаток продуктовой интуиции базовой модели, а не проблема, которую должна была решать архитектура обвязки.
Тем не менее это показало область, где целенаправленные итерации внутри системы могли бы дополнительно улучшить качество результата.
По мере работы с редакторами преимущества новой версии над одноагентной становились всё очевиднее. Редактор спрайтов оказался значительно богаче по возможностям: более аккуратные панели инструментов, улучшенный выбор цвета и более удобное масштабирование.
Поскольку я просил планировщика интегрировать ИИ-функции в спецификацию, приложение также получило встроенную интеграцию с Claude, позволявшую генерировать различные элементы игры через промпты. Это существенно ускоряло рабочий процесс.
Самое большое отличие проявилось в игровом режиме. Я действительно мог управлять своей сущностью и играть в игру. Физика всё ещё имела шероховатости — персонаж запрыгивал на платформу, но частично проваливался в неё, что интуитивно ощущалось неправильным, — однако базовая механика работала, а в одноагентной версии этого добиться не удалось.
После небольшого исследования уровня я столкнулся и с ограничениями ИИ при генерации игровых сцен. Например, на уровне оказалась огромная стена, через которую невозможно было перепрыгнуть, из-за чего прохождение блокировалось. Это указывало на наличие очевидных улучшений и пограничных сценариев, которые архитектура могла бы учитывать для дальнейшей доработки приложения.
При анализе логов стало ясно, что оценщик удерживал реализацию в рамках спецификации. В каждом спринте он проходил по критериям тестирования, указанным в контракте спринта, и проверял работающее приложение через Playwright, создавая баг-репорты для всего, что отклонялось от ожидаемого поведения.
Контракты были достаточно детализированными — только для третьего спринта существовало 27 критериев, связанных с редактором уровней, — а замечания оценщика были достаточно конкретными, чтобы их можно было исправлять без дополнительного расследования. В таблице ниже приведено несколько примеров проблем, выявленных нашим оценщиком:
Критерий контракта | Замечание оценщика |
Инструмент прямоугольной заливки должен позволять заполнить прямоугольную область выбранным тайлом через зажатие и перетаскивание мыши | FAIL — инструмент размещает тайлы только в начальной и конечной точках перетаскивания вместо заполнения всей области. Функция |
Пользователь должен иметь возможность выбирать и удалять размещенные точки появления сущностей | FAIL — обработчик клавиши Delete в |
Пользователь должен иметь возможность менять порядок кадров анимации через API | FAIL — маршрут |
Добиться такого качества работы оценщика оказалось непросто. «Из коробки» Claude плохо справляется с ролью QA-агента. В ранних запусках я видел, как он находил реальные проблемы, а затем сам себя убеждал, что они несущественны, и всё равно аппрувил работу. Кроме того, он часто тестировал поверхностно, вместо того чтобы проверять пограничные сценарии, из-за чего более тонкие ошибки проскальзывали незамеченными.
Цикл настройки выглядел так: я читал логи оценщика, находил случаи, где его суждение расходилось с моим, и обновлял промпт QA, чтобы исправить эти проблемы. Понадобилось несколько раундов такого цикла разработки, прежде чем оценщик начал выставлять оценки на уровне, который я считал разумным.
Даже после этого результат работы архитектуры показывал ограничения модели в роли QA: мелкие проблемы с версткой, местами неинтуитивные взаимодействия и необнаруженные ошибки в более глубоко вложенных функциях, которые оценщик не проверил достаточно тщательно. Очевидно, что дальнейшая настройка могла бы раскрыть дополнительный потенциал верификации.
Но по сравнению с одноагентным запуском, где ключевая функция приложения просто не работала, прирост был очевиден.
Итерации над архитектурой обвязки
Первые результаты архитектуры обвязки выглядели многообещающе, но сама система была громоздкой, медленной и дорогой. Логичным следующим шагом стал поиск способов упростить архитектуру без потери производительности. Отчасти это было здравым смыслом, а отчасти следствием более общего принципа: каждый компонент в архитектуре обвязки кодирует предположение о том, чего модель не умеет делать самостоятельно.
Такие предположения стоит проверять на прочность: они могут быть неверными, а по мере улучшения моделей ещё и быстро устаревать. В нашей статье Building Effective Agents основная идея формулируется как «найдите самое простое возможное решение и усложняйте его только при необходимости». Этот паттерн стабильно встречается у всех, кто поддерживает агентную обвязку.
В первой попытке упростить систему я радикально урезал архитектуру и попробовал несколько новых творческих идей, но не смог воспроизвести производительность исходной версии. Кроме того, стало сложно понять, какие элементы архитектуры действительно были критически важными и каким именно образом они влияли на результат. Исходя из этого опыта, я перешел к более методичному подходу: удалял по одному компоненту за раз и оценивал, как это сказывалось на итоговом результате.
Пока я проходил эти циклы итераций, мы также выпустили Opus 4.6, что дало дополнительный повод снижать сложность архитектуры обвязки. Были веские основания ожидать, что 4.6 потребуется меньше внешних подпорок, чем 4.5.
В нашем анонсе релиза говорилось: «[Opus 4.6] тщательнее планирует, дольше удерживает агентные задачи, надежнее работает в крупных кодовых базах и лучше справляется с код-ревью и отладкой, чтобы находить собственные ошибки». Кроме того, модель существенно улучшилась в поиске по длинному контексту. Все эти возможности как раз и должна была дополнять архитектура обвязки.
Удаление спринтовой структуры
Я начал с полного удаления спринтовой структуры. Раньше спринты помогали разбивать работу на части, чтобы модель могла выполнять её связно и последовательно. С учетом улучшений в Opus 4.6 были основания полагать, что модель сможет справиться с задачей нативно, без такой декомпозиции.
Я оставил и планировщика, и оценщика, поскольку оба по-прежнему давали очевидную пользу. Без планировщика генератор занижал масштаб задачи: получив сырой промпт, он сразу начинал разработку, не формализуя предварительно объем работ, и в итоге создавал приложение с меньшим количеством функций, чем при использовании планировщика.
После удаления спринтовой структуры я перевел оценщика на единственный проход в конце запуска вместо оценки каждого спринта. Поскольку модель стала гораздо сильнее, изменилась и степень критичности оценщика для разных запусков: его полезность теперь зависела от того, насколько конкретная задача находилась за пределами того, что модель уже надежно умеет делать самостоятельно.
В 4.5 эта граница была близко: наши сборки находились на пределе того, что генератор мог качественно реализовать в одиночку, и оценщик находил существенные проблемы по ходу всей разработки.
В 4.6 базовые возможности модели выросли, поэтому граница сдвинулась дальше. Задачи, которым раньше была необходима проверка оценщика для связной реализации, теперь часто попадали в зону, где генератор хорошо справлялся сам. Для таких задач оценщик превращался в лишние накладные расходы. Но для частей сборки, которые всё ещё находились на границе возможностей генератора, оценщик продолжал давать заметный прирост.
Практический вывод состоит в том, что использование оценщика — не фиксированное решение в формате «да» или «нет». Его затраты оправданы тогда, когда задача выходит за пределы того, что текущая модель надежно выполняет самостоятельно.
Параллельно со структурным упрощением я также добавил промпты, улучшающие то, как архитектура обвязки встраивала ИИ-функции в каждое приложение. В частности, я добивался, чтобы генератор создавал полноценного агента, способного управлять функциональностью самого приложения через инструменты.
Это потребовало реальных итераций, поскольку соответствующие знания достаточно новые и слабо представлены в обучающих данных Claude. Но после достаточной настройки генератор начал корректно строить агентов.
Результаты обновленной архитектуры обвязки
Чтобы проверить обновленную архитектуру, я использовал следующий промпт для генерации цифровой звуковой рабочей станции (DAW) — программы для создания, записи и сведения музыки:
Build a fully featured DAW in the browser using the Web Audio API.
Запуск по-прежнему был долгим и дорогим: около 4 часов и $124 затрат на токены.
Большая часть времени пришлась на сборщик, который связно работал более двух часов без разбиения на спринты, необходимого Opus 4.5.
Агент и этап | Длительность | Стоимость |
Планировщик | 4,7 мин | $0.46 |
Сборка, раунд 1 | 2 ч 7 мин | $71.08 |
QA, раунд 1 | 8,8 мин | $3.24 |
Сборка, раунд 2 | 1 ч 2 мин | $36.89 |
QA, раунд 2 | 6,8 мин | $3.09 |
Сборка, раунд 3 | 10,9 мин | $5.88 |
QA, раунд 3 | 9,6 мин | $4.06 |
Итого, архитектура V2 | 3 ч 50 мин | $124.70 |
Как и в предыдущей версии архитектуры, планировщик развернул однострочный промпт в полноценную спецификацию. По логам было видно, что модель-генератор хорошо справилась с планированием приложения и проектированием агента, подключила агента к системе и протестировала его перед передачей результата в QA.
Тем не менее QA-агент всё ещё находил реальные пробелы. В обратной связи первого раунда он отметил:
«Это сильное приложение с отличным соответствием дизайну, добротным ИИ-агентом и хорошим бэкендом. Главная слабая точка — полнота функциональности: хотя приложение выглядит впечатляюще и ИИ-интеграция работает хорошо, несколько ключевых функций DAW реализованы только как визуальное отображение, без интерактивной глубины.
Клипы нельзя перетаскивать или перемещать на таймлайне, отсутствуют панели интерфейса для инструментов — ручки синтезатора, драм-пэды, — а также нет визуальных редакторов эффектов, например кривых эквалайзера или индикаторов компрессора. Это не пограничные случаи, а основные взаимодействия, без которых DAW нельзя считать удобной в работе; спецификация явно требовала их реализации».
Во втором раунде обратной связи он снова обнаружил несколько пробелов в функциональности.
Оставшиеся пробелы:
Запись звука всё ещё реализована как заглушка: кнопка переключается, но захвата микрофона нет.
Изменение длины клипа перетаскиванием за край и разрезание клипа не реализованы.
Визуализации эффектов представлены числовыми ползунками, а не графическими элементами: нет, например, кривой эквалайзера.
Если оставить генератор действовать самостоятельно, он всё ещё мог упускать детали или подменять функции заглушками. QA по-прежнему приносил пользу, выявляя эти проблемы финального этапа, чтобы генератор мог их исправить.
Исходя из промпта, я ожидал получить программу, в которой можно создавать мелодии, гармонии и барабанные партии, раскладывать их в песню и по ходу работы получать помощь от встроенного агента. В этом видео показан результат.
Приложение далеко от профессиональной программы для создания музыки, а навыки агента в сочинении композиций явно требуют серьезной доработки. Кроме того, Claude фактически не может слышать звук, из-за чего цикл обратной связи QA был менее эффективен в вопросах музыкального вкуса.
Тем не менее итоговое приложение содержало все ключевые компоненты рабочей программы для создания музыки: полноценное окно аранжировки, микшер и транспортную панель, работающие прямо в браузере. Более того, я смог собрать короткий музыкальный фрагмент исключительно через промпты: агент задал темп и тональность, создал мелодию, собрал барабанную партию, настроил уровни микшера и добавил реверберацию.
Базовые примитивы для создания музыки присутствовали, и агент мог автономно управлять ими, используя инструменты для создания простой композиции от начала до конца. Можно сказать, что система пока ещё не идеально попадает в ноты — но она уже движется в этом направлении.
Что дальше
По мере развития моделей можно ожидать, что они смогут работать дольше и справляться со всё более сложными задачами. В некоторых случаях это будет означать, что внешняя обвязка вокруг модели со временем станет менее значимой, а разработчики смогут просто дождаться следующей версии модели, после чего часть проблем исчезнет сама собой.
С другой стороны, чем сильнее становятся модели, тем больше появляется пространства для создания архитектур обвязки, способных решать задачи, выходящие за пределы базовых возможностей модели.
С учетом этого из проделанной работы можно вынести несколько важных уроков. Полезно постоянно экспериментировать с моделью, на которой строится система, анализировать её трейсы на реалистичных задачах и настраивать поведение под нужные результаты.
При работе со сложными задачами часто помогает декомпозиция проблемы и использование специализированных агентов для отдельных аспектов работы.
А при появлении новой модели стоит заново пересматривать архитектуру обвязки: убирать элементы, которые больше не влияют критически на производительность, и добавлять новые компоненты, открывающие возможности, ранее недостижимые.
После этой работы я окончательно убедился, что пространство интересных комбинаций архитектур обвязки не сужается по мере развития моделей. Оно просто смещается. И задача инженеров в области ИИ — продолжать находить новые необычные и эффективные комбинации.
Приложение: пример плана, сгенерированного агентом-планировщиком.
RetroForge — конструктор 2D-ретро-игр
Обзор
RetroForge — это веб-студия для проектирования и создания 2D-игр в ретро-стиле. Она сочетает ностальгическое обаяние классической 8- и 16-битной эстетики с современными и интуитивно понятными инструментами редактирования, позволяя всем — от любителей до инди-разработчиков — воплощать игровые идеи без написания традиционного кода.
Платформа включает четыре интегрированных творческих модуля: тайловый редактор уровней для проектирования игровых миров, редактор пиксель-арта для создания визуальных ассетов, визуальную систему поведения сущностей для настройки игровой логики и мгновенный режим тестирования, позволяющий проверять геймплей в реальном времени. Благодаря встроенной AI-помощи на базе Claude RetroForge ускоряет творческий процесс: помогает генерировать спрайты, проектировать уровни и настраивать поведение сущностей через взаимодействие на естественном языке.
RetroForge ориентирован на создателей, которым близка эстетика ретро-игр, но при этом нужны современные удобные инструменты. Пользователи могут быстро прототипировать, визуально дорабатывать и делиться своими проектами — будь то попытка воссоздать платформеры, RPG или экшен-игры из детства либо придумать совершенно новый опыт в рамках ретро-ограничений.
Возможности
1. Панель управления проектами
Панель управления проектами — это отправная точка всей творческой работы в RetroForge. Пользователям нужен понятный и организованный способ управлять своими игровыми проектами: создавать новые, возвращаться к незавершенным и с первого взгляда понимать, что содержится в каждом проекте.
Пользовательские сценарии
Как пользователь, я хочу:
— создать новый игровой проект с названием и описанием, чтобы начать проектировать свою игру;
— видеть все существующие проекты в виде визуальных карточек с названием проекта, датой последнего изменения и миниатюрой предпросмотра, чтобы быстро находить нужный проект и продолжать работу;
— открыть любой проект и перейти в полноценное рабочее пространство игрового редактора, чтобы работать над игрой;
— удалять ненужные проекты с подтверждением действия, чтобы случайно ничего не потерять и поддерживать порядок в рабочем пространстве;
— дублировать существующий проект как основу для новой игры, чтобы переиспользовать уже проделанную работу.
Модель данных проекта
Каждый проект содержит:
— метаданные проекта: название, описание, время создания и последнего изменения;
— настройки холста: разрешение, например 256×224, 320×240 или 160×144;
— настройки размера тайлов: 8×8, 16×16 или 32×32 пикселя;
— выбранную цветовую палитру;
— все связанные спрайты, тайлсеты, уровни и определения сущностей.
Тема ИИ-агентов уже уходит от споров «заменят / не заменят» к более практичному вопросу: как встроить их в рабочие процессы так, чтобы они действительно помогали. В OTUS пройдут два бесплатных демо-урока на эту тему: можно познакомиться с экспертами, задать вопросы и разобраться, где агенты уже применимы на практике.
27 мая в 20:00 — «Мифы про ИИ-агентов: что реально работает в 2026 году»
Обсудим, где вокруг ИИ-агентов больше ожиданий, чем пользы, какие сценарии уже работают и почему это не только история для разработчиков. Записаться15 июня в 20:00 — «Интеграция ИИ-агентов в рабочую разработку: обвязка агента навыками и MCP»
Поговорим о правилах, инструментах, контексте, навыках и MCP, которые помогают встроить агента в реальный процесс разработки. Записаться
Полный список бесплатных уроков по AI, разработке и не только уже доступен в календаре мероприятий.
