Год с Claude Code: как собрать рабочую конфигурацию для вайбкодинга — от CLAUDE.md до skills и routing

Первый год — он трудный самый

Честно? Первые полгода я конфигурил Claude Code методом тыка. Сгенерировал пустой CLAUDE.md с фразой «ты крутой AI, делай хорошо» — и надеялся на чудо. Чуда не случилось. AI путал стек, забывал архитектуру, плодил легаси. Знакомо?

На дворе май 2026, Claude Code оброс возможностями, о которых год назад мы даже не мечтали. Но фокус в том, что без правильной конфигурации даже самая мощная модель — просто дорогой генератор мусора. Давайте пройдемся по тому, что реально работает, а не по красивым блогам Anthropic.

Проблема: один агент против всех

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

Я видел проекты, где CLAUDE.md весит 10 строк: имя проекта, пара запретов. И это работает ровно до первого сложного таска. Потом агент тупит, разработчик бесится, виноват AI. А виноват разработчик, который не настроил окружение.

Решение: три кита вайбкодинга

За год я перепробовал десятки конфигураций. Рабочая — всегда строится на трех слоях:

• CLAUDE.md — база. Правила, запреты, предпочтения, архитектурные принципы.
• Skills — переиспользуемые модули для типовых задач (генерация тестов, рефакторинг, деплой).
• Routing — автоматическое распределение запросов между агентами и subagents.

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

1 CLAUDE.md: пиши как для стажера, который читает раз в жизни

Представьте, что ваш CLAUDE.md — это конституция проекта. В ней нет места лирике. Только факты. Вот skeleton, который я таскаю между проектами:

# Правила для Claude Code

## Стек
- Бэкенд: Go 1.24, chi router, sqlx, PostgreSQL 16
- Фронтенд: React 19, TailwindCSS 4, Vite 6
- Инфра: Docker Compose, Terraform 1.9, AWS ECS

## Архитектурные принципы
- Чистая архитектура: слои handler → usecase → repository
- Все внешние зависимости — через интерфейсы
- Ошибки — только кастомные типы, без пакетов вроде errors.New("text")

## Запреты
- НЕ используй GORM — только sqlx
- НЕ коммить в main без тестов
- НЕ удаляй миграции — только добавляй новые

## Конвенция имен
- Файлы: snake_case.go
- Функции: CamelCase
- Переменные: camelCase (кроме глобальных констант — ALL_CAPS)

Почему это работает? Потому что агент перестает гадать. Он знает, что ты ненавидишь ORM, и не предложит GORM. Знает, что миграции неприкосновенны — не тронет их.

2 Skills: повторяющиеся действия — в отдельный модуль

Если вы каждый раз просите «напиши тесты для всех файлов в папке domain», то вы программист-ремесленник. Автоматизируйте.

Skills — это изолированные промпты, которые можно вызывать по имени. В Claude Code они живут в папке .claude/skills/. Каждый skill — это markdown-файл с инструкцией.

Я держу в проекте 5-7 скиллов: test-gen, refactor-package, deploy-staging, db-migrate, rollback. Вызов выглядит как команда /skill run test-gen domain/. Согласитесь, быстрее, чем писать промпт каждый раз.

# skill: test-gen
## Назначение
Генерирует unit-тесты для указанной директории.

## Правила
- Используй testify + mockery (mockery уже настроен для всех интерфейсов)
- Тесты пиши в той же папке, что и исходный код, файл *_test.go
- Каждый тест должен проверять сценарий успеха и ошибку
- Не тестируй внешние HTTP-запросы — мокай их

## Параметры
{path: путь к директории для тестирования}

Кстати, на маркетплейсе Claude Code уже есть готовые скиллы: от работы с Kubernetes до анализа логов. Обзор 5 полезных скиллов. Не изобретайте велосипед, если можно взять проверенное.

3 Routing: когда один агент не справляется

Самый недооцененный слой. Routing позволяет пускать разные типы задач на разные экземпляры Claude Code (или subagents). Например:

• Вопросы по архитектуре — отправляются агенту с доступом к docs/ и CLAUDE.md
• Рефакторинг кода — агенту, который умеет читать только pkg/ и internal/
• Деплой — отдельному агенту с правами на CI/CD

Настройка routing лежит в файле .claude/routing.md. Это обычный markdown с секциями для каждого роута.

# Routing

## arch
- Описание: Вопросы про архитектуру и документацию
- Контекст: docs/, CLAUDE.md
- Агент: claude-arch (специализированный subagent)

## refactor
- Описание: Рефакторинг и оптимизация
- Контекст: internal/, pkg/
- Запрет: не трогать migrations/, deploy/

## deploy
- Описание: Деплой на стейджинг
- Контекст: deploy/
- Зависимости: подтверждение от человека перед запуском

Когда вы пишете claude q "refactor payment service", он автоматически выбирает роут refactor. Без роутинга агент будет рыться во всем проекте, терять контекст и время.

Собираем всё вместе: реальная конфигурация

Приведу пример рабочей структуры папок проекта, которую я залил на OpenClaw (это открытый репозиторий эталонных конфигов — рекомендую):

my-awesome-project/
├── .claude/
│   ├── CLAUDE.md          # общие правила
│   ├── routing.md          # роуты
│   └── skills/
│       ├── test-gen.md
│       ├── refactor.md
│       └── deploy.md
├── internal/
├── pkg/
├── docs/
└── deploy/

Этой конфигурации хватило на проект с 50k строк Go. Агенты не путались, код оставался консистентным, я только ревьюил.

Грабли, на которые я наступил (и вы наступите)

Подробнее про handoffs и совместную работу агентов.

Вайбкодинг без настроек — это боль

Многие думают, что вайбкодинг — это «просто говори, что нужно, и AI сделает». Нет. Настоящий вайбкодинг (когда ты получаешь рабочий код с минимальным ревью) — это 20% промптов и 80% конфигурации. Если вы не хотите тратить время на написание тестовых данных или развертывание — посмотрите кейс с Claude + n8n, где конфигурация сократила срок разработки с 2 месяцев до 2 дней.

Частые вопросы (FAQ)

Год с Claude Code — это год экспериментов. Если моя конфигурация спасет вас хотя бы от пары ночных дебагов — я уже доволен. Теперь ваша очередь: берите, адаптируйте, ломайте и улучшайте. Превратите AI-помощника в личного инженера.

Подписаться на канал