Шаблоны подсказок для более чистой архитектуры ПО и уменьшения переписок

Как выглядит «чистая архитектура» в работе с ИИ

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

Практическое определение: ясность, модульность, тестируемость

Ясность означает, что назначение и форма системы очевидны из короткого описания: что она делает, кто её использует, какие данные обрабатывает и чего она ни в коем случае не должна делать. В работе с ИИ ясность также значит, что модель может переформулировать требования так, как вы готовы их утвердить.

Модульность значит, что обязанности имеют чёткие границы. Каждый модуль выполняет свою задачу, имеет входы/выходы и минимальное знание внутренних деталей других модулей. Когда ИИ генерирует код, модульность предотвращает разброс бизнес-правил по контроллерам, UI и доступу к данным.

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

Почему происходят переписывания (и как ИИ это усиливает)

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

• Фичу построили для одного типа пользователя, затем оказалось, что есть три роли с разными правами.
• Правила производительности, логирования аудита или хранения данных появились поздно.
• Внешний API ведёт себя иначе, чем ожидалось, и это ломает всё вокруг.

ИИ ускоряет этот сценарий, генерируя убедительный результат быстро — легко опираться на шаткую основу.

Что ожидать от шаблонов в этом руководстве

Паттерны — это шаблоны для адаптации, а не волшебные подсказки. Их цель — вынудить нужные разговоры на ранней стадии: прояснить ограничения, сравнить варианты, задокументировать предположения и определить контракты. Если вы пропустите это мышление, модель охотно заполнит пробелы — и потом вы за это заплатите.

Где эти паттерны вписываются в ваш рабочий процесс

Вы будете применять их на всём цикле доставки:

• Планирование: уточнить требования и критерии успеха
• Дизайн: выбрать границы, потоки данных и контракты
• Кодинг: сохранять разделение ответственности по мере роста реализации
• Ревью: ловить риски и несоответствия до того, как они превратятся в переписывания

Если вы используете vibe-кодинг (где система генерируется и итерируется через чат), эти контрольные точки особенно важны. Например, в Koder.ai можно запустить «режим планирования», чтобы зафиксировать требования и контракты до генерации React/Go/PostgreSQL кода, а затем использовать снимки/откат для безопасной итерации при изменении предположений — без превращения каждого изменения в переписывание.

Как использовать шаблоны подсказок, не создавая лишней работы

Шаблоны подсказок наиболее полезны, когда они уменьшают число принятия решений и возвратов. Секрет — использовать их как короткие, повторяемые чекпоинты: перед кодингом, во время дизайна и при обзоре — чтобы ИИ генерировал артефакты, которые можно переиспользовать, а не дополнительный текст, через который придётся продираться.

Когда использовать паттерны

До кодинга: проведите один цикл выравнивания, чтобы подтвердить цели, пользователей, ограничения и метрики успеха.

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

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

Соберите входные данные заранее (не делайте это тяжёлым)

Вы получите лучше результаты с небольшим, согласованным набором входных данных:

• Цели: что значит «готово» (целевые задержки, UX-результаты, ограничения по стоимости)
• Пользователи: роли, ключевые сценарии и основные боли
• Ограничения: технический стек, сроки, соответствие/безопасность
• Данные и интеграции: источники, владение, API, сторонние зависимости

Если что-то неизвестно, скажите об этом явно и попросите ИИ перечислить предположения.

Просите переиспользуемые форматы вывода

Вместо «объясни дизайн» просите артефакты, которые можно вставить в документацию или тикеты:

• Журнал решений (варианты → плюсы/минусы → выбранный → почему)
• Таблица компонентов с обязанностями и границами
• Чеклист по надёжности и тестированию
• Простой описание диаграммы (например, Mermaid-текст), который можно отрисовать позже

Итерации короткими циклами с критериями приёма

