Дешёвый AI-запрос ещё не значит дешёвую задачу
В счёте за AI стало меньше денег. На ревью стало больше работы. Так вполне может выглядеть «оптимизация» расходов на агента.
14 сентября GitHub добавил в Copilot Auto три режима: efficiency, balance и intelligence. Они задают приоритеты стоимости, качества и времени ответа. Обновление постепенно появляется в VS Code, CLI и Copilot app.
Деталь, которую легко пропустить: набор моделей у режимов общий. Auto выбирает модель для каждого запроса, а оплата зависит от выбранной модели. Даже intelligence может отправить простую задачу небольшой модели. Это не закрепление за вами самого мощного варианта.
Как backend-разработчик, я бы оценивал такой переключатель по стоимости доведённой до merge задачи. Вместе с повторными попытками агента и временем человека на исправления. Цена одного ответа мало говорит о том, сколько будет стоить готовое изменение.
Допустим, агент меняет обработчик платежного события в .NET. В диффе несколько строк, но повторная доставка не должна повторно менять баланс. Для выбора модели запрос может выглядеть простым. Для сервиса ошибка обойдётся дорого: сложность кода и цена ошибки не обязаны совпадать.
Я бы начал с небольшого сравнения на закрытых задачах команды. Одни и те же исходные условия, заранее заданные проверки. Отдельно смотреть расходы на модель и время до принятого решения, включая ручные правки. Документацию сравнивать с документацией, обработчики событий - с обработчиками, иначе среднее скроет разницу.
У такого прогона есть предел: удачный результат на прошлых задачах не доказывает безопасность следующего изменения. Для платежей всё равно нужны проверки повторной доставки и конкурентной обработки. Переключатель intelligence их не добавляет.
Мне интересна экономия, при которой инженер тратит меньше времени на задачу целиком. Если сократили счёт провайдера, но добавили вечер отладки, надо учитывать и этот вечер.
Вы уже считаете стоимость принятого изменения с AI или пока смотрите только на расход запросов?
· 30.09
Считать надо, но с оговоркой: стоимость доведенной до merge задачи - метрика задним числом. Она честно покажет прошлые задачи, но не защитит следующую: обработчик платежей из вашего примера выглядит простым ровно до первого инцидента. Поэтому к вашей метрике я бы добавил цену ошибки по типу изменения - для платежей она перекрывает любую экономию на запросах. Режим intelligence не добавляет проверок, верно; но и метрика merge не покажет, что проверки нужны были до, а не после.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён