Harness design for long-running application development

Автор — Притхви Раджасекаран, участник нашей команды Labs.

Последние несколько месяцев я работал над двумя взаимосвязанными задачами: добиться, чтобы Claude создавал качественные фронтенд-дизайны, и научить его собирать полноценные приложения без участия человека. Эта работа выросла из более ранних усилий над нашим навыком frontend design и harness для долго работающего coding-агента, где мы с коллегами смогли существенно поднять показатели Claude выше базового уровня с помощью prompt engineering и проектирования harness, — но оба подхода в итоге упёрлись в потолок.

Чтобы пробить этот потолок, я искал новые подходы к AI-инженерии, которые работали бы в двух очень разных областях: одна определяется субъективным вкусом, другая — проверяемой корректностью и удобством использования. Вдохновившись Generative Adversarial Networks (GAN), я спроектировал многоагентную структуру с агентами генератора и оценщика. Чтобы построить оценщика, который надёжно — и со вкусом — оценивает результаты, нужно было сначала разработать набор критериев, превращающих субъективные суждения вроде «хорош ли этот дизайн?» в конкретные, измеримые понятия.

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

Почему наивные реализации не работают

Мы уже показывали, что проектирование harness существенно влияет на эффективность долгосрочного агентного кодинга. В одном из ранних экспериментов мы использовали агента-инициализатора, чтобы разложить продуктовую спецификацию на список задач, и coding-агента, который реализовывал задачи по одной фиче за раз, передавая артефакты для переноса контекста между сессиями. Более широкое сообщество разработчиков сошлось на похожих идеях — например, метод «Ralph Wiggum», использующий hooks или скрипты, чтобы поддерживать агентов в непрерывных итерациях.

Но часть проблем оставалась устойчивой. На более сложных задачах агент со временем всё равно начинает уходить с рельсов. Разбирая эту проблему, мы заметили два частых режима отказа у агентов, выполняющих такие задачи.

Первый — модели теряют связность на длинных задачах по мере заполнения контекстного окна (см. наш пост про context engineering). Некоторые модели также демонстрируют «context anxiety» — преждевременно сворачивают работу, приближаясь к тому, что считают своим пределом контекста. Context resets — полная очистка контекстного окна и запуск свежего агента вместе со структурированной передачей состояния предыдущего агента и следующих шагов — решают обе эти проблемы.

Это отличается от компакции, при которой ранние части диалога суммируются на месте, и тот же агент продолжает работу по сокращённой истории. Компакция сохраняет непрерывность, но не даёт агенту чистого листа, а значит, context anxiety может сохраняться. Reset обеспечивает чистый лист — ценой того, что артефакт передачи должен содержать достаточно состояния, чтобы следующий агент мог чисто подхватить работу. В наших ранних тестах Claude Sonnet 4.5 проявлял context anxiety настолько сильно, что одной компакции было недостаточно для устойчивой работы на длинных задачах, поэтому context resets стали критичной частью архитектуры harness. Это решает корневую проблему, но добавляет сложности оркестрации, накладных расходов на токены и задержки в каждый прогон harness.

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

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

Frontend design: как сделать субъективное качество измеримым

Я начал с экспериментов на frontend design, где проблема самооценки была заметнее всего. Без вмешательства Claude обычно тяготеет к безопасным, предсказуемым макетам — технически работающим, но визуально невыразительным.

Harness для frontend design я строил на двух идеях. Во-первых, эстетику нельзя полностью свести к оценке — и индивидуальные вкусы всегда будут различаться, — но её можно улучшить через критерии, кодирующие принципы дизайна и предпочтения. На вопрос «красив ли этот дизайн?» сложно ответить одинаково; вопрос «следует ли он нашим принципам хорошего дизайна?» даёт Claude конкретный ориентир. Во-вторых, разделяя генерацию и оценку фронтенда, мы создаём цикл обратной связи, который подталкивает генератор к более сильным результатам.

С учётом этого я сформулировал четыре критерия оценки и заложил их в промпты как генератора, так и оценщика:

