Проблема в реальной аналитике оценки перформанса AI тулов лежит в том, что мы до сих пор реально не можем корректно померять перформанс людей.

Большинство систем оценки перформанса людей строится одном из двух принципов: 1) Human-based 2) Data-based. На практике оба принципа имеют фундаментальные проблемы.

В первом случае оценку работы выставляет человек. Проблема здесь в том что любой человек субъективен и может ставить оценки через призму своих когнитивных искажений. Например, ставить более высокие оценки тем людям, кто "чаще мелькает", недооценивая тех кто более невзрачен в аспекте презентации своих результатов.

Во втором случае вопрос в качестве собранных данных и в том насколько эти данные реально отражают производительность. Например мерять производительность разработчика по критерию "количество строк кода" - это безумие, потому что хороший инженер может писать мало строк, но код будет более производителен, в то время как неопытный разработчик может строчить полотна для реализации той же функции. Мерять сторипоинты тоже идея так себе - во-первых оценка не всегда совпадает с реальной сложностью задач, во-вторых её тоже ставят люди. И если в голове команды хоть на секунду возникнет мысль что их карьера или зарплата зависят от количества сторипонтов, то команда с производства продукта перефокусируется на производство сторипоинтов, т.е. на максимальное раздутие трудозатрат на функционал.

Гипотетически проблему качества данных могут решить трекеры. Но здесь есть два момента - во-первых, трекеры никто не любит. Во-вторых, все равно понятие "производительность труда" в интеллектуальной работе гораздо шире, чем просто доставка каких-то артефактов. Одна строчка кода может стоить месяцы работы и ресерча, если идет речь о больших системах, если это правильная строчка кода, например правильно выбранный новый фреймворк или библиотека.

Со студентами проще - у них типовые задачи. С любыми рабочими задачами сложно, потому что все они хоть и похожи, но отличаются в той степени разницы чтобы между ними нельзя было бы однозначно поставить знак тождественности с точки зрения оцениваемых трудозатрат.

Производительность команд довольно неплохо видна крупным планом, с точки зрения производства больших систем и проектов. Внутри команды интуитивно-субьективно она тоже видна, но см. п. 1.

Когда мы говорим про аналитику производительности AI все эти вопросы обостряются в новом виде. Мы можем сравнить производительность двух моделей/архитектур для решения типовой задачи. Это аналогично сравнению работы двух студентов. Но для больших проектов нужно время, чтобы можно было взглянуть на картину целиком.

И это время сейчас стартует во многих компаниях. Через год-два появятся бенчмарки по производительности агентов на больших цифрах. И вот именно тогда, когда эта аналитика ляжет на стол корпоративным боссам, на рынке труда могут начаться титанические сдвиги.