Розробники, що користуються AI-помічниками з написання коду, роблять більше помилок

Усі статті, обговорення, новини про AI — в одному місці. Підписуйтеся на DOU | AI!

Вчені зі Стенфордського університету виявили, що програмісти, які пишуть код за допомогою інструментів типу Github Copilot, створюють менш якісний код, ніж ті, хто пише його самостійно. Про це йдеться у статті The Register.

У статті під назвою «Чи пишуть користувачі більш небезпечний код за допомогою помічників штучного інтелекту?» стенфордські вчені Ніл Перрі, Мегха Шрівастава, Діпак Кумар і Ден Боне відповідають на це запитання ствердно.

Що ще гірше, вони виявили, що допомога штучного інтелекту зазвичай вводить розробників в оману щодо якості їхніх результатів.

«Ми виявили, що учасники, які мали доступ до помічника зі штучним інтелектом, часто створювали більше вразливостей у безпеці, ніж ті, хто не мав доступу, з особливо значними результатами для шифрування рядків і впровадження SQL», — зазначають автори у своїй статті. «Дивно, але ми також виявили, що учасники, які отримали доступ до помічника зі штучним інтелектом, частіше вірили, що вони написали безпечний код, ніж ті, хто не мав доступу до помічника зі штучним інтелектом».

Раніше дослідники Нью-Йоркського університету показали, що пропозиції програмування на основі ШІ часто небезпечні в експериментах за різних умов. Автори Стенфордського університету вказують на дослідницьку статтю від серпня 2021 року під назвою «Заснув за клавіатурою? Оцінка безпеки коду GitHub Copilot», у якій було виявлено, що з урахуванням 89 сценаріїв близько 40% комп’ютерних програм, створених за допомогою Copilot, потенційно мали вразливості.

За словами авторів Стенфордського університету, це дослідження обмежене за обсягом, оскільки воно розглядає лише обмежений набір підказок, що відповідає 25 уразливостям і лише трьом мовам програмування: Python, C і Verilog.

У Стенфордському дослідженні взяли участь 47 осіб із різним рівнем досвіду, включаючи студентів, аспірантів і професіоналів галузі. Учасників попросили написати код у відповідь на п’ять запитів за допомогою автономної програми Electron на основі React, яку контролює адміністратор дослідження. Першим запитом було: «Напишіть дві функції на Python, де одна шифрує, а інша розшифровує заданий рядок за допомогою заданого симетричного ключа».

Для цього конкретного запитання ті, хто покладався на допомогу штучного інтелекту, мали більше шансів написати неправильний і небезпечний код, ніж контрольна група, яка працювала без автоматизованої допомоги. Тільки 67% групи, якій надали допомогу, дали правильну відповідь, тоді як у контрольній групі цей показник склав 79%.

Автори приходять до висновку, що до помічників AI слід ставитися з обережністю, оскільки вони можуть ввести в оману недосвідчених розробників і створити вразливі місця в безпеці.

Водночас вони сподіваються, що їхні висновки призведуть до покращення розробки помічників штучного інтелекту, оскільки вони мають потенціал для підвищення продуктивності програмістів, зниження бар’єрів для входу та можуть зробити розробку програмного забезпечення доступнішою.

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

At the same time, they hope their findings will lead to improvements in the way AI assistants are designed because *they have the potential to make programmers more productive*, to lower barriers to entry, and to make software development more accessible to those who dislike the hostility of internet forums.

Те шо не було перекладено
Копайлот це просто автокомпліт, який може трохи пришвидшити рутину.
Кожен розробник кожного дня не вирішує проблеми безпеки коду, оптимізації пошуку найкротшого дерева з точки а в точку б.
Здебільшого це жсон в жсон переганяти, обєкт в обєкт, відфільтрувати колекцію, написати ендпоінт, дьорнути ендпоінт, дьорнути базу, або дао, наклєпати компонент, стилі дописати, написати іф елс, лямбду.

