Meta прибрала використання ШІ з оцінювання інженерів

Чому лічильник використання дав хибний сигнал

Початковий критерій оцінював не результат інженера, а видиму активність у ШІ-інструментах. Працівник міг покращити позицію у внутрішньому рейтингу, просто витрачаючи більше токенів. Так виникло «tokenmaxxing»: поведінка підлаштувалася під показник, хоча сам показник не доводив ані якості, ані складності виконаної роботи.

Новий підхід розділяє засіб і результат. Використання ШІ залишається частиною робочого процесу, але в оцінюванні мають значення якість, швидкість і складність роботи. Для керівника це означає: не заохочувати кількість запитів, токенів чи місце в рейтингу, якщо ці дані не показують, що саме працівник зробив краще або швидше.

• Крок 1. Прибрати обсяг використання ШІ з індивідуальної оцінки.
• Крок 2. Окремо зафіксувати якість, швидкість і складність виконаної роботи.
• Крок 3. Перевірити, чи не можна покращити показник без корисного результату.

Другий приклад: витрати контролюють бюджетом, а не рейтингом

Масове споживання токенів мало не лише поведінковий, а й фінансовий наслідок: внутрішнє використання ШІ у Meta прямує до мільярдних витрат у 2026 році. Тому з 2027 року компанія планує запровадити бюджети та центральну панель контролю. Це інша робоча ситуація: тут дані про використання потрібні не для оцінювання людини, а для керування витратами.

Один і той самий лічильник має різний сенс залежно від рішення. У рейтингу працівників він провокує витрачати більше, щоб виглядати активнішим. У бюджетному контролі він допомагає бачити споживання і тримати його в установлених межах. Отже, метрику варто прив’язувати до власника рішення: результат роботи оцінює керівник, а витрати відстежують через бюджет і загальну панель.

• Не перетворювати витрати токенів на доказ продуктивності.
• Використовувати дані про споживання для бюджетування й централізованого контролю.
• Не змішувати контроль вартості з оцінкою якості роботи.

Третій приклад: агент не запрацює без прийнятного доступу

Під час тестування агента Hatch з’явилася інша межа впровадження. Інструмент має самостійно виконувати завдання на комп’ютері, але частина працівників не хоче під’єднувати до нього особисті акаунти через ризики для приватності. Тут бар’єр виникає не через якість оцінювання чи ціну токенів, а через обсяг доступу, потрібний інструменту.

Тому перевірка агента не зводиться до того, чи здатен він виконати завдання. До підключення акаунта працівник має розуміти, що саме буде під’єднано і чи прийнятний для нього пов’язаний із цим ризик приватності. Якщо люди відмовляються надавати доступ, сам факт наявності агента не забезпечує його використання.

• Визначити, які акаунти треба під’єднати для виконання завдання.
• Не трактувати небажання підключати особистий акаунт як нестачу продуктивності.
• Врахувати приватність як окремий критерій тестування інструмента.

Де проходять межі й що перевірити керівнику

Підхід Meta не означає, що дані про використання ШІ непотрібні. Вони не працюють як самостійна оцінка внеску працівника, бо їх можна наростити масовим споживанням токенів. Водночас ті самі дані придатні для контролю витрат через бюджети та центральну панель. А для агентів критичним стає не обсяг використання, а готовність людей надати потрібний доступ.

• Чи оцінюється завершена робота за якістю, швидкістю і складністю.
• Чи можна отримати кращий рейтинг, не покращивши результат.
• Чи відокремлено показники продуктивності від показників витрат.
• Чи видно загальне споживання ШІ та чи передбачено для нього бюджет.
• Чи потребує інструмент підключення особистих акаунтів і чи прийнятний ризик приватності.