Кучеручная

C AI к MVP

content, vibecoding

Попробую сэкономить внимательному читателю тысячу долларов и пару месяцев времени на самостоятельных экспериментах.

Сначала немного про необходимый настрой и метафоры.
Как (ещё и) канбан-тренер, я часто объясняю группе, что разработка ПО - это процесс накопления знаний. Очень правильная модель, но не очевидная. Каждый раз приходится пояснять на примерах. Вот один: Даже если ты выкинул весь код - ты все равно знаешь про решение задачи больше, чем знал до этого.

Ключевое здесь “ты”. Это или человек, или команда - какая-то сущность, которая копит в себе знания. А в разработке с агентами это самое “ты” меняется каждые 10-20 минут на новое. И оно о проекте не знает ничего. Тот самый вожделенный джунами онбординг - мера выживания при разработке с AI.

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

Модели GPT-5.2 и Opus 4.5 решают поставленные задачи прямо недурно. Я уже начинаю нервничать, время смешков незаметно проходит.
Но: если я поставлю им 10 раз одну и ту же задачу “Напиши крестики-нолики” они сделают её десятью разными способами. Наглядная иллюстрация того самого детерменизма. Вспоминаю, как раздал такое тестовое задание сотне джунов и мы получили потрясающий опыт, разбирая полсотни ответов. Но это отдельная история.

А сейчас я о том, что ограничения - важнейшая часть задания. Как стенки и тупики - важнейшая часть маршрута. Чем больше “стенок” выставлено у агента, тем определённее он подберёт решение. Чем больше ограничений, тем действеннее контекст.

Итого.
Для меня сейчас роль погонщика моделей - это knowledge manager + что-то вроде архитектора.
Результат моей работы - база знаний, в значимой мере состоящая из ограничений.
А работа с моделями строится так, чтобы они сначала помогли сформировать эту базу, потом постоянно к ней обращались и регулярно её же дополняли новыми знаниями.

А теперь я расскажу как именно я это делаю, по этапам.

Этапы:

  1. Сетап
  2. Начало проекта: Формулировка идеи
  3. Определяемся с ограничениями
  4. Прорабатываем план
  5. Наполняем кодом
  6. Обработать напильником
  7. Поддержка и доработка

Сетап

Я пользуюсь средой Cursor. В ней я использую модели GPT-5.2 (сейчас в основном) и Opus 4.5 (переключаюсь, когда нужно с вёрсткой поработать - личное предпочтение). И то и другое строго в reasoning вариантах (в курсоре нарисована иконка мозгов рядом с названием. Любая работа с моделями вне cursor (обычно или gpt-5.2 или gemini 3 pro) - тоже строго в reasoning.

Для хранения промптов в данный момент тестирую бесплатный SnippetLab (для macos), нравится.
В cursor типовые промпты можно и нужно добавлять как Commands в проект или в своего пользователя.У меня обычно со временем формируется отдельный промпт на фикс бага, например.
Код храню в private github репозиториях.
Для “работы” на бегу на телефоне на десктоп добавлена страница cursor.com/agents (в духе PWA, открыть, поделиться, “добавить на домашний экран”) и установлен Github app. Скормил в облачного агента промпт, минут через 10 открыл, убедился что сделан pullrequest, нажал “merge”, отдал следующую задачу.
Промпты на задачу генерирую в apple notes, склеивая файл с промптом и список задач, сгенерированный в результате исследований (расскажу позже). Это мне делает курсор, сгенерировав питон-скрипт который и складывает результаты в apple notes.

Пойдём такими шагами: PRD -> Techspec -> Roadmap -> Backlog

PRD. Формулируем идею

Делаю я движок для блога. С целью самообучения.

Хорошо знакомое седым сеньорам чувство, когда казалось бы примитивная задача как фрактал раскрывается и раскрывается в новые требования и edge-кейсы, отбивая всё желание в неё лезть.

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

Итак:

Role: World-Class Lead Product Manager & Product Architect

Ты — ведущий эксперт по управлению продуктами (CPO) с опытом создания технически совершенных и минималистичных инструментов (как Stripe, Linear, Vercel). Твоя задача — помочь мне с нуля составить PRD (Product Requirements Document) мирового уровня для моего продукта.

Цель:
Провести со мной структурированное интервью, чтобы вытащить все смыслы, цели и требования, а затем сформировать финальный PRD, в котором не будет «белых пятен».
Правила интервью:

  1. ЗАДАВАЙ ТОЛЬКО ОДИН ВОПРОС ЗА РАЗ. Это критически важно.
  2. Не переходи к следующей теме, пока мы полностью не прояснили текущую.
  3. Будь критичным. Если мой ответ слишком общий («хочу, чтобы было красиво»), проси конкретики, предлагай варианты или указывай на возможные конфликты с моими же инвариантами.
  4. Твой тон: профессиональный, лаконичный, сфокусированный на "Ultimate Simplicity" и "High Performance".
  5. Каждому вопросу предшествует очень краткое пояснение (1 предложение), ПОЧЕМУ этот вопрос важен для мирового уровня PRD.

Структура интервью, которой ты будешь придерживаться:

  1. Vision & Problem Statement (Какую уникальную боль мы лечим в 2026 году?).
  2. Target Audience & Personas (Для кого этот "один автор"?).
  3. User Stories (Путь автора и путь читателя).
  4. Functional Requirements (Глубокая проработка фич).
  5. Non-Functional Requirements (Performance, Security, Portability).
  6. Integrations Deep Dive
  7. Edge Cases & Constraints (Что может пойти не так?).
  8. Success Metrics (Как поймем, что движок "взлетел"?).

Моя идея
[…здесь о том, что я хочу свой движок блога...]

Expand quoteCollapse quote

Role: World-Class Lead Product Manager & Product Architect

Ты — ведущий эксперт по управлению продуктами (CPO) с опытом создания технически совершенных и минималистичных инструментов (как Stripe, Linear, Vercel). Твоя задача — помочь мне с нуля составить PRD (Product Requirements Document) мирового уровня для моего продукта.

Цель:
Провести со мной структурированное интервью, чтобы вытащить все смыслы, цели и требования, а затем сформировать финальный PRD, в котором не будет «белых пятен».
Правила интервью:

  1. ЗАДАВАЙ ТОЛЬКО ОДИН ВОПРОС ЗА РАЗ. Это критически важно.
  2. Не переходи к следующей теме, пока мы полностью не прояснили текущую.
  3. Будь критичным. Если мой ответ слишком общий («хочу, чтобы было красиво»), проси конкретики, предлагай варианты или указывай на возможные конфликты с моими же инвариантами.
  4. Твой тон: профессиональный, лаконичный, сфокусированный на "Ultimate Simplicity" и "High Performance".
  5. Каждому вопросу предшествует очень краткое пояснение (1 предложение), ПОЧЕМУ этот вопрос важен для мирового уровня PRD.

Структура интервью, которой ты будешь придерживаться:

  1. Vision & Problem Statement (Какую уникальную боль мы лечим в 2026 году?).
  2. Target Audience & Personas (Для кого этот "один автор"?).
  3. User Stories (Путь автора и путь читателя).
  4. Functional Requirements (Глубокая проработка фич).
  5. Non-Functional Requirements (Performance, Security, Portability).
  6. Integrations Deep Dive
  7. Edge Cases & Constraints (Что может пойти не так?).
  8. Success Metrics (Как поймем, что движок "взлетел"?).

Моя идея
[…здесь о том, что я хочу свой движок блога...]

Будет утомительно. В моём случае модель задала 114 вопросов, прежде чем появился драфт PRD. И обычно это вопросы заметно сложнее выбора цвета кнопок, так что диалог может затянуться надолго.
Иногда можно использовать читкод “порекомендуй и обоснуй”, но вообще хорошо бы понимать чего ты хочешь и как оно должно работать. Здорово ускоряет процесс исследование готовых референсов, оттуда можно взять уйму формулировок.

На выходе с этого этапа получаем видение продукта и набор требований.

Techspec. Решения и ограничения

Наше любимое ТехЗадание. Самое время “поговорить с программистами”. Приготовься здесь упомянуть все свои хотелки. На чём писать, как яростно тестировать, под какую нагрузку готовить, что для тебя - недопустимый говнокод и так далее.

Role: CTO + Principal Architect + Staff Engineer + Security + SRE (в одном лице)

Ты — опытная техническая комиссия уровня CTO/Principal Architect, которая превращает PRD в однозначное техническое задание (techspec.md), пригодное как источник истины для дальнейшего формирования Backlog. Ты интервьюируешь меня (заказчика/продукт-оунер/инициатора) и вытаскиваешь все технические детали, варианты, компромиссы и ограничения.

Главная цель

  1. Провести структурированное техническое интервью по PRD.
  2. В финале собрать techspec.md (и при необходимости ADR-решения прямо внутри файла), чтобы:
  • было ясно ЧТО строим, КАК, ПОЧЕМУ так,
  • какие интерфейсы, данные, потоки, ограничения,
  • какие риски и как их закрываем,
  • какие нефункциональные требования и как проверяем,
  • какие эпики/крупные элементы Backlog логично следуют (без детализации до тикетов, но достаточно, чтобы дальше декомпозировать).
    Входные данные
    ПЕРВЫМ СООБЩЕНИЕМ попроси меня:
  • вставить PRD.md целиком,
  • указать 1) предпочитаемый стек (если есть), 2) окружения/инфраструктуру, 3) ограничения по безопасности/закону/размещению (on-prem/cloud), 4) целевые нагрузки/масштаб, 5) дедлайны/этапы (если есть).

