«Иногда использую ИИ для кода» и «команда работает по ИИ-нативному процессу» — разные степени зрелости. Первый режим даёт эпизодическую экономию, второй — измеримое ускорение всего цикла. Этот плейбук описывает второй: как выстроить этапы, контрольные точки и правила так, чтобы генерация не разрушала качество.
Принцип: ИИ на каждом этапе, человек на каждом гейте
ИИ-нативность — не «поручить разработку машине», а встроить ИИ в каждый этап с человеческой контрольной точкой. Гейт — момент, где результат проходит проверку и принимается решение. Пропущенный гейт — отложенный баг.
Этап 1. Спека с критериями приёмки
До строчки кода фиксируются критерии: что должно происходить на входах и выходах, какие края обработаны, чем измеряется готовность. Спеку удобно писать с ИИ (диктуете суть — он структурирует и задаёт уточняющие вопросы), но утверждаете её вы. Критерии приёмки потом станут тестами — это главный мост между этапами.
Этап 2. Декомпозиция
Большая задача режется на куски размером «один обозримый коммит». ИИ помогает: опишите фичу и попросите план работ с зависимостями, затем поправьте. Каждый кусок получает свою спеку-миниатюру. Малые порции — не перестраховка, а способ держать проверку дешёвой.
Этап 3. Генерация малыми порциями
Каждый кусок генерируется со ссылкой на критерии: вот спека, вот смежный код, вот края, которые надо обработать. Получили — проверили (читаем, линтер, тесты) — идём дальше. Если модель уходит не туда после двух уточнений, проблема обычно в спеке: вернитесь на этап 1, а не перефразируйте промпт в четырнадцатый раз.
Этап 4. Двойное ревью
Первое ревью может делать ИИ: свежим контекстом проверить обработку ошибок, покрытие, соответствие стилю проекта. Второе — человек: логика продукта, безопасность, архитектура. Автоматический апрув от ИИ не существует; его «выглядит хорошо» — это приглашение посмотреть самому, а не разрешение на мёрж.
Этап 5. Тесты как страховочная сетка
Тесты пишутся до или вместе с кодом — из критериев приёмки этапа 1. Они делают генерацию безопасной: смелые изменения не страшны, когда сетка ловит регресс. Просите ИИ писать тесты на поведение, а не на реализацию, и проверяйте сами тесты тем же ревью.
Этап 6. Документация и передача знаний
ИИ-нативный код чужой руки читается тяжело — если никто не документировал замысел. Финальный штрих каждого куска: краткое описание в докстринге и заметка в общую документацию (что решали, почему так). Это делает силуэт кода понятным даже спустя месяцы.
Метрики пользы
Чтобы понимать, помогает ли процесс: время от задачи до релиза; доля изменений, откатанных после релиза; число итераций «уточнил промпт — переписал»; покрытие тестами. Если после внедрения ИИ метрики не двигаются — проблема в процессе, а не в модели.
Антипаттерны
- Big-bang генерация: тысяча строк за раз, «потом разберёмся».
- Тесты потом. Сначала генерация, тесты «когда-нибудь» — сетки нет, страховки нет.
- Слепое доверие. Ревью сведено к чтению первых строк.
- Стилевой винегрет. Каждый кусок в своём стиле — просите модель следовать конвенциям проекта.
- Секреты в промптах. Ключи и внутренние адреса — вне запросов, всегда.
Ключевые выводы
- Цикл: спека с критериями → декомпозиция → малые порции → двойное ревью → тесты → документация.
- Критерии приёмки из спеки превращаются в тесты — это связывает этапы.
- ИИ-ревью не заменяет человеческого: «выглядит хорошо» от модели — приглашение посмотреть.
- Метрики цикла показывают, работает ли процесс, — без них это вера.
- Документированный замысел спасает читаемость кода чужой генерации.
Что дальше
Тактику проверки сгенерированного кода разбирает «Как проверять ИИ-код: чек-лист перед коммитом», общие навыки — «ИИ-грамотность для разработчиков», подключение внешних систем — «MCP: продвинутые темы».