Amazon призвал своих инженеров не превращать токены ИИ в новый KPI. В служебной записке, опубликованной 27 октября, компания прямо предупреждает: высокий расход токенов ИИ может означать не рост эффективности, а лишние расходы и усложнение кода. Для российских команд, которые сейчас пытаются встроить генеративные инструменты в разработку, это полезное напоминание: считать нужно результат, а не количество запросов к модели.
Как сообщает The Register, письмо инженерным командам подписал вице-президент Amazon и distinguished engineer Терк Терковиц. Он назвал новый ориентир «разработчиком эпохи Ренессанса» — специалистом, который сочетает ИИ-инструменты с профессиональным суждением и знанием предметной области. Но ключевая мысль записки куда приземлённее и важнее красивой формулы: роль инженера не определяется тем, насколько активно он пользуется ИИ.
Amazon не запрещает ассистентов, агентские системы и генерацию кода. Напротив, компания ожидает, что инженеры будут применять их там, где это помогает быстрее доставлять продукт и решать задачи бизнеса. Проблемой назван подход, при котором команда начинает гнаться за самим потреблением модели: генерировать больше кода, запускать больше агентов, отправлять больше контекста — лишь бы показать, что ИИ «внедрён».
Внутри Amazon такое поведение получило название tokenmaxxing — максимизация использования токенов. В записке признают, что у некоторых команд высокий объём работы с моделями совпадал с ростом скорости поставки. Однако совпадение не превращает метрику в цель. Если сделать расход токенов показателем успеха, инженеры получат стимул плодить запросы и сложные цепочки автоматизации даже там, где они не улучшают продукт.
Риски компания формулирует без обиняков: неверно выбранные метрики увеличивают стоимость разработки и добавляют техническую сложность. Для Amazon это особенно чувствительно: её инженерная культура давно опирается на принцип «изобретать и упрощать». Код, который агент сгенерировал за минуты, может оказаться дороже в поддержке, хуже объясняться при инциденте и требовать от команды больше времени на ревью, тестирование и исправления.
Вместо этого Amazon предлагает держаться за неизменные критерии: полезное ПО, результат для клиентов и выполнение целей подразделения. Интересно, что в документе есть и редкая для корпоративной ИИ-риторики оговорка. Если конкретная задача не выигрывает от нынешних инструментов, это не провал инженера. Способность аргументированно объяснить, где ИИ пока не помогает, компания считает проявлением нужного профессионального суждения.
Это важный сигнал для менеджеров, которые пытаются построить отчётность вокруг ИИ-разработки. Количество сгенерированных строк, число вызовов модели, стоимость токенов ИИ или доля задач, «затронутых ИИ», могут быть полезны как диагностические данные. Но они плохо отвечают на главный вопрос: стало ли решение лучше для пользователя и выгоднее для бизнеса. Куда полезнее смотреть на время до релиза, число дефектов после поставки, стоимость эксплуатации, выполнение продуктовой цели и реальную экономию времени команды.
Amazon также указывает на разрыв между командами, глубоко вовлечёнными в продукт и бизнес-контекст, и теми, кто от него отдалился. Первые обычно лучше понимают, где агентская разработка способна ускорить работу: например, при подготовке тестов, анализе типовых инцидентов, миграциях или обработке повторяющихся запросов. Вторые рискуют автоматизировать сам процесс автоматизации, не замечая, что узкое место находится в согласованиях, данных, архитектуре или принятии решений.
Похожую позицию летом заняла Microsoft. Исполнительный вице-президент Джей Парих призвал внутренние команды оптимизировать не tokenmaxxing, а результаты, которые заметны клиентам и бизнесу. Когда два крупнейших работодателя для инженеров формулируют одну и ту же мысль, это похоже на завершение первой волны ИИ-эйфории в разработке: демонстрация возможностей уступает место экономике эксплуатации.
Для компаний это означает более скучную, но здоровую работу: выбирать модель под конкретную задачу, ограничивать ненужный контекст, проверять качество результата и не заставлять каждую команду искать применение ИИ ради галочки. Вероятно, следующим конкурентным преимуществом станет не максимальный расход моделей, а умение вовремя отказаться от них — или выбрать достаточно хорошую и заметно более дешёвую альтернативу.
