Я даю Claude писать тесты. Я не даю ему выбирать архитектуру
Claude написал мне 340 строк тестов за восемь минут. Хорошие тесты. Я бы писал их два часа. Но когда я попросил его предложить структуру модулей для нового проекта на Bitrix, он выдал что-то симметричное, логичное и совершенно неработающее в нашем контексте. Разрыв между этими двумя результатами стал для меня рабочим определением: где заканчивается задача для Claude и начинается задача для меня.
Это не статья про то, стоит ли использовать AI. Этот вопрос давно решён. Это про то, где я провёл границу — и почему.
Где AI реально экономит время
Есть класс задач, которые я делегирую Claude без раздумий.
Тесты. Если функция принимает конкретные входные данные и возвращает конкретный результат, Claude покрывает её unit-тестами быстрее, чем я успеваю открыть нужный файл. Не потому что он «умнее», а потому что у него нет ментального переключения контекста. Я даю ему сигнатуру функции, описание поведения, пару edge-кейсов вслух — он возвращает набор PHPUnit-тестов, которые мне остаётся только просмотреть.
Boilerplate. REST-эндпоинт по заданной схеме, migration-файл для новой таблицы, конфигурация webpack с конкретными опциями. Всё, где задача формулируется однозначно и результат проверяется механически.
Рефакторинг по правилу. «Переименуй все переменные $res в $result в этом файле». «Вынеси эту логику в отдельный метод». «Замени deprecated API D7 на текущий». Здесь у Claude есть чёткое правило и ограниченная область применения. Он не решает, нужен ли рефакторинг вообще. Он выполняет конкретное преобразование.
Всё это задачи, где правило уже есть, а делать руками скучно.
Где AI генерирует уверенный мусор
Я видел несколько паттернов, которые повторяются независимо от формулировки запроса.
Предложения по структуре модулей. Claude строит красивые симметричные деревья. Проблема в том, что «красивая симметрия» не учитывает, как реально распределена нагрузка на проекте, где исторически накопилась связность, какие компоненты вообще трогать нежелательно. Он не видел вашего проекта за последние три года.
Решения про кеширование. «Добавьте Redis-кеш на этот запрос» — стандартный совет. Но если в том же запросе уже есть слой кеша в Bitrix, и вы добавите ещё один, вы получите двойную инвалидацию и баги, которые воспроизводятся раз в неделю. Claude не знает про первый слой — он не видел вашего кода весь.
Советы по выбору между двумя решениями. «Использовать ORM или raw SQL?» Ответ Claude будет технически грамотным. Но он не учитывает, что у вас уже есть 40 000 строк на raw SQL, что команда с ORM не работала, что дедлайн через неделю. Его ответ существует в вакууме.
Мусор появляется там, где правильный ответ зависит от контекста, которого у Claude нет.
Почему архитектуру нельзя делегировать модели
Архитектурное решение несёт в себе историю. Почему здесь монолит, а не сервисы. Почему этот компонент написан так, а не иначе. Что было до, что сломалось, что пришлось поменять и почему именно так.
Claude не читал ваши старые pull request'ы. Не знает, что вы пробовали микросервисный подход три года назад и откатились из-за конкретных проблем с командой. Не знает бизнес-ограничения вроде «это трогать нельзя, пока не обновим контракт». И компромиссы, которые уже сделаны, — тоже нет.
Когда Claude предлагает архитектуру, он предлагает решение для абстрактного проекта. Ваш проект — не абстрактный.
Кроме того, у архитектурных решений есть инерция. Если вы выбрали неправильную структуру на старте, вы живёте с последствиями полтора года. Ошибка в тесте стоит одного коммита на исправление. Ошибка в архитектуре модуля стоит месяца рефакторинга или вечной технической задолженности.
Мой рабочий протокол
Иду к Claude:
- Написать или дополнить unit-тесты для функции с известным поведением.
- Сгенерировать boilerplate по шаблону (эндпоинт, миграция, конфиг).
- Применить механический рефакторинг с конкретным правилом.
- Найти и объяснить конкретную ошибку в коде, который я ему показал целиком.
- Написать SQL-запрос по конкретной схеме с конкретными условиями.
Не иду к Claude:
- Проектировать структуру нового модуля или сервиса.
- Решать, нужен ли рефакторинг вообще.
- Выбирать между двумя подходами с неочевидными трейдоффами.
- Оценивать, как изменение одной части системы повлияет на другие.
- Принимать решение про добавление нового слоя (кеш, очередь, индекс).
Практически: перед тем как отправить задачу Claude, я задаю себе один вопрос. «Мог бы я дать эту же задачу хорошему джуниору, который не видел наш проект?» Если да — иду к Claude. Если нет — делаю сам.
Как это меняет роль senior-инженера
Меняет меньше, чем кажется из заголовков.
Я трачу меньше времени на написание кода, который выполняет уже принятое решение. Больше — на то, чтобы принять его правильно: понять контекст, проверить, что результат Claude реально решает задачу, а не тихо создаёт новую.
Senior-инженер в 2026 году — это инженер, который умеет правильно формулировать задачу, проверять результат и знает, где инструмент работает хорошо, а где нет. Это та же роль, что и всегда. Просто инструментов стало больше.
Красная черта
Самое опасное, что я видел в последние полтора года, это не плохой код от Claude. Это ситуация, когда «Claude написал» становится ответом на вопрос «кто отвечает».
Ответственность за архитектурные решения, за выбор подхода, за последствия для системы остаётся за инженером. Всегда. Claude — это инструмент. Его результат нужно проверить, а не заливать в production без review.
Если в команде появился паттерн «AI написал, значит нормально» — это симптом отсутствия инженерной культуры, а не достижение эффективности.
Если правило уже есть — берите Claude. Если правило ещё предстоит определить, это работа инженера, и переложить её некуда.
Про то, как выглядит хороший рабочий контекст для Claude в повседневных задачах, писал отдельно: Claude Code и Obsidian как живая документация.