📋 Сводная шпаргалка практик
Дистилляция опыта 18 практиков CC — от Anthropic и Kent Beck до Geoffrey Huntley и obra/Superpowers — в одну страницу. Без новых откровений: только то, что реально работает, собранное в чек-листы и таблицы для быстрой сверки перед задачей, во время работы агента и перед мержем.
⚠️
Частая ошибка: читать про практики по одной странице эксперта и не собирать их в единую рутину. Отдельные приёмы работают слабо — сила в комбинации: чёткий план + короткий контекст + TDD-страховка + человек на гейтах ревью. Эта страница — шпаргалка для сборки собственного процесса, а не замена профилей экспертов.
Тема → паттерн → кто за него → суть
📐 Планирование
| Паттерн | Кто | Суть |
|---|---|---|
| Plan Mode перед выполнением | Anthropic | Claude показывает план — какие файлы, какие изменения, в каком порядке — до того как что-то менять |
| Spec-driven разработка | Harper Reed, Mitchell Hashimoto | Сначала пишется явная спецификация, потом код по ней — агент не додумывает требования на ходу |
| Research → Plan → Execute → Review → Ship | IndyDevDan, Anthropic | Сквозной пайплайн 2026 года: человек — oversight на каждом гейте, не только в конце |
| Разделение research/planning и implementation | Anthropic | Смешивание фаз — частая причина, когда агент решает не ту задачу |
🧪 Тесты
| Паттерн | Кто | Суть |
|---|---|---|
| TDD как страховка от регрессий агента | Boris Cherny, Kent Beck | Юнит-тесты не дают агенту незаметно сломать рабочий код |
| «Augmented coding» — контроль над тестами | Kent Beck | Агенты пытаются удалять или ослаблять тесты, чтобы «пройти» их — нужен явный контроль, что тесты не тронуты |
| Скилл систематической разработки через тесты | obra / Superpowers | Формализованный процесс test-driven development как переиспользуемый навык агента, а не разовая договорённость |
🧠 Контекст
| Паттерн | Кто | Суть |
|---|---|---|
| Короткий CLAUDE.md (< 500 токенов) | Simon Willison | Раздутый файл памяти читается хуже, чем полное его отсутствие — только необходимое |
| Context engineering как дисциплина | Cole Medin, Hrishi Olickel | Что агент знает/видит/помнит в момент действия важнее того, как сформулирован промпт |
| Компакция и structured note-taking | Cole Medin | Агент ведёт scratchpad-файл вне контекста как persistent memory и перечитывает по необходимости |
🌳 Агенты и параллельность
| Паттерн | Кто | Суть |
|---|---|---|
| Множество параллельных агентов на одну задачу | Steve Yegge | Throughput растёт не от одного «умного» агента, а от нескольких работающих одновременно |
| «Ralph» — циклический автономный агент | Geoffrey Huntley | Агент гоняется в цикле до сходимости результата, минимум ручных вмешательств в процессе |
| Git worktrees для изоляции агентов | Peter Steinberger, Eric Buess | Каждый агент — своя рабочая директория и ветка, чтобы параллельные процессы не топтали общее состояние |
| Субагенты с изолированным контекстом | Anthropic | Возвращают 1000–2000 токенов summary в основной поток — не тащат весь свой контекст наружу |
🔍 Ревью и верификация
| Паттерн | Кто | Суть |
|---|---|---|
| Человек как обязательный гейт перед мержем | Simon Willison, Mitchell Hashimoto | Автономность агента не отменяет финальную проверку человеком — особенно на периметре и в критичных модулях |
| Верификация до заявления «готово» | Thorsten Ball | Прогнать реальную команду и увидеть результат — не полагаться на уверенный тон ответа модели |
⚡ Скорость
| Паттерн | Кто | Суть |
|---|---|---|
| Vibe coding для доступа новичкам | Andrej Karpathy | Высокоуровневое описание задачи без вычитки каждого шага — поднимает пол, а не потолок качества |
| Короткие итерации без лишней подготовки | Nick Dobos | Быстрые проверки гипотез важнее идеально продуманного плана на старте |
Мастер-чек-лист: перед тем как дать агенту задачу
- ☐ Задача сформулирована как явная спецификация, а не «сделай что-то похожее»
- ☐
CLAUDE.md/ память проекта короткие и актуальные — нет мусора, устаревших договорённостей - ☐ Понятно, нужен ли Plan Mode — задача трогает несколько файлов или архитектурные решения
- ☐ Определена модель под сложность задачи (см. таблицу выбора модели ниже)
- ☐ Если задача параллелится — заведён отдельный git worktree, а не общий checkout
- ☐ Есть тесты или явный критерий «когда это done», который агент не сможет обойти
- ☐ Периметр задачи очерчен: какие файлы трогать можно, какие — нет
- ☐ Для рискованных операций (миграции, security-периметр) — заранее решено, что не автоматизируется
- ☐ Понятно, кто и на каком шаге проверяет результат человеком
Чек-лист: во время работы агента
- ☐ Агент придерживается согласованного плана, а не «дрейфует» в сторону
- ☐ Тесты не удаляются и не ослабляются молча — Kent Beck прямо предупреждает про эту ловушку
- ☐ Контекст не разбухает — компакция срабатывает до исчерпания окна, не после
- ☐ Параллельные агенты не пишут в одни и те же файлы вне своих worktree
- ☐ Промежуточные шаги в длинных агентных цепочках проверяются, а не только финальный результат
- ☐ Если агент застрял в цикле 2-3 раза подряд на одном действии — остановка, не бесконечные повторы
- ☐ Изменения на периметре (SQL, права доступа, публичные эндпоинты) — под особым вниманием
Чек-лист: перед мержем/шипом
- ☐ Тесты реально прогнаны и пройдены — не «должны пройти по логике модели»
- ☐ Diff вычитан человеком целиком, а не только summary от агента
- ☐ Проверены SQL-инъекции, XSS, CSRF, права доступа — если менялся периметр
- ☐ Нет забытых debug-логов, закомментированного кода, TODO без тикета
- ☐ Commit message описывает «зачем», а не только «что» — стиль репозитория соблюдён
- ☐ Если использовался «ralph»-цикл или долгая автономная сессия — результат прогнан через отдельный ревью-проход
- ☐ Обновлена документация/память проекта, если решение неочевидное и понадобится в будущем
Делай / не делай
| ✅ Делай | ❌ Не делай |
|---|---|
Держи CLAUDE.md коротким и актуальным |
Не сваливай в память проекта всё подряд «на всякий случай» |
| Разделяй planning и implementation по фазам | Не проси агента одновременно придумать план и сразу его реализовать без паузы на проверку |
| Страхуйся тестами до того, как дал агенту свободу действий | Не доверяй агенту молчаливое удаление или ослабление тестов |
| Используй git worktrees для параллельных агентов | Не запускай несколько агентов в одном общем checkout |
| Выбирай модель под сложность конкретной задачи | Не гоняй рутину на самой дорогой модели «на всякий случай» |
| Оставайся ревьюером на каждом гейте — план, промежуточный шаг, финал | Не переходи в режим «запустил и забыл» на критичных участках |
| Верифицируй фактическим запуском команды/теста | Не полагайся на уверенный тон ответа модели как на доказательство |
| Останавливайся после 2-3 неудачных повторов одного действия | Не крути одно и то же действие в петле в надежде, что «в этот раз получится» |
Быстрый выбор модели
| Модель | Когда |
|---|---|
| Haiku 4.5 | Рутина: форматирование, простые правки, классификация, boilerplate |
| Sonnet 5 | Дефолт — 90% повседневных задач разработки: фичи, рефакторинг, тесты, обычное ревью |
| Opus 4.8 | Сложная логика, security review, архитектура среднего масштаба |
| Fable 5 | Самое требовательное: масштабная архитектура, длинные автономные агентные цепочки, тонкие рассуждения |
Подробное сравнение с ценами и SWE-bench Pro — на странице Fable 5.
💡
Лайфхак: заведи привычку из практики Kent Beck — спрашивай Claude каждый раз, когда в голове возникает вопрос по коду, а не откладывай «на потом». Дешевле спросить сразу, чем потом распутывать контекст заново.
💡
Лайфхак: для крупных фич используй связку «топ-модель планирует, Sonnet исполняет» — Opus 4.8 или Fable 5 коротко и точечно на решающих развилках, основной объём работы на дефолтной модели.
💡
Лайфхак: не жди заполнения контекста для компакции — триггерь её заранее: ~5-20K токенов для простых задач, 50-100K для сложных. Ждать до предела — почти гарантированно сломать длинную агентную сессию.
💡
Лайфхак: при масштабировании параллельных агентов держись 4-8 worktree на разработчика — выше этого числа узкое место не в Claude, а в твоей собственной способности ревьюить.
💡
Лайфхак: одно правило команды экономит больше нервов, чем десять индивидуальных привычек — зафиксируй в team
CLAUDE.md базовые вещи вроде «никогда не запускай агента в main checkout» и «тесты не трогать без явного разрешения».
Шесть примитивов оркестрации — быстрый ориентир
Anthropic описывает архитектуру CC через шесть примитивов. Держи каждый маленьким и сфокусированным — это сама по себе практика, а не техническая деталь.
| Примитив | Роль | Когда тянуться |
|---|---|---|
| Commands | Повторяемые ручные действия | Одна и та же последовательность шагов запускается регулярно |
| Agents (субагенты) | Изолированный контекст под конкретную роль | Нужно прочитать много файлов, не раздувая основной контекст |
| Skills | Модуль инструкций + метаданные, грузится по релевантности | Специфичный процесс нужен не всегда, а только в конкретных ситуациях |
| Hooks | Автоматическая реакция на события | Правило должно применяться всегда, без ручного напоминания |
| MCP servers | Доступ к внешним системам и данным | Нужна интеграция с БД, API, браузером — за пределами файловой системы |
| Memory | Персистентный контекст между сессиями | Решение или договорённость понадобится снова, а в код это не запишешь |
Типичные ловушки и что вместо них
❌ Ловушка
- Один гигантский CLAUDE.md «на все случаи жизни»
- Агент сам решает архитектуру на ходу, без предварительного плана
- Тесты трогаются агентом без отдельного согласия
- Все агенты работают в одном общем checkout
- Самая дорогая модель — дефолт «чтобы наверняка»
✅ Вместо этого
- Короткий CLAUDE.md + Skills, которые грузятся по ситуации
- Plan Mode перед выполнением, план утверждается человеком
- Тесты — неприкасаемая зона без явного разрешения на изменение
- Git worktree на каждого параллельного агента
- Модель подбирается под сложность конкретной задачи
Где искать противоречия
Эта шпаргалка сглаживает различия ради удобства сверки. На практике эксперты расходятся: TDD как обязательная страховка vs скорость без лишних тестов, полная автономия агента vs плотный контроль человеком. Разбор конкретных позиций — на странице Противоречия экспертов.
Смежные гайды по паттернам
Практики выше опираются на два сквозных технических паттерна — им посвящены отдельные подробные разборы в других разделах портала: