Harness design for long-running application development

Written by Prithvi Rajasekaran, a member of our Labs team.

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

Over the past several months I’ve been working on two interconnected problems: getting Claude to produce high-quality frontend designs, and getting it to build complete applications without human intervention. This work originated with earlier efforts on our frontend design skill and long-running coding agent harness, where my colleagues and I were able to improve Claude’s performance well above baseline through prompt engineering and harness design—but both eventually hit ceilings.

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

To break through, I sought out novel AI engineering approaches that held across two quite different domains, one defined by subjective taste, the other by verifiable correctness and usability. Taking inspiration from Generative Adversarial Networks (GANs), I designed a multi-agent structure with a generator and evaluator agent. Building an evaluator that graded outputs reliably—and with taste—meant first developing a set of criteria that could turn subjective judgments like “is this design good?” into concrete, gradable terms.

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

I then applied these techniques to long-running autonomous coding, carrying over two lessons from our earlier harness work: decomposing the build into tractable chunks, and using structured artifacts to hand off context between sessions. The final result was a three-agent architecture—planner, generator, and evaluator—that produced rich full-stack applications over multi-hour autonomous coding sessions.

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

Why naive implementations fall short

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

We've previously shown that harness design has a substantial impact on the effectiveness of long running agentic coding. In an earlier experiment, we used an initializer agent to decompose a product spec into a task list, and a coding agent that implemented the tasks one feature at a time before handing off artifacts to carry context across sessions. The broader developer community has converged on similar insights, with approaches like the "Ralph Wiggum" method using hooks or scripts to keep agents in continuous iteration cycles.

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

But some problems remained persistent. For more complex tasks, the agent still tends to go off the rails over time. While decomposing this issue, we observed two common failure modes with agents executing these sorts of tasks.

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

First is that models tend to lose coherence on lengthy tasks as the context window fills (see our post on context engineering). Some models also exhibit "context anxiety," in which they begin wrapping up work prematurely as they approach what they believe is their context limit. Context resets—clearing the context window entirely and starting a fresh agent, combined with a structured handoff that carries the previous agent's state and the next steps—addresses both these issues.

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

This differs from compaction, where earlier parts of the conversation are summarized in place so the same agent can keep going on a shortened history. While compaction preserves continuity, it doesn't give the agent a clean slate, which means context anxiety can still persist. A reset provides a clean slate, at the cost of the handoff artifact having enough state for the next agent to pick up the work cleanly. In our earlier testing, we found Claude Sonnet 4.5 exhibited context anxiety strongly enough that compaction alone wasn't sufficient to enable strong long task performance, so context resets became essential to the harness design. This solves the core issue, but adds orchestration complexity, token overhead, and latency to each harness run.

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

A second issue, which we haven’t previously addressed, is self-evaluation. When asked to evaluate work they've produced, agents tend to respond by confidently praising the work—even when, to a human observer, the quality is obviously mediocre. This problem is particularly pronounced for subjective tasks like design, where there is no binary check equivalent to a verifiable software test. Whether a layout feels polished or generic is a judgment call, and agents reliably skew positive when grading their own work.

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

However, even on tasks that do have verifiable outcomes, agents still sometimes exhibit poor judgment that impedes their performance while completing the task. Separating the agent doing the work from the agent judging it proves to be a strong lever to address this issue. The separation doesn't immediately eliminate that leniency on its own; the evaluator is still an LLM that is inclined to be generous towards LLM-generated outputs. But tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work, and once that external feedback exists, the generator has something concrete to iterate against.

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

Frontend design: making subjective quality gradable

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

I started by experimenting on frontend design, where the self-evaluation issue was most visible. Absent any intervention, Claude normally gravitates toward safe, predictable layouts that are technically functional but visually unremarkable.

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

Two insights shaped the harness I built for frontend design. First, while aesthetics can’t be fully reduced to a score—and individual tastes will always vary—they can be improved with grading criteria that encode design principles and preferences. "Is this design beautiful?" is hard to answer consistently, but "does this follow our principles for good design?" gives Claude something concrete to grade against. Second, by separating frontend generation from frontend grading, we can create a feedback loop that drives the generator toward stronger outputs.

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

With this in mind, I wrote four grading criteria that I gave to both the generator and evaluator agents in their prompts:

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

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

I emphasized design quality and originality over craft and functionality. Claude already scored well on craft and functionality by default, as the required technical competence tended to come naturally to the model. But on design and originality, Claude often produced outputs that were bland at best. The criteria explicitly penalized highly generic “AI slop” patterns, and by weighting design and originality more heavily it pushed the model toward more aesthetic risk-taking.

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

