Код, згенерований ШІ: що мають перевірити інженери перед запуском

Чому код від AI ламається інакше

Людські помилки зазвичай схожі на помилки: заплутана функція, забутий TODO, дивна назва. Помилки AI схожі на готову роботу. Код охайний, із коментарями, правдоподібний — і саме тому рецензент розслабляється там, де не варто.

Ось типові збої:

• Локально правильно, глобально — ні. Кожна функція робить те, що просили, але в системі загалом три способи перевіряти доступ і два способи форматувати суми.
• Лише вдалий сценарій. Код обробляє випадок із запиту й мовчки ігнорує решту: порожні списки, тайм-аути, повідомлення від платіжного сервісу, що прийшло двічі.
• Застарілі або вигадані API. Модель змішує версії бібліотек, викликає методи, яких уже немає, а іноді пропонує пакети, яких не існує взагалі. Зловмисник може зареєструвати таку назву й чекати, поки хтось її встановить.
• Тести, що нічого не тестують. Згенеровані тести можуть перевіряти лише те, що заглушка повертає те, що їй сказали повернути. Покриття високе, а перевірено нічого.
• Небезпечні налаштування з прикладів: відкритий CORS, режим налагодження, детальні повідомлення про помилки, ключі в конфігураційних файлах.

Це не вирок коду від AI загалом. Це означає, що перевірку треба спрямовувати саме в ці місця.

Чекліст

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

1. Доступи й ролі

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

2. Гроші й стан даних

• Суми зберігаються в копійках чи центах або в точних десяткових числах, ніколи не в числах з плаваючою комою.
• Повідомлення від платіжного сервісу перевіряються за підписом і обробляються так, щоб та сама подія двічі не дала двох виплат.
• Операції, що змінюють кілька записів, ідуть у транзакції або їх можна безпечно повторити.
• Двоє користувачів, що одночасно діють з одним об’єктом, не можуть обидва «виграти»: останній товар на складі, та сама угода, те саме місце.
• Часові пояси й дати задані явно, особливо для кінцевих термінів і розрахункових періодів.

3. Вхідні дані, файли й зовнішні запити

• Усе, що надходить, перевіряється на сервері, зокрема те, що «не може статися», бо форма такого не дозволяє.
• Запити до бази параметризовані, жодних запитів, складених зі шматків рядків.
• Завантаження файлів перевіряє тип і розмір, а файли зберігаються поза публічною частиною сервера.
• Функція, що завантажує щось за посиланням від користувача, не може звернутися до внутрішніх сервісів.
• На вхід, одноразові коди й усе «дороге» є обмеження кількості спроб.

4. Бібліотеки й залежності

• Кожен пакет існує, підтримується і є саме тим, що треба, а не двійником зі схожою назвою.
• Версії зафіксовані, файл блокування версій є в репозиторії.
• Ліцензії сумісні з тим, як ви використовуватимете продукт.
• Ніщо не підключено заради однієї функції, яка вже є в стандартній бібліотеці.

5. Інтеграції

• Код перевірено на справжньому API чи його тестовому середовищі, а не лише на документації, яку «пам’ятала» модель.
• Для кожного зовнішнього запиту є тайм-аут, повторні спроби з паузами й зрозумілий стан помилки.
• Ключі лежать у налаштуваннях середовища, а не в репозиторії.

6. Помилки, журнали й моніторинг

• Помилки перехоплюються там, де з ними можна щось зробити, і не зникають мовчки.
• Журнали допомагають знайти причину проблеми, але не містять паролів, даних карток і зайвих персональних даних.
• Коли ламається щось важливе, про це хтось дізнається одразу.

7. Швидкодія

• Жодних запитів до бази всередині циклу по списку (так звана проблема N+1).
• Списки посторінкові: ніщо не вантажить цілу таблицю, щоб показати двадцять рядків.
• Для запитів, які продукт справді виконує, є індекси.

8. Тести, що мають сенс

• Тести перевіряють поведінку, важливу для користувача, зокрема сценарії збоїв.
• Принаймні критичні сценарії — реєстрація, оплата, головна дія продукту — мають наскрізні тести.
• Тести не згенеровані з того самого хибного розуміння, що й код. Якщо запит був неправильний, тести й код погодяться між собою і будуть неправі разом.

