Как оценивать время ревьюера, когда AI ускоряет разработку программного обеспечения

Почему более быстрый результат не делает delivery дешёвым

AI может быстро подготовить код. Он может написать endpoint, рефакторить модуль или набросать тесты за считанные минуты. Но сам по себе набор текста в коде никогда не был полной стоимостью поставки. Кому-то всё равно нужно решить, подходит ли изменение продукту, защищает ли оно данные и выдержит ли оно реальную нагрузку.

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

Время ревьюера нужно закладывать в бюджет с первого дня. Это не административная работа. Это часть безопасного выпуска программного продукта.

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

Чистый код всё равно может оказаться неправильным кодом. Хороший ревьюер задаёт вопросы, на которые модель сама не ответит. Что будет со старыми записями? Можно ли откатить изменения за десять минут? Кто первым заметит, если всё начнёт падать?

На такие вопросы нужно время, а время стоит денег.

Разрыв между быстрым написанием кода и безопасным выпуском особенно заметен на рискованных изменениях. AI может сгенерировать за день больше кода, чем senior engineer, tech lead или fractional CTO успеют хорошо проверить. Узкое место смещается с создания на принятие решений.

В этом и есть настоящая проблема ценообразования. Код становится дешевле. Решения — нет.

Что на самом деле покрывает человеческое ревью

AI может быстро написать черновик. Но он не может взять на себя риск его выпуска.

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

После того как AI сгенерировал код, кому-то всё равно нужно прочитать изменение в контексте, сравнить его с задачей, проверить крайние случаи, выбрать нужные тесты, решить, как выкатывать, подготовить откат и посмотреть на релиз после деплоя. В lean-команде большая часть этой работы ложится на senior-специалистов.

Поэтому команды так часто недооценивают её. Черновик может занять 15 минут, а staff engineer или fractional CTO всё равно потратит час на ревью миграции базы данных, изменения auth, обновления биллинга или правки инфраструктуры.

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

Возьмём изменение прав доступа для админов. AI может быстро написать код. Но ревьюеру всё равно нужно понять, кто может потерять доступ, какой audit trail останется, как support будет разбирать ошибки и как отменить изменение. Это не «добивка» текста. Это работа, которая не даёт быстрому черновику превратиться в длинный инцидент.

В lean-командах эта работа обычно ложится на одних и тех же людей, поэтому их календари заполняются первыми. Программирование ускоряется, но очередь на ревью никуда не исчезает.

Какие изменения требуют больше времени ревьюера

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

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

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

Короткое изменение заслуживает большего внимания, если оно затрагивает:

• движение денег, например checkout, возвраты, счета, скидки или billing webhooks
• безопасность, например вход в систему, роли, права доступа, токены или secrets
• данные, например миграции, правила удаления, экспорт или настройки хранения
• влияние на клиентов, например регистрацию, доступ к аккаунту, уведомления или повседневные продуктовые сценарии

Если изменение затрагивает две из этих областей, дайте ему вторую пару глаз. Если три — замедлите ревью, даже если diff совсем маленький.

Представьте продуктовую команду, которая использует AI, чтобы обновить один файл в billing service. Патч меняет, как повторяются неудачные платежи. Это может быть всего двадцать строк. Но ревьюеру всё равно нужно прочитать бизнес-правило, проверить крайние случаи, подтвердить логи и убедиться, что support поймёт, что увидят пользователи. На это может уйти час.

А теперь сравните это с десятью правками текста на маркетинговых страницах. Diff больше, но риск ниже. Ревьюер может просмотреть его за несколько минут.

Скрытые зависимости делают ситуацию ещё сложнее. Маленькая правка в auth middleware, налоговой логике или фоновой задаче может отразиться на всём продукте. Считайте время ревью по зоне возможного ущерба, а не по тому, насколько быстро AI написал патч.

Как оценить время ревьюера

Начните с влияния. Перед любой оценкой задайте два вопроса: что изменилось и кто почувствует проблему, если что-то пойдёт не так?

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

Работа с низким риском, например правки текста, лёгкая полировка интерфейса или небольшие внутренние инструменты, часто требует 15–45 минут ревью. Работа со средним риском, например пользовательские сценарии, права доступа, отчёты, интеграции или общая бизнес-логика, обычно занимает 1–3 часа. Работа с высоким риском, например платежи, auth, удаление данных, миграции, инфраструктура или изменения в безопасности, может занять от 4 часов до целого дня.

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

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

Последний пункт важнее, чем многие готовы признать. Ревьюер может потратить 30 минут на первый проход, 25 минут на исправления после комментариев, а потом ещё 20 минут на проверку логов после релиза. То, что выглядело как быстрое ревью, теперь стоит больше часа.

Добавьте запас, чтобы оценка выдержала реальную работу. Для изменений с низким риском часто достаточно около 15 процентов. Для работы со средним или высоким риском безопаснее закладывать 25–40 процентов, особенно если команда трогает старый код, слабые тесты или AI-сгенерированный код, который никто ещё хорошо не знает.

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

Как превратить ревью в статью бюджета

У каждого изменения есть стоимость ревью, даже если большую часть кода сгенерировал AI. Черновик может появиться быстрее, но кому-то всё равно нужно его прочитать, прогнать проверки, поискать побочные эффекты и решить, безопасно ли это выпускать.

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

Достаточно простой модели. Начните с 30–45 минут ревью на каждое изменение. Добавьте ещё час за security- или auth-работу. Добавьте ещё 1–2 часа за платежи, миграции данных или production-инфраструктуру. Если ревьюер отправляет изменение на доработку и должен проверить его ещё раз, добавьте ещё 15–30 минут на второй проход.

