Глава 4: Архитектура v1 Phoenix Project

Пролог: от плана к дизайну#

В Главах 1–3 вы прошли путь от первого промпта до плана проекта:

• Глава 1: получили пользу быстро (первые артефакты + верификация без “дней ручной работы”)
• Глава 2: добавили контроль (ограничения, условия остановки)
• Глава 3: формализовали Phoenix Project (ТЗ v1, план v1)

Теперь Lance Bishop начинает диалог с агентом и думает: “ТЗ и план готовы. Но как это реализовать? Какие компоненты? Какие API? Какие компромиссы?”

VP Engineering спрашивает: “Покажи дизайн. Объясни, почему именно так.”

Разница:

• План: декомпозиция работ, задачи, оценки (что делать, в каком порядке)
• Архитектура: компоненты, интерфейсы, компромиссы (как система устроена)

Сцена из “The Phoenix Project” (2014)#

Глава 12-13 книги: John Pesche показывает “архитектуру” Phoenix Project

Bill Palmer приходит к John Pesche, главному архитектору Parts Unlimited, чтобы разобраться в архитектуре Phoenix Project. John открывает презентацию в PowerPoint: “Architecture Overview”.

Слайды с прямоугольниками и стрелками:

• Слайд 3: “Frontend” → “Backend” → “Database”
• Слайд 7: “Integration Layer” (9 прямоугольников без подписей)
• Слайд 12: “Data Flow” (стрелки во все стороны)

Bill: “Как фронтенд взаимодействует с бэкендом? Какой API?”

John: “Ну… REST API, наверное. Или SOAP. Спроси у разработчиков.”

Bill: “А почему мы выбрали Oracle, а не PostgreSQL или MySQL?”

John: (пауза) “Не помню. Это решение приняли 3 года назад. Тот архитектор уже уволился.”

Bill: “А контракты API? Форматы запрос/ответ?”

John: “Это в коде. Смотри реализацию.”

Bill пытается добавить новую фичу (интеграцию с внешним платёжным шлюзом):

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

Неделя 2: Обнаруживает, что “Integration Layer” — это не слой, а 9 разных сервисов без явных границ ответственности (одни делают аутентификацию, другие делают и аутентификацию, и логирование, и ещё что-то)

Неделя 3: Пытается понять, почему Oracle (читает git history, спрашивает старожилов). Никто не помнит обоснование.

Неделя 4: Реализует фичу, ломает пару других сервисов (потому что границы неясны)

Erik Reid: “Вот что бывает, когда архитектура — это слайды в PowerPoint. Нет явных границ ответственности. Нет контрактов API. Нет обоснования решений. Каждое изменение — это реверс-инжиниринг.”

Ключевые проблемы подхода 2014:

• “Прямоугольники и стрелки” без деталей: “Frontend → Backend” (какой API? REST? gRPC? SOAP?)
• Нет границ ответственности: компоненты делают всё: god objects
• Нет обоснования: “почему Oracle?” — никто не помнит
• Нет компромиссов: альтернативы не рассматривались (или не документированы)

Та же задача в 2026: архитектура v1 с ADR#

Контекст: Lance проектирует Phoenix Project (пользовательская платформа) для релиза Phoenix Project v1. Вместо слайдов в PowerPoint — структурированная архитектура с ADR.

Подход (2026):

Lance использует чат‑режим (например, ChatGPT/DeepSeek) для архитектуры v1:

Роль: ты — архитектор ПО.

Контекст:
- Проект: Phoenix Project (пользовательская платформа) — релиз Phoenix Project v1
- ТЗ: [прикрепи ТЗ v1]
- Стек (пример): Go, PostgreSQL, systemd, deb‑пакеты, Ansible

Задача:
Спроектируй архитектуру v1.

Правила качества:
- Не додумывай требования: если чего-то нет в ТЗ — оформи как вопрос или предположение с пометкой.
- Не “перепридумывай мир”: сначала предложи минимально достаточную архитектуру v1, затем явно отметь, что уйдёт в v2.
- Для каждого решения дай проверяемые последствия (что выигрываем/теряем и как это измерить/проверить).

Структура:
1. Обзор верхнего уровня (компоненты + поток данных)
2. Компоненты детально (назначение, API, границы ответственности)
3. Контракты API (эндпоинты, запрос/ответ, ошибки)
4. Компромиссы (альтернативы, плюсы/минусы, когда пересмотреть)
5. ADR (2-3 ключевых решения: контекст, решение, последствия)

УСЛОВИЯ ОСТАНОВКИ:
- Если ТЗ неясно — задай вопрос
- НЕ додумывай требования, которых нет в ТЗ

Время выполнения:

• Агент генерирует архитектуру: быстро
• Lance делает ревью и правки: быстро
• Итого: быстрый цикл с проверкой

Результат (фрагмент архитектуры v1):

## Компоненты

### Checkout (Phoenix Project)

**Назначение:** Оформление заказа: валидация корзины, создание заказа, запуск оплаты.

**Границы ответственности:**
- Делает: валидация входных данных и корзины
- Делает: идемпотентность: `idempotency key` и управление статусами checkout
- Делает: инициирует создание заказа и запуск платежа
- Не делает: не хранит платёжные данные (это граница PCI в Payments)
- Не делает: не “делает всё” за Orders/Inventory (границы доменов важны)

**API: внешний (пример)**
POST /checkout → 201 Created (order_id) / 4xx validation_error

## Компромиссы

### Монолит и микросервисы

**Выбрали:** монолит (все компоненты в одном процессе)

**Альтернатива:** микросервисы (каждый компонент — отдельный сервис)

**Почему монолит:**
- Плюсы: проще разработка, меньше задержка
- Минусы: сложнее масштабирование, меньше изоляция

**Когда пересмотреть:** если нагрузка и организационная структура требуют независимого масштабирования доменов

## ADR-1: PostgreSQL и MongoDB

**Контекст:** Нужно выбрать БД для заказов/статусов checkout и транзакционных операций Phoenix Project v1.

**Решение:** PostgreSQL для v1.

**Последствия:**
- Плюсы: транзакции ACID, консистентность статусов, понятные миграции и схемы
- Минусы: масштабирование требует дисциплины (индексы, шардирование/реплики — позже)
- Митигация: если нагрузка превышает возможности Postgres → пересмотреть архитектуру хранения в v2

Проверка: Lance делает ревью архитектуры:

• Границы ответственности заданы явно (каждый компонент знает, что делает и что НЕ делает)
• Компромиссы задокументированы (альтернативы + когда пересмотреть)
• ADR объясняет обоснование (“почему PostgreSQL” → понятно)

Показывает VP Engineering. VP: “Почему монолит? Мы же хотим масштабирование?”

Lance: “ADR-1 объясняет: модульный монолит для v1 (быстрее поставка), но если появятся независимые команды на домены и требования к изоляции/масштабированию — пересматриваем.”

Сравнение: 2014 и 2026

Что изменилось:

• Границы ответственности заданы явно: нет god objects, каждый компонент имеет чёткую зону ответственности
• ADR: спустя время понятно “почему PostgreSQL” (не нужен реверс-инжиниринг)
• Компромиссы: понятно “когда пересмотреть решение” (пропускная способность > 10K/час)
• Время на понимание: быстрее (вместо долгого реверс-инжиниринга у Bill)

Что НЕ изменилось:

• Ревью человеком: Lance проверяет архитектуру (агент может переусложнить дизайн)
• Доменная экспертиза: нужно знать компромиссы (монолит и микросервисы, PostgreSQL и MongoDB)
• Решения на человеке: агент предлагает альтернативы, но решение принимает человек

В этой главе вы научитесь:

• проектировать архитектуру v1 с помощью агента
• документировать архитектурные решения (ADR)
• валидировать дизайн через компромиссы и альтернативы

Быстрый старт: архитектура v1#

Цель#

Спроектировать архитектуру v1 для Phoenix Project (релиз Phoenix Project v1): компоненты, API, поток данных, компромиссы.

Сцена: Phoenix Project#

Контекст: ТЗ и план готовы. Команда ждёт дизайн.
Ставки: Если архитектура неправильная — переделка займёт недели.
Задача: Спроектировать решение, которое:

• Выполняет требования Phoenix Project v1 (каталог, checkout, заказы, платежи, интеграции)
• Соблюдает НФТ: безопасность/граница PCI, аудит событий, наблюдаемость, эксплуатация/откат
• Расширяемо: можно добавить новые фичи в v2

Вход#

• ТЗ v1 (функциональные/нефункциональные требования)
• План v1: декомпозиция работ, риски

Промпт для агента (готовый к копированию)#

Роль: ты — архитектор ПО, помогаешь спроектировать систему.

Контекст:
- Проект: Phoenix Project (пользовательская платформа) — релиз Phoenix Project v1
- ТЗ: [прикрепи ТЗ v1]
- Язык реализации: Go (бэкенд), PostgreSQL (БД)
- Деплой: systemd, deb‑пакеты, Ansible

Задача:
Спроектируй архитектуру v1 для проекта.

Правила качества:
- Не выдумывай недостающий контекст (нагрузка, SLO, ограничения). Если критично — спроси.
- Явно отделяй “решение v1” от “вариантов/альтернатив”.
- Все компромиссы и условия пересмотра формулируй как проверяемые триггеры (метрики/порог/событие).

Структура архитектуры:
1. **Обзор верхнего уровня**
   - Компоненты системы (5-7 компонентов)
   - Поток данных (как данные движутся между компонентами)
   - Диаграмма (Mermaid или ASCII art)

2. **Компоненты (детально)**
   - Для каждого компонента: назначение, зоны ответственности, API
   - Границы (что компонент делает, что НЕ делает)

3. **Контракты API**
   - Основные эндпоинты: REST/gRPC
   - Форматы запрос/ответ (JSON схемы)
   - Обработка ошибок (HTTP статус-коды, сообщения об ошибках)

4. **Компромиссы**
   - Альтернативные подходы (что можно было сделать иначе)
   - Почему выбрали этот подход (плюсы/минусы)
   - Когда пересмотреть решение (условия пересмотра)

5. **ADR — записи архитектурных решений**
   - 2-3 ключевых решения
   - Для каждого: контекст, решение, последствия

Формат ответа: Markdown с Mermaid диаграммами.

УСЛОВИЯ ОСТАНОВКИ:
- Если ТЗ неясно или противоречиво — задай уточняющий вопрос
- Если контекст недостаточен (стек, деплой) — перечисли что нужно
- НЕ додумывай требования, которых нет в ТЗ

Пример результата (Архитектура v1)#

Архитектура v1: Phoenix Project (релиз Phoenix Project v1)

1. Обзор верхнего уровня#

Компоненты#

                 [Web Frontend]
                       |
                       v
                  [API Gateway]
                 /     |      \
                v      v       v
           [Catalog] [Cart]  [Checkout]
              |        |        |   \
              v        v        v    v
         [Data Store] [Data Store] [Orders]  [Payments (граница PCI)]
                                     |   \            |
                                     v    v           v
                               [Data Store] [Inventory/ERP Integration]
                                     |
                                     v
                               [Audit Logger]

Дополнительно:
- Orders  -> Audit Logger
- Payments -> Audit Logger

Поток данных#

1. Browse → Catalog

   • Web → API → Catalog → Data Store

2. Cart

   • Web → API → Cart → Data Store

3. Checkout → Orders

   • Web → API → Checkout → Orders → Data Store
   • Идемпотентность через idempotency_key

4. Checkout → Payments (граница PCI)

   • Checkout инициирует оплату
   • Payments → Audit Logger (события оплаты, без PII)

5. Orders → Inventory/ERP

   • Orders вызывает интеграцию с ERP (резервирование/списание)

2. Компоненты (детально)#

API Gateway#

Назначение: Единая точка входа для всех запросов.

Зоны ответственности:

• Валидация запроса (проверка формата, обязательных полей)
• Аутентификация/авторизация: API key, JWT
• Ограничение частоты запросов: максимум 100 запросов/мин
• Маршрутизация запросов (к нужному компоненту)

API:

GET /catalog?query=<q>

POST /cart/items
Запрос:
{
  "product_id": "uuid",
  "qty": 1
}

POST /checkout
Запрос:
{
  "cart_id": "uuid",
  "payment_method": "card",
  "idempotency_key": "string"
}

Ответ:
{
  "order_id": "uuid",
  "status": "created" | "payment_pending" | "paid" | "failed"
}

Границы:

• Делает: валидация, auth, маршрутизация
• Не делает: не содержит доменную логику: Catalog/Cart/Checkout/Orders/Payments
• Не делает: не хранит платёжные данные (граница PCI)

Catalog#

Назначение: Каталог/поиск/карточка товара.

Обязанности:

• Поиск и выдача карточек товаров (минимум для UI)
• Ограничения/лимиты (чтобы не “вывалить всю БД”)

API (internal):

func SearchCatalog(query string, limit int) ([]Product, error)

Границы:

• Делает: каталог
• Не делает: корзина/checkout/платежи

Cart#

Назначение: Состояние корзины (добавить/удалить/количество).

API (internal):

func AddToCart(cartID string, productID string, qty int) error

Границы:

• Делает: корзина
• Не делает: создание заказа — Orders

Checkout#

Назначение: Оформление заказа: orchestration заказа/оплаты, идемпотентность.

Обязанности:

• Валидация корзины
• Создание заказа (через Orders)
• Инициирование оплаты (через Payments boundary)
• Идемпотентность idempotency_key

Границы:

• Делает: orchestration
• Не делает: хранение PCI‑данных — Payments boundary

Orders#

Назначение: Заказы: создание/статусы/история.

API (internal):

func CreateOrder(cartID string, idempotencyKey string) (string, error)

Payments (граница PCI)#

Назначение: Интеграция с платёжным провайдером + аудит событий оплаты.

Границы:

• Делает: граница PCI
• Не делает: бизнес‑логика заказа

Data Store#

Назначение: Хранение данных Phoenix Project v1.

Зоны ответственности:

• Заказы и статусы
• Состояние корзины (если не выносится в отдельное хранилище)
• Технические события для аудита (без секретов)

Schema (PostgreSQL, пример):

CREATE TABLE carts (
  id UUID PRIMARY KEY,
  created_at TIMESTAMP
);

CREATE TABLE cart_items (
  cart_id UUID,
  product_id UUID,
  qty INT,
  PRIMARY KEY (cart_id, product_id)
);

CREATE TABLE orders (
  id UUID PRIMARY KEY,
  status VARCHAR(32),
  created_at TIMESTAMP
);

CREATE TABLE payments (
  id UUID PRIMARY KEY,
  order_id UUID,
  status VARCHAR(32),
  created_at TIMESTAMP
);

Audit Logger#

Назначение: Аудит всех операций (security, compliance).

Зоны ответственности:

• Логирование всех операций (кто, что, когда)
• Структурированное логирование в формате JSON
• Нет чувствительных данных в логах: учётные данные и PII

Формат лога:

{
  "timestamp": "2026-01-17T10:30:00Z",
  "component": "log_parser",
  "operation": "parse_logs",
  "user": "api_key_abc123",
  "log_path": "/path/to/logs/*.log",
  "status": "success",
  "duration_ms": 1234
}

3. Компромиссы#

Компромисс 1: монолит и микросервисы#

Выбрали: монолит (все компоненты в одном процессе)

Альтернатива: микросервисы (каждый компонент — отдельный сервис)

Почему монолит:

• Плюсы:
  • Проще разработка (один репозиторий, один деплой)
  • Меньше задержка (нет сетевых вызовов между компонентами)
  • Проще отладка (один лог, один trace)
• Минусы:
  • Меньше изоляция (если один компонент падает → весь процесс падает)
  • Сложнее масштабировать (нужно масштабировать весь процесс, не отдельные компоненты)

Когда пересмотреть:

• Если нагрузка на checkout/заказы требует независимого масштабирования доменов → выделять доменные сервисы
• Если failure rate одного компонента > 5% → нужна isolation

Компромисс 2: синхронная и асинхронная обработка#

Выбрали: синхронная обработка (request → response сразу)

Альтернатива: асинхронная обработка (request → job ID, polling для результата)

Почему синхронно:

• Плюсы:
  • Проще API (один запрос → один ответ)
  • Задержка предсказуема (≤ 5 минут гарантировано)
• Минусы:
  • Долгие запросы (если логов много → timeout)
  • Нет параллельной обработки (один запрос обрабатывается за раз)

Когда пересмотреть:

• Если задержка > 5 минут для 100 деплоев → нужен асинхронный режим
• Если concurrent requests > 10 → нужна очередь: Kafka/RabbitMQ

Компромисс 3: PostgreSQL и NoSQL: MongoDB/Redis#

Выбрали: PostgreSQL (реляционная БД)

Альтернатива: NoSQL (MongoDB для документов, Redis для кэша)

Почему PostgreSQL:

• Плюсы:
  • ACID transactions (consistency)
  • SQL queries (easy analytics, тренды)
  • JSONB support (flexible schema для hypotheses)
• Минусы:
  • Меньше пропускная способность, чем у NoSQL
  • Сложнее горизонтальное масштабирование

Когда пересмотреть:

• Если нагрузка/паттерны доступа выходят за возможности Postgres → пересмотреть модель хранения в v2
• Если задержка запросов > → добавить cache

4. ADR — записи архитектурных решений#

ADR-1: Монолит для v1#

Контекст: Нужно выбрать архитектурный стиль: монолит или микросервисы.

Решение: Монолит для v1.

Последствия:

• Плюсы:
  • Быстрее разработка (как в плане)
  • Проще деплой (один Docker image)
  • Меньше задержка (нет сетевых накладных расходов)
• Минусы:
  • Сложнее масштабировать (нужно масштабировать весь процесс)
  • Меньше isolation (один компонент падает → все падают)
• Митигация:
  • Если масштабирование станет проблемой (пропускная способность > 10K/час) → переходим на микросервисы в v2
  • Используем структурированное логирование и мониторинг для раннего обнаружения падений

ADR-2: Режим только чтение для безопасности#

Контекст: Агент должен работать с production логами. Риск: агент может внести изменения в production.

Решение: Агент работает в режиме только чтение. Нет операций записи/удаления.

Последствия:

• Плюсы:
  • Безопасно: агент не может навредить production
  • Audit: все операции только чтение, легко проверять аудитом
• Минусы:
  • Ограничение функциональности: агент не может “исправить” проблемы автоматически
• Митигация:
• Если нужны операции записи → добавить явное подтверждение на контрольной точке (v2)
• Для “автоматических исправлений” → отдельный компонент с human-in-the-loop

ADR-3: Синхронная обработка для v1#

Контекст: Нужно выбрать модель обработки: синхронная (request → response сразу) или асинхронная (request → job ID, polling).

Решение: Синхронная обработка для v1.

Последствия:

• Плюсы:
  • Проще API (один запрос → один ответ)
  • Задержка предсказуема (≤ )
• Минусы:
  • Долгие запросы (если логов много → timeout)
  • Нет параллельной обработки (один запрос за раз)