Делайте 10–15 минутные циклы: подсказка → беглый просмотр → уточнение. Всегда добавляйте acceptance criteria (что должно быть верно для принятия дизайна), затем просите ИИ самопроверить результат по ним. Это предотвращает бесконечные редизайны и делает паттерны из следующих разделов быстрыми в применении.

Паттерн 1: Уточните требования до любого дизайна

Большинство «архитектурных переписок» вызваны не плохими диаграммами, а тем, что строят правильную вещь для неправильной (или неполной) проблемы. Когда вы используете LLM рано, не просите сначала архитектуру. Попросите его выявить неоднозначности.

Движение подсказки: превратите неуверенность в чеклист

Используйте модель как аналитика требований. Цель — короткая приоритетная спецификация, которую можно подтвердить до того, как кто-то начнёт проектировать компоненты, выбирать базы данных или фиксировать API.

Вот шаблон для копирования и вставки:

You are my requirements analyst. Before proposing any architecture, do this:

1) Ask 10–15 clarifying questions about missing requirements and assumptions.
   - Group questions by: users, workflows, data, integrations, security/compliance, scale, operations.

2) Produce a prioritized scope list:
   - Must-have
   - Nice-to-have
   - Explicitly out-of-scope

3) List constraints I must confirm:
   - Performance (latency/throughput targets)
   - Cost limits
   - Security/privacy
   - Compliance (e.g., SOC2, HIPAA, GDPR)
   - Timeline and team size

4) End with: “Restate the final spec in exactly 10 bullets for confirmation.”

Context:
- Product idea:
- Target users:
- Success metrics:
- Existing systems (if any):

На что смотреть в ответе

Вам нужны вопросы, которые вынуждают принять решения (а не общие «расскажите подробнее») и список must-have, который реально влезает в ваш таймлайн.

Относитесь к «10 пунктам» как к контракту: вставьте их в тикет/PR, получите быстрое да/нет от стейкхолдеров и только потом переходите к архитектуре. Этот шаг предотвращает наиболее частую причину поздних рефакторингов: создание фич, которые на самом деле не были нужны.

Паттерн 2: Сначала пользовательские пути, потом технические решения

Если вы начинаете с инструментов («нам нужен event sourcing?»), то часто проектируете под архитектуру, а не под пользователя. Быстрый путь к чистой структуре — заставить ИИ сначала описать пользовательские пути простым языком, а затем переводить их в компоненты, данные и API.

Простой шаблон «journey-first» для вставки

• Роли: user / admin / system
• Ключевые действия: что каждая роль пытается сделать
• Пограничные случаи: что может пойти не так (некорректный ввод, отсутствие прав, частичное завершение)

Затем попросите:

1. «Опишите пошаговый поток для каждого действия простым языком.»

2. «Дайте простой список/диаграмму состояний (например, Draft → Submitted → Approved → Archived).»

3. «Перечислите не-хэппи-пасс сценарии: таймауты, повторы, дубликаты запросов, отмены и неверный ввод.»

Как превращать пути в решения (без преждевременных шагов)

Когда потоки ясны, можно попросить ИИ сопоставить их с техническими решениями:

• Где нужна валидация, а где — бизнес-правила?
• На каких шагах требуется идемпотентность (безопасные повторы)?
• Какие данные нужно хранить, что можно выводить и что требует аудита?

Только после этого просите скетч архитектуры (сервисы/модули, границы и ответственности), прямо привязанный к шагам потока.

Перевод потоков в тестируемые acceptance criteria

Завершите тем, что ИИ конвертирует каждый путь в acceptance criteria, которые можно протестировать:

• «Given/When/Then для каждого шага и ошибок.»
• «Что должна возвращать/показывать система?»
• «Что логгировать и что должно инициировать повторную попытку вместо пользовательской ошибки?»

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

Паттерн 3: Журнал предположений, чтобы избежать неприятных сюрпризов

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

Что просить у модели

Цель — вынудить чёткое разделение между фактами, которые вы задали, и предположениями, которые она вывела.

Используйте такой шаблон подсказки:

Template prompt “Before proposing any solution: list your assumptions. Mark each as validated (explicitly stated by me) or unknown (you inferred it). For each unknown assumption, propose a fast way to validate it (question to ask, metric to check, or quick experiment). Then design based only on validated assumptions, and call out where unknowns could change the design.”

Удобный формат «assumption log»

Держите его коротким, чтобы им реально пользовались:

• Assumption: …
• Status: validated / unknown
• Why it matters: какое решение это влияет
• How to validate: вопрос, проверка или spike
• If wrong, likely change: что вы бы переработали

Триггеры «что бы изменило ваш ответ»

Добавьте строку, заставляющую модель назвать точки перелома:

• «List 5 triggers: what would change your answer? (например: объём пользователей, целевая латентность, требования по соответствию, правила хранения данных).»

Этот паттерн превращает архитектуру в набор условных решений. Вы получаете не просто диаграмму — а карту того, что нужно подтвердить прежде, чем фиксировать выбор.

Паттерн 4: Сравните несколько архитектур прежде чем выбирать

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

Основной шаблон подсказки

Попросите шаблон, который требует несколько архитектур и структурированную таблицу компромиссов:

Propose 2–3 viable architectures for this project.
Compare them in a table with criteria: complexity, reliability, time-to-ship, scalability, cost.
Then recommend one option for our constraints and explain why it wins.
Finally, list “what we are NOT building” in this iteration to keep scope stable.

Context:
- Users and key journeys:
- Constraints (team size, deadlines, budget, compliance):
- Expected load and growth:
- Current systems we must integrate with:

Почему это снижает переписывания

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

Таблица критериев останавливает обсуждения типа «микросервисы против монолита» от перехода в сферу мнений и привязывает выбор к тому, что вам действительно важно — быстро выпустить, снизить операционные расходы или повысить надёжность.

Требуйте рекомендацию и границы

Не принимайте «зависит». Попросите ясную рекомендацию и конкретные ограничения, которые она оптимизирует.

Также настаивайте на списке «что мы не строим». Примеры: «Нет multi-region failover», «Нет plugin-системы», «Нет real-time notification'ов». Это предохраняет архитектуру от тихого расширения ради фич, к которым вы ещё не готовы — и предотвращает неожиданные переписывания при изменении объёма.

Паттерн 5: Подсказки про модульные границы и ответственности

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

Основная идея

Попросите ИИ определить модули и ответственности, а также что категорически не принадлежит каждому модулю. Затем запросите только интерфейсы (входы/выходы) и правила зависимостей, а не план сборки или детали реализации.

Шаблон для копирования

Используйте это при скетчинге новой фичи или рефакторинге запутанной области:

• Context: <один абзац про продукт/фичу>
• Goal: предложить модульную архитектуру из 4–8 модулей.

1. Перечислите модули с:

   • Цель (1 предложение)
   • Ответственности (3–5 пунктов)
   • Не‑ответственности («не обрабатывает…») (2–3 пункта)

2. Для каждого модуля определите только интерфейсы:

   • Входы (события/запросы/данные)
   • Выходы (ответы/события/побочные эффекты)
   • Публичный API (имена функций или эндпойнты ок; без внутренних классов)

3. Правила зависимостей:

   • Разрешённые зависимости (A → B)
   • Запрещённые зависимости (A ↛ C) с обоснованием
   • Где живут общие типы (и что никогда не должно быть общим)

4. Тест на будущие изменения: Для трёх вероятных изменений: <list 3>, покажите, какой модуль должен принять изменение и почему.

Как выглядит «хороший» ответ

Цель — модули, которые можно описать коллеге за минуту. Если ИИ предлагает «Utils» или помещает бизнес-логику в контроллеры — надавите: «Перенесите принятие решений в доменный модуль, а адаптеры держите тонкими.»

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

Паттерн 6: Данные и API-контракты сначала (избегайте переработок интеграций)

Переработки интеграций чаще вызваны не плохим кодом, а неясными контрактами. Если модель данных и форма API решаются поздно, каждая команда/модуль заполняет пробелы по‑своему, и в следующем спринте вы тратите время на согласование.

Начинайте с запроса контрактов до разговоров о фреймворках, БД или микросервисах. Чёткий контракт становится общей ссылкой, которая держит UI, бэкенд и пайплайны данных в одной плоскости.

Запрос «контрактов сначала»

Используйте раннюю подсказку:

• Шаблон: “Describe the data model, ownership, and lifecycle for each entity”

Затем обязательно попросите:

• API-контракты с примерами (запросы, ответы, форматы ошибок)
• правила версионирования и ожидания по обратной совместимости
• правила валидации и крайние случаи для каждого поля

Как выглядит «хорошо»

Хороший вывод — конкретные артефакты, а не рассуждения. Например:

• Entity: Subscription
  • Owner: Billing service
  • Lifecycle: created on checkout → active → past_due → canceled (soft-delete after 90 days)
  • Source of truth: billing DB; other services cache read-only copies

И эскиз API:

POST /v1/subscriptions
{
  "customer_id": "cus_123",
  "plan_id": "pro_monthly",
  "start_date": "2026-01-01"
}

201 Created
{
  "id": "sub_456",
  "status": "active",
  "current_period_end": "2026-02-01"
}

422 Unprocessable Entity
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "start_date must be today or later",
    "fields": {"start_date": "in_past"}
  }
}

Правила версионирования и совместимости

Попросите модель задать правила, например: «Добавочные поля допускаются без версии; переименования требуют /v2; клиенты должны игнорировать неизвестные поля.» Этот шаг предотвращает тихие несовместимости и последующие переписывания.

Паттерн 7: Сценарии отказов и чеклист надёжности

Архитектуры переписывают, когда дизайн под счастливый путь сталкивается с реальным трафиком, ненадёжными зависимостями и неожиданным поведением пользователей. Этот паттерн делает надёжность явным результатом проектирования, а не пост‑релизной паникой.

Шаблон для копирования

Используйте этот запрос с описанной архитектурой:

List failure modes; propose mitigations; define observability signals.

For each failure mode:

• What triggers it?
• User impact (what the user experiences)
• Mitigation (design + operational)
• Retries, idempotency, rate limits, timeouts considerations
• Observability: logs/metrics/traces + alert thresholds

Что обязательно покрыть

Сфокусируйте ответ, назвав интерфейсы, которые могут падать: внешние API, БД, очереди, провайдер аутентификации и фоновые задачи. Затем требуйте конкретных решений:

• Повторы: когда повторять, сколько раз, стратегия экспоненциального бэкоффа и какие ошибки повторимы.
• Идемпотентность: ключи идемпотентности, окна дедупа, что безопасно воспроизвести.
• Ограничения скорости: лимиты по пользователю/IP/сервису, сообщения для клиентов и защита на сервере.
• Таймауты: для каждой зависимости, общий бюджет запроса и отмена цепочки.

Чеклист надёжности

Завершите тем: «Вернуть простой чеклист, который можно просмотреть за 2 минуты.» Хороший чеклист содержит пункты вроде: таймауты зависимостей установлены, повторы ограничены, идемпотентность для create/charge операций реализована, есть backpressure/лимиты, определён graceful degradation.

Наблюдаемость, связанная с пользовательскими действиями

Попросите евенты вокруг пользовательских моментов (не только системные): «user_signed_up», «checkout_submitted», «payment_confirmed», «report_generated». Для каждого попросите:

• Поля логов (user_id, request_id, idempotency_key)
• Метрики (success rate, latency p95/p99, retry count)
• Трейсы (спаны по вызовам зависимостей)

Это превращает надёжность в проектный артефакт, который можно валидировать ещё до написания кода.

Паттерн 8: Планирование MVP‑слайса, чтобы не перетрудиться