I calibrated the evaluator using few-shot examples with detailed score breakdowns. This ensured the evaluator’s judgment aligned with my preferences, and reduced score drift across iterations.

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

I built the loop on the Claude Agent SDK, which kept the orchestration straightforward. A generator agent first created an HTML/CSS/JS frontend based on a user prompt. I gave the evaluator the Playwright MCP, which let it interact with the live page directly before scoring each criterion and writing a detailed critique. In practice, the evaluator would navigate the page on its own, screenshotting and carefully studying the implementation before producing its assessment. That feedback flowed back to the generator as input for the next iteration. I ran 5 to 15 iterations per generation, with each iteration typically pushing the generator in a more distinctive direction as it responded to the evaluator's critique. Because the evaluator was actively navigating the page rather than scoring a static screenshot, each cycle took real wall-clock time. Full runs stretched up to four hours. I also instructed the generator to make a strategic decision after each evaluation: refine the current direction if scores were trending well, or pivot to an entirely different aesthetic if the approach wasn't working.

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

Across runs, the evaluator's assessments improved over iterations before plateauing, with headroom still remaining. Some generations refined incrementally. Others took sharp aesthetic turns between iterations.

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

The wording of the criteria steered the generator in ways I didn't fully anticipate. Including phrases like "the best designs are museum quality" pushed designs toward a particular visual convergence, suggesting that the prompting associated with the criteria directly shaped the character of the output.

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

While scores generally improved over iterations, the pattern was not always cleanly linear. Later implementations tended to be better as a whole, but I regularly saw cases where I preferred a middle iteration over the last one. Implementation complexity also tended to increase across rounds, with the generator reaching for more ambitious solutions in response to the evaluator’s feedback. Even on the first iteration, outputs were noticeably better than a baseline with no prompting at all, suggesting the criteria and associated language themselves steered the model away from generic defaults before any evaluator feedback led to further refinement.

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

In one notable example, I prompted the model to create a website for a Dutch art museum. By the ninth iteration, it had produced a clean, dark-themed landing page for a fictional museum. The page was visually polished but largely in line with my expectations. Then, on the tenth cycle, it scrapped the approach entirely and reimagined the site as a spatial experience: a 3D room with a checkered floor rendered in CSS perspective, artwork hung on the walls in free-form positions, and doorway-based navigation between gallery rooms instead of scroll or click. It was the kind of creative leap that I hadn't seen before from a single-pass generation.

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

Scaling to full-stack coding

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

With these findings in hand, I applied this GAN-inspired pattern to full-stack development. The generator-evaluator loop maps naturally onto the software development lifecycle, where code review and QA serve the same structural role as the design evaluator.

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

The architecture

Архитектура

In our earlier long-running harness, we had solved for coherent multi-session coding with an initializer agent, a coding agent that worked one feature at a time, and context resets between sessions. Context resets were a key unlock: the harness used Sonnet 4.5, which exhibited the “context anxiety” tendency mentioned earlier. Creating a harness that worked well across context resets was key to keeping the model on task. Opus 4.5 largely removed that behavior on its own, so I was able to drop context resets from this harness entirely. The agents were run as one continuous session across the whole build, with the Claude Agent SDK's automatic compaction handling context growth along the way.

В нашем раннем 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 сама управляла ростом контекста.

For this work I built on the foundation from the original harness with a three-agent system, with each agent addressing a specific gap I'd observed in prior runs. The system contained the following agent personas:

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

Planner: Our previous long-running harness required the user to provide a detailed spec upfront. I wanted to automate that step, so I created a planner agent that took a simple 1-4 sentence prompt and expanded it into a full product spec. I prompted it to be ambitious about scope and to stay focused on product context and high level technical design rather than detailed technical implementation. This emphasis was due to the concern that if the planner tried to specify granular technical details upfront and got something wrong, the errors in the spec would cascade into the downstream implementation. It seemed smarter to constrain the agents on the deliverables to be produced and let them figure out the path as they worked. I also asked the planner to find opportunities to weave AI features into the product specs. (See example in the Appendix at the bottom.)

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

Generator: The one-feature-at-a-time approach from the earlier harness worked well for scope management. I applied a similar model here, instructing the generator to work in sprints, picking up one feature at a time from the spec. Each sprint implemented the app with a React, Vite, FastAPI, and SQLite (later PostgreSQL) stack, and the generator was instructed to self-evaluate its work at the end of each sprint before handing off to QA. It also had git for version control.

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

Evaluator: Applications from earlier harnesses often looked impressive but still had real bugs when you actually tried to use them. To catch these, the evaluator used the Playwright MCP to click through the running application the way a user would, testing UI features, API endpoints, and database states. It then graded each sprint against both the bugs it had found and a set of criteria modeled on the frontend experiment, adapted here to cover product depth, functionality, visual design, and code quality. Each criterion had a hard threshold, and if any one fell below it, the sprint failed and the generator got detailed feedback on what went wrong.

Before each sprint, the generator and evaluator negotiated a sprint contract: agreeing on what "done" looked like for that chunk of work before any code was written. This existed because the product spec was intentionally high-level, and I wanted a step to bridge the gap between user stories and testable implementation. The generator proposed what it would build and how success would be verified, and the evaluator reviewed that proposal to make sure the generator was building the right thing. The two iterated until they agreed.

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

Communication was handled via files: one agent would write a file, another agent would read it and respond either within that file or with a new file that the previous agent would read in turn. The generator then built against the agreed-upon contract before handing the work off to QA. This kept the work faithful to the spec without over-specifying implementation too early.

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

Running the harness

Запуск harness

For the first version of this harness, I used Claude Opus 4.5, running user prompts against both the full harness and a single-agent system for comparison. I used Opus 4.5 since this was our best coding model when I began these experiments.

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

I wrote the following prompt to generate a retro video game maker:

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

Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode.

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

The table below shows the harness type, length it ran for, and the total cost.

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

The harness was over 20x more expensive, but the difference in output quality was immediately apparent.

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

I was expecting an interface where I could construct a level and its component parts (sprites, entities, tile layout) then hit play to actually play the level. I started by opening the solo run’s output, and the initial application seemed in line with those expectations.

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

As I clicked through, however, issues started to emerge. The layout wasted space, with fixed-height panels leaving most of the viewport empty. The workflow was rigid. Trying to populate a level prompted me to create sprites and entities first, but nothing in the UI guided me toward that sequence. More to the point, the actual game was broken. My entities appeared on screen but nothing responded to input. Digging into the code revealed that the wiring between entity definitions and the game runtime was broken, with no surface indication of where.

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

After evaluating the solo run, I turned my attention to the harness run. This run started from the same one-sentence prompt, but the planner step expanded that prompt into a 16-feature spec spread across ten sprints. It went well beyond what the solo run attempted. In addition to the core editors and play mode, the spec called for a sprite animation system, behavior templates, sound effects and music, an AI-assisted sprite generator and level designer, and game export with shareable links. I gave the planner access to our frontend design skill, which it read and used to create a visual design language for the app as part of the spec. For each sprint, the generator and evaluator negotiated a contract defining the specific implementation details for the sprint, and the testable behaviors that would be tested to verify completion.

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

The app immediately showed more polish and smoothness than the solo run. The canvas used the full viewport, the panels were sized sensibly, and the interface had a consistent visual identity that tracked the design direction from the spec. Some of the clunkiness I'd seen in the solo run did remain—the workflow still didn't make it clear that you should build sprites and entities before trying to populate a level, and I had to figure that out by poking around. This read as a gap in the base model’s product intuition rather than something the harness was designed to address, though it did suggest a place where targeted iteration inside the harness could help to further improve output quality.

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

Working through the editors, the new run's advantages over solo became more apparent. The sprite editor was richer and more fully featured, with cleaner tool palettes, a better color picker, and more usable zoom controls.

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

Because I'd asked the planner to weave AI features into its specs, the app also came with a built-in Claude integration that let me generate different parts of the game through prompting. This significantly sped up the workflow.

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

The biggest difference was in play mode. I was actually able to move my entity and play the game. The physics had some rough edges—my character jumped onto a platform but ended up overlapping with it, which felt intuitively wrong—but the core thing worked, which the solo run did not manage. After moving around a bit, I did hit some limitations with the AI’s game level construction. There was a large wall that I wasn’t able to jump past, so I was stuck. This suggested there were some common sense improvements and edge cases that the harness could handle to further refine the app.

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

Reading through the logs, it was clear that the evaluator kept the implementation in line with the spec. Each sprint, it walked through the sprint contract's test criteria and exercised the running application through Playwright, filing bugs against anything that diverged from expected behavior. The contracts were granular—Sprint 3 alone had 27 criteria covering the level editor—and the evaluator's findings were specific enough to act on without extra investigation. The table below shows several examples of issues our evaluator identified:

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