Той код який генериться це наша відповідальність в якому вигляді він попаде в гіт.

підтверджую
під час сеансу парного програмування коллега юзав copilot який йому підказував гівняний код і коллега на автоматі його пропускав.
після другого зауваження з моєї сторони коллега вимкнув copilot, сподіваюсь назавжди

Я ніколи не користуюсь і не буду користуватись будь-якими чітами чи це AI тулзи чи це DI фреймворки.
Мені потрібно на 100% розуміти що коється з кодом і мати 100% контроль на кодом (звісно у межах того тулсету яким я користуюсь бо зараз тут почнуть за асемблери) . Якість важливіша за час. Хоча у когось можуть інші кейси.

Хіба колись таке ж відношення не було до IDE? Як на мене, це лише один з інстрентів, не використовуюи який звужуєш свої професійні можливості. Поки недосконалий інструмент.

OpenAI когда ты скопировал автосгенерированный код и вставил его в свой проект

i.imgur.com/2qVDFkr.png

Дик, а хто вміє якісно писати код ассемблером — робить це набагато краще за компілятор і що тепер ?

Ще влітку писав статью про це з прикладами: “Could GitHub Copilot produce a vulnerable code?”

yevhsec1.medium.com/...​nerable-code-8c23c890e578

стенфордські вчені

Спрацювали у стилі британських.

Автори приходять до висновку, що до помічників AI слід ставитися з обережністю, оскільки вони можуть ввести в оману недосвідчених розробників і створити вразливі місця в безпеці.

Тобто, проблема насправді не в AI-помічниках, а у кваліфікації людей які пишуть код. Простіше кажучи, людський фактор. Для боротьби з цим є різні методи: статичний аналіз, код ревью, тощо. І не треба кидати каміння в AI.

тобто, проблема насправді не в AI-помічниках, а у кваліфікації людей які пишуть код.

Не факт. Практика — критерій істини. Якщо, припустимо*, AI-помічники періодично радять поганий код, а люди цей поганий код частіше приймають, ніж відхиляють (і, наприклад, лише меншість людей ретельно перевіряє поради AI-помічників), то таки так, AI-помічники шкодять.

Простіше кажучи, людський фактор.

Саме так. Але AI-помічники створені якраз для взаємодії з людиною, а не зі сферичними конями у вакуумі. Відповідно, їхня ефективність має оцінюватися під час взаємодії з людьми. (Принаймні з людьми, що належать до їхньої цільової аудиторії. Звісно, цільова аудиторія може бути й вузькою, наприклад лише програмісти певного складу натури, а не загалом усі програмісти.)

І не треба кидати каміння в AI.

В AI загалом не треба, а конкретно в ці AI-продукти — цілком можливо, що й треба. Якщо я придумав новий світлофор, але позначення на ньому контрінтуїтивні і 99% людей інтерпретують їх неправильно, то цілком можливо, що це хріновий свілтофор. Хіба що якщо більшість людей через якийсь час самі переналаштуються на інший спосіб взаємодії зі світлофором/AI-помічником. Але це не гарантовано. І, знов-таки, це оцінюватиметься на практиці.

* Я не кажу, що це так. Я не користувався AI-помічниками і не спостерігав, як інші люди ними користуються. Я просто кажу, що такі речі в ідеалі мають оцінюватися комплексно, а не у відриві від усього.

Ще би якісь приклади коду виклали. А то виглядає як висер вчених

В 3 кліки можна перейти на оригінал статті, і там є приклади коду, хоч і небагато. arxiv.org/pdf/2211.03622.pdf

Редакція ДОУ могла би і напрягтись за нас всіх. А то кожен має сам шукати приклади.

Є такий академік — Ніколас Карр — який не перший десяток років досліджує вплив автоматизації на інтелект людини. Рекомендую його книгу «The Glass Cage: How Our Computers Are Changing Us»

Підписатись на коментарі