Как сделать вашу компанию AI-driven
Practitioner's framework для CEO, CPO, CTO, фаундера. Не раздать инструменты — построить способ работы. Ценности, принципы, фазы, риски.
Не раздать инструменты — построить способ работы
«Мы купили Claude Code всем. Через месяц пришли — почему ничего не изменилось?»
Слышал этот вопрос несколько раз. Каждый раз ответ один и тот же.
AI-driven компания — это не инструменты. Это способ работы.
Если у вас PRD живут в Confluence и обновляются раз в неделю, архитектура — в голове CTO, QA — это manual-прогон после фичи, скиллы команды у каждого свои в чате — никакой Claude Code не спасёт. Он только ускорит то, что работает. Бардак ускорит тоже.
- единые артефакты — PRD, архитектура, ADR как код, в репе
- общая методология — как промптим, что в контекст, как ревьюем
- ответственность за результат — фича-оунеры, а не «бэкендер» отдельно «фронтендер»
- скиллы как код — версионируются, ревьюются, обновляются после каждого инцидента
Инструменты — это последние 10%. Первые 90% — переписать процесс.
Дальше — что именно переписать. Девять ценностей в основе, потом принципы по пяти доменам, потом трёхфазный план. Запасайтесь временем — это не блог-пост.
Девять вещей, в которые должна поверить команда
Иначе следующие шаги — про принципы и план — не работают. Это фундамент. Если на каком-то пункте у команды «ну да, согласны теоретически» — значит туда нужно вернуться, прежде чем катить процессы.
- 01
AI — рабочий инструмент каждой роли
продукт, разработка, QA, аналитика — не только dev
- 02
Общие инструменты и артефакты
единый стек, единые репозитории, каждый знает где что лежит
- 03
Владение фичей от идеи до прода
каждый отвечает за результат целиком, не «я свою часть сделал»
- 04
Документация и решения as code
PRD, архитектура, ADR — в репозитории. Confluence — на выход
- 05
Лидеры формируют среду
CTO задаёт пример, сеньоры разрабатывают скиллы и платформу
- 06
Скиллы и контекст — основа эффективности AI
экспертиза в коде, контекст агенту даём осознанно
- 07
Автоматизация процессов
историческая основа компании, AI расширяет её границы
- 08
Безопасность с первого дня
правила работы с данными согласованы и соблюдаются
- 09
Исследования — часть работы
выделенное время, обязательный шеринг внутри команды
Эти ценности — не лозунги для обоев. Каждая повторяется в принципах и в плане ниже. Пройдёмся.
Что меняется в каждом домене
Ценности — про вектор. Принципы — про практику. Кликни домен — увидишь что там конкретно нужно поменять. Спойлер: почти везде дело в том, чтобы артефакты переехали в код, а владельцы — стали универсалами.
- — AI с продукта, не только с кода
- — PRD живой — as code, в репе фичи, обновляется в процессе
- — Design system: токены и компоненты
- — AI-прототипы с вёрсткой — дизайн → код за часы
- — Архитектура as code — рядом с кодом
- — Единая BE-платформа, общие конвенции
- — Engineering handbook, скиллы BE / FE / QA
- — .cursorrules / CLAUDE.md в каждом репо
- — Чёткие домены, без дублирования
- — QA = качество, не прогон тестов
- — Автотесты в момент разработки
- — QA валидирует — приёмка и сложные сценарии
- — Песочницы для AI-пилотов
- — AI-триаж ошибок в мониторинге
- — Метрики трансформации — реальные, не самоотчёт
- — Лиды строят среду для мидлов и джунов
- — Вклад в команду больше личного output
- — Ответственность ценится — в том числе у джунов
- — AI ежедневно — все функции, не только dev
- — Владеть AI, применять где выигрыш
- — Weekly demo вместо пересказа статей
- — Ресёрч-время с выходом в артефакт
- — Единый владелец методологии (CTO или сильный лид)
Трёхфазный план — от Запуска до Зрелости
Не пытайтесь скакнуть в зрелость за месяц. Каждая фаза должна закончиться до начала следующей — иначе получите бардак, ускоренный AI. Каждая фаза — это набор волн. Кликните на фазу, чтобы развернуть.
Все попробовали, скиллы начали жить
→ Показать команде, как это круто. Дать поиграться.
Подготовка
- Выделяем AI-драйвераCTO — лучше всех поймёт, как это работает, и его не обманешь. Будет требовать больше, понимая возможности.
- Решаем по безопасностиЧто можно скармливать AI, что нельзя. Согласовать с подрядчиком до закупки тулов.
- Раскатываем Claude Code на всехБазово: dev, QA, продакты, аналитики, фронты.
- Создаём ai-learnings репоСразу — иначе первые находки растворятся в Slack-чатах.
- CTO делает фичу end-to-endBE + FE с нуля до прода. Для собственного понимания и как живой пример команде.
Раскатка
- Все начинают пользоватьсяНикаких правил пока — пусть пробуют. Главное — снять страх «делать не так».
- Cursor как опцияЕсли кому-то с Claude сложно — пробуют Cursor.
- Запускаем weekly AI-митинг30 минут, формат демо, не пересказ статей.
- Выделяем ресёрч-времяНесколько часов в неделю — часть рабочего времени, не вечернее хобби. Рассказывать остальным что выучили.
- Фронты пробуют дизайн-тулыFigma Make, Claude Design — без обязательств, просто понять что они умеют.
- Продакты вайбкодят петНе для прода. На своей коже понять границы: что AI делает легко, что нет.
Первые попытки масштаба
- Лиды пишут первые скиллыБэк-лиды — по своим стекам. FE-лид — фронт. Без претензии на идеал.
- Коммитят в общий репоСкилл = код, ревьюется как код.
- Dev + QA — автотесты в момент разработкиНе отдельная фаза после фичи, а параллельно с кодом.
- Проверяем гипотезу про ускорениеБерём чуть больше задач в спринт. Не штраф если не закрыли — это эксперимент.
- У каждого появляются свои промптыЕсли этого не происходит к концу фазы — человек не пользуется реально, только декларирует.
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 по шаблону под AIContext, 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Готовимся к канбану — нужны базовые цифры до перехода.
- Квартальное планирование остаётся, спринты уйдут
Все — фича-оунеры. Канбан. Продакты пишут PRD прямо в репо.
→ Автоматизировано всё, что можно. Скиллы превратили каждого в универсала.
Переход на канбан
- Объявляем переход через митинг, не молчаОбъясняем зачем и что меняется.
- Квартальное планирование остаётсяДля крупных ставок и направлений.
- Внутри квартала — канбанПоток вместо спринтов. Готова фича — катим.
- Берём чуть больше commitПовышаем планку каждый квартал.
- Релизы независимы от планированияГотова фича — катим, не привязываемся к концу итерации.
Меняем роли
- Все разрабы — фича-оунерыОт PRD до прода, через несколько сервисов. Не «бэкендер» и «фронтендер», а владелец фичи.
- Тимлид → Lead EngineerПоследнее слово в своём стеке, но сам деливерит фичи.
- Сильный лид ведёт от продукта до продаПродукт + архитектура + код + ревью — всё одним человеком, если уровень позволяет.
- Эксперт-ревьюер — роль-скиллНе отдельная позиция: review-по-стеку — навык, который добавляется к основной роли.
Документация легаси
- Документируем всё существующееЛегаси, скрытые знания, обходы — всё что жило в головах, переносим в код.
- В product-docsАрхитектура, сервисы, решения. По единой схеме, чтобы агент мог искать.
- Через AIАгент читает код, разработчик валидирует. Не пишем доку руками — это уже дорого.
- Старые сервисы открываютсяПосле документации новые фича-оунеры могут без страха лезть в незнакомые сервисы.
Скиллы для продукта и анализа
- Продакты пишут PRD через скиллУ продакта нет доступа к репо — есть у агента. Продакт промптит, агент кладёт PRD в product-docs/features/{feature-id}/prd.md.
- Скилл валидирует PRDПеред коммитом проверяет шаблон. Не пускает кривое.
- Лёгкие фичи — сразу в реализациюPRD → черновик кода → PR на ревью разработчику.
- Аналитики делают то же самоеБизнес-требования из встречи → AI → PRD в репо → ревью продакта.
- Барьеры между ролями исчезаютПродакт умеет в код, разработчик умеет в продукт, аналитик умеет и то, и другое. Все универсалы.
Что может пойти не так
Это не запугивание — это карта мин. Все четыре риска видел вживую. Один — у себя.
- 01
Скорость vs стабильность
Пойти вперёд слишком быстро и потерять стабильность продукта. Каждая фаза должна закончиться раньше, чем начнётся следующая.
- 02
«А зачем я теперь нужен»
Разработчики могут воспринять AI не как рост своей мощи, а как угрозу. Нужно явно объяснить: вы нужны за ответственность, а не за набор строк кода.
- 03
Страх сокращения ролей
Команда становится меньше и сильнее. Надо донести: оптимизация — победа и сильная строчка в резюме, а не минус. Отставание на год — вот это минус.
- 04
Технический долг растёт быстрее
AI может всё сделать хорошо, но ему нужно об этом сказать. Без правильных скиллов и ревью получаем работающий, но небрежный код. Особенно у слабых мидлов — они не увидят проблему.
Что не зависит от сценария
Прямые решения — что делаем независимо от того, как сложится трансформация.
- →Найм меняетсяИщем фича-оунеров, не стек-разработчиков
- →Свободные мощностиТехдолг, эксперименты, новые направления — не «пилим всё что можно»
- →Метрики — реальныеLead time, частота релизов, частота инцидентов. Не «у нас 80% сотрудников использует AI»
- →Единый владелец методологииCTO или сильный лид. Иначе — дрейф
Это рабочий документ. Версии будут обновляться по мере накопления опыта. Текущая — v0.1, обновлено 2026-05-10.