← Университет

Автономная разработка: агенты сами строят приложения (план → код → тест → критика → скриншот → доработка)

Аналитический документ для Лучиана. Разбираем не «что такое AI-агенты», а конкретно: как устроена ночная автономная фабрика ПО, которая по одной команде строит сайт/тулзу/MVP без него — и чем это отличается от того, что у него уже частично работает на заводе (channel-hq, гейты EDIT_PENDING/ APPROVAL_PENDING, claude -p).

0. Главная мысль в одном абзаце

«Автономная разработка» — это не отдельный продукт и не новый фреймворк, который нужно скачать и подключить. Это ПРИМЕНЕНИЕ уже знакомого Лучиану паттерна (специализированные роли + гейты + память + QC-петля, как в его видео-заводе) к новому типу конечного артефакта — работающему коду с визуальным интерфейсом. Разница с видео-конвейером всего в двух местах: (а) верификация «на глаз» заменяется на скриншот UI вместо просмотра ролика, (б) единица параллелизма — не «тема видео», а «архитектурный вариант решения» (Best-of-N). Всё остальное — оркестрация, гейты, брокер ресурсов, память, экономика токенов — переносится буквально.

1. Зачем отдельная тема, если завод уже строит видео

Завод Лучиана — это уже пример специализированного автономного конвейера: ниша → концепт → генерация → QC → обложки → SEO → approve → upload → learning (см. 02-factory-overview.md). Но это конвейер для ОДНОГО типа продукта — видео. «Строитель приложений» — это мета-уровень: система, которая сама порождает НОВЫЕ конвейеры под ЛЮБУЮ задачу (сайт, тулза, MVP для клиента, игра). Тот же паттерн (генерация → QC → критика → доработка), но конечный артефакт — не видео, а работающий код с UI, который нужно визуально проверить глазами (скриншот), а не просмотреть.

Это первый приоритет в целевой системе Лучиана (см. профиль, п. «Большая цель», пункт 1) и она же основа консультант-фабрики MVP (пункт 3: вечером — боли клиента, утром — 3–10 готовых демо).

2. Три референсные архитектуры автономных кодинг-агентов

По материалам web/autonomous-coding.md, к 2026 году индустрия сошлась на трёх архитектурных семьях, и все три полезны Лучиану как разные «органы» его будущей системы.

2.1 Claude Code: шесть примитивов расширяемости

Это то, чем Лучиан УЖЕ пользуется (claude -p, мульти-аккаунт failover). Ключевая мысль: Claude Code — не чат-бот, а programmable-платформа из шести кирпичей:

  1. CLAUDE.md — «конституция» репозитория, читается при каждом запуске (у Лучиана это близко к memory-bank profile.json — станд правила канала).
  2. Skills — переиспользуемые workflow-файлы, загружаются только при вызове (экономят токены — прямое попадание в его боль токеномики). Его правило «повторил дважды → оформи скиллом» — это ровно формализация Skills-паттерна.
  3. Subagents — изолированный контекст на подзадачу. Три типа: Explore (только чтение), Plan (план без изменений кода), General-purpose (полный доступ).
  4. Slash commands — типизированные макросы (/compact, /review).
  5. Hooks — «hooks execute deterministic code. They cannot hallucinate» — это ключевая цитата для guardrails. В отличие от промпта, который агент может «неправильно понять», hook — это скрипт, который либо пропускает действие, либо блокирует его по коду выхода. Это прямая параллель с его правилом №3 («скрипт вместо ИИ где можно») — PreToolUse hook формализует именно это: детерминированная проверка ПЕРЕД тем, как агент потратит деньги/токены/сделает необратимое действие.
  6. MCP servers — внешние интеграции как first-class инструменты.

2.2 Devin (Cognition AI): составная архитектура из специализированных моделей

Planner → Coder → Critic → Browser Agent — четыре РАЗНЫЕ роли, не один агент, который сам с собой «разговаривает». Ключевая особенность — self-correcting code: если тесты падают, Devin не идёт к следующей задаче, а чинит текущую. Это именно то петля, которую нужно Лучиану для ночной работы: без такого цикла система за ночь просто накопит гору сломанного кода.