Качество дизайна: Воспринимается ли дизайн как целостное целое, а не набор разрозненных частей? Сильная работа здесь означает, что цвета, типографика, вёрстка, изображения и прочие детали вместе создают отчётливое настроение и идентичность.Оригинальность: Видны ли следы кастомных решений или это шаблонные макеты, дефолты библиотек и AI-сгенерированные паттерны? Дизайнер-человек должен распознать осознанные творческие решения. Немодифицированные стоковые компоненты — или характерные признаки AI-генерации вроде фиолетовых градиентов поверх белых карточек — здесь не проходят.Мастерство (Craft): Техническое исполнение: иерархия типографики, согласованность отступов, гармония цветов, контрастность. Это проверка компетентности, а не креативности. Большинство разумных реализаций по умолчанию справляются; провал означает сломанные основы.Функциональность: Удобство использования вне зависимости от эстетики. Понимают ли пользователи, что делает интерфейс, находят ли основные действия и выполняют ли задачи без догадок?

Я ставил акцент на качество дизайна и оригинальность над мастерством и функциональностью. По умолчанию Claude уже хорошо справлялся с craft и functionality — нужная техническая компетентность давалась модели естественно. Но в дизайне и оригинальности Claude часто выдавал в лучшем случае пресные результаты. Критерии явно штрафовали обобщённые паттерны «AI slop», а повышенный вес дизайна и оригинальности подталкивал модель к большему эстетическому риску.

Я откалибровал оценщика с помощью few-shot примеров с подробной разбивкой оценок. Это согласовало суждения оценщика с моими предпочтениями и уменьшило дрейф оценок между итерациями.

Цикл я построил на Claude Agent SDK, что упростило оркестрацию. Сначала агент-генератор создавал фронтенд на HTML/CSS/JS по пользовательскому промпту. Оценщику я дал Playwright MCP, чтобы он мог напрямую взаимодействовать с живой страницей перед тем, как выставить оценки по каждому критерию и написать подробный разбор. На практике оценщик сам перемещался по странице, делал скриншоты и внимательно изучал реализацию, прежде чем выдать вердикт. Эта обратная связь затем поступала генератору как вход для следующей итерации. Я прогонял по 5–15 итераций на генерацию, и каждая итерация, как правило, толкала генератор в более своеобразном направлении в ответ на критику оценщика. Поскольку оценщик активно навигировал по странице, а не оценивал статический скриншот, каждый цикл занимал реальное время. Полные прогоны растягивались до четырёх часов. Я также инструктировал генератор после каждой оценки принимать стратегическое решение: уточнять текущее направление, если оценки росли, или резко переключаться на совершенно иную эстетику, если подход не работал.

От прогона к прогону оценки оценщика улучшались по мере итераций и затем выходили на плато, оставляя ещё запас. Некоторые генерации уточнялись постепенно. Другие резко меняли эстетический курс между итерациями.

Формулировки критериев направляли генератор так, как я полностью не предвидел. Включение фраз вроде «лучшие дизайны имеют музейное качество» подталкивало дизайны к определённой визуальной сходимости, что говорит: язык, связанный с критериями, напрямую формировал характер выхода.

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

В одном показательном примере я попросил модель создать сайт для голландского художественного музея. К девятой итерации она выдала аккуратную тёмную лендинговую страницу для вымышленного музея. Страница была визуально отполирована, но в целом отвечала моим ожиданиям. Затем на десятом цикле модель полностью отказалась от подхода и переосмыслила сайт как пространственный опыт: 3D-комната с шахматным полом, отрендеренным в CSS-перспективе, картины свободно развешены по стенам, а навигация между залами происходит через дверные проёмы, а не через скролл или клик. Это был тот творческий скачок, какого я раньше не видел от генерации в один проход.

Масштабирование на fullstack-кодинг

С этими находками я применил GAN-подобный паттерн к fullstack-разработке. Цикл генератор–оценщик естественно ложится на жизненный цикл разработки ПО, где code review и QA играют ту же структурную роль, что и оценщик дизайна.

Архитектура

В нашем раннем long-running harness мы добивались связного многосессионного кодинга с помощью агента-инициализатора, coding-агента, работающего по одной фиче за раз, и context resets между сессиями. Context resets были ключевым инструментом: harness использовал Sonnet 4.5, у которого проявлялся упомянутый эффект «context anxiety». Сделать harness, который хорошо работает с context resets, было ключом к удержанию модели на задаче. Opus 4.5 в значительной мере убрал это поведение сам, поэтому я смог полностью отказаться от context resets в этом harness. Агенты работали как одна непрерывная сессия на протяжении всей сборки, а автоматическая компакция Claude Agent SDK сама управляла ростом контекста.

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