Getting the evaluator to perform at this level took work. Out of the box, Claude is a poor QA agent. In early runs, I watched it identify legitimate issues, then talk itself into deciding they weren't a big deal and approve the work anyway. It also tended to test superficially, rather than probing edge cases, so more subtle bugs often slipped through. The tuning loop was to read the evaluator's logs, find examples where its judgment diverged from mine, and update the QAs prompt to solve for those issues. It took several rounds of this development loop before the evaluator was grading in a way that I found reasonable. Even then, the harness output showed the limits of the model’s QAing capabilities: small layout issues, interactions that felt unintuitive in places, and undiscovered bugs in more deeply nested features that the evaluator hadn't exercised thoroughly. There was clearly more verification headroom to capture with further tuning. But compared to the solo run, where the central feature of the application simply didn't work, the lift was obvious.

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

Iterating on the harness

Итерация harness

The first set of harness results was encouraging, but it was also bulky, slow, and expensive. The logical next step was to find ways to simplify the harness without degrading its performance. This was partly common sense and partly a function of a more general principle: every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing, both because they may be incorrect, and because they can quickly go stale as models improve. Our blog post Building Effective Agents frames the underlying idea as "find the simplest solution possible, and only increase complexity when needed," and it's a pattern that shows up consistently for anyone maintaining an agent harness.

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

In my first attempt to simplify, I cut the harness back radically and tried a few creative new ideas, but I wasn't able to replicate the performance of the original. It also became difficult to tell which pieces of the harness design were actually load-bearing, and in what ways. Based on that experience, I moved to a more methodical approach, removing one component at a time and reviewing what impact it had on the final result.

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

As I was going through these iteration cycles, we also released Opus 4.6, which provided further motivation to reduce harness complexity. There was good reason to expect 4.6 would need less scaffolding than 4.5 did. From our launch blog: "[Opus 4.6] plans more carefully, sustains agentic tasks for longer, can operate more reliably in larger codebases, and has better code review and debugging skills to catch its own mistakes." It also improved substantially on long-context retrieval. These were all capabilities the harness had been built to supplement.

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

Removing the sprint construct

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

I started by removing the sprint construct entirely. The sprint structure had helped to decompose work into chunks for the model to work coherently. Given the improvements in Opus 4.6, there was good reason to believe that the model could natively handle the job without this sort of decomposition.

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

I kept both the planner and evaluator, as each continued to add obvious value. Without the planner, the generator under-scoped: given the raw prompt, it would start building without first speccing its work, and end up creating a less feature-rich application than the planner did.

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

With the sprint construct removed, I moved the evaluator to a single pass at the end of the run rather than grading per sprint. Since the model was much more capable, it changed how load-bearing the evaluator was for certain runs, with its usefulness depending on where the task sat relative to what the model could do reliably on its own. On 4.5, that boundary was close: our builds were at the edge of what the generator could do well solo, and the evaluator caught meaningful issues across the build. On 4.6, the model's raw capability increased, so the boundary moved outward. Tasks that used to need the evaluator's check to be implemented coherently were now often within what the generator handled well on its own, and for tasks within that boundary, the evaluator became unnecessary overhead. But for the parts of the build that were still at the edge of the generator’s capabilities, the evaluator continued to give real lift.

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

The practical implication is that the evaluator is not a fixed yes-or-no decision. It is worth the cost when the task sits beyond what the current model does reliably solo.

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

Alongside the structural simplification, I also added prompting to improve how the harness built AI features into each app, specifically getting the generator to build a proper agent that could drive the app's own functionality through tools. That took real iteration, since the relevant knowledge is recent enough that Claude's training data covers it thinly. But with enough tuning, the generator was building agents correctly.

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

Results from the updated harness

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

To put the updated harness to the test, I used the following prompt to generate a Digital Audio Workstation (DAW), a music production program for composing, recording, and mixing songs:

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

Build a fully featured DAW in the browser using the Web Audio API.

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

The run was still lengthy and expensive, at about 4 hours and $124 in token costs.

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

Most of the time went to the builder, which ran coherently for over two hours without the sprint decomposition that Opus 4.5 had needed.

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

As with the previous harness, the planner expanded the one-line prompt into a full spec. From the logs, I could see the generator model did a good job planning the app and the agent design, wiring the agent up, and testing it before handing off to QA.

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

That being said, the QA agent still caught real gaps. In its first-round feedback, it noted:

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

This is a strong app with excellent design fidelity, solid AI agent, and good backend. The main failure point is Feature Completeness — while the app looks impressive and the AI integration works well, several core DAW features are display-only without interactive depth: clips can't be dragged/moved on the timeline, there are no instrument UI panels (synth knobs, drum pads), and no visual effect editors (EQ curves, compressor meters). These aren't edge cases — they're the core interactions that make a DAW usable, and the spec explicitly calls for them.

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

In its second round feedback, it again caught several functionality gaps:

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