Частый сценарий, когда AI‑проектирование создаёт переписку — это стремление «всё предусмотреть» слишком рано. Решение простое: требуйте самый маленький полезный срез, который доставляет ценность, подтверждает дизайн и оставляет опции открытыми.

Шаблон подсказки

Используйте это, когда решение начинает разрастаться:

Template: “Propose the smallest usable slice; define success metrics; list follow-ups.”

Попросите модель ответить:

• MVP slice: что включено, чтобы отправить реальный продукт
• Success metrics: как понять, что это сработало (пользовательские + технические)
• Follow-ups: что можно отложить без потери обучения

Требуйте фазовый роадмап (MVP → v1 → v2)

Добавьте: «Дайте фазовый роадмап: MVP → v1 → v2 и объясните, какой риск сглаживает каждая фаза.» Это держит идеи на виду, но не врезает их в первый релиз.

Желательные результаты:

• MVP валидация ядра и тонкая end-to-end дорожка.
• v1 — укрепление надёжности и недостающих must-have.
• v2 — расширение, интеграции и оптимизации.

Явные исключения, чтобы не раздувать scope

Сильная строка: «Перечислите, что явно вне объёма MVP.» Исключения защищают архитектуру от преждевременной сложности.

Примеры:

• «Нет multi-region failover в MVP (логируем инциденты; план на v2).»
• «Нет plugin-системы пока (держим границы чистыми, фиксируем модули).»
• «Только один платежный провайдер; абстрагируем позже при необходимости.»

Превратите план в тикеты с зависимостями

Наконец: «Конвертируй MVP в тикеты, каждый с acceptance criteria и зависимостями.» Это заставляет понять и явные, и скрытые coupling'и.

Типичный набор тикетов:

1. Тонкий end-to-end «счастливый путь»
2. Минимальная модель данных + API-контракт
3. Базовая обработка ошибок и логирование
4. Одна интеграция с заглушкой на случай недоступности

Если нужно, попросите вывод в формате вашей команды (например, поля в стиле Jira) и держите последующие фазы как отдельный бэклог.

Паттерн 9: Тест‑первый подход, который формирует лучший дизайн

Простой способ не дать архитектуре расползаться — требовать тесты до проектирования. Когда вы просите LLM сначала написать acceptance tests, он вынужден назвать поведение, входы/выходы и крайние случаи. Это естественно выявляет пропущенные требования и толкает реализацию к чистым модульным границам.

Шаблон для копирования

Используйте это как «ворота» перед проектированием компонента:

• Template: “Write acceptance tests first; then propose implementation. You must: (1) list assumptions, (2) name unit vs integration tests, (3) define test data and mocks vs real dependencies, (4) include a definition of done.”

Попросите тесты в рамках модулей

Далее: «Группируй тесты по ответственности модулей (API, доменная логика, персистенс, внешние интеграции). Для каждой группы указывай, что мокать, а что держать реальным.»

Это отталкивает LLM от спутанных дизайнов. Если модель не может объяснить границы интеграционных тестов — архитектура, вероятно, ещё не ясна.

Стратегия тестовых данных: избегайте хрупких наборов

Попросите: «Предложи стратегию тестовых данных: фиксы vs фабрики, как генерировать крайние случаи и как сохранить детерминизм. Какие зависимости можно подменять in-memory, а какие требуют реального сервиса в CI.»

Часто «простая» фича требует контракта, seed‑набора или стабильных идентификаторов — лучше обнаружить это сейчас, чем во время переписывания.

Definition of done (чтобы дизайн ушёл в релиз)

Завершите лёгким чеклистом:

• Тесты проходят (unit + integration) и покрывают критические отказные сценарии
• Минимальная документация: использование, конфиг и краткая инструкция по отладке
• Мониторинг/алерты для ключевых отказных режимов
• План релиза (feature flag, шаги миграции, rollback)

Паттерн 10: Подсказки для ревью дизайна — ловите проблемы рано

