Комментарии 16
Такое ощущение, что вы очень хотели найти хоть что-то, что у вас больше, чем у других
Какая разница, насколько строчка похожа? Важно чтобы код не похож был на то, что вы руками пишете, а чтобы он работал
Единственная метрика полезности ассистента - это суммарное время, которое человек потратит на решение задачи.
Если руками код написать выходит быстрее, чем думать над промптами, ждать запросов/ответов API и исправлять результат, то ассистент бесполезный
А похожесть не обязательно гарантирует, что суммарно вы потратили меньше времени
Исследование посвящено single-line подсказкам, которые прилетают прямо в процессе написания кода. Если такая подсказка совпала, или оказалась очень похоже на то, что вы хотели написать руками, то достаточно просто нажать на Tab, и она вставится в текст. Никаких промптов писать не надо, подсказки прилетают сами)
Так что порой вместо сочинения и написания целой строки кода достаточно просто нажать на одну лишь клавишу Tab. Время экономится, и еще как
Другое дело, что если тестировать не на идеально закоменченном коде с гита, а на обычном коде, который может быть кривоват, то метрика у всех ассистентов подупадет. Тут смысл в том, что они были помещены в одинаковые условия и объективно сравнены.
То, что вы описываете, работало и раньше без AI довольно адекватно, а дремучие деды это называли "сниппетами"
А теперь работает еще лучше. Сниппеты, будь то вставка регулярных синтаксических структрур, вроде блока if или блока объявления класса, или кастомные пользователськие сниппеты, были вполне хорошими для своего времени инструментами для экономии времени написания кода.
Современные нейросетевые языковые модели более гибко подстраиваются под контекст файла, способны обогнать мысль разработчика, порой выдавая 100% точные подсказки еще до того, как разработчик придумал, что же он хотел написать, и имитируют его стиль. Ввиду этого их популярность только растет. Это не умаляет эффективности классических "сниппетов", но пользователи все стремительнее переходят на AI, видимо, считая это решение более удобным. Каждому свое)
А можно в цифрах ваши маркетинговые заготовки?
А теперь работает еще лучше
Лучше как, и по чьим данным?
для своего времени
Своего - это какого? Пока все массово не стали хайповать на ИИ?
Они хуже работать не стали от этого.
Современные нейросетевые языковые модели более гибко подстраиваются под контекст файла
Опять же, более гибко - это как измерено?
способны обогнать мысль разработчика
А это? Какого разработчика, как вы это проверяли, как часто обгоняют и выезжают ли при этом на встречку?
придумал, что же он хотел написать
имитируют его стиль
А если разработчик коммитит в код, который писал не он и вообще первый раз его видит?
Будет ли подсказка эффективной и отражать желание разработчика, а не каких-то людей, которые писали код. Нельзя предполагать, что авторы исходного кода могут иметь лучшее представление о том, что именно разработчик хочет написать.
но пользователи все стремительнее переходят на AI
Пользователи чего? Что это за пользователи, кто/как эту статистику собирал, сколько было, сколько осталось, и т.д.
Хотя я и комментирую от своего имени, но мой позитивый взгляд на AI несомненно делает меня маркетологом)
Как я и сказал, успех нейросетевых моделей не умаляет эффективности классических сниппетов. В случае AI речь идет о другом, более широком функционале. В целом этот фунционал приводит к увеличению эффективности разработки. Пример исследования (https://ar5iv.labs.arxiv.org/html/2302.06590), в котором исследуемая гурппа в 45 человек, имеющая доступ к AI ассистенту, показывает статистически значимый прирост в скорости решения coding задач (на 55.8%) в сравнении с контрольной группой из 50 человек, которые пользовались лишь стандартными средствами IDE. В том, что касается обсуждаемой нами экономии времени, эффект налицо.
Можно понять ваше личное нежелание присоединяться к всеобщему "хайпу" вокруг AI, но одновременно можно констатировать и рост популярности AI-ассистентов. На графике легко просматривается экспоненциальная фаза роста подписчиков GitHub Copilot (https://images.app.goo.gl/fcJrZjwuoJqC7V8q7), а опрос Docker (https://www.docker.com/resources/2024-docker-ai-trends-report-infographic/) показал, что 64% разработчиков в 2024 году так или иначе уже использует AI в своей работе, и 61% от числа опрошенных утверждает, что AI помогаем им в их рабочих задачах. Приток пользователей AI сервисов среди разработчиков налицо. Люди склонны пользоваться тем, что работает, и избегать того, что не работает, только и всего)
Выражение "более гибко" просто-напросто отражает тот факт, что классические подсказки IDE лишь подсказывают имена переменных, или пустые шаблоны для цикла/ определения функции и тд, в то время как генеративный трансформер подсказывает готовый код, учитывая (в силу механизма Self-Attention) весь контекст, предоставленный ему. Как было указано в стаьтье, 37.7% кода таким образом угадывается абсолютно точно (опять же, для 'хорошего' кода с GitHub).
Измерить процент подсказок, которые обогнали мысль разработчика с перечением двойной сплошной, возможно лишь спрашивая оценку самих разработчиков, и такая величина не наблюдаема напрямую.
По поводу коммита в чужой код: пожалуй, даже плюс, что AI ориентируется на уже существующий код в файле, это способствует единству стиля.
Можно заниматься точными оценками вклада AI в разработку, я же ограничусь более скромным комментарием, и подытожу, что такой вклад есть, и он достаточен, чтобы убедить 64% разработчиков пользоваться AI-сервисами.
мой позитивый взгляд на AI несомненно делает меня маркетологом
То, что вы аффилированы с продуктом, о котором статья, делает ваши утверждения необъективными.
В целом этот фунционал приводит к увеличению эффективности разработки. Пример исследования (https://ar5iv.labs.arxiv.org/html/2302.06590)
Исследование проведено Microsoft о продукте, который делает Microsoft.
В статье разработчиков наняли на Upwork, и в задаче явно было указано требование написать код быстрее. То есть люди, которые не заинтересованы в качестве и сопровождении кода, писали код, у которого не было требований к качеству.
У них не было цели писать эффективный код быстрее. У них была задача быстрее произвести какой-то код.
При этом там пишут, что у разработчиков с меньшим опытом разница выше. Обычно чем больше опыта у разработчика, тем больше у него намётан глаз на ошибки и несовершенства. То есть, косвенно этот результат говорит о худшем качестве кода у менее опытных разработчиков, т.к. они тратят меньше времени на коррекцию.
Но хотели бы вы сами пользоваться продуктом или работать над кодом, к которому предъявляются именно такие требования? Если вы ориентируетесь на такие исследования, то наверное и бэкенд GigaCode так же написан :)
На графике легко просматривается экспоненциальная фаза роста
Из экспоненциального там только кусок хвоста, плюс график примерно соответствует росту кол-ва пользователей github в целом. Т.е. доля пользователей практически не меняется. Учитывая то, что Microsoft оценивает кол-во пользоветелей Github как 100+ млн, то это на уровне 5%, что в 13 раз меньше чем ваши 64%.
64% разработчиков в 2024 году так или иначе уже использует AI в своей работе, и 61% от числа опрошенных утверждает, что AI помогаем им в их рабочих задачах
А если посмотреть инфографику, то для написания кода gen AI использует 33%. Это тоже чуть меньше, чем 64, не находите?
Ещё не совсем очевидно, как отличаются результаты в зависимости от опыта/области использования.
37.7% кода таким образом угадывается абсолютно точно
для 'хорошего' кода с GitHub
В реальной жизни пишут реальный код, а не "хороший" c github. Ну и на github не весь код хороший.
пожалуй, даже плюс, что AI ориентируется на уже существующий код в файле, это способствует единству стиля
Стиль в современных языках форсируется линтерами и автоформатированием. Для этого AI не особо нужен. Может быть, стиль именования переменных и методов будет похож. А вот похожесть кода на основе того, что есть в существующем коде - это не гарантия правильной функциональности.
Простой пример - в коде на Go можно получить доступ к элементам массива в цикле через второй параметр range:
for _, elem := range []struct{...} {
fmt.Println(elem)
}Если у вас в файле производится только чтение, это никаких проблем не вызывает. Но вот это будет ошибкой:
for _, elem := range []struct{...} {
elem.X = 1
}Отмечу, что я понятия не имею что именно ассистент предложит в конкретном примере. Важно то, что в разных языках таких семантически верных, но логически неправильных конструкций может быть множество. И ошибки, с ними связанные, допускаются в том числе в реальном коде, на котором учится ИИ.
Согласен, что обширных независимых исследований эффекта применения AI в разработке хотелось бы больше. При этом, если спросить самих разработчиков, можно обнаружить, что, например, в этом опросе (https://www.statista.com/statistics/1440348/ai-benefits-in-development-workflow-globally/) 13% респондентов даже сообщают о воспринимаемом ими повышении качества кода. Да, профессиональный разработчик со стажем в 30 лет, вероятно, не получит прироста в качестве кода от использования AI ассистента. Это не значит, однако, что периодические автодополняющие подсказки, способные порой обогнать скорость его печати, будут для него бесполезны. Кроме того, AI может генерировать больший объем кода по запросу, писать юнит тесты, документацию к коду. Может быть проще доработать сгенерированное AI решение, чем писать свое с нуля. Ответсвенность за качество конечного кода все равно лежит на разработчике.
Справедливым показателем тут может служить удовлетворенность разработчика от использования AI, а как показывают опросы, в целом среди них преобладает положительный сентимент.
В общем мы все живем в одном большом эксперименте по внедрению AI, интересно посмотреть, к чему это нас приведет, если приведет, и каким окажется потолок развития у нынешней LLM архитектуры. Удачи вам)
Раньше говорили, что профессиональный программист (хотя чаще это говорили про верстальщика) пишет код в блокноте. Типа, ему только мешают всякие ide и т.п.. Сейчас код в блокноте пишет только дурак. Через короткое время только дурак не будет использовать ИИ помощников.
Ладно, скажем просто и по-другому
ИИ-ассистенты и копилоты не идеальны. Они не всегда угадывают абсолютно точно, и наверняка не могут помочь хард-сеньорам во всём, что они делают, и так далее. Но у меня таких навыков нет. Я пока что пишу простые вещи и codeium действительно значительно ускоряет мою работу. Например, мне не нужно писать несколько строк запроса к БД и обработки данных. Мне достаточно сделать, например,
// Take seattle users with age > 30, put into sorted by age desc List
и несколько раз нажать таб. А ИИ тем временем посмотрит на несколько похожих запросов в файле, разберётся в структуре полей и таблиц в БД и напишет несколько строк кода. Конкретно в этом случае 95+% вероятность, что не придётся ничего менять вообще. 10 секунд, потраченных на комментарий, были бы потрачены в любом случае, потому что я привыкла их делать даже в простых местах. А всё остальное сделали несколько последовательных нажатий tab
В общем, что я хочу сказать. Да, инструмент не идеален. Да, надо знать, что делаешь, потому что выучить что-то новое с помощью подсказывателя кода не выйдет. Но когда понимание работы программы есть, написание нового кода начинает занимать в разы меньше времени. И никакие сниппеты ТАК сильно мою работу не ускоряют
И да, он действительно может придумать код раньше меня. Я только думаю, что надо сделать if, который проверит возраст, а потом отправит что-то в БД, но ещё не успеваю ни написать комментарий, ни осознать чётко конкретный текст команд, которые собираюсь набрать, а у меня уже выведен серый код и условия, и команды, и скобочки. Остаётся либо нажать tab и идти дальше, либо что-то подправить. Удобно
Например, мне не нужно писать несколько строк запроса к БД и обработки данных. Мне достаточно сделать, например,
// Take seattle users with age > 30, put into sorted by age desc List
SQL - это УЖЕ язык запросов. Получается, что вы пишете текст запроса, чтобы получить текст запроса, вместо того чтобы написать сразу текст запроса.
Вместо этого достаточно написать что-то типа WITH x AS (SELECT * FROM users WHERE city='seattle' AND age > 30 ORDER BY age, desc) INSERT (...) INTO List FROM x. И где тут несколько строк запроса и обработки?
Если уж хотите разрушительные аргументы приводить, то хотя бы не используйте SQL в качестве примера.
Во-первых, по существу вы ничего не ответили, только раскритиковали мой пример. Это на самом деле говорит о многом - вы оспариваете не мою правоту, а мою правоту в этом конкретном случае
Во-вторых, я привела первый пришедший в голову пример. Мб и не идеальный, потому что я не добавила важных деталей, но за пару дней до того, как писать комментарий, я действительно использовала нейросеть для очень похожего куска кода. Я уже не помню подробностей, но, кроме запроса, там было несколько строк обработки данных в нужный формат объектов, который и использовался в коде ещё несколько раз и который успешно подтянула нейросеть без лишних подсказок. В том и прелесть, что мне даже не надо уточнять -- я пишу List, а она уже знает, List каких объектов, как исходные данные в эти объекты сконвертировать, как осмысленно назвать этот список, а иногда даже угадывает, куда я потом эти объекты запихну.
А, ну и да. Ваша аргументация теряет ещё больше смысла - ремарка, , что sql уже язык запросов, абсолютно лишняя. Ведь сам запрос я не писала, чтобы оправдать это УЖЕ. Я написала простым текстом, что мне надо сделать. Даже если бы мне не надо было обрабатывать данные в том же блоке кода, я всё равно сэкономила бы две трети работы: комментарий и без нейронки необходим, а sql запрос, который в два раза длиннее, писала бы уже не я. Вот и выходит, что даже в вашем видении ситуации я в выигрыше по времени
То, что каждая третья подсказка идеально верная - достижение, молодцы!
Какие показатели на других языках, например, Python?
Кроме того, по расстоянию Левенштейна, качество подсказки, у которой ошибка в последнем символе, будет такое же, как и той, у которой ошибка во втором символе с начала строки. Однако для разработчика время на исправления таких ошибок будет различаться
Спасибо) В скором времени опубликуем статистику по большему числу языков, причем оцениваться уже будут подсказки на основании как верхнего, так и нижнего контекста, а так же контекста из других файлов в проекте. Это лишь наши первые результаты, которыми мы решили поделиться.
По поводу замечания:
Все верно, более того, если ошибка, скажем, в трех символах подряд, ее исправить легче, чем ошибку в трех символах на разнесенных позициях. Классическое редакционное расстояние этого не учитывает. Но при этом оно уже хорошо знакомо и обкатано во многих областях применения, для его рассчета существует эффективный алгоритм, поэтому мы и решили использовать расстояние Левенштейна с удвоенной ценой замены символа. Такое расстояние хорошо интерпретируется и в целом адекватно оценивает близость строк.
Всё это конечно здорово. Только, как попробовать, если нет телефона +7 ... и аккаунта в Сбербанке? GitVerse по-другому не даёт зарегистрироваться.
В планах есть Rust добавить в число поддерживаемых языков?
GigaCode и все-все-все. Сравниваем различные ИИ-ассистенты между собой