Год назад разработчик потратил три месяца на рефакторинг legacy-проекта на Go: один файл main.go на 2000 строк, вся бизнес-логика, конфиги, хэндлеры и работа с БД в одном месте. Инструментом был Cursor. Недавно он взялся за проект того же масштаба — и уложился за неделю, причём половину времени потратил на покрытие BDD-тестами через godog. По его оценке, без BDD хватило бы трёх дней.
Разница объясняется не моделью как таковой, а конфигурацией вокруг неё. Автор использовал Claude Code в режиме Opus с тремя субагентами-ревьюверами и собственным тулчейном level85, включающим 25 кастомных скилов. Ниже — как устроена эта система и почему она работает именно так.
| Таб | Цвет | Назначение |
|---|---|---|
| backend | синий | Агентная сессия для бэкенда |
| frontend | оранжевый | Агентная сессия для фронтенда |
| level85 | — | Тулчейн и скилы |
| shell | — | Чистый шелл под разовые команды |
Ключевой ресурс при работе с Claude Code — контекстное окно. У модели Sonnet оно составляет 200 тыс. токенов, у Opus — 1 млн (и стоит дороже). Команда /context показывает, на что уходит контекст: системные промты, инструменты, MCP-серверы, история сообщений. На старте, до первого слова пользователя, системка и инструменты уже занимают около 9%. Главный антипаттерн, который автор наблюдал у себя и коллег, — монолитный CLAUDE.md на 2000 строк со всеми правилами проекта. Такой файл грузится в каждый промт и съедает 30–40 тыс. токенов ещё до того, как модель увидела код. Автор убедил своего тимлида отказаться от аналогичного DOD.md (Definition of Done), показав разницу в расходе токенов: декомпозиция правил на отдельные скилы плюс эталонный проект тратит токены только тогда, когда скил реально нужен.
Главный антипаттерн: монолитный CLAUDE.md на 2000 строк съедает 30–40 тыс. токенов в каждом промте ещё до появления кода.
Скил в Claude Code — это папка внутри .claude/skills/ с файлом SKILL.md. Фронтматтер (поля name и description) читается агентом сразу как индекс; тело документа подгружается только когда агент решил, что скил релевантен задаче. Автор использует префикс x- для всех кастомных скилов (x-bdd-red, x-commit, x-doc-go), чтобы избежать конфликтов со встроенными слэш-командами Claude Code. Все 25 скилов написаны по-русски — сознательное решение для русскоязычной команды, где важны смысловые нюансы. Ещё одно правило, выработанное через ошибки: скил должен быть сформулирован в повелительном наклонении. Не «рекомендуется покрывать тестами», а «покрой тестами до 80%». Примеры кода при этом должны лежать прямо в теле SKILL.md — вынесенные в отдельные файлы references агент не загружает.
Субагенты-ревьюверы — dod-reviewer, test-reviewer, bdd-reviewer — работают иначе, чем кажется на первый взгляд. Каждый из них стартует с чистым контекстным окном и загружает фиксированный набор скилов. Сам по себе ревьювер не содержит правил — он знает только, какие скилы ему принадлежат. Если изменились требования к именованию тестов, достаточно отредактировать x-testing-conventions/SKILL.md, и ревьювер автоматически начнёт проверять по-новому. Правила живут в одном месте, дублирования нет. Для навигации по этой системе автор ведёт AGENTS.md с таблицей «тема → владелец скила»: 17 тем, у каждой единственный канонический владелец.
Для терминала автор выбрал Warp после того, как начинал с Ghostty. Оба поддерживают Shift+Enter для переноса строки в TUI Claude Code — важная деталь для мышечной памяти при переключении между окнами. Warp добавляет нативную интеграцию с Claude Code: статус агента отображается значком на табе (пурпурные часы во время работы, зелёная галочка при успехе, жёлтый stop при ожидании approve), а при завершении долгой задачи появляется уведомление. Это позволяет запустить агента, уйти в соседний таб с другим проектом и вернуться по сигналу. Дополнительно Warp даёт rich input для многострочных промтов, встроенный файловый обозреватель и цветные подписи на табах — автор держит синий таб «backend» и оранжевый «frontend» в одном окне.