2.3 OpenHands: событийная (event-sourced) архитектура

Четыре разделённых Python-пакета (sdk / tools / workspace / agent_server), все взаимодействия — immutable events, добавляемые в лог. Это даёт deterministic replay и надёжное восстановление сессии после сбоя — критично для «упал прогон → чинить вперёд (resume), никогда не удалять», его пятый закон уже сформулирован в этом же духе для видео-конвейера, и его нужно перенести на код-конвейер буквально.

Вывод для Лучиана: три архитектуры — не конкуренты, а три ответа на разные вопросы. У него уже есть мозг (Claude, claude -p) → значит фундамент = Claude Code примитивы (skills, subagents, hooks). Роль Devin-подобного разделения (planner/coder/critic) он реализует через subagents с разными system prompt и разными правами инструментов — ровно как в его текущем заводе (channel-forge отдельно от channel-hq). Событийность OpenHands — это урок «пиши state в файлы/JSONL, не держи всё в контексте одной длинной сессии» — прямое попадание в его требование к токеномике.

3. Цикл план → код → тест → критика → скриншот → доработка: как он устроен по шагам

Собирая воедино orchestration-patterns.md (Planner-Executor-Critic) и autonomous-coding.md (Verifier Pattern, ProofShot), рабочий цикл строится так:

1. PLAN      — Plan-субагент читает задачу (боль клиента / ТЗ), пишет план в файл (не в контекст!)
2. CODE      — Coder-субагент реализует план, пишет код + тесты
3. TEST      — детерминированные проверки: юнит-тесты, линтер, сборка (0 токенов мозга — grep/CI)
4. CRITIQUE  — НЕЗАВИСИМЫЙ Critic-агент (другая сессия/другой контекст, видит только артефакт + требования,
               НЕ видит рассуждений генератора)
5. SCREENSHOT — визуальная верификация: агент запускает приложение, делает скриншот/видео браузера
               (ProofShot-паттерн, Playwright MCP), проверяет визуально, а не только по коду
6. FIX/ITERATE — по вердикту критика либо релиз, либо возврат на шаг CODE (жёсткий лимит 3-5 итераций)

3.1 Почему шаг CRITIQUE не может быть той же моделью/сессией

Ключевая цитата из autonomous-coding.md: «Any mistake made during generation is likely to persist through review — because the reviewer thinks the same way as the writer». Практическое следствие для Лучиана: критик его лендингов/тулз должен получать только результат и исходное ТЗ, без хвоста рассуждений генератора — иначе он унаследует те же слепые пятна. Это прямая параллель с его же thumbnail-studio: там уже есть Haiku vision QC как отдельный судья поверх генератора — паттерн верный, нужно просто повторить его для кода/UI.

3.2 Почему нужен именно скриншот, а не только код-ревью

Для видео-фабрики Лучиана QC уже двухуровневый (детерминированный + vision-QC), и это же нужно для UI-продуктов: агент, который пишет React-компонент, может написать синтаксически верный, тестово проходящий, но визуально сломанный (наехавший текст, битая раскладка на мобильном) код. Данные подтверждают числами: multi-step задачи подчиняются вероятностной математике (см. §5) — визуальный скриншот-шаг — это дополнительная «перезагрузка вероятности ошибки» (термин из case-studies-failures.md, «Selective Autonomy»), которую нельзя заменить только unit-тестами.

3.3 Verifier Pattern: структура эффективной верификации

Из autonomous-coding.md, четыре требования к промпту критика: - конкретные критерии, не «find bugs» — а явный чек-лист (у него уже есть аналог: «хук, визуал, звук, факты» для видео — тот же принцип переносится на код: «работает ли форма, нет ли console-ошибок, проходят ли тесты, не пусто ли на мобильном»); - structured output (JSON: verdict/issues/severity) — чтобы оркестратор мог программно решить «фикс vs релиз», а не парсить текст LLM; - hard iteration limits (3-5 циклов), иначе — Loop of Death (см. §5); - опционально — разные модели/семейства для генератора и критика, для дополнительной независимости.

4. Ночная работа без человека: как реально организуют unattended execution