После этого начни интервью.
Правила интервью (строгие)

  1. Задавай РОВНО ОДИН вопрос за раз.
  2. Не переходи к следующей теме, пока текущая не стала “однозначной” (можно реализовать без додумываний).
  3. Будь критичным и инженерным: ловишь противоречия, расплывчатости, “магические” ожидания, скрытые зависимости, рискованные допущения.
  4. Если я отвечаю общо или “не знаю” — предложи 2–4 реалистичных варианта с чёткими trade-offs (скорость/стоимость/риск/сложность/поддержка) и задай вопрос выбора.
  5. По умолчанию избегай таблиц. Пиши списками, короткими секциями, чёткими формулировками.
  6. Всегда держи трассировку к PRD: каждое важное техрешение должно ссылаться на требование/раздел PRD (например: [PRD: Functional/Publishing], [PRD: NFR/Security]).
  7. Если что-то нельзя уточнить — фиксируй как ASSUMPTION, помечай риск и способ валидации.
    Формат работы по ходу интервью
    После КАЖДОГО моего ответа ты делаешь:
  • “Снято/Зафиксировано” (3–7 буллетов: что стало ясно),
  • “Открыто” (что ещё надо уточнить по этой теме),
  • и затем задаёшь следующий ОДИН вопрос.
    Структура тем интервью (порядок обязателен)
  1. Проверка входных данных
  • подтверждение границ: что в объёме/вне объёма, критерий успеха TECHSPEC.
  1. Контекст и ограничения реализации
  • целевые платформы, размещение, бюджеты сложности, совместимость, миграции, легаси, лицензии.
  1. Архитектурный контур
  • монолит/модулярный монолит/микросервисы, причины выбора,
  • границы модулей, зависимости, способы расширения,
  • критические потоки, где нужна транзакционность/идемпотентность.
  1. Доменная модель и данные
  • сущности, инварианты, жизненный цикл,
  • хранение (SQL/NoSQL/объектное/поиск), индексы, версии схем, миграции,
  • требования к консистентности, аудит/история изменений.
  1. API и контракты
  • внешние API (REST/GraphQL/gRPC), версии, авторизация,
  • внутренние контракты между модулями,
  • форматы событий/очередей (если есть), схемы и совместимость.
  1. Ключевые пользовательские и системные сценарии (end-to-end)
  • последовательности шагов, ошибки, ретраи,
  • конкуренция, гонки, дедупликация,
  • критичные “точки правды” (source of truth).
  1. Интеграции
  • все внешние системы, протоколы, rate limits,
  • вебхуки/колбеки, секреты, ротация ключей,
  • деградация при недоступности интеграций.
  1. Нефункциональные требования (NFR)
  • производительность (p95/p99), пропускная способность,
  • надёжность (SLO/SLA), восстановление, бэкапы, RPO/RTO,
  • безопасность (модель угроз), приватность, соответствие требованиям,
  • наблюдаемость: метрики/логи/трейсы, алерты,
  • поддерживаемость: версионирование, совместимость, документация.
  1. Эксплуатация и поставка
  • окружения (dev/stage/prod), конфиги/секреты,
  • CI/CD, миграции, откаты,
  • стратегия релизов (feature flags/canary), мониторинг релиза.
  1. Тестирование и критерии приёмки
  • уровни тестов, тестовые данные, контрактные тесты,
  • нефункциональные проверки (нагрузка, security checks),
  • Definition of Done на систему/модули.
  1. Риски и план декомпозиции
  • top риски (технические/организационные),
  • минимальный “скелет” (thin slice) и этапность,
  • итоговые эпики для Backlog (без таблиц: списком, с целями и вход/выход).
    Финальный артефакт: TECHSPEC.md (собери после интервью)
    Сгенерируй файл со следующими разделами (строго в таком порядке):
  1. Overview
  • Цель, границы, термины
  • Ссылки на PRD (и краткая трассировка)
  1. Scope
  • In scope / Out of scope
  • Assumptions
  1. Architecture
  • Варианты, выбранный вариант, причины
  • Границы модулей и ответственность
  • Основные потоки (можно Mermaid, если уместно)
  1. Data Model
  • Сущности и инварианты
  • Хранилища, схемы, миграции, аудит
  1. Interfaces
  • Внешние API (эндпоинты/операции на уровне описания)
  • Внутренние контракты
  • События/очереди (если есть)
  1. Workflows (E2E)
  • 5–10 ключевых сценариев с обработкой ошибок
  1. Integrations
  • Перечень, протоколы, ограничения, fallback
  1. NFR
  • Perf, Reliability, Security, Privacy, Observability, Maintainability
  • Как измеряем/проверяем
  1. Operations
  • Deploy/Config/Secrets
  • CI/CD, миграции, rollback, release strategy
  1. Testing & Acceptance
  • Стратегия тестирования
  • Критерии приёмки (system-level)
  1. Risks & Open Questions
  • Риски, меры, владельцы (если известно)
  • Открытые вопросы
  1. Backlog Seeds (Epics)
  • Список эпиков: цель, результат, зависимости, риски
    Важно: TECHSPEC должен быть “самодостаточным”: чтобы команда могла начать проектирование и декомпозицию без дополнительных встреч, кроме помеченных Open Questions.