Планировщик (Planner): Наш предыдущий long-running harness требовал, чтобы пользователь заранее давал подробную спецификацию. Я хотел автоматизировать этот шаг, поэтому создал агента-планировщика, который брал короткий промпт из 1–4 предложений и разворачивал его в полную продуктовую спеку. Я промптил его быть амбициозным в области охвата и сосредоточиться на продуктовом контексте и архитектуре верхнего уровня, а не на детальной технической реализации. Этот акцент возник из опасения: если планировщик попытается заранее задать гранулярные технические детали и ошибётся, ошибки в спеке каскадно повлияют на дальнейшую реализацию. Казалось разумнее ограничивать агентов конкретными целевыми результатами и позволять им самим находить путь по ходу работы. Также я попросил планировщика искать возможности вплести AI-функции в продуктовые спецификации. (Пример см. в Приложении внизу.)

Генератор (Generator): Подход «по одной фиче за раз» из предыдущего harness хорошо работал для управления объёмом. Я применил аналогичную модель здесь, инструктируя генератор работать спринтами, забирая по одной фиче за раз из спецификации. Каждый спринт реализовывал приложение на стеке React, Vite, FastAPI и SQLite (позже PostgreSQL), а в конце каждого спринта генератор должен был самостоятельно оценить работу перед передачей в QA. У него также был git для контроля версий.

Оценщик (Evaluator): Приложения из ранних harness часто выглядели впечатляюще, но имели реальные баги, как только начнёшь ими пользоваться. Чтобы их ловить, оценщик с помощью Playwright MCP кликал по работающему приложению так, как делал бы пользователь, проверяя UI-функции, API-эндпоинты и состояния базы данных. Затем он оценивал каждый спринт как по найденным багам, так и по набору критериев, смоделированных по фронтенд-эксперименту и адаптированных для покрытия глубины продукта, функциональности, визуального дизайна и качества кода. У каждого критерия был жёсткий порог, и если хоть один опускался ниже, спринт не проходил, а генератор получал подробную обратную связь о том, что пошло не так. Перед каждым спринтом генератор и оценщик согласовывали sprint contract — договаривались, как выглядит «готово» для этого куска работы, ещё до написания кода. Это нужно было, потому что продуктовая спека намеренно была верхнеуровневой, и я хотел получить шаг, мостящий разрыв между user stories и тестируемой реализацией. Генератор предлагал, что он будет строить и как проверять успех, а оценщик проверял это предложение, чтобы убедиться, что генератор строит правильную вещь. Они итерировали, пока не приходили к согласию.

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

Запуск harness

Для первой версии этого harness я использовал Claude Opus 4.5, прогоняя пользовательские промпты через полный harness и систему из одного агента для сравнения. Opus 4.5 был выбран, поскольку это была наша лучшая модель для кодинга на момент начала экспериментов.

Я составил такой промпт, чтобы сгенерировать ретро-конструктор видеоигр:

Создай 2D ретро-конструктор игр с функциями level editor, sprite editor, поведением сущностей и игровым тестовым режимом.

В таблице ниже показаны тип harness, длительность прогона и общая стоимость.

Harness обошёлся более чем в 20 раз дороже, но разница в качестве выхода была очевидна сразу.

Я ожидал интерфейс, в котором можно собрать уровень и его компоненты (спрайты, сущности, раскладку тайлов), а затем нажать «play» и реально поиграть в уровень. Я начал с открытия результата одиночного прогона, и первоначальное приложение, казалось, соответствовало этим ожиданиям.

Однако по мере того, как я кликал, начали всплывать проблемы. Раскладка тратила пространство: панели с фиксированной высотой оставляли большую часть viewport пустой. Workflow был жёстким. При попытке заполнить уровень мне предлагалось сначала создать спрайты и сущности, но ничего в UI не подсказывало эту последовательность. Главное — сама игра была сломана. Мои сущности появлялись на экране, но ни одна не реагировала на ввод. Анализ кода показал, что связь между определениями сущностей и runtime игры была сломана, без каких-либо внешних индикаторов где именно.

После оценки одиночного прогона я переключился на прогон через harness. Этот прогон стартовал с того же односложного промпта, но шаг планировщика развернул промпт в спеку из 16 фич, распределённых по десяти спринтам. Это шло далеко за рамки того, на что замахнулся одиночный прогон. Помимо основных редакторов и режима игры, спека требовала систему анимации спрайтов, шаблоны поведения, звуковые эффекты и музыку, AI-ассистированный генератор спрайтов и дизайнер уровней, а также экспорт игры со shareable-ссылками. Я дал планировщику доступ к нашему навыку frontend design, который тот прочитал и использовал, чтобы создать визуальный язык дизайна приложения как часть спеки. Для каждого спринта генератор и оценщик согласовывали контракт, определяющий конкретные детали реализации и тестируемые поведения, которые проверялись бы для подтверждения завершения.

