Skip to main content

Claude Code в production: чему я научился за 6 месяцев

Полгода Claude Code как основного инструмента — какие воркфлоу реально экономят время, какие тихо его съедают, и какую конфигурацию большинство команд так и не настраивают.

Claude Code в production: чему я научился за 6 месяцев

Я использую Claude Code как основной coding-агент полгода в двух production-кодовых базах — одна .NET, другая TypeScript. Достаточно, чтобы понять, что работает, что — маркетинг, и что большинство команд настраивают неправильно. Вот честный разбор.

Это не туториал. Это пост, который мне хотелось бы получить в первый день.

Главная ошибка

Большинство инженеров относятся к Claude Code как к более умному ChatGPT — открывают, просят «исправь баг в user.service.ts», вставляют ответ и оценивают инструмент по качеству этого одного ответа.

Это не про Claude Code. Это agent loop с tools, hooks и постоянной project memory. Использовать его как чат-окно — как купить Tesla и слушать в ней радио. Получаете 5% ценности.

Инженеры, которые получают максимум, сделали четыре конкретные вещи:

  1. Написали CLAUDE.md, описывающий, что проект на самом деле есть
  2. Добавили pre/post-tool hooks, автоматически запускающие линтер и тесты
  3. Настроили allowlist в settings.json, чтобы перестать получать prompt’ы на разрешения
  4. Добавили 1–2 MCP-сервера, привязанных к реальным системам (БД, трекер задач)

Без этого вы используете инструмент за $20/мес для работы на $2.

В чём он реально хорош

После полугода ворклоу, где он стабильно экономит реальное время, уже более узок, чем подсказывает маркетинг, но всё же существенен:

Многофайловые рефакторинги с понятной формой. «Переименуй getUserById в findUserById везде, обнови тесты и перенеси файл из services/ в repositories/.» Такие механические изменения с предсказуемыми границами — там, где агент блистает. За 30 секунд делает то, что у меня занимает 15 минут аккуратной работы.

Чтение чужого кода. Когда онбордюсь на кодовую базу или дебажу что-то в сервисе, который не трогал 8 месяцев, попросить Claude Code «объясни поток данных от этого контроллера до БД» быстрее и надёжнее, чем читать код сверху вниз. Главное — он рассказывает про реальный код, а не про доку, отстающую на три релиза.

Скаффолдинг тестов. «Напиши интеграционные тесты для этого endpoint: happy path, 404, 401 и duplicate-email.» Получаешь тесты на 80% корректные, дописываешь 20%. Итог: пишешь больше тестов, чем без него. Уже это окупает стоимость.

One-shot скрипты. Миграции, парсеры логов, утилиты для cleanup. То, что написал бы за 20 минут и использовал один раз. Агент пишет за 2, я читаю за 1.

В чём он тихо плох

Не менее важно — и редко обсуждается:

Что требует вкуса. Имена, дизайн API, решения о том, что абстрагировать. Агент даст что-то рабочее, но почти всегда на уровень хуже, чем сделал бы senior. Я перестал делегировать это.

Длинные задачи без чекпоинтов. «Сделай эту фичу end-to-end» без разбиения на куски рождает разрастание. Агент создаст файлы, которые вы не просили, абстракции, которые вам не нужны, и feature-флаги под гипотетические будущие случаи. Plan mode — антидот (об этом ниже).

Размытые критерии успеха. «Сделай быстрее» без бейзлайн-метрики или конкретного боттлнека — рецепт изменений, которые невозможно оценить. Сначала зафиксируйте метрику.

Production-дебаг без observability. Он умеет читать логи и стектрейсы, но не видит ваши Datadog-дашборды и distributed traces. Если для понимания бага нужно знать, что произошло в проде — агент это junior-инженер, который угадывает. Полезен только после того, как вы сузили область.

Конфигурации, которые двигают стрелку

Если бы мне нужно было онбордить тиммейта на Claude Code за 30 минут, вот что я бы реально настроил:

1. Реальный CLAUDE.md

Не три строчки. Реальный. Что делает проект, архитектурные решения, неочевидные подводные камни, конвенция тестирования, что НЕ трогать. Мой для .NET-проекта — 90 строк и спасает легко 50% времени «объяснения контекста» между сессиями.

2. Hooks на линтер и тесты

PostToolUse:Edit хук, запускающий линтер на изменённом файле. Stop хук, запускающий unit-тесты для модуля. Агент получает мгновенную обратную связь, сломал ли он что-то, а вы перестаёте его нянчить.

3. Реальный allowlist в settings.json

По умолчанию агент спрашивает разрешение на каждую shell-команду. Через два дня вы апруваете одни и те же 20 команд. Включите в allowlist read-only (git status, npm test, dotnet build, gh pr view) и inner-loop команды. Деструктивные (git push, git reset --hard, rm) держите за стеной.

