Мы попробовали Claude Code в энтерпрайз-разработке и собрали за вас восемь проблем

Привет! Меня зовут Андрей, я инженер в Циане. Примерно год назад мы начали внедрять в работу AI-помощников для разработки, а несколько месяцев назад сфокусировались на Claude Code как самом продвинутом из доступных. Сейчас пилотно используем его в командах инфраструктуры, платформы, продуктовой разработки. Масштаб здесь велик, риски интеграции AI тоже. В статье я расскажу, какие проблемы мы решали в процессе внедрения. И призываю вас поделиться своим опытом в комментариях.

Хранение артефактов AI-помощников в репозиториях

AI-помощников на рынке много, и хранить все их артефакты в репозиториях компонентов может быть накладно. Если вы решите так не делать, это заметно скажется на работе с Claude Code. Для него репозиторий компонентов — это нативное место для конфигурации (claude.md и папка .claude). Причем claude.md — самый надежный способ задать инструкции. Именно им помощник пытается следовать точнее всего.

Кроме claude.md в локальной папке .claude могут храниться скилы, агенты, хуки, правила, настройки (settings.json). Всё это будет недоступно, если вы не будете хранить конфигурацию AI-помощников в репозиториях компонентов.

Как же тогда распространять конфигурацию Claude Code? И что делать без компонентоспецифичной конфигурации?

Общую конфигурацию можно распространять с помощью плагинов. Это вполне нативный способ для Claude Code. Мы получаем простое обновление и версионирование «из коробки», но с плагинами нам доступна только общая конфигурация, не специфичная для компонентов.

Компонентоспецифичную конфигурацию можно вообще не хранить в репозитории, а вместо этого дать Claude Code доступ к информации о каждом компоненте на внутреннем портале. Это можно реализовать, например, как MCP для Backstage или Confluence. А знание о наличии и способе получения информации — оформить как общий скил и положить в плагин.

Windows на машинах разработчиков

На момент написания статьи актуальной была версия Claude Code 2.1.100. А поддержка Windows появилась сравнительно недавно — меньше года назад, в версии 1.0.51.

В глобальном claude.md в профиле можно прописать что-нибудь типа «ты работаешь на Windows». Но это совсем не гарантирует, что Claude Code не будет, как слепой котенок, путаться в bash-командах с кавычками, слешами и так далее. Еще одна, уже фундаментальная проблема: на Windows инструментарий работы с вашими компонентами (сборка, линтеры, тесты) будет отличаться.

Какие подходы к решению видим мы? 

• Через конфигурацию: делать в скилах/агентах ветвление «если ты на Windows — то делай так, иначе делай вот так».

• Скрыть эту разницу внутри универсальной утилиты с единым API.

• Мотивировать разработчиков работать с Claude Code из-под WSL — Windows Subsystem for Linux.

Для нас эта проблема стала весомым аргументом в пользу отказа от Windows на машинах разработчиков в будущем.

Расширение функционала сторонних субагентов

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

Компакцию контекста Claude Code переживает, увы, очень плохо. С каждой новой версией становится лучше, но пока до компакции доводить не стоит. Так что для разных задач придётся использовать субагентов, а корневой агент будет заниматься только оркестрацией.

В магазинах плагинов есть субагенты для различных задач. Например, есть агент, который замечательно программирует на питоне и почти всегда делает все, что нужно. Но есть нюанс: субагент из плагина не знает, что где-то ему надо не программировать, а просто запустить, например, генератор кода. Как объяснить подобные нюансы, не форкая плагин?

Недавно в Claude Code для этого появились скилы с context: fork. Они работают поверх определенных агентов и позволяют модифицировать их инструкции. Чтобы активировать этот режим, нужно указать в описании скила признак context: fork и желаемый тип агента через поле agent. В этом случае Claude Code будет запускать скил в изолированном контексте указанного агента, а его инструкции будут поступать агенту как часть промпта и тем самым изменять его поведение. Через поле agent можно указать тип субагента: explore, plan, general-purpose или кастомный из .claude/agents/. Подробнее можно почитать в документации.

Вопрос использования различных сторонних инструментов (плагинов/скилов/агентов/mcp) тесно связан с вопросом безопасности. Мы обязательно проводим sec ревью всего, что может использоваться разработчиками для расширения функционала Claude Code.

Петли обратной связи

Когда мы пишем реальный продуктовый код, то должны быть уверены: код делает, что нужно, и соответствует нашим требованиям. Чтобы достичь этого с помощью LLM, важно на разных этапах давай ей обратную связь.

Как это сделать при написании кода, примерно ясно: добавляем флоу с прогоном тестов (юнит-, модульных, интеграционных), код-ревью и реализуем цикл исправления проблем. Для этого в Claude Code достаточно написать скил, который определяет этот флоу, либо зашить его в субагенте.

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

Корневой агент не должен доверять субагентам, а внимательно проверять их работу. Как убедиться, что субагент действительно сделал работу, о которой отчитался?

Для этого существуют готовые скилы в популярных плагинах. Они берут изначальную задачу и начинает челленджить ей реализацию: сравнивать одно с другим, запускать билд, прогонять тесты.

Хотя корневой агент не пишет код, он тоже должен знать правила разработки, уметь запускать билды, линтеры и тесты, чтобы провести качественную валидацию работы субагентов. Для этого в корневом агенте можно активировать те же самые скилы, что в субагентах. Или в промпт субагентов добавлять инструкции по возврату команд для сборки и прогона тестов. Это тоже вполне рабочее решение.