Ревью дизайна не должны происходить только после написания кода. С ИИ вы можете провести «пре‑мортем» ревью по черновой архитектуре (даже если это пара абзацев и диаграмма‑в‑словах) и получить конкретный список слабых мест до переписываний.

Основной шаблон ревью

Начните с жёсткой позиции ревьюера и требуйте конкретики:

Prompt: “Act as a reviewer; list risks, inconsistencies, and missing details in this design. Be concrete. If you can’t evaluate something, say what information is missing.”

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

Превращайте фидбек в punch‑лист

Ревью проваливаются, когда фидбек размытый. Попросите ранжированный набор исправлений:

Prompt: “Give me a prioritized punch list. For each item: severity (Blocker/High/Medium/Low), why it matters, suggested fix, and the smallest validation step.”

Это даст задачи, готовые к решению, а не споры.

Квантифицируйте риск переписывания

Полезный приём — простой скор:

Prompt: “Assign a rewrite risk score from 1–10. Explain the top 3 drivers. What would reduce the score by 2 points with minimal effort?”

Не нужна точность; важно выявить самые рискованные предположения.

Завершите «diff‑планом»

И наконец, предупредите расширение scope:

Prompt: “Provide a diff plan: minimal changes needed to reach the target design. List what stays the same, what changes, and any breaking impacts.”

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

Пак с подсказками для копирования и простой рабочий процесс

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

6‑шаговый рабочий процесс (цепочка паттернов)

1. Требования (уточнить + ограничения)
2. Варианты архитектуры (сравнить 2–3 подхода)
3. Границы (модули + ответственности)
4. Контракты (данные + API)
5. Тесты (test-first acceptance + ключевые unit тесты)
6. Ревью (сценарии отказов + чеклист)

На практике команды часто реализуют эту цепочку как повторяемый «рецепт фичи». Если вы строите с Koder.ai, та же структура хорошо ложится в chat-driven процесс: сохраняйте артефакты в одном месте, генерируйте первую рабочую срез и итерируйте со снимками, чтобы эксперименты были обратимы. Когда MVP готов — экспортируйте исходники или деплойте с кастомным доменом — полезно, когда хотите скорость AI‑помощи, но без привязки к единой среде.

Пак подсказок для копирования (с ограничениями)

SYSTEM (optional)
You are a software architecture assistant. Be practical and concise. 
Guardrail: When you make a recommendation, cite the specific lines from *my input* you relied on by quoting them verbatim under “Input citations”. Do not cite external sources or general industry claims.
If something is unknown, ask targeted questions.

1) REQUIREMENTS CLARIFIER
Context: <product/system overview>
Feature: <feature name>
My notes: <paste bullets, tickets, constraints>

Task:
- Produce: (a) clarified requirements, (b) non-goals, (c) constraints, (d) open questions.
- Include “Input citations” quoting the exact parts of my notes you used.

2) ARCHITECTURE OPTIONS
Using the clarified requirements above, propose 3 architecture options.
For each: tradeoffs, complexity, risks, and when to choose it.
End with a recommendation + “Input citations”.

3) MODULAR BOUNDARIES
Chosen option: <option name>
Define modules/components and their responsibilities.
- What each module owns (and does NOT own)
- Key interfaces between modules
- “Input citations”

4) DATA & API CONTRACTS
For each interface, define a contract:
- Request/response schema (or events)
- Validation rules
- Versioning strategy
- Error shapes
- “Input citations”

5) TEST-FIRST ACCEPTANCE
Write:
- Acceptance criteria (Given/When/Then)
- 5–10 critical tests (unit/integration)
- What to mock vs not mock
- “Input citations”

6) RELIABILITY + DESIGN REVIEW
Create:
- Failure modes list (timeouts, partial failure, bad data, retries)
- Observability plan (logs/metrics/traces)
- Review checklist tailored to this feature
- “Input citations”

Если нужен более глубокий материал, см. /blog/prompting-for-code-reviews. Если оцениваете инструменты или развёртывание в команде — /pricing будет практичным следующим шагом.