Если вы хотите внедрить АI в работу команды, недостаточно просто купить подписку и раздать её разработчикам. Возникают распространённые вопросы:

• Как зарегистрировать Claude, если вы работаете из РФ.

• Как безопасно организовать доступы.

• Как понять, что внедрение действительно приносит пользу, а не просто увеличивает траты компании.

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

Материал рассчитан прежде всего на Team Lead’ов, Engineering Manager’ов, CTO и тех, кому предстоит отвечать не только за работу модели, но и за то, чтобы её использование действительно улучшало процессы разработки.

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

Итак, начнём с подготовки требований к инфраструктуре

---

Часть #1: Подготовка, собираем «джентльменский набор»

Для начала реалии того, что потребуется для пользователей из РФ, все остальные могут эту часть пропустить:

1. Зарубежная SIM-карта (оптимально)

Требование к подтверждению аккаунта может отличаться в зависимости от страны, выбранной при регистрации. Например, когда я создавал Claude Team для компании и указал Швецию, система запросила номер телефона. Позже, уже регистрируя организацию для себя, я выбрал Казахстан. В этом случае телефон не понадобился, однако вместо него потребовался регистрационный номер ИП, который у меня уже был. Поэтому не удивляйтесь, если сценарий регистрации у вас окажется немного другим.

Как бы там не было, запомните главное — не пользуйтесь сервисами, которые предоставляет временные номера, это один из наиболее частых сценариев, который приводит к блокировке. Так происходит потому, что подобные сервисы крутят ограниченное кол-во телефонов среди своих пользователей, а Anthropic следит за тем, чтобы никто не регистрировал несколько акков даже для личного использования, ведь это «противоречит их политике использования сервиса». Иначе говоря, они неофициально борются за то, чтобы вы пользовались тарифом Max, а не занимались свитчингом нескольких Pro аккаунтов.

2. Visa или Mastercard, разумеется не РФ

Существуют различные сервисы для пополнения баланса, сам я таким не пользовался, поэтому и рекомендовать их я не стану. Помните, что это тоже определённый риск бана, если есть возможность — получите реальный пластик или пополняйте баланс через знакомых/проверенных людей.

3. Запрещённый сервис состоящий из трёх букв

Назовём его КВН (ну вы поняли о чём речь).

Лично для себя самым надёжным вариантом считаю аренду VPS. Если вы пойдёте по тому же пути, то тут важно учитывать три вещи: страну, протокол и конфигурацию. Чтобы никто не обвинял в рекламе, отправляю вас в Google, но оставлю несколько советов:

• Выбирайте страны с хорошим пингом: Казахстан, Нидерланды, Германия

• Не переплачивайте за мощную конфигурацию. Обычно достаточно 2 CPU, 2-4 GB RAM, 1 Gbps пропускной способности и безлимитный трафик. Средняя цена ~5$ в месяц

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

Теперь то, что потребуется обязательно

1. Собственный домен, который можно подтвердить через DNS-записи.

2. Собственный (или арендованный) почтовый сервер, т.к. Claude Team будет работать только в рамках добавленных в него доменов, иначе говоря какой-нибудь Gmail тут не подойдёт. Многие провайдеры, что предоставляют VPS — предоставляют и такие услуги.

3. Self-hosted сервис для двухфакторной аутентификации, конкретно я использовал Keycloak. Кстати подтверждение домена и двухфакторка через Keycloak отключают запрос подтверждения номера телефона для всей группы.

4. Loki, Prometheus, Grafana и OpenTelemetry.

Понимая заранее, что с последним пунктом могут возникнуть сложности — я подготовил GitHub репозиторий со всеми тех. инструкциями и конфигами

---

Часть #2: Регистрация Claude Team

1. Регистрация

Заходим на Claude AI — Login и регистрируем аккаунт на корпоративную почту. Домен этой почты позже потребуется подтвердить через DNS-запись. Все участники команды также должны будут использовать адреса почты на этом домене. Есть возможность добавить несколько своих доменов, но тем не менее добавить кого-то с публичным email адресом в команду, например в Gmail — у вас не получится.

