Головна цифра — не генерація, а довіра
Разом ці три цифри описують індустрію, яка почала використовувати інструменти швидше, ніж виробила процес для їх безпечного застосування. Ризик — не в самій генерації коду за допомогою AI, а в тому, що згенерований код відправляють у продакшн з такою ж ретельністю перевірки, як перший pull request джуніора, тоді як обсяг давно перевищив те, що може реально охопити ручний рев'ю.
Про що не каже фраза "це написав AI"
Згенерований код може бути синтаксично правильним, легко читатися при швидкому перегляді — і водночас бути помилковим у речах, які проявляються лише під навантаженням, на межових випадках або там, де порушено якесь припущення щодо безпеки, про яке модель просто не могла знати — наприклад, внутрішнє правило авторизації, яке ніде не задокументовано в доступному моделі вигляді. Код, що виглядає гладко, — це не те саме, що код, який є коректним, і ставлення до них як до рівнозначних — саме так і виникає 29% відкатів релізів.
Де згенерований AI код насправді дає збій
- Мовчазні припущення щодо обсягу задачі. Модель заповнює прогалини правдоподібним припущенням замість того, щоб перепитати — і це припущення часто виглядає розумним, але подекуди виявляється точно неправильним саме для вашої системи.
- Застарілі патерни. Згенерований код часто відображає найпоширеніший спосіб розв'язання задачі в даних, на яких навчалася модель, а не той спосіб, який уже прийнятий у вашій кодовій базі — це створює тиху неузгодженість, яка з часом накопичується.
- Припущення щодо безпеки, "закладені" через пропуск. Перевірки авторизації, валідацію вхідних даних і обмеження частоти запитів легко пропустити у фрагменті коду, який "виглядає завершеним", адже сам фрагмент не знає, чого йому бракує.
- Неперевірені межові випадки, які виглядають перевіреними. Тестові набори, згенеровані AI, можуть демонструвати високі показники покриття, при цьому перевіряючи "щасливий шлях" різними способами замість тих сценаріїв відмов, які насправді мають значення.
Код, згенерований AI, варто перевіряти так, як ви б перевіряли першу здачу роботи швидкого, здібного, але позбавленого контексту підрядника в новій кодовій базі — а не так, як пропускаєте рутинну зміну від сеньйора-колеги. Швидкість генерації — реальна перевага. Але вона не скасовує етап рев'ю; якщо на щось і впливає, то радше підвищує, а не знижує значущість цього етапу при зростанні обсягів.
Що насправді працює на практиці
| Практика | Чому вона важливіша саме для коду, згенерованого AI |
|---|---|
| Рев'ю сеньйора на кожному мерджі, без винятків "це ж дрібна зміна" | Впевненість і коректність згенерованого коду не корелюють між собою — навіть невеликий на вигляд diff може приховувати неправильне припущення |
| Тести, написані або перевірені людиною, а не лише згенеровані разом із кодом | Тестовий набір, згенерований тим самим процесом, що й код, може успадкувати ті самі сліпі зони |
| Явний контекст для моделі — ваші реальні патерни, а не загальні best practices | Знижує ймовірність правдоподібного, але неузгодженого результату ще на етапі генерації |
| Ставлення до результату AI як до чернетки, а не готового PR | Відповідає реальній надійності інструментів сьогодні, а не тій, що обіцяє маркетинг |
Чому це аргумент за команду лише з сеньйорів, а не проти AI-інструментів
Цифри щодо відкатів релізів і рівня довіри — це не аргумент проти використання AI для написання коду: приріст продуктивності реальний і вартий того. Це аргумент на користь того, що етап рев'ю потребує рецензента, який справді здатен помітити те, чого не бачить модель: людину, яка знає кодову базу, предметну область і розуміє, як виглядає "здається нормальним, але тут це не так". Це проблема рівня сеньйора-інженера, а не проблема інструментів, і саме тому зниження ретельності рев'ю заради швидкості зазвичай обертається втратою цього часу пізніше — з відсотками — у вигляді відкату релізу.
Хочете прискорену розробку з AI без ризику відкатів?
Наші інженери використовують AI-інструменти, щоб працювати швидше — і перевіряють усе, що вони створюють, так само, як перевіряли б власну роботу.
Поширені запитання
Чи варто заборонити AI-інструменти для написання коду, поки наш процес не наздожене?
Зазвичай ні — приріст продуктивності реальний, а заборона зазвичай просто переводить використання в "тінь", не вирішуючи проблему з рев'ю. Кращий підхід — посилити ретельність рев'ю відповідно до нового обсягу, а не прибирати інструмент, який цей обсяг створив.
Чи потребує код, згенерований AI, іншого підходу до тестування, ніж код, написаний людиною?
Мета тестування та сама — виявити реальні сценарії відмов, — але варто особливо скептично ставитися до тестів, згенерованих AI, оскільки тестовий набір, створений разом із кодом, який він перевіряє, може успадкувати ті самі сліпі зони замість того, щоб незалежно їх виявляти.
Як перевіряти код, згенерований AI, швидше, не жертвуючи якістю?
Дайте моделі більше реального контексту заздалегідь — ваші справжні патерни, справжні обмеження, — щоб результат першої чернетки потребував менше виправлень. Це зменшує навантаження на рев'ю, не знижуючи планку, якій воно має відповідати.
Чи стосується цей ризик відкату конкретного AI-інструменту для написання коду?
Ні — дані опитувань відображають загальногалузеву закономірність для різних інструментів, а не недолік якогось конкретного продукту. Спільним фактором є процес, а не конкретна модель чи інтеграція з IDE.