• Митигация:
  • Таймаут: (если > → error, retry with smaller batch)
  • Если concurrent requests станут проблемой → переходим на асинхронный режим в v2

5. План проверки результата (для архитектуры)#

Как проверить, что архитектура правильная:

Проверка 1: покрытие ТЗ#

• Все ФТ из ТЗ покрыты компонентами
• Все НФТ (performance, security, reliability) учтены в дизайне

Проверка 2: Компромиссы задокументированы#

• Для каждого ключевого решения есть альтернативы
• Плюсы/минусы задокументированы
• Условия пересмотра решения заданы явно

Проверка 3: контракты API понятны#

• Все эндпоинты задокументированы: форматы запросов/ответов
• Error handling определён (HTTP status codes, error messages)
• Границы ответственности заданы явно (что делает, что НЕ делает)

Проверка 4: ревью готово#

• Другой инженер может понять дизайн по документу
• Диаграммы читаемы (компоненты, поток данных)
• ADR объясняют “почему”, не только “что”

Проверка результата (чеклист)#

• Обзор верхнего уровня с диаграммой (компоненты, поток данных)
• Компоненты детально описаны (назначение, зоны ответственности, API, границы)
• Контракты API задокументированы (endpoints, request/response, errors)
• Компромиссы для 2-3 ключевых решений (альтернативы, плюсы/минусы)
• ADR для 2-3 архитектурных решений (контекст, решение, последствия)

Ожидаемый результат#

Артефакт: Архитектура v1 в формате Markdown с Mermaid диаграммами

Время:

• Генерация архитектуры агентом: быстро
• Ревью и корректировки: быстро

Польза:

• Дизайн ревьюируем: команда может дать обратную связь до реализации
• Компромиссы заданы явно: понятно “почему именно так”
• Расширяемость: понятно, что можно добавить в v2

Project plan v1: Phoenix Project (релиз Phoenix Project v1)#

Назначение#

Архитектура отвечает на вопрос “как устроено”. План проекта отвечает на вопрос “как доставим”:

• что делаем — WBS
• что на критическом пути
• какие риски могут убить релиз
• какие контрольные точки качества не даём “перепрыгнуть”

Входы#

• ТЗ v1 Phoenix Project (scope + NFR/DoD)
• Архитектура v1 (компоненты, границы, ADR)
• Ограничения: команда, сроки, зависимости (платёжный провайдер, ERP)

WBS (пример)#

Критический путь#

Phoenix Project v1 чаще всего “умирает” на связке:

• Payments/PCI → аудит/логирование → раскатка/откат

Если это не готово, релиз либо нельзя делать, либо он будет стоить бизнесу слишком дорого при первом же сбое.

Риск‑регистр (пример)#

Контрольные точки качества (привязка к главам)#

• Контрольная точка A: Spec: ТЗ v1 с NFR/DoD (Глава 3) — без этого нельзя “идти в код”
• Контрольная точка B: Architecture: архитектура + 2–3 ADR (Глава 4) — иначе будет реверс‑инжиниринг
• Контрольная точка C: Delivery: SOP “design → PR” + план отката (Глава 5) — иначе ковбойские изменения
• Контрольная точка D: Security/Infra: базовый уровень безопасности + модель угроз (Глава 7) — иначе PCI/утечки

Теория: архитектура как контракт между компонентами#

Концепция 1: Границы ответственности (границы компонентов)#

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

Boundary — это контракт “что компонент делает, что НЕ делает”.

Почему границы ответственности важны:

В 2014 John Pesche, главный архитектор Parts Unlimited, показал Bill “архитектуру” Phoenix Project: слайды PowerPoint с “прямоугольниками и стрелками”. Bill спросил: “Как Frontend взаимодействует с Backend? Какой API?” John: “Спроси у разработчиков.”

Проблема: “Integration Layer” на слайде — это не слой, а 9 разных сервисов без явных границ ответственности. Одни делают аутентификацию, другие делают и аутентификацию, и логирование, и еще что-то. Результат: Bill пытался добавить новую фичу → неделя реверс-инжиниринга → сломал 2 других сервиса (потому что границы неясны).

В 2026 границы ответственности делают обязанности явными:

Component: Checkout
Обязанности: валидация корзины, orchestration заказа/оплаты, идемпотентность
Не обязанности: хранение PCI‑данных — `Payments boundary`, управление заказом — `Orders`, интеграции с ERP — `Inventory`

Если границы ответственности заданы явно → понятно, что делает компонент, что НЕ делает, с кем взаимодействует.

Для работы с агентами:

Агенты часто размывают границы ответственности. Они склонны “помогать” и делать больше, чем нужно — создавать god objects. Без явных границ ответственности агент сделает Checkout, который валидирует корзину, сам создаёт заказ, сам общается с платёжным провайдером, сам пишет аудит, и ещё “на всякий случай” лезет в ERP.

Это опасно: размытая граница → непредсказуемые побочные эффекты → инциденты и долгий дебаг.

История из практики:

На проекте ARIADNE мы попросили агента “спроектировать Checkout”. Агент выдал:

type Checkout struct {}

func (c *Checkout) Checkout(cartID string) (string, error) {
  // 1. Валидация корзины
  // 2. Создание заказа
  // 3. Оплата через провайдера
  // 4. Запись в аудит
  // 5. (почему бы и нет) интеграция с ERP
  return "", nil
}

Проблема: Checkout делает всё (валидация + заказ + платежи + аудит + ERP). Границы ответственности размыты.

Исправление: явно указали границы ответственности в промпте:

Checkout:
- Делает: валидация корзины и идемпотентность
- Делает: создание заказа через Orders
- Делает: инициирование оплаты через Payments (граница PCI)
- Не делает: не хранит платёжные данные
- Не делает: не выполняет ERP‑операции напрямую

Агент пересделал дизайн:

type Checkout struct {
  orders   OrdersService
  payments PaymentsService
}

func (c *Checkout) Checkout(cartID, idempotencyKey string) (string, error) {
  // 1) validate cart
  // 2) orderID := c.orders.CreateOrder(...)
  // 3) c.payments.Authorize(orderID, ...)
  // 4) return orderID
  return "", nil
}

Вывод: Без явных границ ответственности агенты создают “god objects” (компоненты, которые делают всё).

Концепция 2: Компромиссы как проверяемое обоснование#

Вы принимали архитектурные решения. Вы знаете, что каждое решение — это компромисс.

