Як переглядати код, згенерований ШІ

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

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

Підлаштуйте перевірку під ризик

Не кожна зміна потребує однакової уваги.

Крок 1: Подивіться, що змінилося

Перед оцінкою коду отримайте список змін:

• Якщо проєкт у Git, перегляньте diff: файли і рядки, що змінилися з останнього коміту. Див. як використовувати Git із застосунком, побудованим через ШІ.
• Або запитайте ШІ напряму:

Перелічіть кожен файл, який ви змінили в останній зміні, і для кожного в одному реченні поясніть, що змінилося і чому.

Тривожні ознаки на цьому етапі: файли, не пов'язані із запитом, видалені файли, зміни конфігурації або залежностей, які ви не просили.

Крок 2: Спершу протестуйте поведінку

Читання коду каже, що він має робити; тестування показує, що він робить. Перш ніж читати:

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

Якщо тестування провалюється, ви вже зекономили час на читанні — чітко опишіть проблему і дайте ШІ її виправити. Див. як написати хороший звіт про помилку.

Крок 3: Перевірте права доступу на сервері

Найважливіше, що варто перевірити. Інструменти ШІ часто ховають кнопку на сторінці, але залишають сервер готовим виконати дію для будь-кого, хто її попросить.

Для кожного маршруту або функції, які читають чи змінюють дані, запитайте:

• Чи перевіряється, що користувач увійшов?
• Чи перевіряється, що цей користувач має право доступу до цього запису?
• Чи ця перевірка на сервері, а не лише на сторінці?

Для кожного маршруту API, який ви додали або змінили, скажіть мені, яку перевірку прав він робить на сервері, процитувавши рядок. Позначте кожен маршрут без неї.

Потім протестуйте це: увійдіть як користувач A, запишіть ID запису, увійдіть як користувач B і запросіть його. Повну перевірку містить контрольний список безпеки для застосунків, створених ШІ.

Крок 4: Шукайте витеклі секрети

• Пошукайте в змінених файлах усе, що схоже на ключ або пароль.
• Переконайтеся, що секретні ключі читаються зі змінних середовища і використовуються лише в серверному коді.
• Стежте за публічними префіксами, як-от VITE_ або NEXT_PUBLIC_, на секретних змінних — їх вбудовано в код браузера.

Див. як зберігати ключі API в безпеці.

Крок 5: Перевірте вхідні дані та помилки

• Валідація на сервері. Перевірки в браузері можна обійти. Обов'язкові поля, довжини, формати і дозволені значення також мають перевірятися сервером.
• Запити до бази даних використовують параметри, а не текст, зібраний із введених користувачем даних.
• Помилки не ковтаються. Блок try/catch, який нічого не робить, приховує збої. Помилки мають записуватися в журнал, а користувачі мають бачити зрозуміле повідомлення.
• Користувачам не показують внутрішні деталі — трасування стеку і помилки бази даних належать до журналів.

Крок 6: Перевірте, що це реально існує

Моделі ШІ іноді створюють код, який виглядає правильно, але посилається на речі, яких не існує.

• Пакети: кожна нова залежність має бути реальним, підтримуваним пакетом з точно такою назвою. Остерігайтеся назв, що схожі на друкарські помилки в популярних.
• Функції та опції API: якщо код викликає функцію бібліотеки або опцію зовнішнього API, яких ви ніколи не бачили, перевірте офіційну документацію.
• Заглушки: шукайте TODO, mock, fake, жорстко закодовані зразки даних або функції, що повертають фіксоване значення.

Чи додали ви нові пакети? Для кожного вкажіть точну назву, для чого він потрібен і чи можна без нього обійтися.

Крок 7: Перевірте, чи пасує це

Код може працювати і водночас ускладнювати зміни застосунку в майбутньому:

• Дублювання. Та сама логіка, скопійована в кількох місцях, розійдеться.
• Узгодженість. Вона має дотримуватися патернів, які використовує решта застосунку.
• Розмір. Запит на 20 рядків, що породив 600 рядків, варто поставити під питання.
• Мертвий код. Старі версії, що залишилися поруч із новими.

Чи є в проєкті код, який тепер не використовується через цю зміну, або логіка, що дублюється деінде? Нічого не змінюйте, просто перелічіть.

Поширені помилки

• Схвалення, бо виглядає чисто. Охайний код може все одно пропустити перевірку прав.
• Читання замість тестування. Спершу тестуйте, потім читайте.
• Тестування лише щасливого сценарію. Спробуйте погані дані, не того користувача і без входу.
• Ігнорування незв'язаних змін у файлах. Запитайте, чому змінився кожен файл.
• Повна довіра до самоперевірки. Використовуйте огляд ШІ як першу перевірку і підтверджуйте тестуванням.
• Перегляд тижня змін одразу. Переглядайте невеликі зміни в міру їх появи.

Контрольний список

• Я знаю, які файли змінилися і чому, і що нічого зайвого не змінилося.
• Зміна працює на комп'ютері і телефоні, з поганими даними, без входу і як інший користувач.
• Кожен маршрут з даними перевіряє вхід і власність на сервері.
• Немає секретів у коді або збірках для браузера.
• Вхідні дані валідуються на сервері; запити використовують параметри.
• Помилки записуються в журнал, не ковтаються і не показуються користувачам у деталях.
• Нові пакети справжні і потрібні; не лишилося вигаданих функцій чи заглушок.
• Зміни високого ризику отримали уважне читання і, де потрібно, другого рецензента.

Перегляд коду на Mythex

• Режим Ask відповідає на запитання про код без редагування — ідеально для запитів «поясни кожну зміну» і «які маршрути не мають перевірки прав». Див. Чат.
• Перегляд коду показує дерево файлів, редактор і термінал на кожному тарифі (лише читання на Free, редагування на Pro), щоб ви самі могли прочитати, що змінилося. Див. Редактор коду.
• /test змушує агента пройти попередній перегляд як користувач і повідомити про зламані сценарії.
• Контрольні точки дозволяють відкотити зміну, що не пройшла перевірку.

Якщо розробник переглядає код за вас, як працювати з розробником над застосунком, створеним через ШІ пояснює передачу; якщо перевірка виявила помилку, див. як налагодити застосунок, створений через ШІ.

Запитання