04 / 06 · Эксперт

⚡ Паттерны экспертов

Шесть проверенных паттернов от ведущих разработчиков сообщества CC. Реальные подходы с примерами применения — не теория, а то что работает в продакшне.

Spec Pipeline

Harper Reed

CTO Threadless, ex-Obama campaign CTO

Качество Планирование Любые задачи

Прежде чем просить CC написать код — напишите спецификацию задачи. Не подробную документацию, а короткий структурированный документ: что должно получиться, какой интерфейс, какие ограничения, как проверить. Только потом отдаёте его CC как контекст для реализации.

Как применять

Пишете spec самостоятельно — 10–20 минут размышлений о задаче. Что именно нужно? Какой интерфейс? Что точно не входит в scope?

Отдаёте spec в CC — «Реализуй согласно этой спецификации» или вставляете spec в начало промпта.

CC уточняет неясности — вместо того чтобы придумывать решения из головы, он спрашивает о спорных моментах из spec.

Код соответствует spec — после завершения проверяете не «выглядит ли код хорошо», а «выполняет ли код spec».

Пример спецификации

markdown specs/orders-show-endpoint.md

## Spec: GET /api/orders/{id}

Назначение: Получить полную информацию о заказе для страницы деталей

Ответ (200):
- Order с eager-loaded: user, items.product, statusHistory
- Трансформация через OrderDetailResource
- Формат: { data: OrderDetail, meta: { generated_at } }

Авторизация:
- Bearer token обязателен (401 если нет)
- Только владелец заказа (403 если чужой)
- Исключение: admin-роль видит все заказы

Ошибки:
- 404: заказ не найден в БД
- 403: заказ чужой (не раскрывать что он существует)
- 401: не авторизован

Ограничения:
- Не добавлять пагинацию (один заказ)
- Не включать payment_card_number в ответ
- Кэширование: нет (данные меняются)

Тесты (обязательно написать):
- [ ] Владелец видит свой заказ
- [ ] Чужой заказ → 403
- [ ] Несуществующий → 404
- [ ] Без токена → 401
- [ ] Поле payment_card_number отсутствует в ответе

💡

Spec pipeline работает потому что заставляет вас думать о задаче до того как CC начнёт её делать. 80% ошибок CC — это ошибки в постановке задачи, а не в коде.

Параллельные вкладки

Boris Cherny

Инженер Anthropic, автор TypeScript Deep Dive

Параллельность Скорость Полноstack

Держите несколько CC-сессий открытыми одновременно — каждая для своей области. Пока backend-сессия пишет API, frontend-сессия обновляет компонент. Между сессиями переключаетесь по мере готовности частей, а не ждёте завершения каждой по очереди.

Схема параллельных вкладок

Вкладка 1 — Backend

📦 laravel-api/

Миграция discount_amount
OrderService update
CartResource поле
Feature тест

Вкладка 2 — Frontend

🌐 nuxt-frontend/

CartSummary компонент
useCart composable
Типы обновить

Вкладка 3 — Тесты

🧪 E2E / Vitest

Cart flow E2E
CartSummary unit
Снимки обновить

Как применять

Разбейте задачу на независимые части — backend, frontend, тесты, документация. Убедитесь что они не конкурируют за одни файлы.

Открывайте отдельные терминалы — claude из laravel-api/, другой из nuxt-frontend/. Или используйте tmux/Windows Terminal с вкладками.

Переключайтесь когда нужна информация — backend закончил API? Скопируйте Resource структуру во frontend-сессию и продолжайте там.

Не запускайте конкурирующие изменения — если обе сессии пишут в один файл, получите конфликты. Планируйте границы заранее.

⚡

Параллельные вкладки дают прирост скорости 2–4x для полноstack-задач. Особенно эффективно когда у вас монорепо с чёткими границами пакетов.

Vertical Slices

Mitchell Hashimoto

Основатель HashiCorp, создатель Vagrant и Terraform

Архитектура Итерации Feature delivery

Разбивайте задачи вертикально: каждый слайс — это полная реализация одной фичи от базы данных до UI. Не горизонтально («сначала все миграции, потом все модели, потом все контроллеры»). Вертикальный слайс даёт рабочий результат в каждой итерации — его можно протестировать и показать.

Пример: фича «Добавить в корзину»

🗄️

База данных

database/migrations/create_cart_items_table.php

Готово

📦

Модель

app/Models/CartItem.php + Cart.php