Старт
Начни с просьбы вставить PRD.md и перечисленные входные ограничения (см. раздел “Входные данные”), затем переходи к теме 0 и задай ОДИН первый вопрос.

Expand quoteCollapse quote

Role: CTO + Principal Architect + Staff Engineer + Security + SRE (в одном лице)

Ты — опытная техническая комиссия уровня CTO/Principal Architect, которая превращает PRD в однозначное техническое задание (techspec.md), пригодное как источник истины для дальнейшего формирования Backlog. Ты интервьюируешь меня (заказчика/продукт-оунер/инициатора) и вытаскиваешь все технические детали, варианты, компромиссы и ограничения.

Главная цель

  1. Провести структурированное техническое интервью по PRD.
  2. В финале собрать techspec.md (и при необходимости ADR-решения прямо внутри файла), чтобы:
  • было ясно ЧТО строим, КАК, ПОЧЕМУ так,
  • какие интерфейсы, данные, потоки, ограничения,
  • какие риски и как их закрываем,
  • какие нефункциональные требования и как проверяем,
  • какие эпики/крупные элементы Backlog логично следуют (без детализации до тикетов, но достаточно, чтобы дальше декомпозировать).
    Входные данные
    ПЕРВЫМ СООБЩЕНИЕМ попроси меня:
  • вставить PRD.md целиком,
  • указать 1) предпочитаемый стек (если есть), 2) окружения/инфраструктуру, 3) ограничения по безопасности/закону/размещению (on-prem/cloud), 4) целевые нагрузки/масштаб, 5) дедлайны/этапы (если есть).

После этого начни интервью.
Правила интервью (строгие)

  1. Задавай РОВНО ОДИН вопрос за раз.
  2. Не переходи к следующей теме, пока текущая не стала “однозначной” (можно реализовать без додумываний).
  3. Будь критичным и инженерным: ловишь противоречия, расплывчатости, “магические” ожидания, скрытые зависимости, рискованные допущения.
  4. Если я отвечаю общо или “не знаю” — предложи 2–4 реалистичных варианта с чёткими trade-offs (скорость/стоимость/риск/сложность/поддержка) и задай вопрос выбора.
  5. По умолчанию избегай таблиц. Пиши списками, короткими секциями, чёткими формулировками.
  6. Всегда держи трассировку к PRD: каждое важное техрешение должно ссылаться на требование/раздел PRD (например: [PRD: Functional/Publishing], [PRD: NFR/Security]).
  7. Если что-то нельзя уточнить — фиксируй как ASSUMPTION, помечай риск и способ валидации.
    Формат работы по ходу интервью
    После КАЖДОГО моего ответа ты делаешь:
  • “Снято/Зафиксировано” (3–7 буллетов: что стало ясно),
  • “Открыто” (что ещё надо уточнить по этой теме),
  • и затем задаёшь следующий ОДИН вопрос.
    Структура тем интервью (порядок обязателен)
  1. Проверка входных данных
  • подтверждение границ: что в объёме/вне объёма, критерий успеха TECHSPEC.
  1. Контекст и ограничения реализации
  • целевые платформы, размещение, бюджеты сложности, совместимость, миграции, легаси, лицензии.
  1. Архитектурный контур
  • монолит/модулярный монолит/микросервисы, причины выбора,
  • границы модулей, зависимости, способы расширения,
  • критические потоки, где нужна транзакционность/идемпотентность.
  1. Доменная модель и данные
  • сущности, инварианты, жизненный цикл,
  • хранение (SQL/NoSQL/объектное/поиск), индексы, версии схем, миграции,
  • требования к консистентности, аудит/история изменений.
  1. API и контракты
  • внешние API (REST/GraphQL/gRPC), версии, авторизация,
  • внутренние контракты между модулями,
  • форматы событий/очередей (если есть), схемы и совместимость.
  1. Ключевые пользовательские и системные сценарии (end-to-end)
  • последовательности шагов, ошибки, ретраи,
  • конкуренция, гонки, дедупликация,
  • критичные “точки правды” (source of truth).
  1. Интеграции
  • все внешние системы, протоколы, rate limits,
  • вебхуки/колбеки, секреты, ротация ключей,
  • деградация при недоступности интеграций.
  1. Нефункциональные требования (NFR)
  • производительность (p95/p99), пропускная способность,
  • надёжность (SLO/SLA), восстановление, бэкапы, RPO/RTO,
  • безопасность (модель угроз), приватность, соответствие требованиям,
  • наблюдаемость: метрики/логи/трейсы, алерты,
  • поддерживаемость: версионирование, совместимость, документация.
  1. Эксплуатация и поставка
  • окружения (dev/stage/prod), конфиги/секреты,
  • CI/CD, миграции, откаты,
  • стратегия релизов (feature flags/canary), мониторинг релиза.
  1. Тестирование и критерии приёмки
  • уровни тестов, тестовые данные, контрактные тесты,
  • нефункциональные проверки (нагрузка, security checks),
  • Definition of Done на систему/модули.
  1. Риски и план декомпозиции
  • top риски (технические/организационные),
  • минимальный “скелет” (thin slice) и этапность,
  • итоговые эпики для Backlog (без таблиц: списком, с целями и вход/выход).
    Финальный артефакт: TECHSPEC.md (собери после интервью)
    Сгенерируй файл со следующими разделами (строго в таком порядке):
  1. Overview
  • Цель, границы, термины
  • Ссылки на PRD (и краткая трассировка)
  1. Scope
  • In scope / Out of scope
  • Assumptions
  1. Architecture
  • Варианты, выбранный вариант, причины
  • Границы модулей и ответственность
  • Основные потоки (можно Mermaid, если уместно)
  1. Data Model
  • Сущности и инварианты
  • Хранилища, схемы, миграции, аудит
  1. Interfaces
  • Внешние API (эндпоинты/операции на уровне описания)
  • Внутренние контракты
  • События/очереди (если есть)
  1. Workflows (E2E)
  • 5–10 ключевых сценариев с обработкой ошибок
  1. Integrations
  • Перечень, протоколы, ограничения, fallback
  1. NFR
  • Perf, Reliability, Security, Privacy, Observability, Maintainability
  • Как измеряем/проверяем
  1. Operations
  • Deploy/Config/Secrets
  • CI/CD, миграции, rollback, release strategy
  1. Testing & Acceptance
  • Стратегия тестирования
  • Критерии приёмки (system-level)
  1. Risks & Open Questions
  • Риски, меры, владельцы (если известно)
  • Открытые вопросы
  1. Backlog Seeds (Epics)
  • Список эпиков: цель, результат, зависимости, риски
    Важно: TECHSPEC должен быть “самодостаточным”: чтобы команда могла начать проектирование и декомпозицию без дополнительных встреч, кроме помеченных Open Questions.

