Как сделать вашу компанию AI-driven

01 / Манифест

Не раздать инструменты — построить способ работы

«Мы купили Claude Code всем. Через месяц пришли — почему ничего не изменилось?»

Слышал этот вопрос несколько раз. Каждый раз ответ один и тот же: AI-driven компания — это не инструменты, это способ работы.

Если PRD живут в Confluence и обновляются раз в неделю, архитектура — только в голове CTO, QA это manual-прогон после фичи, а скиллы у каждого свои в личных чатах — никакой Claude Code не спасёт. Он ускорит то, что работает. Бардак ускорит тоже.

Дальше нужно разложить, что такое AI-driven по существу. Артефакты — PRD, архитектура, решения — переезжают в репозиторий. Не в Confluence, не в Notion, а рядом с кодом. Методология общая на команду: как промптим, что кладём в контекст, как ревьюем то, что выдал агент. Ответственность смещается с роли на результат — появляются фича-оунеры, которые ведут фичу от продукта до прода, не передавая её «специалисту по такому-то стеку» на полпути. Скиллы превращаются в код: их пишут, версионируют, ревьюят, обновляют после инцидентов.

Инструменты — это последние 10%. Первые 90% — переписать процесс.

Дальше — что именно переписать. Девять ценностей в основе, потом принципы по пяти доменам, потом трёхфазный план.

02 / Ценности

Девять вещей, в которые должна поверить команда

Без этого следующие шаги — принципы и план — не работают. Это фундамент. Если на каком-то пункте у команды «согласны теоретически» — значит туда нужно вернуться, прежде чем катить процессы.

01
AI — рабочий инструмент каждой роли

продукт, разработка, QA, аналитика — не только dev
02
Общие инструменты и артефакты

единый стек, единые репозитории, каждый знает где что лежит
03
Владение фичей от идеи до прода

каждый отвечает за результат целиком, не «я свою часть сделал»
04
Документация и решения as code

PRD, архитектура, ADR — в репозитории. Confluence — на выход
05
Лидеры формируют среду

CTO задаёт пример, сеньоры разрабатывают скиллы и платформу
06
Скиллы и контекст — основа эффективности AI

экспертиза в коде, контекст агенту даём осознанно
07
Автоматизация процессов

историческая основа компании, AI расширяет её границы
08
Безопасность с первого дня

правила работы с данными согласованы и соблюдаются
09
Исследования — часть работы

выделенное время, обязательный шеринг внутри команды

Каждая из этих девяти повторяется ниже — в принципах по доменам и в плане. Они не висят отдельно от практики.

03 / Принципы

Что меняется в каждом домене

Ценности — про вектор, принципы — про практику. Внутри каждого домена меняется не одно-два, а почти всё. Общая логика одна: артефакты переезжают в код, владельцы становятся универсалами. Дальше — конкретика по доменам.

— AI с продукта, не только с кода
— PRD живой — as code, в репе фичи, обновляется в процессе
— Design system: токены и компоненты
— AI-прототипы с вёрсткой — дизайн → код за часы

04 / Фазы

Трёхфазный план — от Запуска до Зрелости

Фазы — это не план на квартал, а порядок. Каждая должна закончиться до начала следующей; иначе получается бардак, ускоренный AI. Внутри фазы — несколько волн, по которым команда движется. Дальше — что происходит в каждой.

Фаза 01 / Запуск

Все попробовали, скиллы начали жить

→ Показать команде, как это круто. Дать поиграться.

Подготовка

Выделяем AI-драйвера

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

Что можно скармливать AI, что нельзя. Согласовать с подрядчиком до закупки тулов.
Раскатываем Claude Code на всех

Базово: dev, QA, продакты, аналитики, фронты.
Создаём ai-learnings репо

Сразу — иначе первые находки растворятся в Slack-чатах.
CTO делает фичу end-to-end

BE + FE с нуля до прода. Для собственного понимания и как живой пример команде.

Раскатка