Три подхода, применимых на его инфраструктуре (см. autonomous-coding.md):

  1. Cron + headless claude -p — самый прямой путь: claude -p "Задача" --output json, запускается systemd-таймером (у него уже есть пример — x-research-daily работает по systemd-таймерам 07:20/09:20, без Docker). Плюс: просто для single-step задач. Минус: нет retry/dependency-логики из коробки.
  2. Orchestration с task queue — для multi-agent pipeline с зависимостями (retry с exponential backoff, run-history). Это ровно то, чем является channel-hq/core/orchestrator.mjs — он уже написан, но выключен (по данным 02-factory-overview.md). Инструмент для «строителя приложений» — тот же паттерн, новый оркестратор для кода вместо видео.
  3. Managed cloud-платформы (GitHub Agentic Workflows и аналоги) — избыточны для его случая (self-hosted завод), но полезна идея: workflows по умолчанию read-only, write требует явного safe-output, и PR никогда не мёржится автоматически — это прямой шаблон для его правила «действие только по явному да», которое должно эволюционировать в «ночная автономия кроме денег»: ночью пиши код, деплой в staging, генерируй демо — но НЕ трать деньги (платный API, покупка домена, оплата рекламы) без утреннего подтверждения.

Safety-чеклист для unattended-режима (из источников, адаптирован)

5. Типичные ошибки: что ломает автономную стройку на практике (не теория — цифры)

Материал case-studies-failures.md даёт самый жёсткий, приземлённый набор фактов из практики 2025-2026, и он прямо адресован его планируемому режиму «полная ночная автономия».

5.1 Математика многошаговых задач

При точности 95% на шаг, 10-шаговый прогон (типичный размер «построй сайт с нуля») даёт 0.95^10 ≈ 60% шанс полного успеха без единой ошибки. Отсюда прямой вывод: не проектировать одну длинную цепочку из 10+ шагов без промежуточных проверок — каждая проверка «перезагружает» вероятность, как явно формулируется в источнике (Selective Autonomy). Практически: между PLAN и CODE, между CODE и CRITIQUE — не просто передавать управление, а сохранять чекпойнт-артефакт (файл, не контекст), чтобы при сбое перезапускался только провалившийся шаг, а не весь конвейер — это опять его собственное правило №2 из завода («упал прогон — resume, не пересоздавать»).

5.2 Loop of Death

Конкретный паттерн отказа: агент пишет код с ошибкой → среда возвращает ошибку → «исправление» создаёт НОВУЮ ошибку → цикл. Решение из практики (снизило расходы на 70%, дало 99.9% надёжность): три компонента: - Smart Routing — маленькая модель классифицирует сложность задачи, простое идёт на дешёвую модель (его лестница: haiku → sonnet → opus уже правильная идея, нужно формализовать роутинг явным правилом, а не полагаться на интуицию при каждом вызове); - Semantic Caching — 40% подзадач обслуживаются из кеша без единого токена; - Sandboxed Execution с жёстким лимитом попыток (max 3) — код выполняется в изолированном контейнере, а не напрямую на хосте.

5.3 «100% автономность — ошибка» (Codemanship, 2026)

Прямая цитата, важная для калибровки ожиданий Лучиана: «Hold the firehose in short, controlled bursts» — успешные команды НЕ ищут полную автономность, а комбинируют небольшие автоматизированные фазы с чек-поинтами между ними. Для его цели «ПОЛНАЯ автономия ночью, кроме денег» это не противоречие, а уточнение: полная автономия — это не «один десятичасовой прогон без единой точки контроля», а «десятки коротких, проверяемых фаз, каждая со своим QC-гейтом», просто человек не смотрит на них до утра.

5.4 «Первая попытка — 95% мусора» (Sanity, staff engineer, 6 недель с Claude Code)

Трёхэтапный workflow из реального опыта: первая попытка (95% мусора, но строит контекст) → вторая (50% мусора, нюансы уточнены) → третья (рабочий итерируемый результат). Практическое следствие: ночной конвейер для НОВОЙ задачи (новый тип MVP) нельзя ожидать готовым с первого прогона — закладывать в дизайн минимум 2-3 цикла критики внутри одной ночи, не одну попытку.

5.5 Стоимость: 15× токенов у многоагентных систем vs простой чат

