Назад в блог

Как мы используем Claude Code в студии — без розовых очков

Год назад я написал статью про то, что не отдаю AI в работе. В ней был список запретов: архитектуру не проектирует, контракты между слоями не меняет, решения по схеме БД не принимает. Список работает. Но за год добавилось кое-что ещё — понимание того, где Claude Code реально полезен. Это не там, где вы думаете.

Полезнее всего Claude Code не там, где пишет код. Полезнее всего там, где показывает, что у тебя нет чёткого понимания задачи.

Что я отдал и не пожалел

Начну с хорошего.

Тесты. Claude Code пишет тесты лучше, чем я пишу их сам, — и быстрее. Не потому что умнее. Потому что не устаёт. Я заплатил за тест 20 минут своей энергии, AI заплатил 40 секунд. За год через него прошло несколько сотен unit-тестов по PHP-логике и TypeScript-утилитам. Промахов по логике было примерно 15% — я правил, не злился.

Boilerplate. Новый Bitrix D7 модуль с регистрацией в include.php, EventManager, базовый REST-handler — скучная работа на 40 минут. Claude Code делает её за 3 минуты. Я читаю, правлю два места, двигаюсь дальше. Это честный выигрыш.

Рефакторинг с понятным контрактом. Когда у меня есть класс с чётким входом и выходом и я хочу разбить его на два — Claude Code справляется. При условии, что я описал: что не должно сломаться, какие тесты есть, что такое «правильный» результат. Без этого описания результат непредсказуем.

Ещё: логи. Claude Code читает 200 строк Laravel/Bitrix-лога и за 30 секунд говорит: «Вот три паттерна ошибок, вот вероятный root cause». Это не диагноз — это первичный срез. Я трачу 5 минут вместо 30.

Что попробовал отдать и вернул

Теперь честно.

Я пытался дать Claude Code писать миграции схемы БД для Bitrix-проекта с 28 000 SKU. Структура выглядела разумно. Я принял PR. Через три дня обнаружил, что миграция добавила индекс на поле, которое используется в составном запросе с ORDER BY — и MySQL начал игнорировать составной индекс, который там был. TTFB на страницах каталога вырос с 480 мс до 1,1 с. Диагностика заняла два часа. Миграции больше не отдаю без явного EXPLAIN в задаче.

Ещё я пытался дать Claude Code дорабатывать PHP-функции, завязанные на Bitrix composite cache. AI генерировал код, который работал в dev-окружении без composite — и незаметно ломал кеширование в production. Composite cache — это нелокальная зависимость: поведение модуля зависит от конфигурации компонента на уровне сайта. Claude Code об этом не знает. Я об этом не написал в задаче. Чья ошибка? Моя.

Третий кейс: я попросил AI написать скрипт синхронизации остатков между 1C и Elasticsearch. Скрипт работал. Но он не учитывал, что у нас три склада с разной логикой доступности, и «в наличии» для одного склада означало «нет в наличии» для региональных заказов. Это не проблема AI — это проблема задачи без контекста предметной области.

Закономерность одна: если задача требует знания нелокального состояния системы, которое не описано явно — Claude Code сделает правдоподобно, но неправильно.

Граница: «пишет код» vs «принимает решения»

Я перестал думать об этом как о границе «что умеет AI». Думаю об этом как о границе «что я формализовал».

Если я могу написать задачу так, чтобы её понял хороший джун без звонка мне — Claude Code справится. Если не могу — то Claude Code либо сделает неправильно, либо (лучший вариант) задаст вопрос, который покажет: я сам не понимал, что хочу.

Второй вариант — самый ценный режим. Когда AI спрашивает «а что должно произойти с заказом, если склад удалён?» — это не баг в AI. Это я обнаружил пробел в спецификации до кода, а не после.

Как организован контекст

У нас в проектах три типа файлов для контекста Claude Code:

CLAUDE.md в корне — общие правила: что нельзя трогать, какие тесты нужно прогонять, какие зоны «горячего» кода с нелокальными зависимостями. Сейчас там 14 строк. Каждая появилась после конкретного инцидента.

TASK.md для каждой задачи больше 1 часа — это мини-спека: что делаем, что не делаем, какой тест покажет «готово». Без этого я не даю Claude Code работать автономно.

Hooks в .claude/settings.json — автоматические проверки после кода: линтер, типы, конкретные тесты. Если хук упал — Claude Code не двигается дальше. Это предотвратило несколько тихих регрессий.

За полгода этого подхода я не имел серьёзных инцидентов от AI-кода в продакшне. Не потому что Claude Code стал лучше. Потому что я стал лучше описывать задачи.

Три вещи, которых мне не хватает

Честно: инструмент хороший, но есть раздражающие ограничения.

Первое — Claude Code не держит долгосрочную память о проекте. Каждый новый сеанс начинается с нуля. CLAUDE.md помогает, но это ручная работа. Хочу, чтобы AI помнил: «в прошлый раз этот подход не сработал в production».

Второе — AI плохо работает с Bitrix-специфичными паттернами: compound events, ORM D7, composite cache. Они нигде не задокументированы достаточно хорошо для обучения модели. Значит, задачи с этим уровнем Bitrix-кишочков я всё равно описываю вручную, детально.

Третье — нет инструмента для измерения качества AI-помощи. Я примерно знаю, что около 60% задач с AI-кодом идут в прод без серьёзных правок. Но «примерно знаю» не метрика. Непонятно, где усиливать промпты, а где AI-помощь просто убыточна по времени.

Итог

Год назад я думал, что Claude Code — это инструмент для ускорения написания кода. Это правда. Но главное, что я понял: это инструмент для обнаружения нечётких задач.

Если задача хорошо написана — AI помогает. Если задача написана плохо — AI это покажет. Иногда через вопрос. Иногда через код, который делает не то.

Это не недостаток. Это функция.

Я не меньше думаю с Claude Code. Я думаю о другом. О том, что важно — о контракте задачи, о контексте системы, о том, что «готово» означает в реальных условиях production.

Это дороже, чем просто ускорение кода. И именно поэтому я продолжаю.


*Внутренние ссылки: non-vibecoder-ai-workflow-php-studio, ai-delegation-framework-what-not-to-give-ai, ai-written-bug-one-week-in-prod*