Comments 16
Я, конечно, в матстате не шарю. Но разве первая таблица не говорит о том, что разница между 2 группами незначительна?
Это данные до начала эксперимента. Чем меньше там разница, тем лучше. Добавил подпись, спасибо.
Ок. Понял. Тогда в итоговой таблице строка "Доля успешных билдов" с минусами интересная выходит. Фигачим больше кода, но он прям заметно хуже работает - я правильно понял?
В отчёте исследования это обходится стороной. Утверждается, что качество не меняется. Вероятно, падение в 5,53 % считается статистически незначительным.
А "доля успешных билдов" с минусами - это что значит? Не скомпилился или не прошёл тесты?
И в том и в другом случае те, кто перед коммитом не запускает автотесты - так себе разрабы.
Эксперимент шёл на протяжении 7 месяцев и задействовал 1746 разработчиков
А можно где-то рядом график о том, насколько больше делают люди за которыми наблюдают и регулярно спрашивают про эту всю чехарду и рядом такой же с графиком насколько быстрее они сгорают в хлам? А то вдруг окажется что если в людей постоянно тыкать палкой без аишечки, то они ещё больше успеют...
В общем получается, что выросло число ПРов, но упало число успешных билдов. Непонятно, почему исследователи фокусируются на первом и оставляют без внимания второе. Это в общем-то инь и ян процесса деливери.
Без ПРа нет билда.
Упавший билд означает, что ПР так себе (не берем в расчет флакающие тесты - они и без всякого ИИ бывают), и ведет к тому, что ты делаешь еще один коммит в ПР, чтобы исправить упавший билд. Можно набить много таких коммитов.
Когда билд успешен, но код не выполняет бизнес-требования, то ты открываешь еще один ПР. Пока задача ходит по кругу In Progress - In Testing, то можно очень сильно повысить количество ПРов без повышения фактической полезности своей деятельности.
Хорошей метрикой было бы уменьшение среднего времени, которая задача проводит в пути In progress -> Done.
В общем у меня вау-эффекта нет. Но исследование полезное. Потоки хайпа нужно охлаждать реальными цифрами.
Не учитывается уровень разработчиков и не хватает статситики в разбивке по этим уровням.
Помню время когда я на поиск информации и синтаксис тратил времени больше чем на придумать алгоритм и написать. Если бы мне гугл выдавал на мой запрос сразу то что нужно я бы тоже резко ускорил написание кода.
Но потом основное время уходило на придумать алгоритм, тест и проверить. И тут проверить за ИИ , поправить думаю не меньше времени бы ушло.
Интересно было бы услышать в таких статьях - как относятся клиенты/заказчики к ситуации, если исполнители/программисты используют в своей работе ЭйАй... готовы ли они платить за работу меньше? больше? Как они относятся к безопасности такой работы, соглашаются ли они "шарить" код в такое окружение? Ожидают ли они сокращение времени от исполнителей, более качественные результаты? Готовы ли они набирать больше дешевых джунов или наоборот? ...в каких отраслях?
... и что же происходит при этом на практике ("под капотом", т.е. на самом деле)?
Обожаю такое - 26.08%. Не 26% или хотя бы 26.1%, а 26.08. Хотя стандартные отклонения такие что и в 6-ке уверенным быть нельзя. Куда делось правило, что результат надо округлять до значащих цифр?
Сперва нужно убедиться, что все понимают что такое значащие цифры )
(к этому сразу нужно добавлять вопросы про средние температуры по больнице.... по частоте использования в разного рода отчетах и выступлениях)
Кстати, даже здесь встречаются люди, которые уверены, что математика в школе не очень важна..., а потом мы встречаем в IT сфере сотрудников, для которых удивительно легко показывать вот такие цифры в презентациях для клиентов..., и если клиенты не с таким же "бэкграундом", а все таки имеют нормальную математическую культуру - ...то такие презентации для них, без объяснений, красный флажок...
Исследование: генеративный ИИ повышает производительность труда разработчиков на 26,08 %