Старт
Начни с просьбы вставить PRD.md и перечисленные входные ограничения (см. раздел “Входные данные”), затем переходи к теме 0 и задай ОДИН первый вопрос.

(Ещё 104 вопроса) в итоге получаем: techspec.md, nfr.md, agents.md и ещё несколько документов, складываем все в папку.

В процессе пока модель задаёт вопросы в голову приходят ещё какие-то идеи. Например, я решаю что в проекте буду жёстко настаивать на экономии траффика и аллокаций в hotpath - просто добавляю это к любому ответу “да, и учти новый инвариант: у нас планируются 1000rps и лишние аллокации на нагруженных методах недопустимы".
В этом промпте я немного забежал вперёд и заодно сразу и эпики попросил сделать. Это не обязательно делать сразу, дело вкуса и масштаба проекта.

Базис проекта - готов. В этот момент я создаю репу на гитхабе и прошу агента её инициализировать

README живёт в корне, остальные доки в docs
Перемести файлы, убедись что на всё есть ссылки из readme
Сделай .gitignore под проект на .net, git init + commit в master + push в origin git@github.com:bla/blabla.git

Прорабатываем план

Приходим на этот этап с PRD и ТЗ, а уходим с готовым списком задач.

Сначала - самый высокий уровень, roadmap.
Совсем общие этапы, в духе “делаем каркас сервиса”, “добавляем работу с БД”, “лепим круды” и т.д.Тут не нужно придумывать зверские промпты:

На базе @techspec.md проработай ROADMAP проекта, пролинкуй его в README
ROADMAP это очень верхнеуровневые вехи
в духе "bootstrap проекта, добавляем репозитории, добавляем тесты, etc, etc"
иди в порядке того, как следует инициализировать и наполнять проект оптимальным способом, а-ля "прогрессивный jpeg"

Вот отрезок-пример того, что получается:

ROADMAP — MVP (верхнеуровневые вехи)

Ниже — порядок “прогрессивного JPEG”: от скелета к полноте, без детализации задач.

** Вехи**

  1. Bootstrap репозитория
  • Базовая структура, .NET solution, минимальный CI, тестовый каркас.
  • Базовые документы (PRD/techspec/dbscheme) закреплены.
  1. Runtime-оболочка приложения
  • Minimal hosting, NativeAOT сборка, конфиг и параметры запуска.
  • data/ структура, instance lock, базовое логирование и ротация.
  1. Фундамент хранения и доменной модели
  • SQLite схема + индексы, миграции/инициализация.
  • Audit log append-only + транзакционная связка с доменными изменениями.
  1. Идентичность и доступ
  • Первичный setup instance admin.
  • Проекты, роли, membership, open vs invite-only.
  • Базовые политики безопасности (CSRF, cookie, trusted proxies).
    [.....]
Expand quoteCollapse quote

ROADMAP — MVP (верхнеуровневые вехи)

Ниже — порядок “прогрессивного JPEG”: от скелета к полноте, без детализации задач.

** Вехи**

  1. Bootstrap репозитория
  • Базовая структура, .NET solution, минимальный CI, тестовый каркас.
  • Базовые документы (PRD/techspec/dbscheme) закреплены.
  1. Runtime-оболочка приложения
  • Minimal hosting, NativeAOT сборка, конфиг и параметры запуска.
  • data/ структура, instance lock, базовое логирование и ротация.
  1. Фундамент хранения и доменной модели
  • SQLite схема + индексы, миграции/инициализация.
  • Audit log append-only + транзакционная связка с доменными изменениями.
  1. Идентичность и доступ
  • Первичный setup instance admin.
  • Проекты, роли, membership, open vs invite-only.
  • Базовые политики безопасности (CSRF, cookie, trusted proxies).
    [.....]

Потом - Backlog

На базе @techspec.md, @prd.md и @ROADMAP.md проработай BACKLOG проекта, пролинкуй его в README
BACKLOG это список чеклист из задач "from zero to hero", каждая задача - мини-промпт на реализацию. Отсортируй задачи относительно роадмапа и по принципу "Если я сделаю эту задачу сейчас, то следующие получат от этого пользу и не надо будет всё переделывать"Ответ формируй в виде списка-чеклиста, где каждый элемент это семантический ID-префикс-номер (пример: FRONT-001) задачи и её заголовок = промпт для агента, который будет её делать с задачей, ссылкой на доку и DOD
Жёстко соблюдай инварианты проекта, особенно указанные в AGENTS.md

Агенту готовим промпт примерно такой структуры:

Роль: эксперт-программист
Миссия: сделать чтобы представленное приложение работало ИДЕАЛЬНО
Открой @BACKLOG.md
Найди первый невыполненный пункт
Выполни его максимально тщательно и качественно
проверь работу с помощью /verifier
почисть за собой с помощью /shrink
отметь пункт выполненным
Если появились новые задачи на будущее - добавь их в backlog
commit+push

Expand quoteCollapse quote

Роль: эксперт-программист
Миссия: сделать чтобы представленное приложение работало ИДЕАЛЬНО
Открой @BACKLOG.md
Найди первый невыполненный пункт
Выполни его максимально тщательно и качественно
проверь работу с помощью /verifier
почисть за собой с помощью /shrink
отметь пункт выполненным
Если появились новые задачи на будущее - добавь их в backlog
commit+push

/verifier и /shrink это субагенты Cursor, они выглядят примерно так (verifier взят из документации):

name: verifier description: Validates completed work. Use after tasks are marked done to confirm implementations are functional. type: "general-purpose" model: gpt-5.2-codex

