Amazon обновил гайдлайн роли SDE: измерять исход, а не токены; «ИИ не помог» — это находка, а не провал
Инженерное руководство Amazon пересмотрело роль гайдлайн SDE. Конкретные ИИ-практики фиксировать не стали — устареют за год; вместо этого фокус на неизменном — исходе для клиента. Входные метрики (токены, внедрение, число изменений) признаны ущербными как цели, но пока коррелируют с результатом; руководителям велено смотреть 10-й и 90-й процентиль внедрения.
Что произошло
Amazon опубликовал обновлённый гайдлайн роли инженера-разработчика — меморандум Terk Terkowitz, VP и Distinguished Engineer подразделения Worldwide Amazon Stores, адресованный инженерам компании (27 октября, на него обратил внимание Симон Уиллисон 28-го). Гайдлайн переписали Distinguished и Senior Principal Engineers всей компании. Ключевое решение: не описывать конкретные ИИ-практики — любая такая формулировка, по их оценке, «выглядит устаревшей через год» и замораживает практику; зафиксировано то, что не меняется: исход для клиента и бизнеса. Эру авторы называют «Renaissance Developer» — сочетание ИИ-инструментов, суждения и экспертизы в предметной области.
Про метрики сказано прямо: входные показатели — потребление токенов, внедрение ИИ-инструментов, число изменений и ревью — «глубоко ущербны», прежде всего потому, что оторваны от результата; как цели они ведут к росту затрат (tokenmaxxing против бережливости) и сложности (замер строк кода против принципа «изобретай и упрощай»). При этом пока эти метрики коррелируют с результатами: команды-«фронтиры» с максимальным внедрением растут в поставке, а команды без внедрения отстают. Рекомендация руководителям: смотреть 10-й процентиль (кто не внедряет и почему) и 90-й (кто внедряет активно и растёт ли поставка на самом деле).
Две формулировки меморандума расходятся как цитаты. Инженеру: «Если ваша работа не получает пользы от текущих ИИ-инструментов — это находка, а не провал. Задокументируйте почему, поделитесь с коллегами, принесите руководителю» — умение объяснить, где ИИ пока не помогает, и есть требуемое суждение. Руководителю: управлять внедрением без работы руками нельзя — нужно поработать с инструментами на продакшн-задачах и уметь назвать задачу, где они помогли, и задачу, где не помогли. Отдельное требование — сблизить инженеров с клиентом и продуктом: удалённость от предметной области лишает агентов правильной постановки задач.
Почему это важно
Для направления «роли и команда» это позиция одного из крупнейших ИТ-работодателей: роль не переписывается под инструменты, а метрики агентизации пока входные — с ними обращаются как с прокси, а не целями. Практическая ценность для руководителя — готовая рамка оценки внедрения: коридор 10–90 процентиль вместо средних по команде, требование к руководителям работать руками в инструментах и легитимизация ответа «ИИ нам здесь не помогает» вместо наказания за него.
Что с этим делать
- Перепроверьте свои метрики агентизации: какие из них входные (токены, внедрение, число PR) и не превратились ли они в цели для команд.
- Введите практику «задача, где помогло / задача, где нет» для руководителей — это критерий работы руками из меморандума.
- Соберите документированные места, где ИИ не даёт пользы: по версии Amazon это материал для улучшения инструментов, а не повод стигматизировать команду.