Из orchestration-patterns.md: многоагентные системы Anthropic потребляют 15× больше токенов, чем обычный чат, но 80% вариативности качества объясняется именно распределением работы и объёмом потреблённых токенов (не моделью). Здесь прямая связь с его требованием к токеномике — экономия достигается не «меньше агентов», а дисциплиной контекста: компакция между этапами, суммаризация перед хендофом, внешнее хранилище вместо раздувания истории разговора.

5.6 Специфика координации нескольких агентов над одним кодом

«Breaks the build, and once the build's broken, everybody's blocked» — параллельные агенты, пишущие в одну кодовую базу без изоляции, создают конфликты интеграции. Практический вывод (из опыта Claude Code 2.0 best practices): не параллелизировать одну и ту же проблему, разводить субагентов по независимым модулям/файлам, а не по «одной и той же задаче с разных углов» — это годится только для Best-of-N (см. §6), где параллельные варианты изначально пишутся в РАЗНЫЕ директории/ветки, а не в один рабочий код.

6. Паттерн Best-of-N + Judge Panel: ядро для консультант-фабрики MVP

Это САМЫЙ прямой мост к третьему пункту его большой цели (боли клиента → ночь → веер 3-10 MVP → демо утром). Из orchestration-patterns.md:

Задача (боль клиента)
  ├→ Generator Agent #1 → MVP-вариант A (например: performance/scalability-first)
  ├→ Generator Agent #2 → MVP-вариант B (developer experience/maintainability-first)
  └→ Generator Agent #N → MVP-вариант N (cost-efficiency/скорость-first)

  → Judge Panel
    ├→ Scorer: оценка по критериям (соответствие боли, юзабельность, готовность к демо)
    ├→ Critic: недостатки, edge cases
    └→ Commander: финальный вердикт + ранжирование

  → Топ-варианты идут к клиенту утром

Из mvp-factory.md — конкретная, уже опробованная реализация этой идеи (Claude Code Ultra: три Explorer-агента в отдельных контекстных окнах + один Critic). Время выполнения параллельного веера примерно равно времени одного самого медленного агента, а не сумме — то есть 3-10 параллельных MVP не займут ночь ×10, если у него достаточно параллельных «слотов» (ровно как resource-governor на заводе уже честно распределяет пулы FastGen между проектами — тот же принцип нужен для code-агентов: брокер параллелизма, не бесконтрольный спавн).

Практическая методология оценки (важно для судейской панели): Pairwise/turnir-схема (knockout tournament, O(N log N)) эффективнее, чем попарное сравнение всех со всеми (O(N²)) — при 10 вариантах разница существенна. И критично — разнообразие судей: гомогенные судьи (одна и та же модель, один и тот же промпт) снижают качество оценки, роль-панель (например, «судья-технарь» + «судья-глазами клиента» + «судья-по бюджету») даёт более надёжный вердикт.

6.1 «Мультиверс-разработка»: экономика вариантов

Из mvp-factory.md: пробовать N архитектурных вариантов параллельно стоит не N×, а 2-3× дороже линейной разработки, при экспоненциально большем объёме изученного пространства решений (O(n×m) вместо O(n)). Для его бизнес-модели (консалтинг с продажей MVP-решений) это прямое экономическое обоснование: генерация 3-10 вариантов за ночь не в 10 раз дороже одного, а в разы дешевле — потому что параллельность не складывает время, а токены на «попытки» частично компенсируются caching и переиспользуемыми skills.

7. «Harness важнее модели» — почему завод Лучиана уже ценнее любого готового фреймворка

Ключевая цитата из Anthropic-материала о больших кодовых базах (efRIrLXoOVA.txt): «The harness matters as much as the model». AI layer — это не сама модель, а весь слой контекста и инструментов вокруг неё: правила (CLAUDE.md), skills, MCP-серверы, субагенты, hooks, LSP. Claude Code out-of-the-box не строит индекс кодовой базы — навигирует как инженер (grep, структура папок), а значит качество навигации целиком зависит от того, насколько хорошо вы курируете контекст заранее.

