Команда, ориентированная на ИИ: понятный план внедрения на 90 дней

Почему первые недели кажутся хаотичными

Первые несколько недель часто одновременно быстрее и хуже. Ассистент на базе ИИ может превратить задачу на два часа в задачу на двадцать минут, но команде всё равно нужно проверять код, тестировать изменения и передавать работу по старым правилам. Производительность растёт сразу. Привычки команды — нет.

Эта разница создаёт трение. Люди пишут больше кода, чем команда успевает безопасно проверить, поэтому мелкие ошибки накапливаются в ревью. Продакт-менеджер видит больше pull requestов. Техлид замечает больше неопределённости. Оба правы.

Дополнительные инструменты ухудшают ситуацию быстро. Команда добавляет один инструмент для генерации кода, один для резюме pull requestов, один для тестов и один для чата. Скоро никто не понимает, какой инструмент для чего. Разработчики тратят время на сравнение ответов, повторные запросы или исправление странного кода, который сначала выглядел нормально.

Хаос обычно проявляется в нескольких местах:

• Pull requestы растут в размерах, потому что с ИИ широкие изменения кажутся дешёвыми.
• Очередь ревью замедляется, потому что ревьюверы проверяют больше строк, а не лучшие изменения.
• Ответственность расплывчата, когда несколько людей трогают код, сгенерированный ИИ, но никто не принимает окончательное решение.
• Тесты отстают, потому что прирост скорости кажется приятным и проверка пропускается.

Отсюда и начинается стресс — с вопроса ответственности. Если баг проскочил, команде нужен простой ответ: владеет кодом разработчик, который открыл pull request, даже если ИИ написал половину. Без этого правила старшие инженеры становятся узким местом, младшие ждут слишком долго, а дефекты переходят в споры.

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

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

Выберите небольшой стартовый стек

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

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

Сохраните путь доставки стабильным. Используйте текущий репозиторий, текущий CI-пайплайн и текущий процесс тикетов, если только что-то уже не сломано. Знакомые рельсы важнее блестящих новинок. Инженерам проще тестировать ИИ, когда pull requestы, ветки и шаги деплоя по-прежнему выглядят привычно.

Лучше начинать с небольшого объёма работ. Начните с unit-тестов для существующего кода, безопасных рефакторов в спокойных местах, внутренней документации, заметок по миграциям и повторяющегося шаблонного кода. Эти задачи полезны, легко проверяются и недороги в откате. Они также быстро показывают, экономит ли команда реальное время или просто создаёт больше правок для ревьюверов.

Запишите, что пока менять не будете. Этот список важен. Например, можно решить не позволять ИИ править миграции продакшен-базы, логику аутентификации, код биллинга или скрипты деплоя в первый месяц. Чёткие ограничения предотвращают неловкие споры в pull requestах.

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

Установите правила для кода, написанного с помощью ИИ

Быстрые команды делают использование ИИ рутинным и отслеживаемым. Если инженер не может объяснить, что написал инструмент, такой код не должен попадать в репозиторий.

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

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

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

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

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

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

Стройте ревью вокруг уровня риска

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

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

Разделите ревью по уровню риска

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

Одно правило помогает больше, чем команды ожидают: держите pull requestы, созданные с помощью ИИ, маленькими. Установите лимит размера до начала развёртывания. Для многих команд это значит — одна ясная задача на PR, а не пять разных изменений в одном пакете. Если diff слишком большой, чтобы прочитать его за 10–15 минут, разбейте его.

Ревьюверы должны смотреть дальше стиля и задавать прямые вопросы:

• Соответствует ли изменение тикету или оно только похоже?
• Какие пограничные случаи могут привести к ошибке в реальной эксплуатации?
• Что произойдёт при плохом вводе, повторных попытках или частичном успехе?
• Можно ли легко откатить изменение, если в продакшне что-то пойдёт не так?
• Затронул ли ИИ файлы вне заявленного объёма?