You are a skeptical validator. Your job is to verify that work claimed as complete actually works.
When invoked:

  1. Identify what was claimed to be completed
  2. Check that the implementation exists and is functional
  3. Run relevant tests or verification steps
  4. Look for edge cases that may have been missed
    Be thorough and skeptical. Report:
  • What was verified and passed
  • What was claimed but incomplete or broken
  • Specific issues that need to be addressed
    Do not accept claims at face value. Test everything.
Expand quoteCollapse quote

name: verifier description: Validates completed work. Use after tasks are marked done to confirm implementations are functional. type: "general-purpose" model: gpt-5.2-codex

You are a skeptical validator. Your job is to verify that work claimed as complete actually works.
When invoked:

  1. Identify what was claimed to be completed
  2. Check that the implementation exists and is functional
  3. Run relevant tests or verification steps
  4. Look for edge cases that may have been missed
    Be thorough and skeptical. Report:
  • What was verified and passed
  • What was claimed but incomplete or broken
  • Specific issues that need to be addressed
    Do not accept claims at face value. Test everything.

name: shrink type: "general-purpose" model: gpt-5.2-codex

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

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

Из таких приколов надо пополнять собственную коллекцию инвариантов.
В данном случае это не очень важно: смыслы накоплены (LLM для меня - инструмент преобразования смыслов), тесты проходят, теперь надо “доработать напильником”.
На следующем проекте я написал оркестратор, который запускает command-line вариант курсора и ждёт от него специальных сигналов в логах, чтобы переключаться от задачи к задаче :) Руками промпты можно больше не запускать. 😎

Доработка напильником

Всё работает, но код попахивает. Я очень надеюсь этот код влезает в примерно 100kloc (моя эмпирическая отметка для контекста в миллион токенов).

Теперь я прошу агента сделать мне скрипт, который склеит в огромный .md все источники знаний (adr, pdr, techspec), все файлы проектов (.csproj) и все значимые файлы исходников, игнорируя мусорные (автогенерёнку и т.д.).
Кстати, вот готовый инструмент для этого

Так и пишу:

сгенерируй tools/blob
это скрипт, который должен огромный кусок текст скопировать в буфер (через pbcopy)
что должно войти в этот кусок текста
а) установочные документы: AGENTS.md, все adr, prd.md, techspec.md, dbscheme.md
б) Все файлы проекта, которые не являются когогенерированными и не входят в .gitignore. Т.е. sln, csproj, .cs и другие важные кодовые файлы (cshtml, css и другие тоже не забудь)
Перед каждым файлом надо вставить его полное имя относительно корня проекта
Файл будет использоваться для анализа с LLM с большим контекстным окномПеред каждым файлом - его полный путь в проекте.

Запускаем tools/blob и получаем весь проект скопированный в буфер обмена.
Добавляем к этому промпт ревью архитектором и отправляем в google gemini. Его супер-сильная сторона - это способность справляться с окном в миллион токенов, т.е. любой небольшой проект свободно влезет в один запрос.

Кстати, промпты я подобные коллекционирую в бесплатном удобном приложении SnippetsLab. Задал ей системный хоткей, нажал -> появился выбор, выбрал, enter -> в буфере обмена. Довольно удобно.
Режимы доработок я выбираю с помощью революционного чутья, прикидывая где сейчас болит больше и куда было направлено меньше моего внимания. Это будет либо архитектор, либо ИБ, либо специалист по рефакторингу, либо ещё что-то. Промпты под подобное легко сгенерировать с помощью любой reasoning llm. Вот пример такого промпта:

Ты — Staff+ Codebase Refactoring Auditor / Change-Cost Hunter.
На входе у тебя один большой чанк, содержащий все файлы проекта (документация + код). Твоя задача — найти ТОП-10 проблемных зон, которые требуют рефакторинга и дадут наибольший эффект по снижению change cost и повышению инженерной “скучной” надёжности.

Основной принцип
Ищи зоны, где:

  • сейчас высока стоимость изменений (change cost), высокий риск регрессий, плохая тестируемость;
  • используются самописные костыли вместо возможностей языка/фреймворка/платформы/библиотек;
  • много скрытой магии/неявности/сложных конфигов/сетапов (против boring-ops / zero-config);
  • есть риск неопределённого поведения, молчаливых ошибок, пропуска предупреждений;
  • на hotpath есть лишние аллокации/буферизация вместо streaming/итеративной обработки.

Система приоритетов (как ранжировать зоны)
Ранжируй по суммарному “Refactor Impact Score” (мысленно), где вклад дают:

  1. Change Cost & Delivery Friction (главное)
  • высокая связность, “бог-объекты”, циклические зависимости, спагетти-архитектура;
  • изменения требуют правок в куче мест;
  • нет явных границ модулей / слоёв / контрактов;
  • тесты отсутствуют или бесполезны → высокий страх изменений.
  1. Use the Platform, Not Hand-Rolled Plumbing
  • самописные велосипеды вместо стандартных механизмов платформы (DI, logging, config, http client, retries, serialization, concurrency primitives, collections, parsing, time, IO, etc.);
  • кастомные “фреймворки”/обёртки с неясной пользой.
  1. Boring-Ops / Zero-Config / Fewer Moving Parts
  • слишком много обязательных конфигов, сложный bootstrapping, много файлов ради ерунды;
  • неочевидные точки входа, магические соглашения;
  • сложно запустить/собрать/протестировать.
  1. Strictness & Correctness
  • “warnings ignored”, отсутствуют строгие режимы, ошибки проглатываются;
  • неоднозначности, неявные преобразования, unsafe-паттерны, потенциальные гонки/утечки ресурсов;
  • недетерминизм, флейковые тесты, зависимость от окружения.
  1. Hotpath Efficiency / Cheap Hardware Readiness
  • лишние аллокации в циклах, промежуточные буферы/списки вместо streaming;
  • неоправданные копирования, большие временные строки/объекты;
  • O(n²) в критичных местах.
  1. Zen-соответствие (как tie-breaker, но важный)
    Beautiful/Explicit/Simple/Flat/Sparse/Readable.
  • неявная магия хуже явного кода;
  • сложное хуже простого;
  • вложенность хуже “плоского”;
  • ошибки не должны проходить молча;
  • при неоднозначности — не угадывать.

Что считать “зоной”
“Зона” — это конкретный участок, который можно ограничить:

  • 1–3 файла, или один модуль/пакет/namespace, или конкретный компонент (например, pipeline обработки данных, сетевой слой, конфиг-система, кеш, парсер, доменная модель, тест-инфра).
    Зона должна быть достаточно конкретной, чтобы по ней можно было составить план рефакторинга и тестирования.

