Стоимость принятого изменения кода выше стоимости его написания

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

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

Принятое изменение соответствует согласованному результату в продакшене, а его операционные последствия понятны команде. Это определение строже, чем «слито», и полезнее, чем «развернуто». Оно заставляет включить в оценку работу, о которой основатели обычно вспоминают после срыва срока: уточнение требований, исправления после ревью, неудачные сборки, выпуск, подготовку к откату, мониторинг, поддержку и доработки.

Написание кода обычно занимает меньшую заметную часть

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

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

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

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

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

Сначала определите единую точку завершения

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

Для обычного изменения в продакшене я использую такую точку завершения:

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

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

Здесь же командам нужны классы изменений. Не сравнивайте исправление текста с низким риском и миграцию схемы, а затем не называйте их среднее значение метрикой продуктивности. Начните с четырех практичных классов:

• обычное поведение продукта без миграции данных
• поведение интеграции или API
• инфраструктурные задачи и задачи надежности
• изменения, связанные с деньгами, правами доступа или необратимыми последствиями для данных

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

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

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

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

Для каждого принятого изменения используйте формулу:

accepted_change_cost =
  specification_cost
+ implementation_cost
+ review_and_repair_cost
+ ci_cost
+ deployment_and_verification_cost
+ rollback_preparation_cost
+ support_and_rework_cost
+ shared_delivery_overhead

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

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

Минимальную запись можно хранить в таблице, таблице хранилища данных или небольшом внутреннем сервисе:

change_id, class, outcome,
spec_minutes, build_minutes, review_minutes, repair_minutes,
ci_runs, ci_runner_cost, ci_investigation_minutes,
deploy_minutes, verification_minutes, rollback_minutes,
support_minutes, rework_minutes, elapsed_hours

Добавьте assistant_mode со значениями вроде none, drafting, test_generation или agent_workflow. Не используйте этот столбец для оценки отдельных инженеров. Он нужен, чтобы сравнивать один и тот же класс работы в разных режимах доставки.

Вот пример с намеренно простыми числами. Продакт-менеджер тратит 30 минут на уточнение области работ. Инженер тратит 90 минут на реализацию и тестирование. Ревьюер тратит 25 минут, а инженер еще 20 минут отвечает на замечания. Конвейер занимает 18 минут времени раннера, затем нестабильный интеграционный тест требует 15 минут на расследование и повторный запуск. Развертывание и проверки в продакшене занимают в сумме 30 минут. Инженер поддержки тратит 20 минут на ответ клиенту из-за изменившегося значения по умолчанию. На общие системы команда распределяет небольшую стоимость на каждое изменение.

Кандидатный код занял 90 минут. Принятое изменение потребовало 230 активных минут человеческого труда, не считая стоимости общей инфраструктуры. Если ассистент сократил реализацию с 90 до 45 минут, но создал дополнительный цикл ревью и еще одно расследование нестабильного теста, стоимость изменения не уменьшилась вдвое. Уменьшилась одна составляющая, а другая могла вырасти.

Именно такое сравнение нужно основателям. Оно превращает инвестиции в ассистента в вопрос экономики доставки, а не в соревнование демонстраций.

Работу над спецификацией нельзя делегировать автодополнению

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

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

Поместите в начало задачи или pull request небольшой контракт изменения:

Intent: Existing workspace owners can set a default export format.

Must remain true:
- Existing API clients receive the current format unless an owner changes it.
- Members cannot change the workspace default.
- A failed export does not alter the saved default.

Evidence after release:
- Successful export rate stays within the normal range.
- Permission-denied responses do not increase.

Rollback condition:
- Revert the application release. The migration only adds a nullable column.

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

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

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

Ревью это цикл контроля, а не формальное одобрение

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

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

Ревьюерам стоит задать пять конкретных вопросов:

• Соответствует ли изменение заявленному контракту, включая то, что должно остаться без изменений?
• Не вышел ли патч за пределы запроса?
• Могут ли тесты упасть из-за нужного нам дефекта, или они лишь повторяют предположения кода?
• Соответствует ли операционное поведение плану выпуска и отката?
• Сможет ли сопровождающий понять и изменить это через полгода?

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

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

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

CI входит в стоимость изменения, даже если раннер почти ничего не стоит

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

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

Фиксируйте CI в трех категориях:

1. Стоимость выполнения: минуты раннера, хранилище и платные внешние проверки.
2. Стоимость работы людей: время на чтение ошибок, повторные запуски, исправление тестов и настройку конвейера.
3. Стоимость пробела в уверенности: дефекты в продакшене, которые прошли CI, потому что проверки не охватили нужное поведение.

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

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

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

Отслеживайте долю сбоев CI, вызванных дефектами продукта, тестов, среды и конфигурации. Если преобладают проблемы среды и тестов, у команды проблема в системе доставки, а не в дисциплине разработчиков.

Развертывание и откат требуют проектных решений

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

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

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

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

До выпуска план отката должен отвечать на такие вопросы:

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

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

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

Поддержка показывает качество доставки

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

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

Обращения в поддержку показывают затраты, которые ревью и CI часто не видят:

• пользователи неправильно поняли новое значение или элемент управления по умолчанию
• потребитель API без документации зависел от старого поведения
• медленный путь проявился только на реальных размерах аккаунтов
• сработало оповещение, но в нем не хватило контекста для определения измененного выпуска
• выпуск создал работу для операционной или финансовой команды

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

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

Сравнивайте разработку с ассистентом по одному стандарту принятия

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

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

Для каждого класса рассчитайте по выборке завершенных изменений такие показатели:

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

Медиана часто честнее среднего: небольшое число крупных инцидентов может исказить среднее значение. Но выбросы нужно сохранять. Именно в выбросах часто проявляется серьезная конструктивная проблема процесса доставки.

Затем изучите изменение стоимости по этапам. Если помощь ассистента сокращает реализацию на 40 минут, но исправления после ревью растут на 30 минут, а поддержка еще на 20, команда не получила дополнительную производительность. Если тот же ассистент сокращает реализацию, уменьшает исправления CI благодаря лучшим тестам, а доработки в продакшене остаются на прежнем уровне или снижаются, это настоящее улучшение.

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

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

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

Постройте систему измерений на уже имеющихся свидетельствах

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

Выберите сочетание разных классов изменений. Для каждого попросите ответственного ретроспективно оценить активные усилия широкими диапазонами: меньше 30 минут, от 30 до 90 минут, от 90 минут до половины дня, от половины дня до дня и больше дня. Этого достаточно, чтобы увидеть, куда уходят деньги, и это создает меньше ложной точности, чем записи по семь минут.

После восстановления опубликуйте для руководства результат на одной странице:

• медианная стоимость принятого изменения по классам
• активные усилия по этапам доставки
• время ожидания по этапам доставки
• три главные повторяющиеся причины доработок
• одно ограничение, которое мешает безопасно ускорить доставку

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

Аудит Team & AI полезен, когда свидетельства разбросаны по разным инструментам, а люди не могут договориться, куда исчезает время доставки. Результатом должна стать модель затрат, привязанная к вашему реальному пути доставки, а не общее заявление о том, что ассистенты быстрее пишут код.

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