Внедрение ИИ замедляет разработку — закон Гудхарда
Есть ощущение, что ТОПы вообще не слышали про закон Гудхарда, а ведь это настолько базовое знание для менеджера, что даже не обязательно знать название, чтобы на интуитивном уровне понимать как он работает. Об этом говорят у кулера, на конференциях, на кассе пятерочки. Этот закон окружает нас везде в реальной жизни, где есть какие-то цели. И пора бы уже начать принимать его во внимание.
Закон (принцип) Гудхарта — утверждение, гласящее «Когда мера становится целью, она перестает быть хорошей мерой» Да и за примерами далеко ходить не надо. Может быть помните был раньше тренд в айти считать эффективность разработчика по количеству написанных строк. И всё начали вместо качественного и компактного кода писать длинную бессмыслицу. Возможно, тогда и появилась Java, lol. Но, к счастью, довольно быстро поняли что в разработке иногда важнее даже не написать больше кода, а наоборот — удалить. А фикс, над которым работали несколько дней, может состоять из одной строки. И это нормально.
И что же стало с внедрением ИИ?
Бизнес как будто штормит. Сначала был тренд: «пишите сами, ИИ использовать запрещено». Теперь он сменился на «используй ИИ обязательно». Компании не просто покупают лицензии или разворачивают локальные нейронки, они начинают вводить метрики. Яндекс, например, публично представил программу 75/75/75, суть которой что по итогам программы 75% кода будет генериться нейронкой. И похожие программы появились во всех крупных компаниях.
Я могу понять мотивацию: компаниям хочется идти в ногу со временем, не отставать от трендов, быть на передовой технологий несмотря на санкции. Но как это делается — это тупик.
Главная цель использования нейронок в разработке — повысить эффективность разработки, сократить издержки, заработать больше денег. Но как только вводятся метрики, цель сразу подменяется. Теперь цель — достичь этих сраных метрик. И денег заработает только тот, у кого KPI зависит от количества сгенерированного кода, но точно не компания.
Банально, раньше разработчик мог написать решение в пару строк, а теперь он возьмет эти пару строк, но не закоммитит, а закинет в чат с промтом «перепиши подлиннее, добавь комментарии к каждой строке, jsdoc, тесты» (тесты, которые никогда не будут запущены) и на выходе получит десяток строк буллшита и ачивку «AI-энтузиаст». На это потратится больше времени, код станет хуже, но зато метрики будут на высоте. И таких лайфхаков можно придумать бесконечное количество. Накидайте примеров в комменты, из лучших сделаю подборку в следующий пост!
Но разве этого мы хотим?
Мне кажется, мы хотим работать эффективнее и быть счастливее. А в итоге будем работать хуже, дольше, да еще и страдать от результата.
Менеджерам на заметку: «Хотите испортить отличную идею — добавьте её в KPI.»
· 10.08
Да, TTM тоже можно испортить, если превратить его в KPI без контекста. Я бы смотрел не только на скорость, но и на lead time, escaped defects и долю доработок после релиза. Тогда видно, где ускорение, а где имитация. Какие метрики у вас живут дольше квартала?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён