https://telegra.ph/Budushchee-raboty-ZHizn-posle-revolyucii-AI-agentov-v-razrabotke-PO-07-21
Вторая часть статьи. Решил порассуждать про будущее рынка труда. Тут важно отметить что процесс будет идти плавно и то что я написал - это лишь один из вариантов попыток предугадать как оно будет выглядеть. Поскольку сами модели меняются в динамике и пока еще не вышли на плато производительности, то ситуация может быть сильно другой: этот этап возможно пролетит быстрее чем кажется к условно "коробочной" сборке нетехнарями, возможно он наступит не так быстро если появятся реальные бенчмарки по внедрению аи и модели будут улучшаться не так быстро. Но в целом направление вижу такое: "слесаря-фрезировщика" заменит "оператор ЧПУ".
Вторая часть статьи. Решил порассуждать про будущее рынка труда. Тут важно отметить что процесс будет идти плавно и то что я написал - это лишь один из вариантов попыток предугадать как оно будет выглядеть. Поскольку сами модели меняются в динамике и пока еще не вышли на плато производительности, то ситуация может быть сильно другой: этот этап возможно пролетит быстрее чем кажется к условно "коробочной" сборке нетехнарями, возможно он наступит не так быстро если появятся реальные бенчмарки по внедрению аи и модели будут улучшаться не так быстро. Но в целом направление вижу такое: "слесаря-фрезировщика" заменит "оператор ЧПУ".
Telegraph
Будущее работы: Жизнь после революции AI-агентов в разработке ПО
Технологический сдвиг, вызванный внедрением AI-агентов в разработку, касается не только технологий — он касается людей. Подъем автоматизированного "заводского цеха", управляемого AI-агентами, неизбежно изменит рынок труда, переопределит роли и заставит нас…
Проблема в реальной аналитике оценки перформанса AI тулов лежит в том, что мы до сих пор реально не можем корректно померять перформанс людей.
Большинство систем оценки перформанса людей строится одном из двух принципов: 1) Human-based 2) Data-based. На практике оба принципа имеют фундаментальные проблемы.
В первом случае оценку работы выставляет человек. Проблема здесь в том что любой человек субъективен и может ставить оценки через призму своих когнитивных искажений. Например, ставить более высокие оценки тем людям, кто "чаще мелькает", недооценивая тех кто более невзрачен в аспекте презентации своих результатов.
Во втором случае вопрос в качестве собранных данных и в том насколько эти данные реально отражают производительность. Например мерять производительность разработчика по критерию "количество строк кода" - это безумие, потому что хороший инженер может писать мало строк, но код будет более производителен, в то время как неопытный разработчик может строчить полотна для реализации той же функции. Мерять сторипоинты тоже идея так себе - во-первых оценка не всегда совпадает с реальной сложностью задач, во-вторых её тоже ставят люди. И если в голове команды хоть на секунду возникнет мысль что их карьера или зарплата зависят от количества сторипонтов, то команда с производства продукта перефокусируется на производство сторипоинтов, т.е. на максимальное раздутие трудозатрат на функционал.
Гипотетически проблему качества данных могут решить трекеры. Но здесь есть два момента - во-первых, трекеры никто не любит. Во-вторых, все равно понятие "производительность труда" в интеллектуальной работе гораздо шире, чем просто доставка каких-то артефактов. Одна строчка кода может стоить месяцы работы и ресерча, если идет речь о больших системах, если это правильная строчка кода, например правильно выбранный новый фреймворк или библиотека.
Со студентами проще - у них типовые задачи. С любыми рабочими задачами сложно, потому что все они хоть и похожи, но отличаются в той степени разницы чтобы между ними нельзя было бы однозначно поставить знак тождественности с точки зрения оцениваемых трудозатрат.
Производительность команд довольно неплохо видна крупным планом, с точки зрения производства больших систем и проектов. Внутри команды интуитивно-субьективно она тоже видна, но см. п. 1.
Когда мы говорим про аналитику производительности AI все эти вопросы обостряются в новом виде. Мы можем сравнить производительность двух моделей/архитектур для решения типовой задачи. Это аналогично сравнению работы двух студентов. Но для больших проектов нужно время, чтобы можно было взглянуть на картину целиком.
И это время сейчас стартует во многих компаниях. Через год-два появятся бенчмарки по производительности агентов на больших цифрах. И вот именно тогда, когда эта аналитика ляжет на стол корпоративным боссам, на рынке труда могут начаться титанические сдвиги.
Большинство систем оценки перформанса людей строится одном из двух принципов: 1) Human-based 2) Data-based. На практике оба принципа имеют фундаментальные проблемы.
В первом случае оценку работы выставляет человек. Проблема здесь в том что любой человек субъективен и может ставить оценки через призму своих когнитивных искажений. Например, ставить более высокие оценки тем людям, кто "чаще мелькает", недооценивая тех кто более невзрачен в аспекте презентации своих результатов.
Во втором случае вопрос в качестве собранных данных и в том насколько эти данные реально отражают производительность. Например мерять производительность разработчика по критерию "количество строк кода" - это безумие, потому что хороший инженер может писать мало строк, но код будет более производителен, в то время как неопытный разработчик может строчить полотна для реализации той же функции. Мерять сторипоинты тоже идея так себе - во-первых оценка не всегда совпадает с реальной сложностью задач, во-вторых её тоже ставят люди. И если в голове команды хоть на секунду возникнет мысль что их карьера или зарплата зависят от количества сторипонтов, то команда с производства продукта перефокусируется на производство сторипоинтов, т.е. на максимальное раздутие трудозатрат на функционал.
Гипотетически проблему качества данных могут решить трекеры. Но здесь есть два момента - во-первых, трекеры никто не любит. Во-вторых, все равно понятие "производительность труда" в интеллектуальной работе гораздо шире, чем просто доставка каких-то артефактов. Одна строчка кода может стоить месяцы работы и ресерча, если идет речь о больших системах, если это правильная строчка кода, например правильно выбранный новый фреймворк или библиотека.
Со студентами проще - у них типовые задачи. С любыми рабочими задачами сложно, потому что все они хоть и похожи, но отличаются в той степени разницы чтобы между ними нельзя было бы однозначно поставить знак тождественности с точки зрения оцениваемых трудозатрат.
Производительность команд довольно неплохо видна крупным планом, с точки зрения производства больших систем и проектов. Внутри команды интуитивно-субьективно она тоже видна, но см. п. 1.
Когда мы говорим про аналитику производительности AI все эти вопросы обостряются в новом виде. Мы можем сравнить производительность двух моделей/архитектур для решения типовой задачи. Это аналогично сравнению работы двух студентов. Но для больших проектов нужно время, чтобы можно было взглянуть на картину целиком.
И это время сейчас стартует во многих компаниях. Через год-два появятся бенчмарки по производительности агентов на больших цифрах. И вот именно тогда, когда эта аналитика ляжет на стол корпоративным боссам, на рынке труда могут начаться титанические сдвиги.