Первая учётная запись получает роль Primary Owner. После создания команды её место в подписке — можно передать другому пользователю. Поэтому лучше сразу создать отдельный ящик, например ai@company.com и использовать его только для управления подпиской, биллингом и доступами, не привязывая всё к личной почте какого-то конкретного сотрудника.

После вас перекинет в Onbording, где у вас спросят, для каких целей вы собираетесь использовать зарегистрированный аккаунт, тут потребуется выбрать: With my team

Если учётная запись уже есть

Если у вас уже есть учётная запись, которая зарегистрирована на корп. почту, то вы можете просто открыть страницу Upgrade, далее перейти во вкладку Team and Enterprise и выбрать Get Team Plan

2. Биллинг

Для подключения Claude Team необходимо сразу приобрести минимум пять мест, это обязательное требование тарифа.

Для начала оптимально выбрать Standard за $25 на пользователя. Есть также Premium Seat, апгрейд на него вы сможете сделать в любое время. При этом отмечу, Team-тарифы дают на ~25% (на текущий момент) больше квоты, чем личные подписки Pro и Max x5, за упущенную выгоду можно не беспокоиться.

Сразу расскажу как работает биллинг — полная стоимость списывается в начале месяца. Т.е. если добавить пользователя в середине, спишется только сумма за оставшиеся дни. По такому же принципу работает переход со Standard на Premium, оплачивается лишь разница между тарифами до конца периода.

Также есть возможность место передавать, нет жесткой привязки на конкретный email.

3. Подтверждение владения доменом

Открываем Admin Setttings организации.

В разделе Domains нажимаем Add Domains, добавляем и запускаем Verify. Anthropic выдаст TXT-запись, которую нужно внести в DNS.

Обычно проверка занимает десять минут, но иногда растягивается до ~48 часов. После статуса Verified на можно переходить к следующему шагу.

4. Подключаем SSO

К этому этапу — у вас уже должны быть настроен Keycloak, согласно нашему джентльменскому набору (см. начало данной статьи).

Далее переходим в раздел Authentication → Setup SSO. Выбираем провайдера (в нашем случае это Keycloak SAML) и далее следуем внутренней инструкцией предоставленной Anthropic.

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

---

Часть #3: Сбор метрик

Итого, на текущий момент у нас:

• ✓ Claude Team зарегистрирован

• ✓ домен подтверждён

• ✓ SSO работает

К этому моменту также уже должны быть развёрнуты необходимые сервисы:

• OpenTelemetry

• Prometheus

• Loki

• Grafana

Если с этим возникли сложности, воспользуйтесь моим репозиторием с конфигами и инструкциями

Настраиваем мониторинг

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

Переходим в Organization settings → Claude Code → Managed settings и добавляем следующие строки из примера ниже, не забывая поменять параметры OpenTelemetry на свои. Пример json см. здесь

Далее ждём н-е кол-во времени, пока команда попользуется Claude Code (т.к. нужны хоть какие-то данные), затем проверяем работоспособность коллектора:

1. Идём в Grafana → Explore → Prometheus.

2. В Metrics browser вводим claude_code. Если в списке появились метрики, значит коллектор работает.

Строим графики и данные для анализа

Теперь необходимо подготовить Dashboard. Предлагаю следующие варианты:

• Можно собрать самостоятельно, используя пример Anthropic и описание доступных метрик

• Используйте мой шаблон

• Попросите Claude Code сгенерировать JSON по вашим требованиям.

Как бы там не было, результат импортируем в Grafana: Home → Dashboards → New → Import.

На какие показатели стоит обращать внимание:

• Активное время (active_time_seconds_total | type: user/cli) — Показывает, сколько разработчиков используют Claude Code в реальном времени и как долго длятся сессии. Полезно на этапе адаптации команды.