Это прямое подтверждение того, что Лучиан уже делает интуитивно правильно: memory-bank (3 банка памяти), _STYLE_PLAYBOOK.md, «правило стиля = per-channel profile, не хардкод в коде» — это всё и есть его персональный «harness» для видео-домена. Для строителя приложений нужен АНАЛОГИЧНЫЙ harness для кода: свой CLAUDE.md/AGENTS.md с конвенциями стека, своя библиотека skills («как деплоить Node-сервис на его VPS», «как подключить Caddy+SSO», «как писать docker-compose для нового сервиса» — многое из 08-contracts.md уже фактически такой skill в прозе, нужно формализовать в .claude/skills/).

8. Что перенести из завода в строитель приложений буквально

Механизм завода видео Аналог для строителя приложений
channel-forge: ниша → 5 углов → концепт → profile.json Requirements-агент: боль клиента → 3-5 архитектурных углов → ТЗ
Два гейта EDIT_PENDING / APPROVAL_PENDING Гейт «код готов, жду визуальной проверки» + «готов к деплою/трате денег»
resource-governor (брокер пулов FastGen) Брокер параллельных code-агентов/контейнеров (чтобы не заспамить CPU/API-лимиты)
thumbnail-studio: 2-уровневый QC (детерм. + Haiku vision) Test-раннер (детерм.) + vision-QC по скриншоту UI
memory-bank: 3 банка (global/per-channel/per-generator) Banks: global-конвенции / per-project / per-agent-role
Стадия LEARNING (сейчас холостая) Обратная связь: какие MVP-паттерны клиенты купили → в память для след. веера
orchestrator.mjs (написан, выключен) Тот же принцип оркестратора, применённый к code-pipeline, ВКЛЮЧЁН с самого начала
«Упал прогон — resume, не удалять» Чекпойнты кода в git-коммитах, откат вместо пересоздания с нуля

9. Практические выводы для дорожной карты Лучиана

  1. Не изобретать новый фреймворк — расширить существующий harness. У него уже есть работающий Claude Code harness (memory-bank, skills-мышление, оркестратор написан). Строитель приложений — это тот же набор примитивов (subagents, hooks, skills), применённый к новому типу артефакта (код+UI вместо видео), а не отдельная система на LangGraph/AutoGen.
  2. Ввести Verifier Pattern как отдельную независимую сессию, а не «спроси ту же модель, всё ли хорошо» — иначе критик унаследует слепые пятна генератора. Технически: отдельный claude -p вызов с чистым контекстом, только артефакт + требования.
  3. Обязательный скриншот-шаг через headless-браузер (Playwright MCP или ProofShot-подобный подход) — для UI-продуктов code-review недостаточен, нужна визуальная верификация, аналогично Haiku vision-QC на обложках.
  4. Жёсткие лимиты итераций и таймауты на каждом уровне (3-5 циклов критики, sandboxed execution, max 3 попытки исправления одной ошибки) — иначе ночной прогон рискует «Loop of Death» и сожжённый бюджет к утру.
  5. Гейт денег остаётся ЕДИНСТВЕННОЙ красной линией — реализуется как hook (PreToolUse), не как промпт-инструкция: детерминированная проверка суммы/типа операции перед любым платным вызовом. Публикация демо, деплой в staging, генерация кода — свободно; оплата домена/API/рекламы — стоп до утра.
  6. Best-of-N + Judge Panel — это и есть архитектура консультант-фабрики MVP. Параллельные Explorer- агенты (перф/DX/cost-приоритеты) + независимый критик/турнир — тот же паттерн, что уже валидирован в отрасли (Claude Code Ultra: 3 explorer + 1 critic), нужно просто адаптировать под «3-10 вариантов под конкретную боль бизнеса», используя resource-governor-подобный брокер параллелизма.
  7. Многошаговость — враг надёжности; проектировать короткими проверяемыми фазами. 0.95^10 ≈ 60% — не абстракция, а прямое указание дробить любой ночной прогон на фазы с чекпойнтами (файл на диске, не контекст сессии), с возможностью resume отдельной фазы при сбое.
  8. Стадия LEARNING (сейчас холостая на заводе) — обязательна для строителя приложений с первого дня, иначе веер MVP не будет умнеть от ночи к ночи: какие архитектурные углы клиенты реально покупают, какие визуальные паттерны судья/клиент чаще одобряют — должно течь обратно в память (per-domain banks), не теряться.

