Amazon предложила разработчикам документировать случаи, когда ИИ в Amazon ухудшает работу, а не помогает ей. Но в том же мемо компания предупредила, что сотрудники, не осваивающие такие инструменты, рискуют отстать — и эта оговорка важнее любой корпоративной риторики для инженеров и руководителей, которым уже меряют эффективность через «внедрение ИИ».
Автор документа — Терк Терковиц, вице-президент и distinguished engineer Amazon. Его обращение к инженерам и их менеджерам сначала распространили внутри компании в сентябре, а затем оно стало публичным. Как пишет The Register, текст пытается одновременно поддержать профессиональное суждение разработчика и ускорить внедрение генеративных инструментов. Это разумная цель, но формулировки оставляют менеджерам слишком широкий выбор: признать отказ от ИИ обоснованным или записать его в признак технологического отставания.
Центральный тезис мемо выглядит здраво: если конкретная задача не выигрывает от текущих ИИ-инструментов, это результат проверки, а не ошибка сотрудника. Инженеру предлагают зафиксировать проблему, обсудить её с руководителем и разобраться, почему инструмент не дал эффекта. Терковиц также делает акцент не на количестве сгенерированного кода, а на клиентском результате и инженерном решении — двух вещах, которые пока плохо сводятся к числу запросов к модели.
Отдельно Amazon признаёт слабость «входных» метрик: объёма токенов, числа обращений к ассистенту или доли задач, выполненных с его помощью. Компания предлагает смотреть на команды, которые активнее всех расходуют ИИ-ресурсы, и сравнивать их фактическую скорость поставки с остальными. Если расход вырос, а релизы, исправленные дефекты и качество не изменились, повод для восторга заканчивается. Для индустрии, которая любит строить дашборды раньше, чем договариваться о смысле показателей, это редкая трезвая оговорка.
Когда метрика становится целью
Проблема в том, что вслед за критикой примитивных метрик мемо всё же допускает их осторожное применение, а затем предупреждает об отставании тех, кто не внедряет ИИ. В реальной организации эти три позиции легко превращаются в разные правила для разных людей. Сильному разработчику можно сказать: «Ваш случай задокументирован, продолжайте работать привычным способом». Сотруднику с конфликтом с руководителем — «Вы не адаптируетесь к новой модели работы». Формально обе реакции будут выглядеть совместимыми с текстом документа.
Подобная двусмысленность особенно чувствительна на фоне сокращений и тревоги вокруг профессии. По данным публикации, на этой неделе Amazon, как сообщалось, объявила ещё о 250 сокращениях. Прямой связи между мемо и кадровыми решениями источник не устанавливает, но инженер, читающий одновременно про эффективность, освоение ИИ и увольнения, вряд ли воспринимает эти темы изолированно. Корпоративный призыв экспериментировать быстро начинает звучать как неявный тест на сохранение места.
У Amazon уже был наглядный пример того, как ломается стимул. В мае компания закрыла KiroRank — созданную сотрудниками таблицу лидеров по потреблению токенов. Предсказуемо, часть участников стала запускать бессмысленные задачи, лишь бы подняться в рейтинге; в отрасли это поведение уже называют tokenmaxxing. Мемо Терковица прямо называет такую практику противоречащей принципу бережливости. Но сам эпизод показывает не моральный дефект отдельных сотрудников, а дефект конструкции: если показатель влияет на статус или оценку, его начинают оптимизировать независимо от пользы.
Внутри — экономия, снаружи — продажа токенов
В истории есть и коммерческая ирония. Внутри Amazon избыточный расход токенов — затрата, которую нужно контролировать. Снаружи компания продаёт доступ к моделям через AWS Bedrock и Kiro с расчётом, привязанным к потреблению. Для клиента высокий счёт за токены не равен автоматически новому продукту, закрытому инциденту или сокращённому времени вывода функции на рынок. Схожее противоречие есть у всей индустрии: поставщики предлагают измеримый расход вычислений, тогда как бизнесу нужен измеримый результат.
Для русскоязычных команд вывод практический. Внедрение ИИ-ассистентов нельзя превращать в KPI вида «каждый разработчик должен сделать N запросов» или «X процентов кода обязаны пройти через модель». У таких требований почти гарантированно появятся обходные манёвры: пустые промпты, раздутые контексты, декоративные задачи и pull request'ы, которые придётся долго вычищать на ревью. Полезнее выбрать несколько повторяемых сценариев — подготовку тестов, разбор логов, миграции, поиск по большой кодовой базе — и до эксперимента зафиксировать базовые показатели: время цикла, число возвратов с ревью, дефекты после релиза и стоимость эксплуатации.
Руководителям стоит заранее разделить две вещи: обучение новым инструментам и оценку результативности. Разработчик, который аргументированно отказался от модели для задачи с чувствительными данными, нестабильными требованиями или дорогой проверкой ответа, не должен выглядеть хуже коллеги, который сгенерировал больше текста. И наоборот, скепсис не освобождает команду от экспериментов там, где ИИ действительно снимает рутину. Нужен след решения: что пробовали, на какой задаче, какой эффект получили и почему продолжили или остановились.
Мемо Amazon интересно не обещаниями об автоматизации, а вопросом, который оно невольно ставит перед любой технологической компанией: сможет ли она защитить профессиональное суждение инженера, когда дашборд требует роста использования ИИ? Пока ответ определяется не текстом принципов, а тем, что произойдёт с первым сотрудником, который честно напишет: в этой задаче ИИ в Amazon сделал результат хуже.