Готово

⚙️

Сервис

app/Services/CartService.php → addItem()

Готово

🌐

API

app/Http/Controllers/CartController.php → store()

Готово

🧩

Компонент

nuxt-frontend/components/Product/AddToCart.vue

В работе

🧪

Тест

tests/Feature/CartTest.php → test_user_can_add_to_cart

Осталось

Промпт для вертикального слайса

markdown Пример промпта

Реализуй полный вертикальный слайс для фичи «Добавить товар в корзину».

Включает:
1. Миграция: таблица cart_items (user_id, product_id, quantity, price_snapshot)
2. Модели Cart и CartItem с Eloquent-связями
3. CartService::addItem(User $user, Product $product, int $qty)
4. POST /api/cart/items — контроллер + Form Request + Resource
5. Feature тест: пользователь добавляет товар, видит его в ответе

НЕ включает в этом слайсе: удаление, изменение количества, оформление.
Это следующие слайсы.

Критерий готовности: php artisan test --filter CartTest проходит.

🎯

Горизонтальные задачи («напиши все миграции для интернет-магазина») заставляют CC генерировать много кода который никто не проверил. Вертикальные слайсы — маленькие, проверяемые, рабочие единицы.

Specs as stdlib

Geoffrey Huntley

Staff Engineer, активный контрибьютор открытых AI-проектов

Документация Организация Масштаб

Создайте директорию specs/ в корне проекта и держите там спецификации каждой фичи в .md файлах. Это «стандартная библиотека» вашего проекта — CC ссылается на неё при работе. Новый разработчик (или новая CC-сессия) открывает specs/ и сразу понимает как устроена система.

Структура specs/ директории

specs/ ├── README.md ← навигация по спекам ├── api/ │ ├── auth.md ← авторизация, токены, refresh │ ├── orders.md ← CRUD заказов, статусы │ └── cart.md ← корзина, добавление, checkout ├── frontend/ │ ├── checkout-flow.md ← UX flow оформления заказа │ └── product-gallery.md ← компонент галереи ├── data/ │ ├── schemas.md ← схемы БД, типы, связи │ └── etl-pipeline.md ← ETL процессы └── decisions/ ├── 001-why-pinia.md ← архитектурные решения (ADR) └── 002-api-versioning.md ← почему v1/v2, не header

Как ссылаться в промптах

markdown Примеры промптов со ссылками на specs

# Промпт 1: реализация по spec
Реализуй эндпоинт оформления заказа.
Spec в specs/api/cart.md, раздел «Checkout».
Следуй структуре ответа из этого файла точно.

# Промпт 2: обновление spec
Мы добавляем поддержку промокодов в корзину.
Сначала обнови specs/api/cart.md чтобы описать новое поведение.
Потом реализуй изменения в коде.

# Промпт 3: ревью на соответствие spec
Проверь app/Http/Controllers/CartController.php на соответствие
спецификации в specs/api/cart.md. Найди расхождения.

# Промпт 4: новый разработчик
Что нужно знать перед работой с модулем заказов?
Смотри specs/api/orders.md и specs/decisions/.

📚

Specs as stdlib особенно ценны в долгосрочных проектах. Через полгода вы сами забудете зачем сделали то или иное решение — spec-файлы сохраняют это знание.

Rule of Five

Steve Yegge

ex-Google, ex-Amazon, автор популярных постов о разработке

CLAUDE.md Системные ошибки Правила

Если CC делает одну и ту же ошибку пять и более раз — это структурная проблема, не случайность. Не тратьте время на переформулировку промпта. Добавьте правило в CLAUDE.md. Одно правило один раз — и проблема исчезнет навсегда в этом проекте.

Как работает правило

🔄

CC делает ошибку

Создаёт контроллер с логикой вместо сервиса

→

🔢

Пять раз подряд

Вы исправляли, объясняли, переформулировали

→

✍️

Добавляете правило

В CLAUDE.md: «логику только в Services/»

→

✅

Проблема исчезла

CC следует правилу в каждой сессии

Правила которые стоит добавить в CLAUDE.md

markdown CLAUDE.md — примеры правил по Rule of Five

## Запрещённые паттерны (добавлены по Rule of Five)

# Ошибка: логика в контроллерах
- НЕ писать бизнес-логику в контроллерах.
  Только: валидация → сервис → ответ.
  Сервисы: app/Services/

