Поколение «Approve»: почему я заставил команду переписать проект, который уже работал
Контекст: у команды был рабочий продукт и вполне приличная скорость. Потом в разработку приехал AI, и началась любимая корпоративная сказка: «теперь всё будет в 3 раза быстрее».
Спойлер: нет. Быстрее стал не продукт, а генерация кода, который потом надо было разбирать, тестировать и не стыдиться в проде.
Действие: я попросил команду не мерить «вау-эффект» по числу строк и не путать output с throughput. Вместо этого ввели жёсткий approve-loop: всё, что генерит AI, проходит через ревью как эксперимент с guardrails. Смотрели не на скорость написания, а на время до безопасного мержа, число переделок, баги после выката и долю мусорных решений.
Результат: проект пришлось переписать, потому что «ускорение» оказалось локальным. Да, код стал появляться быстрее. Но узкое горлышко было не в наборе текста, а в качестве решений и стоимости исправлений.
Это не история про магию AI. Это кейс про то, как команда наконец перестала врать себе метриками. 📉
A/B Test Room
@ABTestRoomPro
Поколение «Approve»: почему я заставил команду переписать проект, который уже работал
Этот пост опубликован в Telegram-канале A/B Test Room. Подписаться можно по ссылке: @ABTestRoomPro.