Компромисс — это выбор между альтернативами (плюсы и минусы).

Почему это важно для работы с агентами:

Агенты склонны давать один вариант без альтернатив.

История из практики:

На проекте ASIMOV мы попросили агента “выбрать БД для проекта”. Агент выдал:

Рекомендация: PostgreSQL
Причина: ACID transactions, SQL queries, JSONB support

Проблема: нет альтернатив, нет компромиссов. Мы не знаем, почему PostgreSQL лучше MongoDB.

Исправление: попросили агента: “сравни PostgreSQL и MongoDB, покажи компромиссы”. Агент выдал:

PostgreSQL и MongoDB:

PostgreSQL:
- Плюсы: ACID, SQL-запросы, JSONB
- Минусы: меньше пропускная способность, сложнее горизонтальное масштабирование

MongoDB:
- Плюсы: высокая пропускная способность, простое горизонтальное масштабирование
- Минусы: нет ACID; согласованность — eventual consistency; сложнее аналитика

Рекомендация: PostgreSQL для v1 (нужны ACID + analytics).
Когда пересмотреть: если пропускная способность > 5K/час → MongoDB.

Теперь понятно, почему PostgreSQL и когда пересмотреть решение.

Вывод: Компромиссы делают решения прозрачными и ревьюируемыми.

Концепция 3: ADR как историческая память#

Вы работали с legacy системами. Вы знаете проблему: “Почему это сделано так? Никто не помнит.”

ADR — записи архитектурных решений — это историческая память проекта.

Формат ADR:

• Контекст: какая была ситуация
• Решение: что решили
• Последствия: к чему это привело (плюсы/минусы)

Почему ADR важны:

Bill Palmer в 2014 спросил John Pesche: “Почему мы выбрали Oracle, а не PostgreSQL?” John (пауза): “Не помню. Это решение приняли 3 года назад. Тот архитектор уже уволился.” Результат: Bill потратил неделю на реверс-инжиниринг: читал историю git, спрашивал старожилов, пытался понять обоснование.

В 2026 ADR — это историческая память проекта:

ADR-1: PostgreSQL и MongoDB

Контекст: Нужна БД для данных о деплоях.
Решение: PostgreSQL для v1.
Последствия:
- Плюсы: ACID transactions, SQL analytics
- Минусы: меньше пропускная способность, чем у MongoDB
- Когда пересмотреть: если пропускная способность > 5K/час → рассмотреть MongoDB

Спустя время новый инженер читает ADR → понятно “почему PostgreSQL” без реверс-инжиниринга.

Для работы с агентами:

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

История из практики:

На проекте MORPHEUS мы спроектировали систему с агентом. Спустя время нужно было добавить новую фичу. Вопрос: “Почему мы выбрали монолит, а не микросервисы?”

Документация:

Архитектура: монолит

Не помогает. Нет контекста и обоснования.

Фикс: теперь мы требуем ADR для каждого ключевого решения:

ADR-1: Монолит для v1

Контекст:
Нужно выбрать архитектурный стиль. Команда: Senior инженер, сроки: несколько недель.

Решение:
Монолит для v1.

Последствия:
- Плюсы: быстрее разработка, проще деплой
- Минусы: сложнее масштабирование
- Митигация: если пропускная способность > 10K/час → переходим на микросервисы в v2

Теперь спустя время понятно, почему монолит и когда переходим на микросервисы.

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

Практика: SOP для архитектурного дизайна#

Назначение#

Воспроизводимый процесс проектирования архитектуры с агентом: от ТЗ до архитектуры v1 с компромиссами и ADR.

Входы#

• ТЗ v1 (функциональные/нефункциональные требования)
• План v1 (декомпозиция работ, риски)
• Технологический стек (язык, БД, деплой)

Процедура#

Шаг 1: High-level design (компоненты + data flow)#

Что делать:

• Попроси агента “разбить систему на 5-7 компонентов”
• Для каждого компонента: назначение (1-2 предложения)
• Нарисовать data flow (как данные движутся между компонентами)

Контрольная точка 1: компоненты покрывают ТЗ

Чеклист:

• Все ФТ из ТЗ покрыты компонентами
• Все НФТ учтены в дизайне (performance, security, reliability)
• Количество компонентов разумное (5-7, не 20)

Сценарий сбоя: На проекте VOSTOK агент создал 20 компонентов (каждый метод — отдельный компонент). Over-engineering. Пришлось упростить до 6 компонентов.

УСЛОВИЕ ОСТАНОВКИ: Если агент создаёт > 10 компонентов — остановись и упрости. Over-engineering.

Шаг 2: Детализация компонентов (обязанности, API, границы ответственности)#

Что делать:

• Для каждого компонента: обязанности (что делает)
• Для каждого компонента: обязанности (что делает)
• API (если компонент предоставляет API): endpoints, запрос/ответ
• Границы ответственности заданы явно: “что делает, что НЕ делает”

Контрольная точка 2: границы ответственности заданы явно

Чеклист:

• У каждого компонента границы ответственности заданы явно
• Нет пересечений (два компонента не делают одно и то же)
• Контракты API задокументированы (если применимо)

Сценарий сбоя: На проекте SEVER два компонента (Parser и Analyzer) оба вычисляли статистику. Пересечение → дублирование. Пришлось разделить обязанности.

Шаг 3: Компромиссы (альтернативы + плюсы/минусы)#

Что делать:

• Идентифицируй 2-3 ключевых архитектурных решения
• Для каждого: альтернативы, плюсы/минусы, когда пересмотреть

Контрольная точка 3: компромиссы задокументированы

Чеклист:

• Для каждого решения есть минимум 1 альтернатива
• Плюсы/минусы задокументированы
• Условия пересмотра решения заданы явно (“когда пропускная способность > X”)

Сценарий сбоя: На проекте ZAPAD мы выбрали PostgreSQL без компромиссов. Спустя время пропускная способность выросла → PostgreSQL не справился. Пришлось перейти на MongoDB. Потеря: недели.

УСЛОВИЕ ОСТАНОВКИ: Если агент не предлагает альтернативы — остановись и запроси: “покажи альтернативы и сравни”.

Шаг 4: ADR — записи архитектурных решений#

Что делать:

• Для 2-3 ключевых решений: создай ADR
• Формат: контекст, решение, последствия (плюсы/минусы/митигация)

Контрольная точка 4: ADR заполнены

Чеклист:

• ADR для 2-3 ключевых решений
• Контекст объясняет “почему нужно было решать”
• Последствия включают плюсы/минусы/митигацию