• Потребление токенов (token_usage_tokens_total | input, output, cacheRead, cacheCreation) — Позволяет анализировать динамику по дням, пользователям и моделям.

• Lines of Code (lines_of_code_count_total | type: added/removed) — Количество строк, добавленных или удалённых с помощью модели.

• Accept rate (code_edit_tool_decision_total | decision: accept/reject) — Доля изменений, принятых или отклонённых разработчиками. Насколько часто результат модели используется командой.

Например, как с этим можно работать и какие гипотезы строить:

Accept Rate:
40-60%
нормально

20%
стоит разобраться

5%
скорее всего разработчики модели не доверяют

Если этих данных мало

Prometheus предоставляет лишь агрегацию числовых показателей. Для более глубокого анализа взаимодействия команды с LLM — можно использовать события и логи из Loki. Какие данные можно получить там:

• Список MCP подключений

• Топ-лист Skills по числу активаций

• Размер контекста по сессиям

• Список доступов, предоставленных модели

• Кто и при каких условиях достигает лимитов сессии

• Полный детальный лог событий и промптов

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

Пара советов

Вам необходимо сопоставлять эти показатели с инженерными и продуктовыми метриками: lead time, cycle time, количеством завершённых задач, скоростью прохождения MR/PR, временем code review, числом дефектов и rollback.

Опять же в качестве примера, возможные сценарии:

• Рост Active Time + рост Lead Time — значит люди много общаются с AI, но быстрее работать не стали. Стоит проанализировать стоперы.

• Рост Accept Rate + снижение Code Review Time — AI действительно помогает команде.

Стройте доказательную базу влияния AI — сравнивая периоды до и после внедрения, находите нужные корреляции.

---

Часть #4: С чего начать внедрение в команду

Создание правил / Rules

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

Хранить их можно в «.claude/rules«, разбив на несколько md-файлов. Пример:

.claude/rules/
architecture.md
code-style.md
best-practice.md
testing.md
vue.md

• architecture.md — краткая навигация по проекту, где и какие файлы хранить и какую методологию вы для этого используете (например модульную архитектуру или FSD).

• code-style.md — более детальное описание принятых код-стайлов. Проще говоря, всё, что вы ещё не успели закрыть линтерами.

• best-practice.md — требования к итоговому результату, какие подходы и методологии нужно соблюдать (KISS, DRY, SOLID и т.п.). Также тут можно указать ваши основные паттерны и другие требования.

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

Несколько советов по формированию Rules

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

2. Не пытайтесь сразу описать каждый возможный случай. Начните с краткой справки, а если результат не устраивает — добавляйте конкретные примеры с кодом: «делай вот так, не делай эдак«.

3. Не пишите что-то вроде: «Представь, что ты Senior Fullstack Engineer с 20 годами опыта«. Окей, AI не тупой и не ленивый. Он примет любые правила игры, но если вы оставили свободу интерпретации, не ждите результат, который существует только у вас в голове.

4. Если собственных знаний не хватает, идите на GitHub и ищите репозитории с правилами или скиллами под нужные технологии. Но не тащите в проект готовые «комбайны», о которых нейро-инфлюенсеры рассказывают на перебой. Там обязательно будет три десятка языков и столько же фреймворков, но главное, всё это, разумеется, сгенерировано самой нейронкой из ничего. Такие наборы неэффективны и лишь забивают контекст тем, с чем LLM никогда не столкнётся в вашем проекте, что повышает риск галлюцинаций. Количество звёздочек в GitHub тут ничего не гарантирует. Смотрите, внимательнее что автор репы из себя представляет, связан ли он крупным бигтехом, контрибьютит ли что либо полезное, есть ли у него релевантный опыт, кроме собственного AI-стартапа, о котором вы никогда не слышали и, вероятно, не услышите.

5. Проще всего, если у команды уже есть база знаний в условном Confluence. Передайте её AI и попросите сформировать правила. Противоречия с предыдущим пунктом нет — это не генерация из ничего, а миграция накопленных знаний команды в формат, понятный нейронке.

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