«Космолёт не взлетит»

Когда вы видите всю мощь скилов и агентов, очень хочется запилить какой-нибудь универсальный комбайн. Даешь ему, грубо говоря, ID эпика в Jira — а он всё делает и возвращает тебе результат. Так сделать можно, и это, на первый взгляд, будет работать. Но только на первый, и поэтому так делать не нужно. Пока. В мае 2026 года 🙂

Разработчики могут использовать готовые фреймворки для флоу разработки, что-нибудь популярное или написать что-нибудь свое. Или даже не использовать вообще никакие фреймворки, а просто открыть Claude Code и дать ему задачу на багфикс. У всех разные подходы. А если не ограничивать разработчиков каким-то одним фреймворком, то как обеспечить все необходимые петли обратной связи?

Можно ограничиться всего одним правилом: мы всегда разрабатываем через план. Неважно откуда он взялся, но план должен быть всегда. Это нормально ложится на реализацию популярных фреймворков, работающих поверх Claude Code, а также заложено в нативный Claude Code в виде plan mode, в конце которого тоже появляется план. В этой точке можно определить флоу путем модификации плана.

Например, вводим определенный чек-лист «хорошего» плана: есть прогон тестов, код-ревью, валидация выполнения всех шагов. И делаем инструмент, который в случае, если в плане нет чего-то из этого чек-листа, добавляет это автоматически. Так мы не заставляем людей туннелиться в некий определённый фреймворк и при этом помогаем Claude Code реализовывать задачи с нужным нам качеством.

В плагинах есть поддержка хуков — обработчиков событий Claude Code. Если вы работаете с Plan Mode, это станет элегантным решением, которое будет работать автоматически, потому что Plan Mode генерирует событие перед показом плана пользователю и вы можете повесить на него хук. Например, запуск субагента, который получит план на вход, проверит его по чек-листу и автоматически допишет недостающие шаги.

А если вы не используете Plan Mode в Claude Code, можно реализовать скил валидации и модификации плана для запуска вручную.  

Тестирование скилов

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

Как их реализовать?

• Написать python-скрипты, запускать Claude Code через параметр -p, скармливая ему инструкции с запуском тех или иных скилов и анализируя ответы.

• Написать сценарий текстом и попросить Claude Code выполнить тесты, запуская нужные скилы в отдельных тасках.

• Использовать фреймворк для тестирования скилов (да, есть и такие): например стандартный плагин от Anthropics Skill-Creator или отдельный плагин superpowers для написания плагинов superpowers-developing-for-claude-code.

Решения могут быть разными, но тесты должны быть обязательно.

Интересный момент. Если в скилах вы реализуете какие-либо запреты — например, нельзя коммитить или пушить, — в тестах стоит отдельно акцентировать внимание на том, что такие тесты нужно запускать «под давлением». Вы должны провоцировать Claude Code в своих сценариях нарушить это ограничение — и убеждаться, что он его не нарушает ни при каких условиях. Акцент на таких тестах делается в superpowers.

Код-ревью перед коммитом

Если с Claude Code вы пилите пет-проект, то можно просто залить код прямо на GitHub, посмотреть его, прокомментировать или призвать для этого Copilot. А затем отправить Claude Code разбирать комментарии. 

В энтерпрайз-разработке всё сложнее. При движении задачи по флоу могут быть автоматически назначены ревьюеры, которые увидят косячный код раньше вас. Или PR могут создаваться только после проверок на CI, которые занимают некоторое время — например, час. Или циклы in-review -> reopen -> in-review могут считаться в метриках разработки и на что-нибудь влиять.

Даже если код пишет AI — это ваш код, за который вы ответственны. И прежде чем отправлять код на ревью, вы должны присвоить код себе и эту ответственность взять.

Как же тогда оценивать код и отгружать обратную связь в нужную сессию Claude Code до коммита?

Можно использовать какой-нибудь готовый инструмент, который запускает Claude Code внутри самого себя и имеет возможностью ревью изменений. Или, делать PR вручную, до движения задачи по своему флоу и проводить ревью самостоятельно и затем просить Claude Code обработать комментарии.

Возможно, у вас есть ещё более классное решение — будет интересно узнать о нем.

Auto approve

Каждое прерывание на апрув — это переключение фокуса разработчика и увеличение времени выполнения задачи, особенно при работе сразу в нескольких сессиях.

Поэтому возникает соблазн выдать Claude Code широкие разрешения и не отвлекаться на подтверждения. Это один из самых серьезных рисков при внедрении агентской разработки: широкие разрешения означают, что в многопоточной работе может быть исполнено то, что исполнять не стоило.

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

Базовый набор мер, который мы считаем обязательным:

• Максимально порезать в правах учетку для работы с Claude Code.

• Запускать Claude Code в изоляции — в песочнице, на отдельной виртуальной машине и т. д.

• С помощью сторонних средств вычленять опасные команды из Claude Code и блокировать их выполнение.

В статье я перечислил восемь основных проблем, которые нам пришлось решать при внедрении Claude Code.

Специально не акцентировал внимание на том, какие именно решения выбрали мы, так как мы делаем выбор с учётом жестких требований ИБ и они сильно его ограничивают.

Ещё мы поняли, что качественная агентская разработка в enterprise возможна только тогда, когда для этого реализован зрелый тулинг (или даже экосистема). Мы в начале этого пути и расскажем о результатах в следующих статьях на эту тему.

Но наверняка у вас есть что добавить уже сейчас, давайте обсудим!

Источник: habr.com