Сценарий сбоя: На проекте VIKI мы не создали ADR. Спустя время забыли, почему выбрали монолит. Пришлось восстанавливать обоснование из git history.

Шаг 5: Ревью (архитектура ревьюируема)#

Что делать:

• Дай архитектуру на ревью другому инженеру
• Вопросы: понятен ли дизайн? Согласен ли с компромиссами? Видит ли пробелы?

Контрольная точка 5: ревью пройдено

Чеклист:

• Ревьюер понял дизайн без дополнительных объяснений
• Ревьюер согласен с компромиссами или предложил лучшие альтернативы
• Пробелы идентифицированы и устранены

УСЛОВИЕ ОСТАНОВКИ: Если ревьюер не понял дизайн — остановись и улучши документацию (диаграммы, границы ответственности).

Выходы#

• Архитектура v1: компоненты, API, поток данных, диаграммы
• Компромиссы: альтернативы, плюсы/минусы, когда пересмотреть
• ADR: 2-3 архитектурных решения (контекст, решение, последствия)

Доказательства#

Как доказать, что SOP выполнен правильно:

• Архитектура покрывает все ФТ и НФТ из ТЗ
• Границы ответственности заданы явно: без пересечений
• Компромиссы задокументированы (альтернативы, плюсы/минусы)
• ADR созданы для ключевых решений
• Ревью пройдено (другой инженер понял дизайн)

Типовые ошибки#

Ошибка 1: Over-engineering (слишком много компонентов)#

Симптом: Архитектура содержит 15-20 компонентов для простой задачи.

Пример: Задача: “Парсить логи и вычислять статистику”.

Агент создал:

• LogReader (читает файлы)
• LogValidator (валидирует формат)
• LogParser (парсит)
• DataExtractor (извлекает поля)
• StatisticsCalculator (вычисляет stats)
• HypothesisGenerator (генерирует гипотезы)
• ResultFormatter (форматирует ответ)
• ErrorHandler (обрабатывает ошибки)
• Logger (логирует)
• … (ещё 10 компонентов)

Проблема: слишком гранулярно. Каждый метод — отдельный компонент.

Почему это происходит: Агенты склонны к “чистому дизайну” (один компонент = одна ответственность). Но это приводит к переусложнению.

Последствия:

• Сложность: много компонентов → сложно понять систему
• Overhead: много интерфейсов → больше кода, больше тестов

Как избежать: Укажи ограничение: “разбей систему на 5-7 компонентов (не больше)”.

Ошибка 2: Компромиссы без альтернатив#

Симптом: Документ содержит решение, но нет альтернатив.

Пример:

Решение: PostgreSQL
Причина: ACID transactions, SQL queries

Нет сравнения с MongoDB, Redis, etc. Непонятно, почему PostgreSQL лучше.

Почему это происходит: Агент даёт “правильный ответ” без контекста. Он не понимает, что trade-off — это выбор между альтернативами.

Последствия: Решение не ревьюируемо. Команда не может дать обратную связь, потому что нет альтернатив для сравнения.

Как избежать: Требуй явно: “покажи альтернативы (минимум 2) и сравни их (плюсы/минусы)”.

Ошибка 3: ADR без последствий#

Симптом: ADR содержит контекст и решение, но нет последствий.

Пример:

ADR-1: Монолит для v1

Контекст: Нужно выбрать архитектурный стиль.
Решение: Монолит.

Нет раздела “Последствия” (плюсы/минусы). Непонятно, к чему это приведёт.

Почему это происходит: Агент фокусируется на “что решили”, игнорирует “к чему это привело”.

Последствия: ADR не помогает в будущем. Спустя время непонятно, какие были компромиссы.

Как избежать: Требуй полный формат ADR: Контекст + Решение + Последствия (плюсы/минусы/митигация).

Эволюция ролей: как изменилась команда после Кейса 1#

Кейс 1 (Главы 1-4): Хаос деплоев → Анализ + Spec + Architecture

До/после: Lance (Senior → Senior+, путь к Staff)#

До Кейса 1 (начало Главы 1):

• Распределение времени: 60% исполнение (написание кода, отладка, ручные задачи) + 40% стратегия (дизайн, архитектурное мышление)
• Ключевые активности: написание кода, исправление багов, ручные деплои, “пожаротушение”
• Координация: встречи (weekly syncs, planning), цепочки писем, треды в Slack (неявные ожидания)
• Зона решений: тактика (код, выбор tech stack), стратегия через менеджера
• Выход: индивидуальный исполнитель (код для своей команды)

После Кейса 1 (конец Главы 4, архитектура v1 готова):

• Распределение времени: 50% исполнение (ревью кода агента, проверка результата) + 50% стратегия (промпт-инжиниринг, архитектура, дизайн проверки результата) — сдвиг: +10% в стратегию
• Ключевые активности: написание промптов, создание планов проверки результата, проектирование архитектуры агента, SOP для диалога
• Координация: промпты (явные контракты), контрольные точки (автоматическая проверка), условия остановки (критерии эскалации)
• Зона решений: тактика + стратегия (решения по архитектуре агента, митигация рисков)
• Выход: воспроизводимые процессы (промпты, планы проверки результата, документация архитектуры) — эффект на уровне команды

Навыки (Кейс 1):

• Промпт-инжиниринг: формулировать задачи для агентов (роль, контекст, задача, формат, условия остановки)
• Дизайн проверки результата: создавать проверяемые DoD (выборочная проверка, граничные случаи, проверка здравого смысла)
• Создание ограничений: что агент НЕ должен делать (ограничения безопасности)
• Архитектура для агентов: как проектировать системы где агент = компонент (границы ответственности, компромиссы, ADR)
• Основы оркестрации: как координировать агента (контрольные точки вместо встреч)

Маркер Senior+:

• Сократили время на исполнение на 17% (60% → 50%, агенты берут на себя анализ и парсинг)
• Создали воспроизводимые процессы (3 промпта, 2 плана проверки результата, 1 документ архитектуры)
• Улучшили точность данных 70% → 95% (план проверки результата работает)
• Увеличили стратегическую ёмкость (+10%, с 40% → 50%)
• Улучшили Bus factor (всё ещё 1–2, но процессы задокументированы — прогресс к Staff)

Дистанция до Staff Engineer:

• Текущий прогресс: заметно ближе к Staff (промпт-инжиниринг освоен, проверка результата работает, архитектура v1 готова)
• Ещё нужно: создание SOP (Глава 5), фиксация знаний от экспертов (Глава 5), организационный эффект (шаблоны используются вне своей команды)
• Timeline: ещё 3-4 месяца через Главы 5-7

До/после: Richard Hendricks/Expert (bottleneck → путь к Principal, начало делегирования)#

До Кейса 1:

• Нагрузка: 65+ часов/неделю (постоянное “пожаротушение”, дежурства каждую ночь)
• Рутина: 80% (ручные деплои, первичный разбор инцидентов, анализ данных, изменения конфигурации)
• Стратегическая работа: 20% (архитектурное мышление когда есть время, наставничество если срочно)
• Bus factor: 1 (знания в голове Richard, команда блокируется 15-20 раз/неделю)
• Зависимость команды: критический путь (любой деплой/инцидент требует участия Richard Hendricks)

После Кейса 1 (архитектура v1, агенты для анализа):

• Нагрузка: высокая (делегирование началось)
• Рутина: 70% (часть анализа берут на себя агенты, но деплои/инциденты всё ещё делаются вручную) — -10% через агентов
• Стратегическая работа: 30% (архитектура v1 создана, больше времени на дизайн) — +10%
• Bus factor: всё ещё 1 (но процессы начали документировать, агенты фиксируют часть знаний)
• Зависимость команды: немного снизилась (15 блокировок/неделю → 12 блокировок/неделю, -20% через делегирование анализа)

Навыки (Кейс 1):

• Делегирование агентам: как давать задачи агенту (промпт вместо устных указаний)
• Мышление проверки результата: подход “Доверяй, но проверяй” (не слепая вера, а проверка по фактам)
• Начало оркестрации: контрольные точки вместо ручной координации (первый шаг к автоматизации)

Прогресс к Principal:

• Текущий прогресс: первые признаки движения к Principal (делегирование началось, но ещё не системно)
• Ещё нужно: методика фиксации знаний (Глава 5), создание SOP (Глава 5), организационные шаблоны (Главы 7-9)
• Хронология: ещё 6-8 месяцев через Главы 5-10

До/после: Команда (результат и масштабируемость, первые улучшения)#

До Кейса 1:

• Скорость: порядка 100 story points/спринт (оценка; базовый уровень)
• Накладные расходы на координацию: 30% времени (встречи, синхронизации, цепочки писем, ожидание Richard Hendricks)
• Обмен знаниями: неформализованный (в голове Richard Hendricks + 1-2 старших инженеров)
• Масштабируемость: линейная (больше работы → нужно больше людей, не масштабируется)
• Частота деплоев: 2 раза/неделю (ручной процесс, медленно, много ошибок: 60% доля неудачных деплоев)

После Кейса 1:

• Скорость: порядка 120 story points/спринт (оценка; +20% без роста численности команды, часть анализа берут агенты)
• Накладные расходы на координацию: 25% (-5% через промпты вместо встреч для некоторых задач)
• Обмен знаниями: начали формализацию (3 промпта задокументированы, планы проверки результата написаны, архитектура v1 существует)
• Масштабируемость: всё ещё в основном линейная, но фундамент заложен (промпты = воспроизводимые процессы)
• Частота деплоев: 3 раза/неделю (+50% частота, агенты раньше ловят проблемы через анализ)

Метрики трансформации команды (Кейс 1):

• Успешность деплоев: 40% → 55% (+15pp, агенты раньше обнаруживают проблемы)
• Время анализа: дни → быстро (автоматизация агентом)
• Точность данных: 70-80% → 95%+ (+20pp, планы проверки результата)
• Bus factor: 1 → 1.5 (пока низко, но процессы задокументированы — прогресс начался)

Индикаторы карьерного роста (Кейс 1 завершён)#

Lance (Senior → Senior+):

• Старт (Глава 1): Senior Engineer (фокус на тактическом исполнении, 60% написание кода)
• После Кейса 1 (Глава 4): Senior+ Engineer (промпт-инжиниринг освоен, дизайн проверки результата работает, архитектура v1 готова)
• Следующий маркер: Staff- (через Главы 5-7: создание SOP, фиксация знаний, организационный эффект)

Траектория к Staff:

Senior → Senior+ → Staff-  → Staff
 (Гл1)    (Гл4)     (Гл7)    (Гл10)
  |         |          |         |
  v         v          v         v
60% исполнение  50% исполнение  30% исполнение  20% исполнение
40% стратегия   50% стратегия   70% стратегия   80% стратегия

Richard Hendricks (экспертное узкое место → Expert+):

• Старт: экспертное узкое место (Bus factor = 1, 80% рутина, 20% стратегия)
• После Кейса 1: Expert+ (делегирование началось, -10% рутины через агентов, архитектурное мышление усилилось)
• Следующий маркер: Principal- (через Главы 5-7: создание SOP, системная фиксация знаний, шаблоны для команды)

Траектория к Principal:

Bottleneck → Expert+ → Principal- → Principal
   (Гл1)      (Гл4)       (Гл7)       (Гл10)
     |          |            |            |
     v          v            v            v
Bus=1     Bus=1.5      Bus=3-4       Bus=5+
80% рутина  70% рутина     40% рутина      20% рутина
20% стратегия 30% стратегия 60% стратегия   80% стратегия

Сравнение с Phoenix Project: скорость эволюции ролей (Кейс 1)#

Команда Bill Palmer (2014, после первых месяцев):

• Эволюция Senior Engineer: всё ещё фокус на исполнении (первые скрипты автоматизации появились, но роли почти не изменились)
• Узкое место Brent: всё ещё 100% узкое место (попытки документации провалились, Bus factor = 1)
• Скорость команды: +10% (первые скрипты автоматизации работают)
• Хронология до маркеров Staff: ~2-3 года (через традиционное наставничество, проекты, доменную экспертизу)

Команда Инженера (2026 с агентами, после Кейса 1 — через несколько месяцев):

• Эволюция Senior Engineer: Senior → Senior+ (+10% стратегической ёмкости, промпт-инжиниринг освоен)
• Узкое место Richard Hendricks: немного снижено (Bus factor 1 → 1.5, делегирование началось)
• Скорость команды: +20% (агенты берут анализ, проверка результата работает)
• Хронология до маркеров Staff: месяцы через оркестрацию + создание SOP (Главы 5-10)

Мультипликатор агентов для карьерного роста (Кейс 1):