Приложение сразу показало больше отполированности и плавности, чем одиночный прогон. Canvas использовал весь viewport, панели имели разумные размеры, у интерфейса была согласованная визуальная идентичность, отслеживающая дизайн-направление из спеки. Часть неуклюжести, которую я видел в одиночном прогоне, осталась: workflow по-прежнему не подсказывал, что сначала надо собрать спрайты и сущности, а потом заполнять уровень, — это пришлось выяснять методом тыка. Это читалось скорее как пробел в продуктовой интуиции базовой модели, а не как то, на что был рассчитан harness, но указывало на место, где целевая итерация внутри harness могла бы дополнительно улучшить выход.

По мере работы с редакторами преимущества нового прогона над одиночным становились всё заметнее. Sprite editor был богаче и функциональнее, с более чистыми палитрами инструментов, удобным color picker и более пригодными контролами zoom.

Поскольку я просил планировщика вплетать AI-функции в спеки, приложение также шло с встроенной интеграцией Claude, позволявшей генерировать разные части игры через промптинг. Это существенно ускоряло workflow.

Главное отличие было в режиме игры. Я действительно мог двигать сущность и играть в игру. У физики были шероховатости — мой персонаж запрыгивал на платформу, но оказывался перекрытым с ней, что интуитивно казалось неправильным, — но ядро работало, чего одиночный прогон не сумел. Поиграв немного, я столкнулся с ограничениями в построении уровня от AI: была большая стена, через которую я не мог перепрыгнуть, и застрял. Это говорило, что есть очевидные улучшения и edge cases, которые harness мог бы обработать, чтобы дополнительно отполировать приложение.

Из логов было видно, что оценщик удерживал реализацию в рамках спеки. На каждом спринте он проходил тестовые критерии sprint contract и тестировал работающее приложение через Playwright, заводя баги на всё, что расходилось с ожидаемым поведением. Контракты были детальными — один только Спринт 3 имел 27 критериев по level editor, — а находки оценщика были достаточно конкретными, чтобы по ним можно было действовать без дополнительного расследования. В таблице ниже несколько примеров проблем, выявленных нашим оценщиком:

Чтобы добиться такого уровня работы оценщика, пришлось потрудиться. «Из коробки» Claude — плохой QA-агент. В ранних прогонах я видел, как он выявляет реальные проблемы, а затем уговаривает себя, что они не критичны, и всё равно одобряет работу. Он также склонен тестировать поверхностно, не докапываясь до edge cases, поэтому более тонкие баги часто проскальзывали. Цикл настройки заключался в том, чтобы читать логи оценщика, находить случаи, где его суждение расходилось с моим, и обновлять промпт QA для решения этих проблем. Потребовалось несколько раундов такого цикла разработки, прежде чем оценщик начал ставить оценки разумным с моей точки зрения образом. Даже тогда выход harness показывал пределы возможностей QA модели: мелкие проблемы вёрстки, кое-где неинтуитивные взаимодействия и необнаруженные баги в глубоко вложенных функциях, которые оценщик не отработал тщательно. Запас по верификации явно ещё оставался для дальнейшей настройки. Но по сравнению с одиночным прогоном, где центральная функция приложения попросту не работала, выигрыш был очевиден.

Итерация harness

Первый набор результатов от harness вдохновлял, но он также был громоздким, медленным и дорогим. Логичный следующий шаг — найти способы упростить harness, не теряя его производительности. Это было отчасти здравым смыслом, отчасти проявлением более общего принципа: каждый компонент в harness кодирует предположение о том, чего модель не может сама, и эти предположения стоит проверять на прочность — как потому, что они могут быть неверны, так и потому, что они быстро устаревают по мере улучшения моделей. Наш пост Building Effective Agents формулирует ту же идею так: «находите самое простое решение и наращивайте сложность только при необходимости» — и это паттерн, который постоянно всплывает у любого, кто поддерживает harness агента.

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

Пока я проходил эти итерационные циклы, мы выпустили Opus 4.6, что дополнительно мотивировало снижать сложность harness. Были веские причины ожидать, что 4.6 потребуется меньше scaffolding, чем 4.5. Из нашего launch-блога: «[Opus 4.6] планирует тщательнее, дольше удерживает агентные задачи, надёжнее работает на крупных кодовых базах и имеет улучшенные навыки code review и debugging, чтобы ловить собственные ошибки». Он также существенно улучшил извлечение информации из длинного контекста. Всё это — способности, которые harness и был призван дополнять.

Удаление конструкции спринтов

Я начал с того, что полностью убрал конструкцию спринтов. Структура спринтов помогала разбивать работу на куски, чтобы модель работала связно. Учитывая улучшения в Opus 4.6, были основания полагать, что модель справится со всем нативно, без такой декомпозиции.

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

С удалённой конструкцией спринтов я перевёл оценщика на единый проход в конце прогона, а не на оценку каждого спринта. Поскольку модель стала намного способнее, изменилась и нагрузка на оценщика для разных прогонов: его полезность зависела от того, где задача расположена относительно того, что модель надёжно делает сама. На 4.5 эта граница была близкой: наши сборки были на пределе того, что генератор мог сделать в одиночку, и оценщик ловил значимые проблемы по всей сборке. На 4.6 «сырая» способность модели выросла, и граница сдвинулась наружу. Задачи, которым прежде требовалась проверка оценщика для связной реализации, теперь часто оказывались в зоне, где генератор справлялся сам; для таких задач оценщик становился ненужным overhead. Но для тех частей сборки, что всё ещё находились на пределе возможностей генератора, оценщик продолжал давать реальный выигрыш.

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

Параллельно структурному упрощению я также добавил промптинг, чтобы улучшить, как harness встраивает AI-функции в каждое приложение, — конкретно, заставляя генератор собирать полноценного агента, который умеет управлять функциональностью приложения через инструменты. Это потребовало серьёзной итерации, поскольку соответствующие знания достаточно свежи, и обучающие данные Claude покрывают их слабо. Но после достаточной настройки генератор корректно собирал агентов.

Результаты обновлённого harness

Чтобы проверить обновлённый harness, я использовал следующий промпт для генерации Digital Audio Workstation (DAW) — программы для производства музыки, позволяющей сочинять, записывать и сводить песни:

Собери полнофункциональный DAW в браузере с использованием Web Audio API.

Прогон всё равно был долгим и дорогим: около 4 часов и $124 в токенах.

Большая часть времени ушла на builder, который связно работал более двух часов без декомпозиции спринтов, которая была нужна Opus 4.5.

Как и в предыдущем harness, планировщик развернул однострочный промпт в полную спеку. По логам видно, что модель-генератор хорошо спланировала приложение и дизайн агента, подключила агента и протестировала его перед передачей в QA.

При этом QA-агент всё равно ловил реальные пробелы. В обратной связи первого раунда он отметил:

Это сильное приложение с отличной fidelity дизайна, хорошим AI-агентом и хорошим бэкендом. Главная точка отказа — Feature Completeness: при том, что приложение выглядит впечатляюще, а AI-интеграция работает хорошо, несколько ключевых функций DAW сделаны display-only без интерактивной глубины: клипы нельзя перетаскивать/перемещать по timeline, нет UI-панелей инструментов (synth knobs, drum pads), и нет визуальных редакторов эффектов (EQ-кривые, индикаторы compressor). Это не edge cases — это ключевые взаимодействия, которые делают DAW пригодным к использованию, и спека явно их требует.

Во втором раунде обратной связи QA снова поймал несколько пробелов по функциональности:

Оставшиеся пробелы: - Запись звука всё ещё stub-only (кнопка переключается, но микрофон не пишет) - Изменение размера клипа за край и разделение клипа не реализованы - Визуализации эффектов — это числовые слайдеры, а не графика (нет EQ-кривой)

Генератор всё ещё был склонен упускать детали или оставлять заглушки фич, если его оставить наедине с задачей, и QA по-прежнему добавлял ценность, ловя такие «last mile» проблемы, которые генератор затем чинил.

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

Приложение далеко от профессиональной программы для производства музыки, а навыки агента в сочинении песен явно требуют большой доработки. К тому же Claude буквально не слышит, что делает цикл обратной связи QA менее эффективным с точки зрения музыкального вкуса.

Но в финальном приложении были все ключевые элементы рабочей программы для производства музыки: рабочая arrangement view, mixer и transport, работающие в браузере. Сверх того, я смог собрать короткий фрагмент песни целиком через промптинг: агент задал темп и тональность, выложил мелодию, построил drum track, скорректировал уровни на mixer и добавил reverb. Базовые примитивы для написания песен были на месте, и агент мог управлять ими автономно, используя инструменты, чтобы собрать простое произведение от начала до конца. Можно сказать, что пока ещё не идеально звучит, но к этому идёт.