Сделайте этот второй проход видимым. Он съедает больше времени, чем команды ожидают, особенно когда AI позволяет отправить черновик до того, как его нормально протестировали.

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

Если один senior-специалист проверяет большую часть рискованной работы, этот подход защищает и его время. Это особенно важно, когда lead engineer или fractional CTO отвечает за финальное одобрение production-изменений.

Простой пример из небольшой продуктовой команды

Представьте стартап с тремя инженерами и одним product manager. Им нужно изменить логику биллинга до следующего цикла продления. Цель звучит просто: если клиент продлевает подписку раньше срока, система должна продлить доступ без двойного списания, а если карта не проходит, grace period всё равно должен действовать.

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

Команда выделяет 45 минут на построчное чтение изменения и на то, чтобы проследить продления, повторные попытки, скидки и изменения тарифов. Потом они тратят ещё час на проверку тест-кейсов и добавление тех, которые AI пропустил, например смены часового пояса, неудачные webhooks, дублирующиеся платежные события и апгрейд клиента в последний день. Затем они тратят 30 минут на подтверждение плана отката, включая то, какой feature flag нужно отключить и как исправить счета, если новая логика сработает неправильно. После прогона в staging с реалистичными клиентскими аккаунтами они используют ещё 15 минут на финальное одобрение.

В сумме это 2,5 часа ревью для одного изменения, и цифра выглядит разумно. Ошибки в биллинге редко остаются маленькими. Один пропущенный крайний случай может за день привести к двойным списаниям, обращениям в поддержку и ручным возвратам.

В lean-команде эту работу часто делает senior engineer. Иногда этим занимается fractional CTO, особенно когда команда работает быстро, но внутри нет глубокого опыта в биллинге. Такое дополнительное ревью стоит денег, но обычно оно гораздо дешевле, чем исправлять сломанный цикл продления.

Именно поэтому время ревьюера должно быть отдельной строкой в бюджете. AI может сократить время сборки вдвое, но человеческий слой по-прежнему несёт на себе основную часть риска.

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

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

Ещё одна распространённая ошибка — считать только часы программирования. AI может быстро сократить время на черновик. Но он не убирает очереди на ревью, переделки, проверку тестов, подготовку релиза и переписку, когда что-то кажется неправильным. Задача, на которую ушло два часа программирования, всё равно может пролежать день в ожидании нужного ревьюера.

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

Команды также создают узкие места, даже не замечая этого. Все работают быстрее, а потом один senior engineer должен в конце недели утверждать самые страшные изменения. Ревью становится поверхностным, срочная работа пролезает без очереди, и люди перестают просить раннюю обратную связь, потому что думают, что она их тормозит.

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

Планирование релиза по той же причине тоже часто пропускают. Код выглядел правильным, тесты прошли, и никому не хотелось делать ещё один шаг. А потом реальные затраты появляются уже после merge: обращения в поддержку из-за крайних случаев, время на откат, срочные исправления вне рабочего времени и потерянное время у product- или operations-команды.

Небольшая команда чувствует это уже за один день. Допустим, AI помогает сгенерировать аккуратное обновление checkout, тесты проходят, и команда вливaет изменения поздно в пятницу. Никто не планирует окно релиза, запасные шаги или то, кто будет следить за платежами после запуска. Редкий налоговый кейс ломается, возвраты растут, и три человека полдня в понедельник всё исправляют. Время на программирование казалось дешёвым. Стоимость поставки — нет.

Быстрые проверки перед релизом

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

Помогает простой ритуал:

• Сначала оцените зону влияния. Если изменение затронуло платежи, вход, данные клиентов, права доступа или основной путь, по которому пользователи регистрируются или покупают, считайте это работой с повышенным вниманием.
• Назначьте одного человека, который принимает финальное решение. Если решение никому не принадлежит, команда скатывается в режим «вроде нормально».
• Оставляйте время на ещё один проход после исправлений. Ревью редко заканчивается первой волной комментариев.
• Записывайте шаг отката до релиза. Команды работают быстрее, когда знают, как аккуратно отступить назад.

Первый пункт недооценивают чаще всего. Маленькое изменение в billing rule или auth flow может быстро подорвать доверие. Ошибка в цвете кнопки раздражает людей. Неудачный платёж или заблокированный аккаунт создаёт обращения в поддержку, возвраты и ночные сообщения.

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

Командам также нужно сознательно закладывать второй проход. Если AI-ассистент обновил checkout-логику, ревьюер заметил проблему с налогами, а разработчик исправил её за десять минут, всё равно нужен ещё один взгляд. Быстрые исправления очень часто создают новые ошибки.

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

Что делать дальше

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

Достаточно простой модели. Разделите работу на несколько уровней риска, задайте ожидаемое время ревью для каждого уровня и используйте одни и те же правила в каждом спринте. Если изменение затрагивает биллинг, auth, права доступа, удаление данных или production-инфраструктуру, закладывайте на него больше времени на ревью ещё до того, как кто-то назовёт задачу завершённой.

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

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

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

Некоторым командам для настройки этого процесса нужна внешняя помощь. Oleg Sotnikov на oleg.is работает со стартапами и небольшими и средними компаниями как fractional CTO и advisor, помогая выстраивать lean-процессы разработки с AI без отказа от человеческих проверок, которые защищают выручку и uptime.

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