• Карьерный рост: траектория быстрее (месяцы вместо лет до Staff)
• Освоение навыков: быстро (промпт-инжиниринг за месяцы в сравнении с инженерной экспертизой в коде за годы)
• Масштаб эффекта: на уровне команды с самого начала (промпты воспроизводимы, не только личный навык)

Что сделало возможной эту трансформацию (Кейс 1)#

Технические факторы:

• Промпты зафиксировали процесс: процесс анализа (дни ручной работы → быстро с агентом) теперь задокументирован
• Планы проверки результата построили доверие: команда видела доказательства (выборочная проверка, граничные случаи) — не слепая вера
• Контрольные точки автоматизируют проверки: критерии ревью архитектуры заданы явно (не субъективное “выглядит нормально”)
• Архитектура v1 готова: фундамент для системной разработки агента (не разрозненные скрипты)

Культурные факторы:

• “Доверяй, но проверяй” стало нормой: не паранойя (запретить агентов), не слепая вера (принимать всё), а проверка по фактам (выборочная проверка подтверждает корректность)
• Явное важнее неявного: промпты = явные контракты (роль, задача, ограничения), встречи = неявные предположения
• Оркестрация начинается: контрольные точки вместо синхро‑встреч (агент сообщает статус, человек подтверждает на контрольной точке)

Организационные факторы:

• Роли начали меняться: Lance Bishop от “я пишу код” к “я оркестрирую агентов” (первые шаги)
• Измерение навыков началось: качество промптов, покрытие проверки результата измеримо (не субъективные оценки)
• Воспроизводимость ценится: промпт = процесс, который может воспроизвести любой (не неформализованные знания)

Трудности, с которыми столкнулись (Кейс 1)#

Задача 1: Сопротивление “Агенты заменят меня?”

• Проявление: команда скептична: “это просто игрушка”, “я быстрее сделаю вручную”
• Решение: Показали быстрый ощутимый эффект (Глава 1), команда убедилась через доказательства
• Результат: сопротивление → интерес → внедрение (команда спрашивает: “что ещё могут агенты?”)

Задача 2: Сначала пропустили проверку результата

• Проявление: ранний промпт без проверки результата → презентация CEO с 15% ошибок (неловко)
• Решение: план проверки результата обязателен (Глава 1), контрольные точки обеспечивают проверки (Глава 2)
• Результат: доверие восстановлено, уверенность команды выросла

Задача 3: Промпты без условий остановки

• Проявление: агент галлюцинировал данные (выдумывал отсутствующие логи)
• Решение: условия остановки заданы явно (Глава 2), агент обучен эскалировать при неопределённости
• Результат: ноль галлюцинаций после добавления условий остановки

Следующая волна (Кейс 2 начинается)#

Готовность к Кейсу 2 (Узкое место Brent/Richard Hendricks):

• Фундамент заложен: промпты работают, проверке результата доверяют, архитектура v1 существует
• Команда обучена: 3 инженера могут писать промпты и планы проверки результата
• Процессы начались: 3 промпта задокументированы, воспроизводимы
• ⏳ Следующая задача: системная фиксация знаний (неявные знания Richard Hendricks → SOP)

Ожидаемо после Кейса 2 (Главы 5-7):

• Lance: Senior+ → Staff- (создание SOP, фиксация знаний, организационные шаблоны)
• Richard: Expert+ → Principal- (Bus factor 1.5 → 4, системное делегирование через SOP)
• Скорость команды: ~120 → ~150 story points/спринт (оценка; +50% суммарно)
• Bus factor: 1.5 → 4 (SOP + агенты, любой инженер может делать изменения)

Хронология: несколько месяцев (Главы 5-7)

Кумулятивные метрики (конец Кейса 1)#

Операционные:

• Время анализа: заметно меньше (дни → быстро)
• Точность данных: +20pp (70-80% → 95%+)
• Успешность деплоев: +15pp (40% → 55%)
• Скорость команды: +20% (100 → ~120 story points/спринт; оценка)

Организационные:

• Bus factor: 1 → 1.5 (процессы задокументированы, агенты фиксируют часть знаний)
• Накладные расходы на координацию: -5% (30% → 25%, промпты вместо части встреч)
• Стратегическая ёмкость: Lance +10% (40% → 50%), Richard +10% (20% → 30%)

Карьерный рост:

• Lance: Senior → Senior+ (признаки движения к Staff)
• Richard: узкое место → Expert+ (признаки движения к Principal)
• Команда: фундамент для экспоненциального роста (промпты = воспроизводимые процессы)

Финансовые:

• Кумулятивный эффект: автоматизация анализа + воспроизводимость (Глава 1)
• Инвестиции: время на промпты, проверку результата и архитектуру (Главы 1-4)
• Окупаемость: считать по вашему контексту (см. шаблон в Приложении A)

Резюме#

Что мы сделали#

• Спроектировали архитектуру v1 с агентом (компоненты, API, data flow)
• Задокументировали компромиссы (альтернативы, плюсы/минусы, когда пересмотреть)
• Создали ADR для ключевых решений (контекст, решение, последствия)

Артефакты#

• Архитектура v1: 5-7 компонентов с явно заданными границами ответственности, контракты API, диаграммы
• Компромиссы: 2-3 ключевых решения с альтернативами и плюсами/минусами
• ADR: 2-3 записи архитектурных решений

Ключевые принципы#

1. Границы ответственности как контракт: у каждого компонента границы ответственности заданы явно (что делает, что НЕ делает)
2. Компромиссы как проверяемое обоснование: каждое решение — это выбор между альтернативами (плюсы и минусы)
3. ADR как историческая память: документируй “почему”, не только “что”

Критерии приёмки главы#

Вы успешно освоили материал, если можете:

• Описать архитектуру v1 как набор компонентов с границами ответственности и контрактами
• Зафиксировать 2–3 ключевых компромисса (альтернативы + когда пересмотреть)
• Оформить ADR по ключевому решению (контекст → решение → последствия)

Следующие шаги#

В Главе 5 (Кейс 2: Узкое место Brent) вы научитесь:

• создавать SOP “дизайн → PR” (как делать изменения с агентом)
• использовать контрольные точки для контроля качества на каждом этапе
• делать ревью кода, созданного агентом

Hook: У вас есть дизайн. Но как реализовать его с агентом? Как контролировать качество на каждом этапе (дизайн → реализация → тестирование → PR)? Об этом — в следующей главе.

От плана к архитектуре. Кейс 1 завершён. 40% книги пройдено.