Обзор на остальные слои

С rules всё ясно, они попадают в контекст каждого запроса, а значит учитываются моделью. А вот MCP, Skills и Agents подключаются только при определённых условиях.

MCP

Выступает связующим звеном между моделью и внешними миром. MCP нужен не потому что “можно”, а потому что LLM не должна угадывать. Она должна получать актуальные данные.

Например MCP позволяет:

• Тянуть макеты из Figma

• Загружать необходимую документацию из Confluence

• Получать задачи из Jira, анализировать их и обновлять статусы

• Запускать Playwright или Chrome MCP для проверки пользовательских сценариев и анализа Core Web Vitals и т.п.

Для многих популярных сервисов уже существуют готовые MCP-серверы. Часть из них создаётся и поддерживается разработчиками самих платформ, но и комьюнити не стоит на месте, а значит практически для всего, что придёт вам в голову — уже найдётся готовое решение в GitHub. Но не забывайте про безопасность. Если будете бездумно цеплять серверы от неизвестных авторов без репутации, не удивляйтесь потом, что корп. токены и исходники ваших проектов утекли.

Skills

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

Например:

• Провести нагрузочное или регрессионное тестирование

• Проверить актуальность зависимостей

• Добавить новый ключ локализации

• Мигрировать модуль на новую версию стека

Конечный список будет сугубо зависеть от конкретной команды и направления.

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

Agents

Изолированные исполнители, которым основная модель делегирует часть задачи. Ключевое отличие от Skills: сабагент работает в собственном контексте — читает файлы, ищет по проекту, разбирает код и документацию у себя, а в основную сессию возвращает только итог, а не сотни строк прочитанного и промежуточных рассуждений.

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

Ясно, понятно

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

---

Часть #5: Период адаптации

Как я писал ранее, все дополнительные слои вокруг LLM, кроме rules — опциональны.

Это не только моё, возможно излишне консервативное, мнение. Процитирую Бориса Чёрного, создателя Claude Code, в интервью Lenny’s Podcast:

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

Текстовый пересказ см. здесь.

Но вопрос о том, как эти боли выявить и мотивировать команду участвовать в формировании процесса разработки с помощью AI?

Поделюсь простой практикой, которую использовал:

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

2. Заранее определите цели встречи, формат, требования к выступлениям и общие правила для всех участников.

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

4. Дайте каждому желающему 10–15 минут на выступление, но не делайте участие обязательным. Обсуждение начинается только после завершения выступления.

5. Назначьте ответственного по внедрению ведущего, который будет следить за регламентом и фиксировать все договорённости: что необходимо проверить на практике, кто за это отвечает и к какому сроку должен быть готов результат.

6. Ведите подробный постмит и создайте общий чат, посвящённый внедрению AI. После каждой встречи публикуйте там итоги, принятые решения и следующие шаги.

7. Сразу обозначьте, что в этом чате можно и нужно делиться полезными находками, примерами использования моделей, результатами экспериментов и вопросами, возникающими в процессе работы.Главная задача таких встреч заключается не в том, чтобы навязать команде “правильный” способ работы с AI, а в том, чтобы создать безопасное пространство для обмена опытом.

Со временем из наиболее активных и заряженных ребят — можно сформировать небольшую рабочую группу. Она станет основой внутреннего AI-комитета, который будет проверять инструменты и подходы, документировать успешные практики и помогать распространять их внутри компании.

---

Заключительное слово

А на этом всё. Надеюсь мне удалось описать основные этапы внедрения и это поможет уже вам перейти на AI-Driven Development . Однако, не ждите роста продуктивности в +400%, это миф. Ориентируйтесь скорее на +30%.

По крайней мере на текущий момент — нейросети всё ещё остаются прикладным инструментом для разработчиков, которые способны создать необходимые спецификации и могут произвести качественный code-review результатов после, что в свою очередь поможет удержать компанию от растущего тех. долга и ухудшения качества разработки.