9.1 Экономика: во что реально обходится ночная стройка

Цифры из источников дают Лучиану конкретные якоря для бюджета ($500-2000/мес по его профилю):

9.2 GitHub Agentic Workflows как готовый шаблон гейтов, а не как инструмент

Даже если Лучиан не будет использовать GitHub Actions напрямую (весь завод self-hosted), сама модель из шести категорий continuous-автоматизации (triage, documentation, code simplification, test improvement, quality hygiene, reporting) — это готовый чек-лист, какие ночные под-задачи вообще стоит поручать агентам ПОМИМО генерации нового кода: например, регулярный «ночной health-report» по уже построенным MVP клиентов, автоматическая синхронизация документации/README с изменениями в конвейере строителя. Принцип «workflows read-only по умолчанию, write требует явного safe-output, PR никогда не мёржится автоматически» — это готовая формулировка для его же правила про деньги, только расширенная на любые необратимые действия: чтение/анализ/генерация — свободно ночью, любой write наружу (публикация, деплой в production, отправка клиенту) — либо явный safe-output с логом, либо утренний approve.

9.3 Сквозной сценарий: ночь консультант-фабрики от начала до утреннего демо

Чтобы принципы §1-9 не оставались абстракцией, соберём их в один воображаемый прогон, максимально близкий к его целевому режиму («боли клиента → ночь → веер MVP → демо утром»):

  1. Вечер, ввод: Лучиан голосом/в Telegram диктует боли клиента (например, кофейня теряет деньги на списании продуктов и путанице в бронях столиков). Requirements-агент (аналог channel-forge) превращает это в короткое ТЗ + 3-5 архитектурных углов (склад-фокус vs брони-фокус vs dashboard-для-владельца-фокус) — записывает в файл, не в контекст.
  2. Ночь, генерация: оркестратор поднимает N Explorer-субагентов параллельно, каждый — свой git-branch / своя рабочая директория (чтобы не «ломать чужую сборку», см. §5.6), каждый следует циклу PLAN→CODE→TEST из §3, с жёстким лимитом попыток (3-5) на любую застрявшую ошибку (Loop of Death, §5.2). Модель-роутинг: механика (CRUD, формы, boilerplate) — Sonnet, архитектурные развилки — Opus, если возникают.
  3. Ночь, верификация: независимый Critic-агент (чистый контекст, только ТЗ + артефакт) прогоняет тесты, затем headless-браузер делает скриншоты ключевых экранов (desktop + mobile) — визуальный QC, аналогичный Haiku vision-QC на обложках. Judge Panel сравнивает N вариантов турниром (knockout, не попарно все против всех) и ранжирует по чек-листу: решает ли боль, юзабельно ли, готово ли к демонстрации без стыда.
  4. Гейт денег: если для демо нужен платный домен/API-ключ/хостинг — это единственная точка, где hook блокирует автоматическое действие и оставляет пометку «ждёт да» на утро; всё остальное (код, деплой в staging на его собственной инфраструктуре, генерация скриншотов) идёт свободно.
  5. Утро: Лучиан получает 2-3 лучших демо с кратким резюме судейской панели («вариант B: быстрее всего юзабелен, но дороже в поддержке») — идёт к клиенту с готовым выбором, а не с сырым черновиком.
  6. После продажи (Learning): какой архитектурный угол клиент реально купил — записывается в persistent-память (per-domain bank), чтобы в следующий раз для похожего бизнеса Judge Panel заранее знала, какие углы обычно выигрывают — закрывает разрыв «стадия LEARNING сейчас холостая» уже на старте нового конвейера, а не как доработка потом.

Этот сценарий не требует новых теоретических изобретений — это прямая рекомбинация того, что уже валидировано отдельно в §2-8: subagents с изоляцией контекста, Verifier Pattern, скриншот-QC, Best-of-N + Judge Panel, memory-bank-подобная персистентная память и hook-гейт на деньги.

10. Открытые вопросы, которые стоит решить в живом roadmap

Источники (материалы mas-research)