AI-код і технічний борг: хто прибирає після агентів

AI-код і технічний борг варто обговорювати разом: за галузевими оглядами, pull request’и з AI-асистованим кодом містять у 1,7 раза більше проблем, ніж написані людиною. Агенти вже в роботі, тож практичне питання — хто перевіряє результат, виправляє помилки й підтримує його далі. Ось де шукати приховану роботу та як домовитися про неї в команді.

Коротко:

— Враховуй перевірку й підтримку, коли оцінюєш виграш від генерації.

— Цифри з оглядів потребують перевірки за першоджерелами.

— Домовся, хто пояснює код, перевіряє безпеку й прибирає дублювання.

AI-код і технічний борг: що показують наведені дані

Матеріали Innovative Group, Of Ash and Fire та огляд літератури на arXiv посилаються на різні первинні дослідження. Нижче — показники з галузевих оглядів; умови вимірювання кожного з них потрібно звіряти з першоджерелом.

Ці цифри варто перевіряти за першоджерелом: які саме завдання досліджували, що вважали проблемою та з чим порівнювали результат. Наведені діапазони не варто усереднювати, а показники для різних умов — подавати як суперечність між джерелами. Зокрема, загальна частка випадків з уразливостями та рівень збоїв для Java описують різні зрізи.

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

Готовий pull request ще потребує перевірки й прибирання

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

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

За галузевими оглядами, сеньйори повідомляють про більше часу на перевірку, коли джуніори сильно покладаються на AI-асистентів. Не перетворюй це на претензію до рівня людини: краще домовся, з якою підготовкою зміна потрапляє на рев’ю. Автору варто принести пояснення рішення, результати перевірок і відкриті питання, які ще потребують допомоги.

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

Упевненість у коді не замінює перевірку безпеки

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

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

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

Що з цим робити

• Додай до опису pull request’а пояснення автора. Напиши, яку задачу вирішує код, чому обрано цей підхід і що ти перевірив. Незрозумілі місця познач прямо, щоб рев’юер знав, де потрібна спільна робота.
• Перевір дублювання до передачі на рев’ю. Знайди схожу логіку в проєкті й виріши, чи потрібна нова реалізація. Якщо залишаєш повторення свідомо, поясни причину поруч зі зміною.
• Оціни роботу після генерації. Порівнюй час підготовки коду, перевірки та виправлень у власних задачах. Обговорюй із командою весь шлях до прийнятної зміни, а не лише момент появи готового фрагмента.
• Закріпи відповідальність за відкладені виправлення. Запиши проблему, відповідальну людину й умову повернення до неї. Не залишай рев’юера єдиним, хто пам’ятає про борг.
• Збережи самостійний дебаг у навчанні. Спробуй відтворити збій і сформулювати власне пояснення перед зверненням до асистента. Потім зістав його підказку зі своїми спостереженнями.

Хто перевіряє AI-код, шукає дублювання і бере на себе виправлення вразливостей — питання, які варто проговорювати вголос, а не тягнути самому. Двічі на місяць по п'ятницях це можна обговорити в клубі тех-спільноти Рівного: зустріч Silicon Drinkabout безкоштовна, без реєстрації. Принеси свій приклад розподілу відповідальності за техборг і зістав його з чужим досвідом.