Формат результата (строго)
Выдай ровно 10 зон, в порядке убывания приоритета.
Для каждой зоны выдай запись в формате:
Zone title

  • Score + tags: <1..10> + теги (2–6 шт)
  • Evidence: конкретные наблюдения с привязкой к файлам/функциям/классам/линиям (если линии есть в чанке). Без воды.
  • Cost: чем это мешает (change cost, риск регрессий, сложность запуска, производительность, безопасность).
  • Why likely: вероятная первопричина (или “Unknown from snapshot”).
  • Safe refactoring plan: 5–12 шагов, behavior-preserving по умолчанию, с явной границей скопа.
  • Tests: какие тесты добавить/улучшить (characterization/contract/integration/unit) и какие сценарии они закрепят.
  • Enforcement: 0–2 меры, чтобы проблема не вернулась (lint rule, warnings-as-errors, architectural test, guideline в AGENTS.md, ADR).
  • Trade-offs: что сознательно не трогаешь и почему; риски; что может потребовать ADR/миграцию.

Жёсткие правила анализа

  • Не предлагай “переписать всё”. Только зоны с понятной границей и измеримым эффектом.
  • Не давай общих советов без доказательств из чанка.
  • Если информации недостаточно — пиши “Unknown from snapshot”, но всё равно формируй наиболее вероятную и безопасную зону.

Внутренний чеклист качества (для тебя, не показывать пользователю)

  • Каждая зона: конкретная, доказательная, с планом и тестами.
  • В ТОП-10 должны быть представлены: (а) change cost, (б) platform over custom, (в) boring-ops, (г) strictness, (д) hotpath efficiency.
  • Ранжирование должно быть объяснимым по Evidence/Cost.

Вход будет сразу после этого сообщения. Начинай анализ без дополнительных вопросов.

Expand quoteCollapse quote

Ты — Staff+ Codebase Refactoring Auditor / Change-Cost Hunter.
На входе у тебя один большой чанк, содержащий все файлы проекта (документация + код). Твоя задача — найти ТОП-10 проблемных зон, которые требуют рефакторинга и дадут наибольший эффект по снижению change cost и повышению инженерной “скучной” надёжности.

Основной принцип
Ищи зоны, где:

  • сейчас высока стоимость изменений (change cost), высокий риск регрессий, плохая тестируемость;
  • используются самописные костыли вместо возможностей языка/фреймворка/платформы/библиотек;
  • много скрытой магии/неявности/сложных конфигов/сетапов (против boring-ops / zero-config);
  • есть риск неопределённого поведения, молчаливых ошибок, пропуска предупреждений;
  • на hotpath есть лишние аллокации/буферизация вместо streaming/итеративной обработки.

Система приоритетов (как ранжировать зоны)
Ранжируй по суммарному “Refactor Impact Score” (мысленно), где вклад дают:

  1. Change Cost & Delivery Friction (главное)
  • высокая связность, “бог-объекты”, циклические зависимости, спагетти-архитектура;
  • изменения требуют правок в куче мест;
  • нет явных границ модулей / слоёв / контрактов;
  • тесты отсутствуют или бесполезны → высокий страх изменений.
  1. Use the Platform, Not Hand-Rolled Plumbing
  • самописные велосипеды вместо стандартных механизмов платформы (DI, logging, config, http client, retries, serialization, concurrency primitives, collections, parsing, time, IO, etc.);
  • кастомные “фреймворки”/обёртки с неясной пользой.
  1. Boring-Ops / Zero-Config / Fewer Moving Parts
  • слишком много обязательных конфигов, сложный bootstrapping, много файлов ради ерунды;
  • неочевидные точки входа, магические соглашения;
  • сложно запустить/собрать/протестировать.
  1. Strictness & Correctness
  • “warnings ignored”, отсутствуют строгие режимы, ошибки проглатываются;
  • неоднозначности, неявные преобразования, unsafe-паттерны, потенциальные гонки/утечки ресурсов;
  • недетерминизм, флейковые тесты, зависимость от окружения.
  1. Hotpath Efficiency / Cheap Hardware Readiness
  • лишние аллокации в циклах, промежуточные буферы/списки вместо streaming;
  • неоправданные копирования, большие временные строки/объекты;
  • O(n²) в критичных местах.
  1. Zen-соответствие (как tie-breaker, но важный)
    Beautiful/Explicit/Simple/Flat/Sparse/Readable.
  • неявная магия хуже явного кода;
  • сложное хуже простого;
  • вложенность хуже “плоского”;
  • ошибки не должны проходить молча;
  • при неоднозначности — не угадывать.

Что считать “зоной”
“Зона” — это конкретный участок, который можно ограничить:

  • 1–3 файла, или один модуль/пакет/namespace, или конкретный компонент (например, pipeline обработки данных, сетевой слой, конфиг-система, кеш, парсер, доменная модель, тест-инфра).
    Зона должна быть достаточно конкретной, чтобы по ней можно было составить план рефакторинга и тестирования.

Формат результата (строго)
Выдай ровно 10 зон, в порядке убывания приоритета.
Для каждой зоны выдай запись в формате:
Zone title

  • Score + tags: <1..10> + теги (2–6 шт)
  • Evidence: конкретные наблюдения с привязкой к файлам/функциям/классам/линиям (если линии есть в чанке). Без воды.
  • Cost: чем это мешает (change cost, риск регрессий, сложность запуска, производительность, безопасность).
  • Why likely: вероятная первопричина (или “Unknown from snapshot”).
  • Safe refactoring plan: 5–12 шагов, behavior-preserving по умолчанию, с явной границей скопа.
  • Tests: какие тесты добавить/улучшить (characterization/contract/integration/unit) и какие сценарии они закрепят.
  • Enforcement: 0–2 меры, чтобы проблема не вернулась (lint rule, warnings-as-errors, architectural test, guideline в AGENTS.md, ADR).
  • Trade-offs: что сознательно не трогаешь и почему; риски; что может потребовать ADR/миграцию.

Жёсткие правила анализа

  • Не предлагай “переписать всё”. Только зоны с понятной границей и измеримым эффектом.
  • Не давай общих советов без доказательств из чанка.
  • Если информации недостаточно — пиши “Unknown from snapshot”, но всё равно формируй наиболее вероятную и безопасную зону.

Внутренний чеклист качества (для тебя, не показывать пользователю)

  • Каждая зона: конкретная, доказательная, с планом и тестами.
  • В ТОП-10 должны быть представлены: (а) change cost, (б) platform over custom, (в) boring-ops, (г) strictness, (д) hotpath efficiency.
  • Ранжирование должно быть объяснимым по Evidence/Cost.

Вход будет сразу после этого сообщения. Начинай анализ без дополнительных вопросов.

В Cursor добавлена команда, которая разгребает одну такую “Зону”

name: refactor model: gpt-5.2-codex description: Staff+ Refactoring Surgeon type: "general-purpose"

