Недавно я вёл урок по прототипированию сервисов в Cursor. На рабочую часть ушло максимум 40 минут: 15–20 минут я рассказывал, 20–25 минут мы работали. Из этого времени сам Cursor чистыми отработал минут десять, остальное я говорил, копировал промпты и показывал на экране. На выходе получился репозиторий с прототипом редакционного конвейера для новостного сайта: оркестратор на 10 шагов, 10 ролей‑субагентов, 8 файлов правил, канон артефактов прогона. И тут же, при зале, мы прогнали цепочку целиком: от сырых источников до готового черновика новости и вердикта авто‑судьи. Прикладного кода: ноль строк. Каталога src/ в проекте нет вообще.
Сразу сниму ожидание магии. Мы не собирали работающий сервис: ни бэкенда, ни планировщика, ни деплоя. Прогон исполнили агенты Cursor по правилам, а не какая‑то запущенная система. Целью было показать практику: алгоритм будущей системы можно целиком проработать на уровне правил, до того как написана первая строка кода. Для порядка: файлы правил на моей машине созданы за окно 19:33–19:38, десять артефактов прогона — в 19:39. Понимаю, что метки времени на локальном диске ничего не доказывают, подделываются одной командой touch, так что тайминг тут — рассказ очевидца, а не пруф. Проверяемая часть — репозиторий демо на GitHub: правила, роли, канон прогона и полный прогон 01→10. Выложен позже демо, в README указана дата live‑сессии.
Ставка была не в зрелищности, а в тезисе. В аудитории около 90% работали в Claude Code, у большинства один разбухший AGENTS.md на все случаи жизни. Я утверждал, что правила представляют собой исполняемый чертёж системы и что держать всё в одном файле неправильно. Проверка простая: если после урока не пойдут вопросы, значит, тезис не попал. Вопросы пошли сразу.
TL;DR. Прототип системы можно держать в правилах Cursor, без кода. Человек даёт intent и параметры; правила, роли и MCP создаются из чата, основной контур работы обходится без ручной правки файлов. За десятки минут получается артефакт, на котором проверяется корректность алгоритма: цепочку прогоняешь и получаешь нумерованные артефакты каждого шага. Во второй половине статьи доказательство, что приём не игрушка: полная версия того же конвейера прожила у меня в правилах и прогонах несколько месяцев и превратилась в прод‑спеки сервиса, который сейчас публикует статьи, а сам учебный прототип позже стал заготовкой ещё одной рабочей системы.
Приём: алгоритм в правилах, код потом
Классический цикл: нарисовали архитектуру, начали кодить, на второй неделе поняли, что алгоритм не тот, переделали половину. Дорого здесь вовсе не написание кода. Дорого выяснение того, что алгоритм неверен, после того как код написан.
Если всерьёз работать в Cursor, рано или поздно приходишь к выводу: для проверки алгоритма программировать часто вообще не нужно. Достаточно осознать алгоритм и прототипировать его прямо в Cursor. Алгоритм описывается в виде правил. Доступ к внешним системам идёт через MCP, либо ещё проще: кладёте рядом выгрузки из Excel, базы, любой CSV, чтобы на уровне прототипа представлять, что будет внутри. Вся работа делается через сам Cursor, человек даёт только intent и параметры.
Какой будет бэкенд у будущего приложения (Node.js, PHP, Python), на этом этапе не имеет значения. Правила описывают работу будущих методов, будущих команд, будущих функций. Стек выбирается потом, когда алгоритм уже проверен.
Одна оговорка про инструмент, без которой приём не работает. Cursor без правил превращается в тот же GPT: тупой инструмент, которому надо каждый раз писать огромные промпты, чтобы он хоть что‑то понял. Поэтому в первый же промпт я вкладываю ссылки на документы о правильных практиках: официальные доки по rules, skills, subagents, MCP, плюс пара внешних текстов про спецификации и контекст‑инжиниринг. Без этой базы агент будет генерировать правила «как получится».
Демо: конвейер публикации новостей за три промпта
Задача демо взята из моего реального проекта: автоматический контур публикации контента. Источники (RSS, HTML, API) → нормализация и дедуп → отбор темы по метрикам хайпа за окно 3 дня → сбор контекста → обогащение из веба → черновик на русском → редактура → авто‑судья «публиковать или нет» → human approve → выкладка. Ниша: ИИ‑разработка и vibe coding.
Весь прототип собрался за три промпта.
Первый промпт: продуктовый запрос плюс план ролей. Я не прошу «нарисуй архитектуру из пяти коробочек». Я описываю пайплайн по шагам, задаю имена артефактов (01_normalized.jsonl … 10_verdict.json) и прошу план: оркестратор, роли, структура правил и субагентов, канон прогона. В конце промпта два жёстких ограничения: «Не реализуй пока — только план. Не создавай src/. Не выбирай технологии (Redis, Celery, Strapi) — только роли и порядок». И блок ссылок на практики, о котором я говорил выше.
Второй промпт: реализация плана. «Implement the plan» плюс явный список файлов: оркестратор с таблицей всех шагов и alwaysApply: true, правила ролей с входом, выходом и критерием готовности, субагенты, editorial/runs/README.md как канон прогона.
Третий промпт: строгое ревью. Обязательный шаг, который почти все пропускают: «Проведи полное ревью созданных правил. Есть ли таблица всех шагов с критериями перехода? У каждой роли есть вход, выход, критерий? Нет ли противоречий между тем, что оркестратор ожидает, и тем, что роль обещает? Если нашёл проблемы — исправь сразу». Первый проход всегда неполный; ревью своим же агентом закрывает дыры дешевле, чем их потом находит человек.
Вот что лежит в репозитории демо после урока:
cursor-rules-pipeline-demo/ ├── AGENTS.md # тонкий индекс: где что лежит ├── README.md # добавлен при выкладке на GitHub ├── .cursor/ │ ├── rules/ # 8 файлов │ │ ├── editorial-orchestrator.mdc # таблица 10 шагов, PASS-критерии, STOP-коды │ │ ├── editorial-boundaries.mdc # границы: что пайплайну запрещено │ │ ├── editorial-tone-vibe-coding.mdc │ │ └── … ещё 5 правил-схем # форматы артефактов: jsonl, draft, line-edit, verdict │ └── agents/ # 10 ролей, по одной на шаг │ ├── ingest.md dedup.md relevance.md ranker.md topic_picker.md │ └── context_builder.md enricher.md lead_author.md line_editor.md publisher_judge.md └── editorial/ └── runs/ ├── README.md # канон прогона: schema_version, поля, валидация └── 2026-04-09_ai-coding-agents-hype/ # реальный прогон: 01 → 10
Сердце прототипа — таблица оркестратора. Фрагмент как есть:
| Шаг | Роль | Вход (минимум) | Выход | PASS → следующий шаг | |-----|------|----------------|-------|----------------------| | 4 | ranker | только строки 03 с relevance: "kept" | 04_ranked.jsonl | у каждой строки hype_score, hype_breakdown, окно 3 дня | | 5 | topic_picker | 04_ranked.jsonl + лимиты/пороги | 05_selected_topic.json | либо status: "selected" — одна тема, source_ids ⊆ id из 04; либо status: "stop" + валидный stop_code (шаги 6–10 не выполняются) |
Обратите внимание на ветку отказа. У шага выбора темы есть STOP‑коды: no_candidates, weak_hype, duplicate_topic, policy_block. Если ни одна тема не проходит порог, конвейер обязан остановиться и объяснить почему, а артефакты 06–10 не создаются. Это поведение будущего сервиса, спроектированное и проверяемое до всякого кода. В классической разработке ветку «пустого пула» обычно вспоминают на проде.
Главное правило процесса, которое я проговариваю трижды: в основном контуре эти файлы руками не трогают. Правила, роли, канон создаются из чата Cursor промптами и там же правятся. Это не табу навсегда, а рабочий сигнал: если захотелось открыть .mdc и дописать что‑то вручную, значит, intent сформулирован плохо. Чините интент.
Прогон: чем «пощупать алгоритм» отличается от «запустить сервис»
Сразу после ревью, не выходя из демо, мы прогнали конвейер целиком. В репозитории осталась папка 2026-04-09_ai-coding-agents-hype/ с десятью артефактами от 01_normalized.jsonl до 10_verdict.json. Сырьё — пара реальных публикаций про AI coding agents; на выходе 05_selected_topic.json с выбранной темой и обоснованием, черновик новости на русском, отредактированная версия и вердикт судьи. Вот он целиком, как есть:
{ "schema_version": 1, "decision": "publish", "scores": { "accuracy": 8, "niche_fit": 9, "readability": 8, "hype_justified": 8 }, "blockers": [], "recommendations": [ "Перед публикацией сверить конкретные проценты опроса Pragmatic Engineer по первоисточнику, если цитировать их как точные цифры.", "При желании добавить одну дату релиза Claude Code в основной текст, если подтверждена в открытом источнике." ], "summary": "Текст соответствует нише ИИ-разработки и vibe coding; различает эмпирические источники и кликбейт; оговорены ограничения бенчмарков и доступа к опросу. Публикация без блокеров при ручной проверке цифр." }
Судья, описанный правилом на полстраницы, сам потребовал проверить цифры по первоисточнику перед публикацией. Этого поведения никто не кодил.
При этом никакого сервиса не существует. Прогон исполняют агенты Cursor по правилам, шаг за шагом, каждый пишет свой файл. Именно это я называю «пощупать корректность алгоритма»: при зале видно, что цепочка сходится, что схемы стыкуются, что судья реально ловит слабые места. И видно дыры: прогон один, сырьё подготовленное, реального ingest из RSS через MCP в демо не было. Для прототипа этого более чем достаточно; для сервиса, разумеется, нет.
Что удивило аудиторию (и что удивило меня)
Напомню, около 90% слушателей работали в Claude Code. Реакции разложились так.
«Правила решают настолько много?» Да. Большинство не предполагали, что на уровне правил можно строить мультиагентные системы: маршрутизацию ролей, контракты передачи, гейты готовности. У большинства один промпт, одно правило или один AGENTS.md, куда годами доливается всё подряд.
Это неправильная работа, и у Claude с Codex та же история. AGENTS.md решает другую задачу: описывает проект, что где лежит и какие зоны закрыты. В демо‑репозитории AGENTS.md занимает десяток строк и только ссылается на правила. А правила работы, правила intent, живут отдельным слоем, в workspace rules.
Что удивило уже меня: у части слушателей оказалась практика редактировать системные правила приложения. Это за рамками корректной работы с любым инструментом, ведь системный промпт перезатирается при каждом обновлении. Вышла новая версия, всё стёрлось, копируй заново. Если очень нужно, есть user rules. Но я всегда говорю: делайте workspace rules. User rules распространяются на одного пользователя; если вы делаете продукт больше чем для себя, подходят только workspace rules, и никак иначе.
Доказательство: от прогонов к проду
Честный вопрос к демо: хорошо, за 40 минут собрали чертёж с одним прогоном, а живёт ли такой прототип дальше?
Живёт, и я показывал его аудитории как эталон: демо было уменьшенной копией моего реального кейса. Полная версия этого же редакционного конвейера (те же шаги от ingest до судьи, тот же канон нумерованных артефактов) жила у меня в правилах и прогонах несколько месяцев. Требования, затем спецификация с измеримыми порогами, затем редакционная миссия и машиночитаемый гейт тем, затем контракт промптов с запретом выдуманных фактов, затем оркестрация правилами Cursor и канон прогона. И десять задокументированных прогонов полной версии только за один месяц, каждый в датированной папке, любой сравним с любым.
Именно на прогонах чертёж отлаживался: пороги релевантности, тай‑брейки при ранжировании, условия «пустого пула». Алгоритм менялся правкой правил и контрактов, без рефакторинга кода, которого не было. Несколько раз я говорил агенту прямым текстом: «посмотри, как плохо связаны правила — нет оркестратора, роли не стыкуются», и чертёж становился точнее. Прогон → критика → доработка, тот же цикл, что в третьем промпте демо.
Когда алгоритм стабилизировался, прототип «закрылся по смыслу»: стало понятно, что именно строить. Инварианты, выжитые из прогонов, легли в продовые спецификации, и сервис был реализован уже как нормальный бэкенд, с воркерами, CMS и деплоем. Сейчас он в проде и каждый день выпускает статьи. Ссылку на него не даю сознательно: пост про приём, а не про продукт. Кодом при этом стала обвязка: очереди, планировщик, хранилище, публикация. А редакционные шаги — автор, редактор, судья — внутри прод‑воркера по‑прежнему исполняет агент по правилам ролей, с контрактом против выдуманных фактов и тем же каноном нумерованных артефактов прогона: черновик, редактура и вердикт в проде так же ложатся файлами 08, 09, 10. Чертёж из прототипа не «перенесли в код» и не выбросили: он буквально работает внутри боевой системы. В этом весь смысл приёма. Черновик требований, проверенный десятком прогонов, вместо архитектурной фантазии на доске.
История получила и второе продолжение, уже после урока. Тот простой учебный прототип, собранный для демонстрации, я не выбросил: на его основе позже выросла полноценная контент‑фабрика, мультиагентный редакционный контур, который сегодня в ежедневной работе готовит статьи. Сорокаминутное демо оказалось предварительной работой перед реальной системой. Это, пожалуй, лучший аргумент за приём: чертёж, сделанный «для тренировки», дожил до боевого применения, потому что в нём с самого начала был проверенный алгоритм, а не слайды.
Честные оговорки и чеклист
На демо мы показывали вариант реализации; сам сервис на тот момент существовал только у меня в голове. Прототип при этом настоящий, а не слайды, и дыры в нём честные: один прогон, подготовленное сырьё, ingest без реальных источников. Для проверки корректности алгоритма этого более чем достаточно. Не путайте два разных результата: проверенный алгоритм и работающую систему — второе появляется позже, отдельной разработкой.
Черновик требований не равен проду. Полная версия конвейера дошла до прода только через отдельный полноценный цикл: спеки, ревью, код, тесты. Прототип в правилах экономит самую дорогую часть, выяснение алгоритма, но инженерию не отменяет.
Приём затягивает в вечную полировку. Править правила дёшево, поэтому легко залипнуть в бесконечное улучшение чертежа. Мне помогает жёсткий признак выхода: два прогона подряд не меняют правил, значит, прототип закрыт, дальше спека.
Порог входа существует. Нужен платный тариф и модель уровня Composer, на слабых моделях агент не удержит дисциплину шагов. Аудитория приёма: люди, которые уже живут в Cursor и понимают, как он работает. Токенов при этом уходит немного, основная работа состоит из чтения и генерации маркдауна.
Где приём не работает: когда риск лежит в технологии, а не в алгоритме. Нагрузка, latency, специфичное железо. Правилами не проверить, выдержит ли база миллион записей в секунду. Проверяется алгоритм: порядок шагов, контракты, гейты, форматы данных.
Повторить у себя: чеклист на один вечер
Возьмите сырую идею, которую хочется «потрогать»: конвейер, интеграцию, внутренний сервис.
Создайте пустой репозиторий. Никакого
src/, договоритесь с собой, что кода не будет.В первый промпт вложите продуктовое описание пайплайна по шагам, имена артефактов каждого шага и ссылки на практики правил вашей платформы (rules, skills, subagents, MCP). Попросите план: оркестратор, роли, канон прогона. Запретите реализацию и выбор технологий.
Вторым промптом попросите реализовать план: правила и роли с явным входом, выходом, критерием перехода.
Третьим промптом устройте строгое ревью: все ли шаги покрыты ролями, стыкуются ли входы и выходы, есть ли ветки отказа (STOP‑коды). Нашёл проблемы — пусть исправляет сразу.
Внешние данные подключите через MCP, либо просто положите выгрузку (CSV, дамп) рядом: для проверки алгоритма этого достаточно.
Правила и роли правьте только из чата, промптами. Руками файлы не трогать; хочется править вручную — значит, чините intent.
Прогоняйте цепочку и складывайте артефакты в датированные папки прогонов. Два прогона подряд без правок правил: прототип закрыт, пишите спеку.
Весь чертёж с демо, от оркестратора до прогона с вердиктом, собран примерно за 10 минут чистого времени работы агента внутри 40-минутного сегмента с рассказом и разбором. Проверка алгоритма до кода стоит дешевле любого рефакторинга после.
Вопрос залу тот же, что я задал на уроке. Сколько строк у вас в AGENTS.md или CLAUDE.md? Это один разбухший файл «про всё», или есть отдельный слой правил работы? И пробовал ли кто‑то держать алгоритм системы в правилах до кода — что получилось, а что развалилось?