Простой пример показывает важность этого. Если ИИ обновляет flow логина и одновременно редактирует session storage, шаблоны писем и миграцию в одном PR, код может пройти проверки и скрывать реальный риск. Разбейте это на отдельные изменения и проверьте аутентификацию и миграцию вручную.

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

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

Добавляйте тестирование в правильном порядке

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

Начните со smoke-тестов для этих потоков и держите их компактными. Если пара проверок говорит, что приложение открывается, пользователь может войти, платёж проходит и деплой не ломает продакшн, вы уже убрали много риска.

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

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

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

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

Нестабильные тесты наносят реальный вред. Они замедляют слияния, вызывают споры и учат людей нажимать rerun до зелёного статуса. Держите их вне основной ветки. Карантиньте, исправляйте быстро или удаляйте, если они не тянут на свою пользу.

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

Порядок внедрения на 90 дней

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

Дни 1–14 — настройка. Выберите инструменты, которыми команда действительно будет пользоваться, напишите короткие правила для запросов, ответственности за код и безопасности, и прогоните одну общую тестовую задачу от начала до конца. Возьмите что-то обыденное, например добавление небольшого API-эндпоинта или чистку формы, чтобы люди сравнивали результаты, а не спорили о масштабе.

Дни 15–30 — безопасная работа. Разрешите инженерам использовать ИИ при исправлении багов с ясными шагами, для внутренних инструментов и небольших рефакторов. Держите биллинг, аутентификацию и глубокие архитектурные изменения вне зоны на данный момент. Цель — понять, где инструмент помогает, не подвергая важный код риску.

К 31–60 дню процесс должен получить чёткие проверки. Добавьте шаблон ревью с простыми вопросами: что сгенерировал ИИ? что изменил инженер? какие тесты покрывают изменение? что может пойти не так в продакшне? Поставьте тестовые препятствия в CI и введите лимиты использования, если люди начинают вставлять большие файлы или принимать код, который не прочитали внимательно.

Дни 61–90 — время расширять использование ИИ за кодом. Команды часто получают хорошие результаты от помощи в планировочных заметках, черновиках документации, чек-листах миграций и инструкциях для онколла. Когда команда доверяет правилам, ИИ может делать первый набросок, а инженеры сохраняют суждение.

Проводите 15-минутный еженедельный чек на протяжении всего внедрения. Отслеживайте сбежавшие дефекты, время от тикета до мержа и уровень стресса команды. Если дефекты растут или люди устают, приостановите внедрение на неделю и исправьте слабое место перед дальнейшим расширением.

Простой пример команды

Небольшая SaaS-команда — хороший пример. В ней три инженера, один основатель, который всё ещё пишет код, и один старший разработчик, который проверяет почти каждый pull request. Этот ревьюер — узкое место, и все это знают.

Они не начинают с того, чтобы давать ИИ самые сложные части продукта. В первые две недели используют его для багфиксов, написания тестов, небольших рефакторов и уборочной работы, которую никто не любит делать вручную. Старые вспомогательные функции получают понятные имена. Появляются недостающие unit-тесты. Небольшие баги в UI исправляются быстрее.

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

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

Команда приостанавливается на день и пересматривает правила:

• Один pull request — одна цель.
• Никаких изменений базы данных, созданных ИИ, без ручного дизайна и ревью.
• Каждый PR с участием ИИ требует короткого резюме от человека.
• Тесты должны приходить вместе с кодом, а не позже.

К шестой неделе настроение спокойнее. Pull requestы мельче. Комментарии в ревью короче. Ревьюер теперь проверяет риск, а не шум из форматирования или отсутствующих тестов. Команда также понимает, что ИИ делает хорошо, а что всё ещё требует аккуратной человеческой работы.

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

Ошибки, которые замедляют команды

Большинство задержек не из-за модели, а из-за плохих практик внедрения. Команда может потерять две недели, просто добавив помощник для кода, генератор тестов и агент в одном спринте.

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