# Ошибка: прямые SQL вместо Eloquent
- Никогда DB::statement() для CRUD.
  Исключение: сложные отчёты (только в Repository).

# Ошибка: хардкод config-значений
- Все конфиги через config() или env().
  Запрещено: new Client(['timeout' => 30])
  Правильно: config('services.http.timeout')

# Ошибка: console.log в продакшн коде
- Убирать все console.log перед коммитом.
  Логирование: только через useLogger composable.

# Ошибка: catch без обработки
- Никогда пустых catch-блоков.
  Всегда: либо log + rethrow, либо fallback-значение.

🔍

Ведите «список пяти»: когда CC делает одно и то же неверно — ставьте галочку. Дошли до пяти — немедленно добавляете правило в CLAUDE.md. Со временем ваш CLAUDE.md становится точной картой ваших стандартов.

💡

Тонкий момент: CLAUDE.md правила работают только внутри текущего проекта. Если вы работаете с несколькими проектами или монорепо — каждый пакет нуждается в своём CLAUDE.md с релевантными правилами. Глобальный ~/.claude/settings.json подходит только для настроек инструментов (permissions, hooks), а не для бизнес-правил конкретного проекта.

Verification First

Anthropic Engineering Team

Команда разработки Claude Code

Качество Критично Культура

Никогда не считайте задачу завершённой только потому что CC сказал «готово». «Claude написал код» — это начало, а не конец. Всегда верифицируйте результат: запускайте тесты, проверяйте граничные случаи, делайте code review. Внедрите это как культуру в команде.

Пирамида верификации

🧪 Автотесты проходят — минимум

👁️ Ручная проверка в браузере / Postman

🔍 Code review (другой человек или сессия)

✅ CI/CD зелёный — идеально

Протокол завершения задачи

markdown Чеклист верификации (добавьте в CLAUDE.md)

## Задача считается завершённой когда:

# Обязательно (минимум):
- [ ] Запущены тесты: php artisan test / npm run test
- [ ] Нет новых ошибок линтера: ./vendor/bin/pint / npm run lint
- [ ] TypeScript компилируется без ошибок: npm run build

# Желательно:
- [ ] Проверено вручную в браузере / через curl
- [ ] Граничные случаи протестированы (пустой ввод, 404, 403)
- [ ] Код прочитан глазами (не только CC)

# Для продакшн-деплоя:
- [ ] CI/CD pipeline зелёный
- [ ] Ревью от другого разработчика
- [ ] Staging-проверка

«Claude сказал что готово» — НЕ является критерием готовности.

Как передать культуру команде

Добавьте чеклист в CLAUDE.md — CC сам будет напоминать о верификации в конце каждой задачи если вы напишете правило.

В PR описании всегда указывайте как проверяли — «тесты прошли», «проверил в браузере шаги 1-3». Это нормализует верификацию как норму.

Никогда не мёрджите по доверию — «Claude сгенерировал, выглядит хорошо» не проходит. Только зелёный CI + ревью.

🚨

Главный риск работы с CC — verification gap: вы настолько доверяете генерации что перестаёте проверять. Это именно то место где баги проходят в прод. Verification First — это культурный противовес этому риску.

📊 Сводная таблица: когда применять какой паттерн

Паттерн	Применять когда	Не применять когда	Усилие
Spec Pipeline Harper Reed	Новая фича, неясные требования, важная задача	Мелкий баг, рефакторинг по понятному правилу	Высокое (разовое)
Параллельные вкладки Boris Cherny	Полноstack задача, независимые части, монорепо	Задачи с жёсткими зависимостями, один разработчик новичок	Среднее
Vertical Slices M. Hashimoto	Большая фича, нужен быстрый прогресс, agile-команда	Рефакторинг всего слоя, изменение схемы БД целиком	Среднее
Specs as stdlib G. Huntley	Долгосрочный проект, команда 3+ человек, сложная бизнес-логика	Прототип, одноразовый скрипт	Высокое (окупается долгосрочно)
Rule of Five Steve Yegge	CC повторяет одну ошибку снова и снова	Разовая ошибка, контекстная проблема	Низкое (5 мин на правило)
Verification First Anthropic	Всегда. Без исключений.	—	Низкое (привычка)

🔗

Смотрите также: Базовую настройку hooks для автоматизации верификации (Verification First) — в разделе Продвинутый: Хуки. MCP инструменты для ускорения паттернов: MCP. Работа в монорепо с Spec Pipeline и Vertical Slices: Монорепо.