4. Plan mode для всего нетривиального

Plan mode — это review-перед-исполнением. Агент показывает, что собирается делать, вы апруваете или редактируете, потом запускается. Используйте на любую задачу больше двух файлов. 30 секунд на чтение плана экономят 30 минут разворачивания плохих решений.

5. Один-два MCP-сервера

Главный апгрейд для меня — привязать MCP-сервер к нашей внутренней документации и трекеру задач. Агент теперь отвечает «какой design doc для фичи X» без копипасты ссылок. Их строить просто — глубоко покрыто в курсе Создание MCP-серверов и AI-инструментов.

Sub-agents — когда их реально использовать

Sub-agents (Explore, Plan, general-purpose и т.д.) мощные, но легко переборщить. Мои правила:

  • Explore — когда нужно что-то найти в незнакомой кодовой базе. У него отдельный context window, не засоряет основную сессию.
  • Plan — перед нетривиальной реализацией. Та же причина, плюс письменный артефакт для ревью.
  • General-purpose — для параллелизуемой независимой работы (например, «исследуй X, пока я делаю Y»).
  • Не используйте sub-agents на то, что закончите за 5 минут сами. Накладные расходы оркестрации реальны.

Экономика

Для соло-работы Claude Code за $20/мес окупается в первую же половину дня. Для команды математика тоньше:

  • Junior’ы получают самый большой абсолютный прирост (50%+), но и кода для ревью производят больше.
  • Senior’ы получают меньший процент (15–25%), но прирост в high-leverage работе — освобождаются от рутины, не от архитектуры.
  • Нагрузка на ревью растёт, не падает. Планируйте. Либо чаще ротируйте дежурство по ревью, либо вводите политику «PR от агента обязательно содержит обоснование».

Команды, которые выигрывают, меняют процесс, а не только инструменты. Команды, которые проигрывают, внедряют это как productivity hack и шипят больше плохого кода быстрее.

80/20 если читаете только это

Если унесёте одну вещь:

Потратьте полдня на конфигурацию, а потом — неделю на использование. Серьёзный CLAUDE.md, реальный allowlist, два хорошо подобранных хука и один MCP-сервер дадут 80% ценности. Большинство инженеров этого не делают и судят инструмент по неконфигурированному опыту. Это как судить о Linux по live-USB.

Если хотите структурированный путь по hooks, slash commands, sub-agents и MCP — это содержание курса Claude Code Mastery: agentic coding для инженеров. Пять недель, десять занятий, фокус на ускорении на реальных проектах, а не игрушечных демо.

Где я бы поспорил с хайпом

Claude Code не превращает junior’а в senior’а. Он делает junior’а быстрее в той работе, которую junior производит — что в основном нормально, но ограничивающий фактор карьеры junior’а — это суждение, не скорость набора. Инструмент не учит суждению. Менторство и code review — учат.

Он также не отменяет внимательного чтения кода. Инженеры, пропускающие read-and-understand, потому что «агент написал», копят долг, который пока не видят. Счета приходят через квартал-два, когда никто в команде уже не знает, как реально работает система.

Используйте. Но с теми же стандартами, что к контрактору: вы отвечаете за то, что зашипилось, даже если набирал кто-то другой.


Хотите концентрированный путь по фичам Claude Code? Начните с Claude Code Mastery: agentic coding для инженеров. Уже шипите с ним? Создание MCP-серверов и AI-инструментов — естественный следующий шаг: пишете свои MCP-серверы, чтобы экспонировать внутренние tools и данные команды Claude.

Поделиться
X LinkedIn
Следующий шаг

Закрепите эту тему на курсе

Структурированный путь от теории к production-коду — с проектами и код-ревью.

Oleksii Anzhiiak

Автор статьи

Oleksii Anzhiiak

Софтвер-архитектор, Senior .NET инженер и со-основатель

Алексей Анжияк — софтвер-архитектор, Senior .NET инженер и со-основатель ToyCRM.com и ProfectusLab. Имея более 15 лет опыта, он специализируется на распределённых системах, облачной инфраструктуре, высоконагруженной backend-разработке и платформах аутентификации. Занимается проектированием архитектуры, созданием безопасных систем авторизации и разработкой современных образовательных программ, которые помогают студентам получить реальные карьерные результаты.

LinkedIn →

Рекомендуем посмотреть

Подобранные сторонние видео по теме. Открываются на YouTube.

~1:56:00
Продвинутый Andrej Karpathy

Создаём GPT с нуля

Редкий практический разбор внутреннего устройства GPT — от теории к коду. Для инженеров, а не пользователей.

~11:00
Начинающий DeepLearning.AI

Объяснение Large Language Models

Чёткое и структурированное введение в LLM без перегрузки.

~32:00
Средний Sebastian Raschka

Как работают Transformer-модели

Инженерно точное объяснение архитектуры трансформеров.

Связаться с нами