В последние месяцы шли эксперименты по двум связанным задачам: добиться от Claude выдачи качественных дизайнов интерфейсов и сборки полноценных приложений полностью самостоятельно. Эти усилия выросли из работ над навыком фронтенд-дизайна и каркасом для долгоживущих кодинговых агентов. Там удалось сильно поднять производительность Claude за счет точной настройки промтов и конструкции harness, но в итоге уперлись в ограничения.
Чтобы преодолеть барьер, применили свежий подход к инженерии ИИ, который сработал сразу в двух разных областях: одной — с субъективным вкусом, другой — с проверяемой правильностью и удобством. Взяв за основу генеративно-состязательные сети (GAN), построили структуру из нескольких агентов: генератор и оценщик. Надежный оценщик, который ставит баллы с учетом вкуса, потребовал сначала выделить критерии, превращающие вопросы вроде «хороший ли дизайн?» в четкие, оцениваемые пункты.
Потом эти методы перенесли на автономную разработку кода в длинных сессиях, взяв два урока из прошлых harness: разбивать сборку на выполнимые части и передавать контекст через структурированные артефакты между сессиями. Итог — архитектура из трех агентов (планировщик, генератор, оценщик), которая выдавала насыщенные full-stack приложения за многочасовые автономные сессии кодинга.
Почему простые реализации не справляются
Ранее уже доказали, что дизайн harness сильно влияет на успех долгоживущих агентных кодинговых задач. В прошлом эксперименте инициализатор разбивал спецификацию продукта на список задач, а кодинговый агент реализовывал фичи по одной, передавая артефакты для сохранения контекста между сессиями. Сообщество разработчиков пришло к похожим выводам — например, метод Ralph Wiggum использует хуки или скрипты для непрерывных циклов итераций агентов.
Но проблемы оставались. На сложных задачах агент со временем сходит с рельсов. Разобрав неисправности, выявили два типичных сбоя при таких задачах.
Первая — модели теряют связность на длинных заданиях из-за заполнения контекстного окна (см. пост о инженерии контекста). Некоторые модели страдают «тревогой контекста» — начинают завершать работу раньше времени, приближаясь к предполагаемому лимиту. Сброс контекста — полная очистка окна с новым агентом плюс структурированная передача состояния и следующих шагов — решает обе проблемы.
Это не компакция, где ранние части беседы суммируют на месте для продолжения тем же агентом на укороченной истории. Компакция сохраняет непрерывность, но не дает чистого листа, так что тревога контекста может остаться. Сброс дает чистый лист ценой детального артефакта передачи для плавного продолжения. В прошлых тестах Claude Sonnet 4.5 сильно страдал от тревоги контекста, компакции одной не хватало для длинных задач, так что сбросы стали ключевыми в harness. Это решает суть, но добавляет сложность оркестрации, расход токенов и задержки.
Вторая проблема, ранее не освещавшаяся, — самооценка. Когда агенты оценивают свою работу, они уверенно хвалят ее, даже если для человека качество посредственное. Это особенно заметно на субъективных задачах вроде дизайна, где нет бинарной проверки как в тестах ПО. Полиролид ли интерфейс или шаблонный — вопрос вкуса, и агенты всегда завышают баллы своей работе.
Даже на задачах с проверяемыми результатами агенты иногда судят плохо, что мешает выполнению. Разделение исполнителя и судьи сильно помогает. Разделение само по себе не убирает снисходительность — оценщик тоже LLM, склонный к мягкости с LLM-выводом. Но настроить скептицизм у отдельного оценщика проще, чем заставить генератор критиковать себя, а наличие внешней обратной связи дает генератору опору для итераций.
Фронтенд-дизайн: превращение субъективного качества в баллы
Начали с фронтенд-дизайна, где самооценка давала самые заметные сбои. Без вмешательств Claude тянется к безопасным, предсказуемым макетам — функциональным, но визуально скучным.
Два ключевых вывода определили harness для фронтенда. Во-первых, эстетику не сведешь полностью к баллам — вкусы разные, — но улучшить можно критериями на основе принципов дизайна и предпочтений. Вопрос «красив ли дизайн?» трудно оценивать стабильно, а «соответствует ли принципам хорошего дизайна?» дает конкретную основу. Во-вторых, разделение генерации и оценки создает цикл обратной связи, толкающий генератор к лучшим результатам.
С этими идеями сформулировали четыре критерия оценки, которые передали промтами генератору и оценщику:
- Качество дизайна: Выглядит ли дизайн цельным, а не набором частей? Хороший результат — когда цвета, типографика, расположение, изображения и детали создают уникальное настроение и характер.
- Оригинальность: Есть ли следы авторских решений или это шаблоны, дефолты библиотек, типичные ИИ-паттерны? Человек-дизайнер должен увидеть осознанные креативные выборы. Стоковые компоненты без изменений или ИИ-признаки вроде фиолетовых градиентов на белых карточках проваливают критерий.
- Мастерство исполнения: Техническая сторона: иерархия шрифтов, равномерные отступы, гармония цветов, контраст. Это проверка базовых навыков, не креатива. Большинство разумных реализаций проходят по умолчанию; провал — сломанные основы.
- Функциональность: Удобство вне эстетики. Пользователи понимают, что делает интерфейс, находят ключевые действия и выполняют задачи без догадок?
Акцент на дизайне и оригинальности, а не на мастерстве и функциональности. Claude по умолчанию справлялся с техникой, но на дизайне и оригинальности выдавал пресные результаты. Критерии штрафовали шаблонный «ИИ-шлак», а больший вес дизайна и оригинальности подталкивал к смелым эстетическим рискам.
Оценщика откалибровали на few-shot примерах с разбором баллов. Это синхронизировало его с предпочтениями и минимизировало дрейф оценок по итерациям.
Цикл построили на Claude Agent SDK — оркестрация простая. Генератор сначала строил HTML/CSS/JS фронтенд по пользовательскому промту. Оценщику дали Playwright MCP для взаимодействия с живой страницей перед баллами и критикой по критериям. На практике оценщик сам просматривал страницу, скринил и изучал перед вердиктом. Обратная связь шла генератору на следующую итерацию. Делали 5–15 итераций за генерацию, каждая толкала к большему отличию по реакции на критику. Поскольку оценщик работал с живой страницей, цикл занимал реальное время. Полные запуски тянулись до четырех часов. Генератору велели стратегически решать после оценки: дорабатывать курс при росте баллов или менять эстетику при неудаче.
По запускам оценки росли по итерациям до плато, с запасом. Некоторые поколения шли инкрементально, другие резко меняли стиль.
Формулировки критериев непредсказуемо влияли на генератор. Фразы вроде «лучшие дизайны — музейного уровня» вели к визуальной конвергенции, показывая, как промты критериев формируют характер вывода.
Баллы росли, но не всегда линейно. Поздние версии лучше в целом, но иногда средняя итерация нравилась больше финальной. Сложность реализации росла — генератор тянулся к амбициозным решениям на обратную связь. Даже первая итерация превосходила базовый промт без оценки, — критерии и язык сразу отводили от шаблонов, а критика дорабатывала.
В ярком примере промт на сайт нидерландского художественного музея. К девятой итерации вышел чистый лендинг в темной теме для вымышленного музея — полированный, но ожидаемый. На десятой полностью перестроили в пространственный опыт: 3D-комната с шахматным полом в CSS-перспективе, картины на стенах в свободном расположении, навигация дверями вместо скролла или кликов. Такой креативный прыжок не встречался в однопроходных генерациях.
Масштабирование на full-stack кодинг
С этими выводами применили GAN-подход к full-stack разработке. Цикл генератор–оценщик ложится на цикл разработки ПО, где код-ревью и QA играют ту же роль, что дизайн-оценщик.
Архитектура
В прошлом долгоживущем harness решили coherentный кодинг в нескольких сессиях: инициализатор, кодер по фичам, сбросы контекста. Сбросы были ключом — использовали Sonnet 4.5 с «тревогой контекста». Правильный harness через сбросы держал модель на задаче. Opus 4.5 сам убрал это поведение, так что сбросы выкинули. Агенты шли в одной непрерывной сессии на всей сборке, с автоматической компакцией Claude Agent SDK.
На базе старого harness построили трехагентную систему, где каждый агент закрывал конкретный пробел из прошлых запусков. Персоны агентов:
Планировщик: Старый harness требовал детальной спецификации от пользователя заранее. Автоматизировали: планировщик из 1–4 предложений промта разворачивал полную продуктовую спецификацию. Промт делал его амбициозным по объему, фокусированным на продуктовом контексте и высокоуровневом техдизайне, без детального техреализующего. Если планировщик ошибется в гранулярных деталях, ошибки потекут вниз. Лучше ограничить агентов продуктом и дать им самим найти путь. Плюс велели вплести ИИ-функции в спецификацию. (Пример в приложении ниже.)
Генератор: Подход по одной фиче из старого harness хорошо управлял объемом. Здесь аналогично: спринты по фиче из спецификации. Каждый спринт строил стек React, Vite, FastAPI, SQLite (потом PostgreSQL), с самооценкой в конце перед QA. Плюс git для версионного контроля.
Оценщик: Приложения из старых harness впечатляли видом, но ломались в использовании. Оценщик с Playwright MCP кликал как пользователь: UI, API, БД. Затем баллы по спринту на баги и критериям из фронтенд-эксперимента, адаптированным под глубину продукта, функциональность, визуал, качество кода. Каждый критерий с жестким порогом: ниже — фейл спринта и детальная обратная связь.
Перед спринтом генератор и оценщик договаривались о контракте спринта: что значит «готово» до кода. Спецификация высокоуровневая, контракт мостит до testable реализации. Генератор предлагал, что и как проверить, оценщик правил, чтобы строили нужное. Итерации до согласия.
Общение через файлы: один пишет, другой читает и отвечает в файле или новом. Генератор строил по контракту, потом к QA. Это держало верность спецификации без преждевременных деталей реализации.
Запуск harness
Для первой версии harness использовали Claude Opus 4.5, сравнивая с соло-агентом. Opus 4.5 был топ-моделью для кодинга на старте экспериментов.
Промт для ретро-игрового конструктора:
Создай 2D-ретро игровой конструктор с редактором уровней, спрайтов, поведениями сущностей и тестовым режимом игры.
Таблица с типом harness, длительностью и стоимостью:
| Harness | Длительность | Стоимость |
|---|---|---|
| Solo | 20 мин | $9 |
| Полный harness | 6 ч | $200 |
Harness в 20+ раз дороже, но качество вывода сразу отличалось.
Ожидал интерфейс для сборки уровня (спрайты, сущности, тайлы), потом play. Соло-вывод сначала соответствовал: открытие показало ожидаемое.
Но при кликах вылезли проблемы. Макет тратил место зря — панели фиксированной высоты оставляли viewport пустым. Workflow жесткий: для заполнения уровня требовал спрайты и сущности сначала, без подсказок в UI. Главное — игра сломана: сущности видны, но без реакции на ввод. В коде обрыв связки определений и рантайма, без намека.
После соло перешли к harness. Из того же промта планировщик развернул 16 фич на 10 спринтов — дальше соло. Кроме редакторов и play: анимация спрайтов, шаблоны поведений, звуки/музыка, ИИ-генератор спрайтов/уровней, экспорт с шаринг-ссылками. Планировщик читал навык фронтенд-дизайна и добавил визуальный дизайн-язык в спецификацию. По спринтам — контракты с деталями реализации и тестами.
Приложение сразу полированнее соло: canvas на весь viewport, панели разумных размеров, единый визуал по спецификации. Клунковость осталась — workflow не подсказывал порядок (спрайты перед уровнем), пришлось ковырять. Это пробел базовой продуктовой интуиции модели, не цель harness, но итерации могли бы доработать.
В редакторах превосходство harness ярче: спрайт-редактор богаче — чистые инструменты, picker цветов, зум. Планировщик вписал ИИ-функции — встроенный Claude ускорял создание частей игры промтами.
Ключевое отличие — play mode. Сущность двигалась, игра работала. Физика с шероховатостями (персонаж налезал на платформу), но основа функционировала — соло не смог. Застрял у стены от ИИ-уровня — нужны common sense и edge cases для доработки.
Логи показали: оценщик держал по спецификации. По спринтам проверял критерии контракта через Playwright, фейлил отклонения. Контракты детальные — спринт 3 с 27 критериями по редактору уровней. Находки конкретны для фикса. Примеры:
| Критерий контракта | Находка оценщика |
|---|---|
| Инструмент заполнения прямоугольника позволяет клик-драг для заливки области тайлом | FAIL — Инструмент ставит тайлы только в старт/энд драга, не заливает. Функция fillRectangle есть, но не срабатывает на mouseUp. |
| Пользователь может выбрать и удалить точки спавна сущностей | FAIL — Хендлер Delete в LevelEditor.tsx:892 требует selection и selectedEntityId, но клик по сущности ставит только selectedEntityId. Условие: selection || (selectedEntityId && activeLayer === 'entity'). |
| Пользователь может переупорядочивать фреймы анимации через API | FAIL — Роут PUT /frames/reorder после /{frame_id}. FastAPI ловит 'reorder' как frame_id integer, 422: «unable to parse string as an integer». |
Довести оценщика до такого уровня стоило усилий. Без настройки Claude слаб как QA: находил баги, но убеждал себя в мелочи и одобрял. Тестировал поверхностно, пропуская edge cases. Настройка — читать логи, фиксить расхождения с промтом QA. Несколько раундов до разумных оценок. Выводы harness показывали лимиты QA модели: мелкие layout, неинтуитивные взаимодействия, недотестированные вложенные фичи. Запас для тюнинга есть. Но против соло, где core фича не работала, прогресс очевиден.
Итерации над harness
Первые результаты ободряли, но harness был громоздким, медленным, дорогим. Следующий шаг — упростить без потери производительности. Это здравый смысл плюс принцип: каждый компонент harness отражает, чего модель не умеет сама, — тестировать допущения, они устаревают с улучшением моделей. Пост Building Effective Agents формулирует: «самое простое решение, сложность только по нужде» — паттерн для harness.
Первый упрощающий раунд радикально срезал и добавил идеи, но не повторил оригинал. Стало неясно, что load-bearing. Перешли к методичному: убирать по одному, смотреть эффект.
Параллельно вышел Opus 4.6, мотивируя упрощение. Ожидалось меньше scaffolding. Из анонса: «[Opus 4.6] планирует тщательнее, держит агентные задачи дольше, работает надежнее в больших кодбейсах, лучше ревьюит и дебажит свои ошибки». Плюс long-context retrieval. Это то, чем harness компенсировал.
Убираем спринты
Сначала выкинули спринты. Они помогали разбивке для coherentности. Opus 4.6 мог сам.
Оставили планировщика и оценщика — ценность ясна. Без планировщика генератор недооценивал: строил без спеца, приложение беднее.
Без спринтов оценщик — один пасс в конце. Модель capable, так что роль оценщика зависела от задачи vs. соло-возможностей. На 4.5 граница близко: билды на краю, оценщик ловил много. На 4.6 граница outward: задачи в зоне соло не нуждались, оценщик — overhead. Но на краю — польза.
Вывод: оценщик не yes/no, стоит на задачах за соло-лимитом модели.
Плюс доработали промты для ИИ-фич: генератор строил агента с tools для своей функциональности. Требовало итераций — знания свежие, coverage слабый. Но настроили.
Результаты обновленного harness
Тест на промте для Digital Audio Workstation (DAW) — браузерного музыкального продакшена:
Построй полноценный DAW в браузере на Web Audio API.
Запуск ~4 часа, $124 токены.
Большинство времени — билдер, coherentно >2 часов без спринтов, нужных 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 Harness | 3 ч 50 мин | $124.70 |
Планировщик развернул промт в спеца. Логи: генератор хорошо спланировал app и агента, подключил, протестировал перед QA.
QA ловил пробелы. Первый фидбек:
Сильное приложение с верным дизайном, солидным ИИ-агентом, хорошим бэкендом. Главный фейл — полнота фич: app впечатляет, ИИ работает, но core DAW фичи display-only без интерактива: клипы не двигаются по timeline, нет панелей инструментов (синт-кнобы, драм-пэды), редакторов эффектов (EQ-кривые, компрессоры). Это не edge — core usability, спецификация требует.
Второй раунд:
Остатки:
- Запись аудио заглушка (кнопка мигает, микрофон не ловит)
- Ресайз клипа краем и сплит не сделаны
- Визуалы эффектов — слайдеры, не графики (без EQ-кривой)
Генератор сам мог упустить или заstubить, QA ловил last mile для фикса.
По промту ожидал: мелодии, гармонии, драм, аранж, ИИ-помощь. Видео ниже — результат.
App далек от проф, агент в композиции слаб. Claude не слышит, QA по вкусу хуже.
Но core DAW есть: аранж-вью, миксер, транспорт в браузере. Собрал snippet песни промтами: агент задал темп/тональность, мелодию, драм, микс, реверб. Примитивы композиции работали, агент вел tools end-to-end. Не идеал, но близко.
Что дальше
С ростом моделей ожидать дольше работы и сложнее задач. Иногда scaffold меньше нужен — жди следующую модель, проблемы уйдут. Но чем лучше модели, тем больше места для harness на задачи за базой.
Уроки: тестируй модель на реальных задачах, читай трассы, тюнь под цели. На сложном — разбивка и спецагенты по аспектам. При новой модели — перезапуск harness: убрать ненужное, добавить для новых высот.
Пространство интересных harness не сжимается с моделями — оно сдвигается, инженерам ИИ — искать новые комбинации.
Приложение
Пример плана от планировщика.
RetroForge - 2D Ретро Игровой Конструктор Обзор RetroForge — веб-студия для создания 2D-ретро игр. Сочетает ностальгию 8-бит/16-бит эстетики с современными редакторами — для хоббистов и инди от идеи к игре без традиционного кода. Четыре модуля: тайловый редактор уровней, пиксельный спрайтов, визуальные поведения сущностей, мгновенный тестовый play. ИИ (Claude) ускоряет: генерит спрайты, уровни, поведения промтами. Цель — фанаты ретро с современными удобствами. Прототипирование, итерации, шаринг. Фичи 1. Дашборд проектов Дом для работ: новые, WIP, обзор. User Stories: As a user, I want to: - Создать проект с именем/описанием для старта - Видеть проекты как карточки (имя, дата, thumb) для быстрого доступа - Открыть в редактор - Удалить с подтверждением - Дублировать для reuse Data Model: метаданные (имя, desc, timestamps), canvas (256x224, 320x240, 160x144), tile size (8x8, 16x16, 32x32), палитра, спрайты/тайлсеты/уровни/сущности ...