Комментарии 3
И вот это ещё оставлю тут на всякий случай https://www.tbank.ru/career/it/ml/lead-ai-engineer-rnd-msk/
Очень радует, что, судя по статье, ЛПР не требуют от вас выраженного экономического эффекта, по сути соглашаясь с показателями инженерной продуктивности. Но говоря о положительных метриках ни слова не сказано о "стоимости проверки".
Например "стабильный лайк-рейт около 30%" говорит о том, что каждый из этих комментариев вынужденно проверяется, и 70% из них сомнительны. И даже подтверждённый комментарий, тоже съел время на проверку.
"конверсия... в принятый merge-реквест... около 10%", это значит что в 9 из 10 случаев LLM создала бесполезную работу для человека. В одном случае из 10 эта работа закончилась хотя бы чем-то полезным.
Автодополнение кода "распространение... перевалило далеко за 50%", здесь налог на проверку скрыт, но фактически он есть, как время на проверку и понимание человеком того, что предложила LLM.
И так далее... "Налог на проверку" на сегодня принципиально не устраним из работы с LLM.
Но в целом, статья показывает, как правильно нужно относиться к LLM и с точки зрения программистов и с точки зрения ЛПР.
Вообще про метрики инженерной продуктивности хочу сделать отдельную статью, как и написал выше.
Экономический эффект, конечно же, всех интересует, но пока что рано его прям "требовать" - это понимание у ЛПР есть.
Метрики во многих сценариях нужны на текущем этапе в первую очередь для управляемого улучшения сценариев, и лишь когда-нибудь в будущем накопленную историю по каким-то из этих технических метрик можно будет использовать для трассировки до экономического импакта.
В случае с код-ревью комментарии - это ключевой артефакт, который людям по сути в любом случае нужно читать. А когда прочитали, то кликнуть на лайк/дизлайк уже почти ничего не стоит. Даже некоторые комментарии, на которые поставили дизлайк могут неявно натолкнуть на полезные мысли. А самое главное, мы пока в процессе сравнения лайк-рейта для комментов от ИИ и от людей (а у люди тоже оставляют комментарии не на 100% полезные).
Про конверсию в юнит-тестах: не все 10 запусков вообще доходят до человеческого ревью, потому что иногда система сама решает, что не может ничего сгенерировать. До ревью человеком реально доходит 4-5 из 10, из которых 1 мёржится без редактирования, а те, которые мёржатся с редактированием мы пока не учитываем. Конверсия 10% - это усреднение за всё время работы, но в последних версиях он подрастает. И основной расчёт как раз на то, что при работе с обучаемыми системами качество постепенно преодолеет любой критический порог по полезности.
В случае оценки качества автодополнения кода из-за массовости распространения можно сказать, что разработчики субъективно посчитали этот налог на проверку оправданным. Кто-то не посчитал, и отключил автодополнение, но большинство продолжает пользоваться. А значит это можно транслировать в приемлемость этого налога на уровне компании. И эта логика относится ко всем сценариям использовании ИИ, работающими по запросу от человека, а не навязываемым.
ИИ в программной инженерии: обзор практик, инструментов и проблем