Розробник просить асистента написати функцію, яка перевіряє, чи може користувач завантажити звіт. Код компілюється. Тест на щасливий шлях проходить успішно. Запит на зняття виглядає акуратно. Через два тижні колега помічає, що функція перевіряє, чи користувач увійшов у систему, але ніколи не перевіряє, чи належить йому звіт.
Це ілюстративний сценарій, а не задокументований інцидент. Він описує прогалину, яку має заповнити навчання з перевірки коду, згенерованого штучним інтелектом: згенерований код, який проходить базову перевірку, все ще може містити недолік авторизації або паралельності, і людина, яка його перевіряє, повинна знайти його та пояснити, чому це важливо.
Цей посібник призначений для керівників інженерних відділів та менеджерів з інженерного забезпечення. У ньому розповідається, як описати проблему продуктивності, діагностувати прогалини, підготувати та практикувати проектування, опрацювати кейс та оцінити, чи можна застосувати навички до реальних перевірок. Йдеться про проектування навчання. Кожен дефект, тест та правило перевірки у вашій програмі повинні бути перевірені старшими інженерами та вашою командою безпеки.
Що таке навчання з перевірки коду, згенерованого штучним інтелектом?
Навчання з перевірки коду, згенерованого штучним інтелектом, навчає розробників чітко підказувати асистенту, а потім оцінювати та перевіряти отриманий код: чи він правильний, чи безпечний, чи поводиться він під одночасною навантаженням, чи достатньо ефективний? Це не курс про конкретний інструмент. Він навчає звичці перевірки, яка залишається незмінною, коли інструмент змінюється.
Швидкі факти
| Питання | Коротка відповідь |
|---|---|
| Яке завдання? | Проведіть аудит згенерованого коду та обґрунтуйте кожен ризик за допомогою тесту. |
| Який бал ви отримуєте? | Якість перевірки та чи були виявлені відповідні дефекти. |
| Чи достатньо тесту з правил безпечного кодування? | Ні. Це підтверджує передумови, але не те, чи може розробник помітити недолік у коді, який виглядає правдоподібним. |
| Хто перевіряє зміст? | Керівник інженерної служби та ваша команда безпеки. |
| Чого не можуть виправити тренування? | Час на перегляд, інструменти, нечітка структура власності та тиск на швидке об'єднання. |
| Звідки ви знаєте, що це спрацювало? | Нова, невідома вправа з кодом, оцінена за узгодженими критеріями, з подальшим відстеженням реальних відгуків. |
1. Опишіть проблему продуктивності
Почніть із завдання: перевірте згенерований код та обґрунтуйте ризики за допомогою тестів. Аудит – це читання з підозрою. Обґрунтування – це перетворення підозри на доказ, зазвичай тест, який не проходить, або відтворення, яке показує недолік.
Дослідження показує, чому це потребує цілеспрямованої практики. У дослідженні GitHub Copilot Пірс та його колеги створили 1,689 програм за 89 сценаріями, обраними за відомими типами вразливостей, і виявили, що близько 40 відсотків з них були вразливими (Пірс та колеги, 2021). Це був ранній інструмент і певний набір сценаріїв, тому не варто розглядати цю цифру як показник для сучасних асистентів. В окремому дослідженні користувачів учасників просили написати код з асистентом на базі штучного інтелекту та без нього. Ті, хто мав асистента, писали значно менш безпечний код і частіше вважали свій код безпечним (Перрі та колеги, 2023). У цьому ж дослідженні було виявлено, що учасники, які менше довіряли асистенту та більше взаємодіяли з його підказками, мали менше вразливостей.
З розробки навчальних матеріалів випливають два висновки. Правдоподібний результат потребує активного експерта. А впевненість – це не доказ, тому вправа має запитувати про перевірку, а не думку.
Напишіть заяву про продуктивність одним реченням і попросіть керівника інженерної служби перевірити її: «Враховуючи згенеровану зміну, розробник перераховує ризики безпеки, паралельності та ефективності, які він бачить, і для кожного з них описує або пише тест, який би це показав».
2. Діагностуйте прогалини у навчанні та контексті
Перш ніж щось створювати, порівняйте завдання з тим, що практикується та оцінюється у вашій поточній програмі. Три питання зазвичай відрізняють прогалину в навчанні від чогось іншого:
- Чи використовує сучасна практика реальне завдання? Якщо навчання охоплює швидке написання, але ніколи не просить розробників перевіряти результат, ніхто не практикував аудит. Якщо оцінювання – це тест із множинним вибором на правила безпечного кодування, воно вимірює приховування.
- Що таке когнітивний попит? У переглянутій таксономії Блума оцінка безпеки коду та вибір тесту, який це доводить, знаходяться на рівнях аналізу та оцінки, а розробка кращого запиту або виправлення досягає рівня створення. Зіставлення дій з цими рівнями розглядається в нашому посібнику з зіставлення навчальних завдань з таксономією Блума.
- Чи щось, окрім навичок, заважає? Перевірте час перевірки, інструменти та відповідність. Якщо у рецензентів є п'ять хвилин на кожен запит на внесення змін, жодне навчання не призведе до аудиту. Якщо в конвеєрі немає статичного аналізу або набору тестів, розробник може знайти ризик, але не обґрунтувати його. Повідомте про причини, що не пов'язані з навчанням, людям, які можуть їх виправити.
3. Підготовка та практика проектування
Як тільки ви зрозумієте, які прогалини може заповнити навчання, дайте кожному етапу окреме завдання.
Підготовка. Перевірте передумови за допомогою короткої діагностики: загальні категорії слабких місць, з якими стикається ваш стек, як структуровані ваші тести, контрольний список, який використовує ваша команда. На цьому етапі підходить самостійне навчання. Перевірка повторення підтверджує лише передумови.
Практика. Використовуйте аудиторські вправи, побудовані на основі реалістично згенерованого коду. Засійте кожну з них невеликою кількістю дефектів різного типу, таких як відсутня перевірка власності, змагання між двома запитами та неефективний цикл, плюс деякий код, який працює належним чином. Розробник переглядає, називає кожен ризик, пояснює його серйозність та пропонує тест, який би це показав. Просіть про обґрунтування, а не список номерів рядків.
Зворотний зв'язок. Пов’яжіть це з рішеннями, а не із загальним балом. Фраза «Ви позначили цикл, але не перегони на спільному лічильнику, і ваш тест не виявив би цього, оскільки він виконує запити по одному» корисніша, ніж «Знайдено 2 з 3».
Живий ввід чи асинхронний огляд? Живий внесок додає найбільшої цінності, коли ризик неоднозначний, і розробники дізнаються, слухаючи пояснення старшого інженера, чому вони блокують об'єднання. Асинхронного огляду достатньо для порівняння висновків розробника з анотованим експертним оглядом. Багато команд використовують обидва варіанти: спочатку підготовку у власному темпі, а потім фасилітовану сесію для розгляду складних випадків.
4. Розгляньте реалістичний приклад
Ілюстрація. Керівник інженерного відділу повинен перевірити кейс та критерії відповіді перед використанням.
Справа. Згенерована кінцева точка повертає рахунок-фактуру клієнта за ідентифікатором рахунку-фактури. Вона перевіряє, чи має абонент дійсний сеанс, використовує параметризований запит і проходить базовий тест. Та сама функція збільшує спільний лічильник завантажень без блокування.
Завдання. Розробник визначає кожен ризик, який він бачить, ранжує їх та описує тест, який би підтвердив кожен з них.
Перша спроба. «Виглядає добре. Запит параметризовано, і тест пройдено». Розробник розглядав пройдений тест як доказ і не запитував, чого тест не охоплює.
Зворотній зв'язок та повторна спроба. Рецензент просить розробника назвати, що доводить перевірка сеансу, а що ні. Повторна спроба просить його розглянути двох різних клієнтів та два одночасні запити.
Сильніша спроба. «Перевірка сеансу підтверджує, хто телефонує, а не те, що рахунок належить саме йому. Я б написав тест, у якому клієнт А запитує ідентифікатор рахунку клієнта Б та очікує відмови. Лічильник збільшується без синхронізації, тому два запити одночасно можуть втратити оновлення. Я б запустив паралельний тест і порівняв лічильник. Сам запит параметризований, тому я б не витрачав на це час». Зверніть увагу, що ця відповідь ранжує ризики та пов’язує кожен з тестом.
Чому кожна відповідь є обґрунтованою або неповною. Оцінюйте кожен варіант за затвердженими критеріями, а не за вподобаннями рецензента. Перша спроба відповідає звичці, але не містить доказів. Більш переконлива спроба є конкретною, пріоритетною та такою, що може бути перевірена.
5. Оцінка можливостей та планування передачі
Доказом здібностей є виконання нової вправи, яку учень ще не бачив. Якість перевірки оцінок та виявлення відповідних дефектів. Проста рубрика використовує шкалу від 0 до 2 за кожен критерій:
| критерій | Спостережувані докази |
|---|---|
| Виконання завдання | Перевіряє згенерований код та записує докази кожного висновку. |
| Обґрунтування | Пояснює обмеження, альтернативи та те, що залишається невизначеним, а також ранжує ризики. |
| Межі | Дотримується правил перевірки команди та передає запит спеціалісту з безпеки, коли ризик виходить за межі його компетенції. |
Якірні показники: 0 – відсутній або непідтверджений, 1 – частковий з відповідними пропусками, а 2 – повний та обґрунтований відповідно до узгоджених критеріїв. Окремо визначте критичні помилки, такі як затвердження коду із незахищеним шляхом доступу, щоб загальна оцінка не могла їх приховати. Ця рубрика є пропозицією, а не затвердженим стандартом готовності: адаптуйте її разом з керівником інженерії та пілотуйте. Наш посібник з розробка інтерактивної практики з корисним зворотним зв'язком показує, як писати відгуки, що посилаються на рішення.
Плануйте перенесення ретельно. Після вправи об’єднайте кожного розробника зі справжнім пул-реквестом, який включає згенерований код, і разом перегляньте їхні висновки або проведіть короткий ретроспективний аналіз нещодавнього огляду, в якому щось пропущено.
Де допомагає інтерактивна доставка
Інтерактивні формати допомагають усім взяти на себе зобов'язання, перш ніж вони побачать групу. Під час живого сеансу фасилітатор може показати згенерований фрагмент коду, попросити кожного розробника ввести ризики, які він бачить, та тест, який він би написав, а потім розкрити розкид перед обговоренням. Та сама вправа може виконуватися у власному темпі для підготовки. AhaSlides підтримує інтерактивне навчання та перехід між живим сеансом та власним темпом. Це інструмент для презентацій та навчання, а не місце для виконання коду, тому виконуйте вправи з кодом у власному середовищі. Звірте будь-яку конкретну функцію створення, зворотного зв'язку або звітності, на яку ви плануєте покладатися, зі своїм власним робочим процесом. Щоб отримати рекомендації щодо вибору форматів, дивіться нашу статтю про коли використовувати адаптивне, інтерактивне та живе навчання.
Виміряйте, що змінилося
Заздалегідь вирішіть, що покаже, що розробники можуть виконати завдання. Порівняйте якість перевірки та виявлення дефектів на невидимій вправі з базовим рівнем. Визначте, хто бере участь, знаменник та терміни. Якщо результати покращуються, перевірте, що ще змінилося за той самий період, наприклад, нове правило статичного аналізу, переглянутий контрольний список або зміна асистента, перш ніж зараховувати навчання.
Обмеження, які можуть залишитися
- Час огляду. Аудит триває довше, ніж попередній, а терміни виконання скорочуються.
- Інструменти. Без випробувального джгута або сканування трубопроводу ризик важко підтвердити.
- Зміна інструментів. Помічники швидко змінюються, тому вправи мають бути спрямовані на звичку оглядати, а не на один продукт.
- Покриття справ. Одна вправа показує кілька типів дефектів. Оцінка не описує судження розробника загалом.
- Трансфер Продуктивність на семінарі — це не те саме, що продуктивність у щільній черзі на перевірку.
Заздалегідь назвіть їх спонсорам та сплануйте окремі виправлення. Навчання покращує те, що розробник може знайти та довести. Воно не створює часу чи інструментів.
Часті питання
Що таке навчання з перевірки коду, згенерованого штучним інтелектом?
Він навчає розробників підказувати, оцінювати та перевіряти код, створений помічником штучного інтелекту, виявляти проблеми безпеки, паралельності та ефективності, а також підкріплювати кожну з них тестом.
Чи згенерований код менш безпечний, ніж людський код?
Дослідження вказують на ризик, але результати залежать від інструменту, завдання та дизайну дослідження. Одне дослідження користувачів показало, що учасники з асистентом писали менш безпечний код і почувалися впевненіше щодо нього, що є причиною для розвитку звички перегляду.
Як ви оцінюєте, чи можуть розробники перевіряти згенерований код?
Наведіть нову вправу з коду та оцініть якість перевірки та виявлення дефектів за узгодженими критеріями. Вікторина з правил безпечного кодування підтверджує лише передумови.
Чи потрібна вам пісочниця коду для навчання?
Вам потрібне місце для виконання вправ, зазвичай це ваше власне середовище. Переконайтеся, що будь-який інструмент, який ви використовуєте, відповідає вашим потребам, перш ніж покладатися на нього.
З чого почати
Виберіть один повторюваний тип згенерованих змін у вашій кодовій базі. Напишіть заяву про продуктивність, попросіть керівника інженерії перевірити початкові дефекти та тести, які їх виявлять, а також складіть рубрику з трьома критеріями зі шкалою від 0 до 2 та списком критичних помилок. Проведіть пілотне випробування з невеликою групою, перш ніж розгортати.
Щоб побачити, як аудиторська вправа може бути проведена в прямому ефірі з вашою власною командою та використана повторно у власному темпі згодом, ознайомтеся з AhaSlides.