9. Узгодженість

• Для кожної типової речі один спосіб: одна перевірка доступу, один формат сум, одна форма помилок.
• Мертвий код і покинуті експерименти прибрано.
• Назви й структура відповідають решті коду, щоб наступний інженер міг у ньому зорієнтуватися.

Якщо потрібно глибше про безпеку, безплатний і надійний орієнтир, з яким можна звіряти перевірку, — OWASP Application Security Verification Standard.

Як організувати перевірку

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

1. Невеликі зміни. Зміну на кілька сотень рядків можна перевірити як слід, зміну на п’ять тисяч — лише проглянути. Просіть модель робити невеликі кроки, а не всю функцію за раз.
2. У кожної зміни є автор-людина. Інженер, який сформулював запит до AI, відповідає за результат, може пояснити кожен рядок і відповідає на запитання рецензента. «Це написав AI» — не пояснення.
3. Спершу машини. Перевірка типів, лінтери, аудит залежностей, пошук ключів і паролів у коді та автотести запускаються ще до того, як подивиться людина. Тоді рецензент витрачає увагу на логіку, а не на форматування.
4. Люди — на ризикованих ділянках. Увага senior-розробників іде на ділянки, описані вище: доступи, гроші, інтеграції, дані. Решта отримує легшу перевірку.
5. Тестове середовище з реалістичними даними, де QA проходить реліз так, як пройшов би користувач, перш ніж він потрапить у продакшн.

Хто що перевіряє

Не кожен рядок потребує однакової уваги. Саме правильний розподіл робить розробку з AI водночас швидкою й безпечною.

Як це пов’язано з форматами розробки

В EVA-X саме цей розподіл відрізняє наші три формати. В AI Build більшу частину коду генерує AI, а інженери перевіряють лише інтеграції та реліз — тому ми радимо його для прототипів і внутрішніх сервісів, де результат перевіряє людина. В AI + DEV інженери відповідають за архітектуру, критичну логіку, інтеграції й повний QA — тобто за рядки таблиці з позначкою «рядок за рядком». У DEV код від початку до кінця пишуть senior-розробники, а AI ніколи не є автором. Який формат підходить якому продукту, ми розібрали в статті AI Build, AI + DEV чи DEV.

Хоч би з ким ви працювали, поставте одне запитання: хто остаточний автор кожної частини коду і хто що перевіряє? Чітка відповідь — добрий знак. «Наші розробники використовують AI» — не відповідь.

Що можна перевірити, не читаючи код

Щоб помітити багато з того, що пропускає слабка перевірка, не обов’язково бути інженером. Коли модуль приходить на приймання:

• Прочитайте опис передання. У ньому має бути сказано, що зроблено і як це перевірити. Якщо ні — попросіть.
• Пройдіть сценарії збоїв. Введіть порожні й абсурдні значення. Двічі натисніть «Сплатити». Поверніться назад у браузері посеред оформлення. Вимкніть інтернет на телефоні на середині форми.
• Поміняйтеся ролями. Увійдіть як звичайний користувач і відкрийте посилання на сторінку адміністратора чи на чужий запис.
• Зробіть те саме двічі одночасно. Відкрийте той самий запис у двох вкладках чи на двох пристроях і змініть в обох.
• Перевірте «нудні» речі. Скидання пароля, підтвердження пошти, вихід з усіх пристроїв, видалення акаунта.

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

Тривожні сигнали, коли код пише переважно AI

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

Кілька слів про права на код

Код, написаний за допомогою AI, ставить юридичне питання, якого немає у звичайного коду: частина його може взагалі не охоронятися авторським правом. Це не заважає вам володіти продуктом і користуватися ним, але варто подивитися, як це прописано в договорі. За умовами EVA-X права переходять до вас після повної оплати договору, а на згенеровані AI частини, які не охороняються, студія передає ті права, що має, і не висуває на них жодних претензій. Детальніше — у статті кому належить код.

Якщо ви плануєте продукт з AI-функціями чи розробку з використанням AI, загляньте на сторінку розробки AI-застосунків або опишіть продукт в оцінці, щоб побачити модулі, рекомендований формат і ціну; команда розбере оцінку з вами, перш ніж договір її зафіксує.