Remaining gaps:
- Audio recording is still stub-only (button toggles but no mic capture)
- Clip resize by edge drag and clip split not implemented
- Effect visualizations are numeric sliders, not graphical (no EQ curve)

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

The generator was still liable to miss details or stub features when left to its own devices, and the QA still added value in catching those last mile issues for the generator to fix.

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

Based on the prompt, I was expecting a program where I could create melodies, harmonies, and drum patterns, arrange them into a song, and get help from an integrated agent along the way. The video below shows the result.

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

The app is far from a professional music production program, and the agent's song composition skills could clearly use a lot of work. Additionally, Claude can’t actually hear, which made the QA feedback loop less effective with respect to musical taste.

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

But the final app had all the core pieces of a functional music production program: a working arrangement view, mixer, and transport running in the browser. Beyond that, I was able to put together a short song snippet entirely through prompting: the agent set the tempo and key, laid down a melody, built a drum track, adjusted mixer levels, and added reverb. The core primitives for song composition were present, and the agent could drive them autonomously, using tools to create a simple production from end to end. You might say it’s not pitch-perfect yet—but it’s getting there.

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

What comes next

Что дальше

As models continue to improve, we can roughly expect them to be capable of working for longer, and on more complex tasks. In some cases, that will mean the scaffold surrounding the model matters less over time, and developers can wait for the next model and see certain problems solve themselves. On the other hand, the better the models get, the more space there is to develop harnesses that can achieve complex tasks beyond what the model can do at baseline.

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

With this in mind, there are a few lessons from this work worth carrying forward. It is always good practice to experiment with the model you're building against, read its traces on realistic problems, and tune its performance to achieve your desired outcomes. When working on more complex tasks, there is sometimes headroom from decomposing the task and applying specialized agents to each aspect of the problem. And when a new model lands, it is generally good practice to re-examine a harness, stripping away pieces that are no longer load-bearing to performance and adding new pieces to achieve greater capability that may not have been possible before.

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

From this work, my conviction is that the space of interesting harness combinations doesn't shrink as models improve. Instead, it moves, and the interesting work for AI engineers is to keep finding the next novel combination.

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

Acknowledgements

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

Special thanks to Mike Krieger, Michael Agaby, Justin Young, Jeremy Hadfield, David Hershey, Julius Tarng, Xiaoyi Zhang, Barry Zhang, Orowa Sidker, Michael Tingley, Ibrahim Madha, Martina Long, and Canyon Robbins for their contributions to this work.

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

Thanks also to Jake Eaton, Alyssa Leonard, and Stef Sequeira for their help shaping the post.

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

Appendix

Приложение

Example plan generated by planner agent.

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

RetroForge - 2D Retro Game Maker Overview RetroForge is a web-based creative studio for designing and building 2D retro-style video games. It combines the nostalgic charm of classic 8-bit and 16-bit game aesthetics with modern, intuitive editing tools—enabling anyone from hobbyist creators to indie developers to bring their game ideas to life without writing traditional code. The platform provides four integrated creative modules: a tile-based Level Editor for designing game worlds, a pixel-art Sprite Editor for crafting visual assets, a visual Entity Behavior system for defining game logic, and an instant Playable Test Mode for real-time gameplay testing. By weaving AI assistance throughout (powered by Claude), RetroForge accelerates the creative process—helping users generate sprites, design levels, and configure behaviors through natural language interaction. RetroForge targets creators who love retro gaming aesthetics but want modern conveniences. Whether recreating the platformers, RPGs, or action games of their childhood, or inventing entirely new experiences within retro constraints, users can prototype rapidly, iterate visually, and share their creations with others. Features 1. Project Dashboard & Management The Project Dashboard is the home base for all creative work in RetroForge. Users need a clear, organized way to manage their game projects—creating new ones, returning to works-in-progress, and understanding what each project contains at a glance. User Stories: As a user, I want to: - Create a new game project with a name and description, so that I can begin designing my game - See all my existing projects displayed as visual cards showing the project name, last modified date, and a thumbnail preview, so that I can quickly find and continue my work - Open any project to enter the full game editor workspace, so that I can work on my game - Delete projects I no longer need, with a confirmation dialog to prevent accidents, so that I can keep my workspace organized - Duplicate an existing project as a starting point for a new game, so that I can reuse my previous work Project Data Model: Each project contains: Project metadata (name, description, created/modified timestamps) Canvas settings (resolution: e.g., 256x224, 320x240, or 160x144) Tile size configuration (8x8, 16x16, or 32x32 pixels) Color palette selection All associated sprites, tilesets, levels, and entity definitions ...

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 пикселя) выбор цветовой палитры все связанные спрайты, тайлсеты, уровни и определения сущностей ...