Что дальше

По мере того как модели продолжают улучшаться, можно ожидать, что они смогут работать дольше и над более сложными задачами. В каких-то случаях это будет означать, что окружающий модель scaffolding со временем становится менее важным, и разработчики могут просто ждать следующую модель и наблюдать, как часть проблем решается сама. С другой стороны, чем лучше становятся модели, тем больше пространства для разработки harness, способных решать сложные задачи за пределами того, что модель умеет в базе.

С учётом этого, есть несколько уроков из этой работы, которые стоит унести с собой. Всегда полезно экспериментировать с моделью, под которую вы строите, читать её traces на реалистичных задачах и настраивать её производительность под желаемые исходы. На более сложных задачах иногда есть запас в декомпозиции задачи и применении специализированных агентов к каждой части проблемы. И когда выходит новая модель, обычно стоит пересмотреть harness, отбрасывая части, которые уже не несущие, и добавляя новые, чтобы достичь возможностей, которые прежде были недостижимы.

Из этой работы моё убеждение в том, что пространство интересных комбинаций harness не сужается по мере улучшения моделей. Оно смещается, и интересная работа AI-инженеров — продолжать находить следующую новую комбинацию.

Благодарности

Особая благодарность Майку Кригеру, Майклу Агаби, Джастину Янгу, Джереми Хэдфилду, Дэвиду Хёрши, Джулиусу Тарнгу, Сяои Чжан, Бэрри Чжану, Орова Сидкеру, Майклу Тингли, Ибрахиму Мадхе, Мартине Лонг и Каньону Роббинсу за их вклад в эту работу.

Спасибо также Джейку Итону, Алиссе Леонард и Стеф Секейре за помощь в работе над текстом поста.

Приложение

Пример плана, сгенерированного агентом-планировщиком.

RetroForge — 2D Retro Game Maker Обзор RetroForge — это веб-студия для проектирования и сборки 2D-видеоигр в ретро-стиле. Она соединяет ностальгическое очарование классической 8-bit и 16-bit эстетики игр с современными интуитивными инструментами редактирования, позволяя любому — от энтузиастов до инди-разработчиков — воплощать свои идеи игр без написания традиционного кода. Платформа предоставляет четыре интегрированных творческих модуля: Level Editor на основе тайлов для проектирования игровых миров, Sprite Editor для рисования pixel-art ассетов, визуальную систему Entity Behavior для определения игровой логики и режим Playable Test Mode для тестирования геймплея в реальном времени. Вплетая AI-ассистирование на всех уровнях (на базе Claude), RetroForge ускоряет творческий процесс — помогая пользователям генерировать спрайты, проектировать уровни и настраивать поведение через диалог на естественном языке. RetroForge ориентирован на создателей, которые любят ретро-эстетику игр, но хотят современных удобств. Воссоздают ли они platformers, RPG или action-игры своего детства или изобретают совершенно новый опыт в рамках ретро-ограничений — пользователи могут быстро прототипировать, итерировать визуально и делиться созданным с другими. Функции 1. Project Dashboard & Management Project Dashboard — это домашняя база для всей творческой работы в RetroForge. Пользователям нужен ясный, организованный способ управлять своими игровыми проектами — создавать новые, возвращаться к незавершённым работам и понимать, что в каждом проекте, с одного взгляда. User Stories: Как пользователь, я хочу: - Создать новый игровой проект с именем и описанием, чтобы начать проектировать свою игру - Видеть все мои существующие проекты как визуальные карточки с именем проекта, датой последнего изменения и превью-миниатюрой, чтобы быстро находить и продолжать работу - Открывать любой проект, чтобы войти в полное рабочее пространство редактора игры - Удалять проекты, которые мне больше не нужны, с подтверждающим диалогом, чтобы избежать случайностей, и поддерживать порядок в рабочем пространстве - Дублировать существующий проект как стартовую точку для новой игры, чтобы переиспользовать прошлые наработки Модель данных проекта: Каждый проект содержит: метаданные проекта (имя, описание, временные метки создания/изменения) настройки canvas (разрешение: например, 256x224, 320x240 или 160x144) конфигурацию размера тайла (8x8, 16x16 или 32x32 пикселя) выбор цветовой палитры все связанные спрайты, тайлсеты, уровни и определения сущностей ...