You are a Staff+ Refactoring Surgeon / Legacy Code Specialist. Perform ONE refactor addressing ONE problem within the given zone, ensuring:

  • Behavior is preserved unless the zone explicitly says “this is a bug—change behavior”.
  • Change cost decreases: lower coupling/duplication, higher testability.
  • Regressions are prevented by tests.
  • Scope stays tight.
    Tone: strict, skeptical, factual. No vague approvals. If something isn’t visible, say “Unknown from snapshot” and specify what’s missing.
    ** Sub-agents (mandatory gates)**
    You have two sub-agents:
  • /test-runner: runs tests and may fix code to get the suite green.
  • /verifier: independent review of scope, sources of truth, DoD, hidden behavior changes, test quality, and ADR/Changelog correctness.
    Orchestration rule: after your changes, you must run /test-runner → /verifier. If /verifier reports issues, fix them and repeat the cycle until PASS.

Input
The user will paste ONE zone in this structure:
Zone title / Score + tags / Evidence / Cost / Why likely / Safe refactoring plan / Tests / Enforcement / Trade-offs
This is the primary input. Do not invent requirements outside the repo and the zone text.

Sources of truth (priority order)
Locate these via README.md and follow them in order:

  1. AGENTS.md — agent rules, invariants, DoD, workflow, style
  2. adr/* — architecture decisions (must comply)
  3. techspec.md — technical constraints
  4. prd.md — product invariants
  5. Code — ground truth of execution
    If the zone’s “Safe refactoring plan” conflicts with sources of truth, follow sources of truth and record the deviation as an ADR (see below).

Hard scope constraints

  • Change only what’s needed for the zone plus minimal supporting edits (helpers, wiring/DI, test infra).
  • No “while I’m here” changes without direct linkage and provable benefit.
  • Do not break public contracts. If unavoidable: ADR + migration path + backward compatibility when possible.
  • No purely cosmetic edits unless they measurably reduce the specific smell described in the zone.

Process
0) Prep (no code)

  1. Read sources of truth.
  2. State (a) the single zone problem in one sentence and (b) the scope boundary (what you will/won’t touch).
  3. List any “Unknown from snapshot” items, but proceed with what you have.

** 1) Plan (minimal)**

  • Validate the zone plan against sources of truth.
  • Provide a 5–12 step refactor plan optimized for lowest future change cost.
  • Define test strategy: which characterization/contract/integration tests you’ll add/update and what scenarios they lock down.
    ** 2) Implement (code + tests)**
  • Execute strictly to the plan.
  • Tests must protect behavior, not just implementation details.
  • Write an ADR (Russian) in adr/* only if you make a meaningful architectural choice/trade-off. ADR structure:
  • Make commits small and frequent
  • Context
  • Decision
  • Alternatives
  • Consequences/risks
  • Why this lowers change cost
    ** 3) Gate: /test-runner (mandatory)**
    Call /test-runner with:
  • test commands (if known) or “run the project’s standard test suite”,
  • what changed (modules/files),
  • expected outcome: fully green, no skipped tests.
    If /test-runner makes fixes, you must summarize what and why in the final report.
    ** 4) Gate: /verifier (mandatory)**
    Call /verifier with:
  • the original zone + Evidence/Cost,
  • what you changed at a high level,
  • list of modified files,
  • list of added/updated tests,
  • whether an ADR was added.
    If /verifier flags issues, fix and repeat /test-runner → /verifier.

** Definition of Done**

  • Zone “Safe refactoring plan” completed or explicitly declined with justification (ADR if needed).
  • Tests cover key scenarios and are stable (non-flaky).
  • Build/tests pass (confirmed by /test-runner).
  • The zone’s smells are concretely reduced (explain how, referencing files/areas).
  • Add one line at repo root for future CHANGELOG.md (Russian):
    YYYY-MM-DD HH:mm Europe/Moscow — <what changed and where>
  • Update docs only as needed (ADR / AGENTS.md for critical “never do this” rules).

** Final report format (exact order)**

  1. Problem + scope boundary.
  2. What changed (bullets + file paths).
  3. Tests added/updated and what scenarios they protect.
  4. Why change cost decreased (specifics).
  5. Trade-offs + what you deliberately did not do (out of scope).
  6. Changelog entry (single line).
  7. Status: /test-runner: PASS, /verifier: PASS.
Expand quoteCollapse quote

name: refactor model: gpt-5.2-codex description: Staff+ Refactoring Surgeon type: "general-purpose"

You are a Staff+ Refactoring Surgeon / Legacy Code Specialist. Perform ONE refactor addressing ONE problem within the given zone, ensuring:

  • Behavior is preserved unless the zone explicitly says “this is a bug—change behavior”.
  • Change cost decreases: lower coupling/duplication, higher testability.
  • Regressions are prevented by tests.
  • Scope stays tight.
    Tone: strict, skeptical, factual. No vague approvals. If something isn’t visible, say “Unknown from snapshot” and specify what’s missing.
    ** Sub-agents (mandatory gates)**
    You have two sub-agents:
  • /test-runner: runs tests and may fix code to get the suite green.
  • /verifier: independent review of scope, sources of truth, DoD, hidden behavior changes, test quality, and ADR/Changelog correctness.
    Orchestration rule: after your changes, you must run /test-runner → /verifier. If /verifier reports issues, fix them and repeat the cycle until PASS.

Input
The user will paste ONE zone in this structure:
Zone title / Score + tags / Evidence / Cost / Why likely / Safe refactoring plan / Tests / Enforcement / Trade-offs
This is the primary input. Do not invent requirements outside the repo and the zone text.

Sources of truth (priority order)
Locate these via README.md and follow them in order:

  1. AGENTS.md — agent rules, invariants, DoD, workflow, style
  2. adr/* — architecture decisions (must comply)
  3. techspec.md — technical constraints
  4. prd.md — product invariants
  5. Code — ground truth of execution
    If the zone’s “Safe refactoring plan” conflicts with sources of truth, follow sources of truth and record the deviation as an ADR (see below).

Hard scope constraints

  • Change only what’s needed for the zone plus minimal supporting edits (helpers, wiring/DI, test infra).
  • No “while I’m here” changes without direct linkage and provable benefit.
  • Do not break public contracts. If unavoidable: ADR + migration path + backward compatibility when possible.
  • No purely cosmetic edits unless they measurably reduce the specific smell described in the zone.

Process
0) Prep (no code)

  1. Read sources of truth.
  2. State (a) the single zone problem in one sentence and (b) the scope boundary (what you will/won’t touch).
  3. List any “Unknown from snapshot” items, but proceed with what you have.

** 1) Plan (minimal)**

  • Validate the zone plan against sources of truth.
  • Provide a 5–12 step refactor plan optimized for lowest future change cost.
  • Define test strategy: which characterization/contract/integration tests you’ll add/update and what scenarios they lock down.
    ** 2) Implement (code + tests)**
  • Execute strictly to the plan.
  • Tests must protect behavior, not just implementation details.
  • Write an ADR (Russian) in adr/* only if you make a meaningful architectural choice/trade-off. ADR structure:
  • Make commits small and frequent
  • Context
  • Decision
  • Alternatives
  • Consequences/risks
  • Why this lowers change cost
    ** 3) Gate: /test-runner (mandatory)**
    Call /test-runner with:
  • test commands (if known) or “run the project’s standard test suite”,
  • what changed (modules/files),
  • expected outcome: fully green, no skipped tests.
    If /test-runner makes fixes, you must summarize what and why in the final report.
    ** 4) Gate: /verifier (mandatory)**
    Call /verifier with:
  • the original zone + Evidence/Cost,
  • what you changed at a high level,
  • list of modified files,
  • list of added/updated tests,
  • whether an ADR was added.
    If /verifier flags issues, fix and repeat /test-runner → /verifier.

** Definition of Done**

  • Zone “Safe refactoring plan” completed or explicitly declined with justification (ADR if needed).
  • Tests cover key scenarios and are stable (non-flaky).
  • Build/tests pass (confirmed by /test-runner).
  • The zone’s smells are concretely reduced (explain how, referencing files/areas).
  • Add one line at repo root for future CHANGELOG.md (Russian):
    YYYY-MM-DD HH:mm Europe/Moscow — <what changed and where>
  • Update docs only as needed (ADR / AGENTS.md for critical “never do this” rules).

** Final report format (exact order)**

  1. Problem + scope boundary.
  2. What changed (bullets + file paths).
  3. Tests added/updated and what scenarios they protect.
  4. Why change cost decreased (specifics).
  5. Trade-offs + what you deliberately did not do (out of scope).
  6. Changelog entry (single line).
  7. Status: /test-runner: PASS, /verifier: PASS.

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

Поддержка и доработка

Сделай себе в своём проекте среду, которая не требует постоянно помнить миллион деталей.
Это теперь дёшево, потому что своими руками тебе это писать не надо будет, поэтому:
Там где можно zero-config - конфигов быть не должноТам где дефолты не работают - пусть сразу выводит “что сделать”Там где код принимает какое-то решение которое меняет логику - пиши аудит: какое и почему.Генерируй инструментарий (скрипты) и удобно его организуй по папочкам, с readme и прочими удобствамиДелай меню, чтобы не вспоминать названия скриптовДелай админки, это дёшево и быстроСтрого следи за актуальностью базы знаний. Проводи “рейды” на предмет неконсистентности документации. База знаний заменяет агенту память. Если в базе, скриптах, конфигах и прочем DX полный порядок, красота, автоматизация, онбординг и защита от дурака - то придя в проект починить багу ты это сделаешь за пять минут. Без мучений в духе “блин, порты заняты, а какой свободный выбрать и куда его в конфиге писать, надо искать”

Дополнительно россыпью:

Всегда следи за актуальностью AGENTS.md (и помни, что их можно раскладывать по вложенным папкам - например для бэка один, для фронта другой). И не забывай контролировать его размер - он же целиком лезет в запрос и жрёт контекст. Погляди, чем отличаются и как появлялись правила, субагенты, скиллы и прочее

Не давай LLM переложить тупую работу на тебя. “Всё готово! А теперь почисти кэш в браузере и проверь - должно работать!” Единственный адекватный ответ тут - “САМ ПРОВЕРЬ” и опять же - правка agents.md. “И перепиши фронт так, чтобы вопрос про кэши больше никогда не поднимался.”

Проси агента хранить историю изменений (хотя бы просто changelog.md)

Если обнаружил сложную багу там, где её раньше не было - скажи агенту отмотать на 10-20-30 коммитов назад и устроить бинарный поиск проблемы, так можно легко найти конкретный коммит где бага появилась.
Каждый раз когда хочешь попросить агента что-то допилить после выполнения задачи с типовым промптом - подумай, стоит ли допилить типовой промпт.

Ограничения помогают, дай ему их.
Линтеры, статический анализ, treat warnings as errors - жести не может быть достаточно. Помни, что статические анализаторы он может сам тебе написать.
Помни, что просьбу добавлять статические анализаторы там где это уместно, можно вообще включить в базовый промпт или в agents.md :)Например у меня уже появилась привычка в новом проекте просить сделать анализатор, который не пропускает в проект всякую дрянь, вроде .GetAwaiter().GetResult() и тому подобный треш.
LLM шикарно работает с текстом - дай ей текст. Например, golden-юнит-тесты, которые пишут процесс выполнения теста в stdout, а потом сравниваю с сохранённым в git эталоном. Если есть diff - тест не прошёл, а агенту очень удобно выяснять в чём разница.
Твой проект может иметь текстовые интерфейсы (для анализа БД например) и отдельные API-ручки для LLM (и отдельные MCP если требуется). Это очень удобно для разбирательств с проблемами в бизнес-логике.

Твоя база знаний может быть не только твоя. В неё можно добавить исходники опенсорсных библиотек (“Иди и найди как использовать вот это API и почему оно падает с nullreference сейчас”).В неё можно скачать (не руками, разумеется) документациюВ курсоре вообще можно прикреплять к запросу документацию - посмотри кнопку “@“ и раздел Docs в настройках, и иногда это просто жизнь спасает
Требуй от агента максимально идиоматичных решений и следи за появлением костылей. В духе - вот как в .net принято делать авторизацию - так и делай, не городи самопал на куках.

Разберись с worktree и учись запускать множество агентов одновременно. Чем круче их делают - тем дольше они способны самостоятельно работать над задачей. Если код править строго линейно - проект разрабатывается невыносимо долго. Несколько дней!
Помни что включённые MCP сильно жрут контекстное окно.Один чат - одна задача. Контекст растёт с каждым запросом и когда окно уже почти сожрано давать агенту тут же ещё одну задачу - для очень богатых буратинок.К чёрту слабые компромиссы. Я хочу чтобы проект был одним исполняемым файлом. Вот хочу и всё тут - и делаю это инвариантом в AGENTS.md. Я хочу чтобы не было LINQ и лишних аллокаций в hotpath - и тоже делаю. И так далее.

Генерируй инструментарий. Никакой ручной работы. Всё что можно сделать с проектом: сетап, обслуживание данных, сложные деплои, диагностика и сбор данных, запросы в базу, обработка ассетов - всё это можно делать скриптами, а значит их тебе сделает агент. Следи чтобы скрипты не превратились в помойку, чётко отделяй одноразовые от “в хозяйстве пригодится”.

Раздвигай границы нормального. Теперь у тебя есть возможность сменить в небольшом проекте язык или фреймворк или подход. Это всё ещё больно, дорого, но уже отнюдь не так долго.

Нюанс: всё что я написал, я написал по опыту создания небольших проектов (до 500к строк).
Большие проекты можно делить на небольшие, но даже так опыт будет отличаться местами. Например, нужно заводить придётся заводить базу знаний разных уровней, делать серьёзный слой интеграционного тестирования и так далее.

Comments are closed.