Все начинают пользоваться

Никаких правил пока — пусть пробуют. Главное — снять страх «делать не так».
Cursor как опция

Если кому-то с Claude сложно — пробуют Cursor.
Запускаем weekly AI-митинг

30 минут, формат демо, не пересказ статей.
Выделяем ресёрч-время

Несколько часов в неделю — часть рабочего времени, не вечернее хобби. Рассказывать остальным что выучили.
Фронты пробуют дизайн-тулы

Figma Make, Claude Design — без обязательств, просто понять что они умеют.
Продакты вайбкодят пет

Не для прода. На своей коже понять границы: что AI делает легко, что нет.

Первые попытки масштаба

Лиды пишут первые скиллы

Бэк-лиды — по своим стекам. FE-лид — фронт. Без претензии на идеал.
Коммитят в общий репо

Скилл = код, ревьюется как код.
Dev + QA — автотесты в момент разработки

Не отдельная фаза после фичи, а параллельно с кодом.
Проверяем гипотезу про ускорение

Берём чуть больше задач в спринт. Не штраф если не закрыли — это эксперимент.
У каждого появляются свои промпты

Если этого не происходит к концу фазы — человек не пользуется реально, только декларирует.

Фаза 02 / Эффективность

AI стал инструментом — теперь делаем рычагом

→ Команда уже знакома с AI. Пора повысить эффективность использования: контекст, скиллы, продуктовые репо.

Учимся работать с AI правильно

Изучаем best practices

Официальные доки от Anthropic, open-source скиллы (superpowers, agency-agents).
Разбираем на митингах

Что заходит у нас, что нет. Не всё применимо — нужен фильтр под наш контекст.
Принимаем как факт: контекст решает

90% проблем с AI — это нехватка контекста, а не модель.
Команда осознанно даёт контекст

В промпт — что за фича, какой стек, какие ограничения. Не «напиши функцию», а «напиши с учётом X, Y, Z».

Строим продуктовые репо

Создаём первый {product-name}-docs

Один репо на продукт — единая точка контекста для AI и людей.
Описываем структуру

README, architecture/ (overview, services, decisions), features/{feature-id}/, tests/.
feature-id = номер задачи в трекере

Сквозной идентификатор: одна и та же ID связывает Jira, ветку во всех репо, папку в product-docs.
CTO кладёт архитектуру по существующим фичам

Минимум — overview сервисов и связей.
Пилот на одной новой фиче

Разраб и продакт садятся рядом, через скилл коммитят PRD в репо.
Скилл-навигатор

Агент умеет ходить между product-docs и сервисами по feature-id.

Скиллы становятся системой

Отдельный репо под скиллы

Это центральный артефакт всей трансформации.
Сеньоры пишут скиллы по своей области

Backend, Frontend, Mobile, QA — каждая зона экспертизы переносится из голов в код.
Скиллы версионируются и ревьюятся

Скилл = код. PR, code review, changelog. Не «накидал md и забыл».
Постмортем → апдейт скилла

После каждого инцидента — апдейт скилла, чтобы AI больше не наступил на эти грабли.
Скилл для legacy

Предсказуемый рефакторинг — самая болезненная зона любой команды.

Продукт и аналитика подключаются

PRD по шаблону под AI

Context, User stories, Acceptance criteria, Edge cases, Out of scope. Без шаблона агент путается.
Аналитики делают черновик из заметок

Запись встречи с бизнесом → AI делает черновик PRD → BA доводит. Учит и ускоряет одновременно.
Продакты + аналитики в общем цикле

Видят, что они часть AI-потока, не отдельная фаза.

Процессные изменения

AI code review до человеческого

Первый проход делает агент по правилам из скилла. Человек ревьюит уже подчищенный PR.
Единый branch name по фиче

Во всех репо — сервисы плюс FE — одно и то же имя, привязанное к feature-id.
Архитектура as code в product-docs

Пока делает CTO, к концу фазы — лиды.
Начинаем мерить lead time