Ещё одна опасная ошибка: люди мержат код, который не могут объяснить. Если разработчик не может сказать, что делает запрос в БД, зачем нужен retry-loop или что может сломаться в продакшне, такой код не готов. ИИ пишет хороший первый черновик, но человек, который открывает PR, несёт ответственность за каждую строку.

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

Плохие метрики усугубляют это. Количество промптов — показатель тщеславия. То же самое с «часами, сэкономленными», если никто не может связать это с более быстрыми релизами, меньшим числом дефектов или сокращением времени ревью. Измеряйте доставленную работу: закрыто ли больше тикетов в спринте? Упало ли время ревью? Поймали ли тесты проблемы до релиза?

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

Несколько ранних предупреждающих знаков:

• Люди используют разные инструменты ИИ для одной и той же задачи и ничего не сравнивают.
• Pull requestы растут в размерах, потому что «ИИ написал это быстро».
• Вопросы в ревью задают базовые вещи, на которые автор не может ответить.
• Покрытие тестами остаётся прежним, а объём кода растёт.
• Права доступа расширяются, но никто их не аудирует.

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

Быстрые проверки на первый квартал

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

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

• Попросите каждого инженера объяснить, где ИИ помогает, а где ему место — нет. Хорошие ответы конкретные. Черновики шаблонов, суммаризация логов и предложения тест-кейсов — нормальны. Исправления безопасности, расплывчатая продуктовая логика и рискованные миграции требуют жёсткого контроля.
• Проверьте ownership в pull requestах. Каждый PR должен показывать, кто его создал, чем помог ИИ, какие тесты запущены и что ещё требует человеческого взгляда. Если никто не владеет итоговым кодом, баги проскальзывают.
• Убедитесь, что ревьюверы знают, какие файлы требуют особого внимания. Аутентификация, биллинг, права доступа, миграции базы данных, конфигурация инфры и изменения публичного API никогда не должны проходить тем же быстрым ревью, что правка текста или мелкий UI-фикс.
• Наблюдайте CI до мержа, а не после релиза. Он должен ловить известные команде ошибки: линт, проблемы типов, сломанные unit-тесты, провал сборки и несколько базовых интеграционных проверок.
• Сравните скорость с уровнем дефектов. Доставка должна идти быстрее при стабильном количестве багов в продакшне. Если релизы участились, а тикеты поддержки, количество откатов или хотфиксов растут — команда платит за скорость впоследствии.

Один пример упрощает понимание. Если команда мержит на 30% больше работы после добавления помощи ИИ, это звучит хорошо. Если та же команда теперь тратит каждый пятничный день на исправление сломанных тестов и патчинг пограничных случаев в оплате — процесс ещё не работает.

Чище всего выглядит скучный результат. Инженеры знают, когда просить ИИ сделать первый черновик, а когда писать код самим. Ревьюверы замедляются на рискованных файлах. CI блокирует обычные ошибки. Релизы выходят быстрее, и пользователи не замечают дополнительного количества поломок.

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

Что делать после 90 дня

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

Не развертывайте новый процесс сразу для всех команд. Выберите одну команду, один репозиторий и один 30-дневный пилот для следующего шага. Держите объём узким. Узкий пилот показывает, работают ли ваши правила, когда меняются кодовая база, люди или частота релизов.

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

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

• затраты на инструменты и соответствие использования результатам;
• нагрузка ревью, включая время, которое pull requestы проводят в ожидании;
• тренды багов после релиза, особенно повторяющиеся ошибки из кода, сгенерированного ИИ;
• время, потраченное на исправление низкокачественных предложений или переписывание сгенерированного кода.

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

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

Для небольших компаний это часто удобнее делать через fractional CTO, чем нанимать целого руководителя. Oleg Sotnikov at oleg.is работает со стартапами и малыми командами над такими внедрениями, особенно когда нужна практичная адаптация ИИ без лишних инструментов, расходов и процессов.

Если дни с 1 по 90 про обучение, то дни с 91 и дальше про дисциплину. Расширяйтесь шаг за шагом, держите правила в актуальном виде и делайте каждую еженедельную встречу с одной ясной решением.