Поколение «Approve»: почему я заставил команду переписать проект, который уже работал

Поколение «Approve»: почему я заставил команду переписать проект, который уже работал

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

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

Результат: меньше хаоса, быстрее цикл принятия решений, понятнее P&L по времени команды. Да, переписка проекта стоила недель. Но дальше она сняла постоянный налог на переделки. В баинге это как с кривой связкой: если она дает лиды, но сжирает весь операционный ресурс — ты не масштабируешься, ты тонешь.