Готовимся к канбану — нужны базовые цифры до перехода.
Квартальное планирование остаётся, спринты уйдут

Фаза 03 / Зрелость

Все — фича-оунеры. Канбан. Продакты пишут PRD прямо в репо.

→ Автоматизировано всё, что можно. Скиллы превратили каждого в универсала.

Переход на канбан

Объявляем переход через митинг, не молча

Объясняем зачем и что меняется.
Квартальное планирование остаётся

Для крупных ставок и направлений.
Внутри квартала — канбан

Поток вместо спринтов. Готова фича — катим.
Берём чуть больше commit

Повышаем планку каждый квартал.
Релизы независимы от планирования

Готова фича — катим, не привязываемся к концу итерации.

Меняем роли

Все разрабы — фича-оунеры

От PRD до прода, через несколько сервисов. Не «бэкендер» и «фронтендер», а владелец фичи.
Тимлид → Lead Engineer

Последнее слово в своём стеке, но сам деливерит фичи.
Сильный лид ведёт от продукта до прода

Продукт + архитектура + код + ревью — всё одним человеком, если уровень позволяет.
Эксперт-ревьюер — роль-скилл

Не отдельная позиция: review-по-стеку — навык, который добавляется к основной роли.

Документация легаси

Документируем всё существующее

Легаси, скрытые знания, обходы — всё что жило в головах, переносим в код.
В product-docs

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

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

После документации новые фича-оунеры могут без страха лезть в незнакомые сервисы.

Скиллы для продукта и анализа

Продакты пишут PRD через скилл

У продакта нет доступа к репо — есть у агента. Продакт промптит, агент кладёт PRD в product-docs/features/{feature-id}/prd.md.
Скилл валидирует PRD

Перед коммитом проверяет шаблон. Не пускает кривое.
Лёгкие фичи — сразу в реализацию

PRD → черновик кода → PR на ревью разработчику.
Аналитики делают то же самое

Бизнес-требования из встречи → AI → PRD в репо → ревью продакта.
Барьеры между ролями исчезают

Продакт умеет в код, разработчик умеет в продукт, аналитик умеет и то, и другое. Все универсалы.

05 / Риски

Что может пойти не так

Это не запугивание — это карта мин. Все четыре риска видел вживую. Один — у себя.

01
Скорость vs стабильность

Пойти вперёд слишком быстро и потерять стабильность продукта. Каждая фаза должна закончиться раньше, чем начнётся следующая.
02
«А зачем я теперь нужен»

Разработчики могут воспринять AI не как рост своей мощи, а как угрозу. Нужно явно объяснить: вы нужны за ответственность, а не за набор строк кода.
03
Страх сокращения ролей

Команда становится меньше и сильнее. Надо донести: оптимизация — победа и сильная строчка в резюме, а не минус. Отставание на год — вот это минус.
04
Технический долг растёт быстрее

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

06 / Закрепляем

Что не зависит от сценария

Решения, которые принимаются вне зависимости от того, как именно сложится трансформация. То, что в любом случае меняется.

→

Найм меняется

Ищем фича-оунеров, не стек-разработчиков
→

Свободные мощности

Техдолг, эксперименты, новые направления — не «пилим всё что можно»
→

Метрики — реальные

Lead time, частота релизов, частота инцидентов. Не «у нас 80% сотрудников использует AI»
→

Единый владелец методологии

CTO или сильный лид. Иначе — дрейф

Это рабочий документ. Версии будут обновляться по мере накопления опыта. Текущая — v0.1, обновлено 2026-05-10.

Не раздать инструменты — построить способ работы

Девять вещей, в которые должна поверить команда

AI — рабочий инструмент каждой роли

Общие инструменты и артефакты

Владение фичей от идеи до прода

Документация и решения as code

Лидеры формируют среду

Скиллы и контекст — основа эффективности AI

Автоматизация процессов

Безопасность с первого дня

Исследования — часть работы