# Затраты на автономное программирование должны окупаться > Затраты на автономное программирование экономят деньги лишь до измеримого предела. Рассчитайте его по принятым изменениям, проверкам, повторам и зарплатам. Автономное программирование экономит деньги, только когда стоимость принятых изменений, пригодных для продакшена, ниже стоимости тех же результатов, которые дает команда без агентов. Сами по себе расходы на токены почти ничего не говорят. Дешевый агент, после которого остаются отклоненные патчи, длинная очередь на проверку и исправления, может обойтись дороже дорогого агента, который вносит чистые изменения. Полезный показатель - не стоимость токена, задачи, пул-реквеста или запуска агента. Считать нужно полную дополнительную стоимость принятого изменения и сравнивать ее с затратами на труд, от которых бизнес действительно избавился. Я видел, как основатели радовались небольшому счету за модель, пока старшие инженеры тратили половину недели на разбор результатов ее работы. Видел и обратное: большой счет за инференс полностью оправдывал себя, потому что два инженера выполняли работу, для которой раньше требовалась гораздо более крупная команда. Границу можно рассчитать до споров о моделях. Нужны пять исходных показателей: принятые изменения, часы проверки людьми, повторные попытки, расходы на инференс и сэкономленный фонд оплаты труда или рабочие часы. Еще нужны единый период наблюдения и правило учета дефектов. Без них таблица поощряет активность и прячет дорогие части процесса. ## Точка окупаемости начинается с альтернативного сценария Точка окупаемости сопоставляет два реалистичных способа выполнить один и тот же объем работы одного класса. С одной стороны находится базовый процесс без автономного программирования. С другой - процесс с агентами, включая все человеческие и машинные затраты, без которых изменения не попадут в продакшен безопасно. Если стороны дают несопоставимые результаты, расчет превращается в спектакль. Выберите период, обычно месяц или скользящий квартал. Запишите базовую стоимость принятых изменений при работе людей, обычных инструментов и прежнего процесса. Затем запишите новую стоимость: зарплаты оставшихся инженеров, инференс модели, инфраструктуру агентов, проверку людьми, потери на повторных попытках и последствия ошибок в изменениях. Разница и будет экономией. Альтернативный сценарий должен описывать выбор, который компания действительно могла сделать. Фонд оплаты труда за прошлый год подходит как база, если объем и содержание работы остались похожими. План найма подходит, когда автономное программирование позволяет не открывать уже утвержденные вакансии. Оценка в часах подходит для проекта, который иначе отдали бы агентству. Не сравнивайте текущий счет с выдуманной командой из десяти человек, которую никто не собирался нанимать. Сэкономленные затраты бывают двух видов. Экономия на фонде оплаты труда - деньги, которые компания перестала платить или не начала платить после смены рабочей модели. Экономия рабочего времени - часы, которые действующие сотрудники могут потратить на другие задачи. Первый вид прямо влияет на денежный поток. Второй имеет экономический смысл, только если освободившееся время дает полезный результат, устраняет реальное узкое место или позволяет отказаться от найма. Если назвать каждый сэкономленный час денежной экономией, результат окажется завышенным. Используйте это месячное уравнение денежных затрат, если изменился штат или расходы на подрядчиков: ```text net_savings = baseline_delivery_cost - current_human_cost - inference_cost - agent_infrastructure - failure_and_recovery_cost ``` В этом расчете не добавляйте зарплату проверяющих второй раз, если она уже входит в current_human_cost. Часы проверки полезны как рабочий показатель, но отдельный учет и зарплаты, и тех же часов дважды спишет стоимость одного труда. ## Знаменателем служит принятое изменение Принятое изменение проходит обычные проверки команды, сливается с основной веткой, попадает в нужное окружение и выдерживает заданный период наблюдения без отката или существенных исправлений. Точный срок зависит от частоты развертываний и риска, но правило нужно записать до начала измерений. Пул-реквест, открытый агентом, пока остается запасом незавершенной работы, а не ценностью. Даже простое число принятых изменений может ввести в заблуждение. Переименование переменной и замена платежного процесса считаются одним слиянием каждое. Если состав работ сильно меняется от базового к измеряемому периоду, разделите задачи на несколько устойчивых классов: небольшое обслуживание, обычное продуктовое изменение и изменение с высоким риском. Сравнивайте затраты внутри класса или заранее назначьте простые веса, с которыми согласна команда. Не используйте строки кода в знаменателе. Агенты генерируют их дешево, а крупные изменения часто требуют больше времени на проверку. Оценки в условных баллах тоже плохо подходят для сравнения периодов, если команда меняет подход к оценке. Принятые изменения несовершенны, но они связывают активность с контрольной точкой, где бизнес получает поддерживаемое ПО. Для практической записи о приемке достаточно нескольких полей: - идентификатор изменения и класс работы - время первого запуска агента и время слияния - стоимость инференса для всех попыток - время проверки и исправлений человеком - состояние развертывания после периода наблюдения Считайте отмененное изменение отклоненным, пока его замена не выдержит тот же период. Если агент создал три пул-реквеста, а принят только третий, запишите одно принятое изменение и привяжите к нему все три попытки. Так активный агент не сможет выглядеть продуктивным за счет множества артефактов. Некоторые команды боятся, что такое определение несправедливо к экспериментам. Это нормальная строгость. У экспериментов есть бюджет, и они могут приносить знания, но их нельзя включать в заявление об экономии на продакшене, если базовый сценарий не содержит сопоставимой экспериментальной работы. Ведите отдельный журнал исследований и прямо указывайте его назначение. ## Выберите один способ учета до сложения затрат Учет по фонду оплаты труда отвечает на вопрос, снижает ли новая рабочая модель общие расходы на разработку. Учет на единицу результата показывает, приносит ли следующее принятое изменение положительный вклад после переменных затрат. Нужны оба взгляда, но смесь отдельных частей дает ложный результат. Расчет по фонду оплаты труда лучше подходит основателю, который решает, нанимать ли людей, сокращать ли подрядчиков или менять структуру команды. Начните с базового фонда оплаты труда со всеми начислениями и расходов на подрядчиков. Вычтите текущий фонд, постоянную инфраструктуру агентов, устранение последствий ошибок и инференс. Остаток определит предельные расходы на инференс: ```text maximum_monthly_inference = baseline_delivery_cost - current_human_cost - agent_infrastructure - failure_and_recovery_cost - required_savings_margin ``` Допустим, реалистичный базовый сценарий стоит $180 000 в месяц, а нынешняя команда - $75 000. Инфраструктура агентов обходится в $15 000, а инциденты и восстановление после изменений агентов - в $8 000. Без обязательного запаса экономии инференс может вырасти до $82 000, прежде чем денежная выгода исчезнет. Если руководство требует экономить $30 000 в месяц ради оправдания риска перехода, предел снизится до $52 000. Учет на единицу лучше подходит для выбора моделей, уровня автономности или класса задач. Оцените базовую стоимость человеческого труда на одно принятое изменение. Вычтите проверку, исправления человеком, ожидаемую стоимость ошибок, переменную инфраструктуру агентов и инференс для этого изменения. Остаток будет вкладом в покрытие затрат. Затем постоянные расходы определят, сколько принятых изменений нужно получить, чтобы месяц стал прибыльным. Не включайте весь текущий фонд оплаты труда в расчет на единицу и одновременно не оценивайте каждый час проверки, если только вы намеренно не распределяете зарплату по видам деятельности. Не заявляйте экономию фонда в денежном расчете, а затем не добавляйте стоимость освободившихся часов тех же людей. Выберите подход под конкретный вопрос, запишите свой выбор и сверяйте два расчета в конце периода. ## Повторные попытки относятся к выжившему изменению Каждая неудачная попытка входит в стоимость получения принятого изменения. Сюда относятся вызовы модели, завершившиеся по тайм-ауту, патчи, отклоненные тестами, циклы из-за нехватки контекста, брошенные ветки и запуски, которые человек остановил из-за неверного направления работы агента. Учет только последнего успешного запуска равносилен тому, как если бы завод игнорировал брак. Привязывайте повторы к рабочей задаче. Складывайте входные и выходные токены, плату за кэш, отдельно оплачиваемые вызовы инструментов и комиссии конкретной модели по всем попыткам. Если повтор не помог получить принятое изменение, отправьте его стоимость в категорию неуспешной работы. В конце месяца распределите ее по принятым изменениям или покажите отдельно в общем расчете. Не удаляйте эти расходы. Одной частоты повторов недостаточно, потому что цена попыток различается. Отслеживайте долю стоимости повторов: ```text retry_cost_ratio = inference_cost_before_final_attempt / total_inference_cost ``` Также отслеживайте долю принятых результатов: ```text acceptance_yield = accepted_changes / work_items_started ``` Система может делать много дешевых повторов и работать хорошо. Может произойти и одна огромная повторная попытка с избыточным контекстом, которая испортит всю экономику. Денежная оценка связывает поведение с решением лучше, чем число попыток. Популярный совет отправлять почти все задачи самой дешевой модели ради сокращения расходов часто ошибочен. Он популярен, потому что тариф виден в счете и легко сравнивается. Если дешевая модель увеличивает время проверки, раздувает циклы повторов или создает изменения, которые ломаются позже, стоимость принятого изменения растет. Выбирайте маршрутизацию по полной стоимости для класса работ, а не по цене за миллион токенов. Задайте жесткий бюджет для каждой рабочей задачи, но не считайте лимит способом оптимизации. Лимит ограничивает потери при поломке цикла. Полезным средством управления станет правило эскалации: после известного вида сбоя нужно дать недостающий контекст, сменить модель, сузить задачу или передать ее человеку. Бездумное повторение того же запроса по более низкой цене все равно остается растратой. ## Проверка человеком может уничтожить выгоду Время проверки обычно первым среди скрытых расходов перекрывает экономию от инференса. Старшие инженеры стоят дорого, а автономная работа может перевести их от реализации к диагностике. Агент создает патч за четыре минуты, но проверяющий тратит два часа, чтобы восстановить замысел, найти опасное допущение и запросить несколько исправлений. Измеряйте активное время проверки, а не промежуток между открытием и слиянием пул-реквеста. Учитывайте чтение, локальные тесты, комментарии, исправление результата агента и проверку новой версии. Время ожидания держите отдельно: оно влияет на продолжительность цикла, но не расходует рабочие часы. Простой таймер или короткое поле, заполняемое при слиянии, надежнее просьбы вспомнить весь месяц задним числом. В расчете на единицу используйте полную часовую стоимость труда. В нее входят зарплата, налоги на фонд оплаты труда, льготы и принятая в компании доля накладных расходов. Не придумывайте универсальный коэффициент. Число должен дать финансовый отдел, причем одно правило нужно применять и к базовой реализации, и к текущей проверке. Сокращать проверку можно лишь до определенной границы. Для знакомых изменений с низким риском тесты и узкий объем задачи уменьшают работу проверяющего. На границах безопасности, при миграции данных, в платежной логике и необратимых операциях сокращение проверки может лишь перенести расходы в инциденты. Цель не в минимальном внимании человека. Нужен наименьший объем внимания, при котором ожидаемая стоимость ошибок остается в пределах допуска компании. Отслеживайте медианное время проверки по классу работ и дорогой хвост распределения. Среднее значение скрывает патч, который отнимает целый день. Я использую 90-й процентиль как диагностический показатель, даже когда финансовая модель считает общее число часов: растущий хвост часто выдает нехватку контекста, плохие границы задач или уровень автономности, который репозиторий пока не выдерживает. Учитывайте подготовку, без которой проверка невозможна. Если инженер приводит ветку в порядок, перезапускает нестабильный тест, восстанавливает пропущенную миграцию или пишет пояснение, потому что агент не объяснил решение, это время относится к изменению. Команды часто записывают лишь минуты внутри окна проверки. В итоге проверка выглядит дешевой, а та же работа проявляется как необъяснимое падение доступной мощности инженеров. Загрузка проверяющего меняет денежный смысл этих часов. Если компания платит фиксированную зарплату, а у инженера есть свободное время, дополнительный час не создает немедленного денежного платежа. Но он занимает мощность и может задержать более выгодную работу. Если проверка ведет к переработкам, помощи подрядчика или еще одному найму, денежный эффект становится прямым. Измеряйте часы одинаково, а способ учета определит их оценку. К доле одобрений нужна та же доля скепсиса, что и к числу принятых изменений. Высокая доля может говорить о хорошем результате агентов или о том, что проверяющие стали снисходительнее под давлением очереди. Сопоставляйте ее с расходами на восстановление, числом откатов и временем проверки по классам работ. Если одобрений становится больше, проверка сокращается, а восстановительных работ прибавляется, процесс, скорее всего, убрал контроль, а не лишнюю работу. Время проверки также показывает, когда организация переместила узкое место вместо его устранения. Если агенты создают изменения быстрее, чем квалифицированные специалисты принимают их, работа накапливается, ветки устаревают, а конфликты растут. Дополнительный инференс тогда покупает новую очередь, а не поставку изменений. Не увеличивайте параллелизм, пока число принятых изменений не растет без сопоставимого увеличения часов проверки. ## Расходы на качество приходят после счета за модель Слитое изменение еще не заслужило записанной экономии, если оно вызывает откат, обращения в поддержку, устранение уязвимости или внеплановые доработки. Расходы на качество отстают от инференса, поэтому панель за текущий день всегда приукрашивает автономность. Задайте период наблюдения и исправляйте учет, когда проявляются поздние сбои. Ожидаемая стоимость ошибки подходит для редких, но существенных инцидентов: ```text expected_failure_cost_per_change = failure_probability * average_recovery_cost ``` Оцените обе величины по собственным данным и разделите их по классам работ. Включите время инженеров на восстановление, срочные расходы на подрядчиков, компенсации или прямое возмещение клиентам, если финансовый отдел может их отнести к инциденту, а также стоимость заменяющего изменения. Не придумывайте денежную цену репутации ради красивой полноты формулы. Опишите рядом риски, которым не назначили цену. Рассмотрим знакомый сбой. Агент обновляет проверку прав и создает аккуратное изменение. Тесты проходят, потому что тестовые данные охватывают вошедших и не вошедших пользователей, но не доступ между разными клиентами системы. Проверяющий просматривает небольшой патч за двенадцать минут и одобряет его. Через два дня обращение в поддержку запускает расследование, два инженера прерывают плановую работу, команда откатывает изменение, пишет недостающий тест, исправляет код и снова его проверяет. Исходный учет показывал одно дешевое принятое изменение. Исправленный учет содержит отклоненную попытку, стоимость ее инференса и проверки, труд по восстановлению и одно принятое позже заменяющее изменение. Здесь важно различать синтаксическую и экономическую приемку. Слияние доказывает лишь то, что процесс пропустил изменение. Экономическая приемка означает, что изменение дало нужный результат без расходов, отменяющих заявленную экономию. Команды, которые смешивают эти понятия, ускоряют поток одобрений и одновременно накапливают исправления. Не нужно ждать несколько месяцев, чтобы получить хоть какие-то выводы. Используйте короткий предварительный срок для обычных изменений и более долгую проверку для отсроченных эффектов, а последний период помечайте как незавершенный. Финансовые специалисты давно умеют учитывать начисления и поздние корректировки. Экономика разработки требует такой же честности. ## Предел расходов меняется вместе с объемом Максимально допустимые расходы на инференс не могут быть одним постоянным числом для всей компании. Они зависят от объема принятых изменений, состава работ, времени проверки, постоянных расходов на платформу и объема труда, от которого компания действительно отказалась. Модель может приносить выгоду при 120 принятых изменениях в месяц и давать убыток при 50, потому что постоянные расходы распределяются на меньшее число результатов. Возьмем условный расчет на единицу. До автономной работы обычное продуктовое изменение требует 6,5 часа инженера по полной ставке $140, поэтому базовая стоимость труда равна $910. С автономной работой каждое принятое изменение потребляет инференс на $185, требует 1,4 часа проверки стоимостью $196 и несет ожидаемые восстановительные расходы $35. Месячная инфраструктура агентов стоит $24 000. Вклад одного принятого изменения до постоянных расходов равен $494: ```text 910 baseline labor - 185 inference - 196 review - 35 expected recovery = 494 contribution before fixed cost ``` Системе нужно 49 принятых изменений для покрытия постоянных расходов $24 000, потому что 24 000, разделенные на 494, дают 48,6. При 120 принятых изменениях вклад после постоянных расходов равен $35 280. Этот пример не обещает таких показателей каждой команде. Он точно показывает, куда подставлять местные данные. Теперь найдем предельные расходы на инференс вместо использования фиксированной цены модели. При 120 принятых изменениях доля постоянных расходов составляет $200 на изменение. Базовая ценность равна $910, проверка стоит $196, а ожидаемое восстановление - $35. Поэтому максимальный инференс равен $479 на принятое изменение, или $57 480 в месяц. Расходы выше этой границы уничтожат всю рассчитанную экономию. При 50 принятых изменениях доля постоянных затрат вырастает до $480 на изменение. Предел инференса падает до $199 на принятое изменение, или $9 950 в месяц. Финансовый отдел, который посмотрит только на предел денежного учета $82 000 из другого сценария, может утвердить слишком много. Рабочий расчет на единицу объясняет, почему объем и доля принятых результатов так важны. Считайте несколько диапазонов чувствительности вместо спора вокруг одного прогноза. Найдите результат при ожидаемой, слабой и высокой доле приемки, затем меняйте часы проверки и стоимость восстановления. Если небольшое изменение одного допущения убирает экономию, система неустойчива. Сохраняйте узкие границы автономности, пока наблюдаемое распределение не станет лучше. ## Небольшой калькулятор делает решение проверяемым Калькулятор ниже использует учет на единицу и выводит нужные основателю показатели: вклад до постоянных расходов, число принятых изменений для их покрытия, общий предел инференса при наблюдаемом объеме и чистую экономию. Замените исходные числа примером одного класса работ из собственного журнала. ```python from math import ceil accepted_changes = 120 baseline_hours_per_change = 6.5 loaded_hourly_cost = 140 review_hours_per_change = 1.4 repair_hours_per_change = 0.25 inference_per_accepted_change = 185 fixed_monthly_agent_cost = 24000 required_monthly_savings = 0 baseline_value = baseline_hours_per_change * loaded_hourly_cost review_cost = review_hours_per_change * loaded_hourly_cost repair_cost = repair_hours_per_change * loaded_hourly_cost non_inference_variable = review_cost + repair_cost contribution_before_fixed = ( baseline_value - non_inference_variable - inference_per_accepted_change ) if contribution_before_fixed <= 0: break_even_changes = None else: break_even_changes = ceil( (fixed_monthly_agent_cost + required_monthly_savings) / contribution_before_fixed ) inference_ceiling_total = max( 0, accepted_changes * (baseline_value - non_inference_variable) - fixed_monthly_agent_cost - required_monthly_savings ) actual_inference_total = ( accepted_changes * inference_per_accepted_change ) net_savings = ( accepted_changes * baseline_value - accepted_changes * non_inference_variable - actual_inference_total - fixed_monthly_agent_cost ) print({ 'contribution_before_fixed': contribution_before_fixed, 'break_even_changes': break_even_changes, 'inference_ceiling_total': inference_ceiling_total, 'actual_inference_total': actual_inference_total, 'net_savings': net_savings, }) ``` С исходными данными из примера результат имеет такую структуру и значения: ```text {'contribution_before_fixed': 494.0, 'break_even_changes': 49, 'inference_ceiling_total': 57480.0, 'actual_inference_total': 22200, 'net_savings': 35280.0} ``` Калькулятор предполагает сопоставимую базовую ценность каждого принятого изменения. Если допущение не выполняется, запускайте его отдельно для разных классов работ. В нем также часы исправлений играют роль ожидаемой стоимости качества; когда накопятся данные об инцидентах, замените этот показатель более полной оценкой ожидаемого восстановления. Обязательная экономия должна входить в модель. Компания вправе требовать запас из-за риска перехода, зависимости от одного поставщика или управленческих расходов, которым простой расчет не назначил цену. Нулевое значение required_monthly_savings находит бухгалтерскую точку окупаемости. Минимальная выгода, которую ожидает компания, дает рабочую границу для бюджета моделей. Такую арифметику я применяю в Team & AI Audit на oleg.is: сначала явно определяю границу затрат, а потом проверяю, удержится ли текущий процесс ниже нее. Красивое демо агента не заменит принятых изменений и сверенного учета. ## Управляйте автономностью по кривой, а не по счету Месячный счет за модель показывает прошлые расходы, а кривая стоимости помогает понять, принесет ли следующий доллар принятую работу. Нанесите накопленный инференс и накопленные принятые изменения для каждого класса работ. На той же временной оси добавьте часы проверки. Если инференс растет быстрее приемки или часы проверки загибаются вверх, параллелизм либо автономность вышли за полезный диапазон. Установите бюджеты на трех уровнях. Для каждой рабочей задачи задайте предел потерь, для каждого класса - предел инференса на принятое изменение, для всей программы - месячный предел на основе сэкономленных затрат. Эти ограничения отвечают на разные сбои. Предел задачи останавливает бесконтрольные циклы, предел класса исключает неподходящий сценарий, а месячный предел защищает экономический смысл программы. Сделайте условия остановки конкретными. Приостановите или сузьте класс работ, если его стоимость принятого изменения превышает предел на протяжении двух периодов, если очередь проверки растет при стабильном спросе или если позднее восстановление уничтожает обязательный запас экономии. Возобновляйте работу только после изменения контекста, тестов, маршрутизации, границ задачи или человеческого контроля, которые вызвали убыток. Простое обнуление бюджета запустит тот же сбой снова. Не стремитесь к минимальным расходам на инференс. Более сильная модель может снизить общую стоимость, если ей нужно меньше повторов и проверки. Дополнительный контекст обходится дешево, когда предотвращает неверное архитектурное допущение, и становится растратой, когда каждая попытка заново загружает ненужную историю. Решение нужно принимать на уровне принятого изменения, где сходятся все эффекты. Первый месяц должен дать диапазон, а не победный отчет. Сверьте счета, журналы проверки, принятые изменения и восстановительные работы. Сравните результат с альтернативным сценарием, который финансовый и инженерный руководители согласовали до испытания. Затем финансируйте лишь те классы работ, которые сохраняют запас даже при слабых допущениях. Автономное программирование перестает экономить деньги в тот момент, когда инференс, человеческая работа и последствия ошибок, необходимые для приемки его результатов, поглощают стоимость труда, от которого компания действительно отказалась. Эту точку можно измерить. Если никто не может показать журнал принятых изменений, компания не знает, получила ли она автоматизацию или необычно занимательный счет расходов.