Помилки ШІ-асистентів для програмування та як їх уникати

Більшість помилок ШІ-асистентів для програмування починаються до генерування коду: завдання нечітке, обмеження приховані або ніхто не визначив, як перевірити результат. Запобігання полягає не у відмові від ШІ. Воно полягає в тому, щоб дати асистенту кращу інженерну проблему для розв’язання.

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

«Перемістіть кнопку до бічної панелі» повідомляє асистенту, де щось розташувати, але не пояснює, чому поточне розташування не працює.

Запобігання: Спершу вкажіть проблему користувача та результат.

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

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

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

«Очистіть потік автентифікації» запрошує до великого diff. Асистент може торкнутися провайдерів, маршрутів, тестів і API-викликів, бо не бачить межі.

Запобігання: Назвіть першу межу та цілі поза межами завдання.

Перевірте лише callback входу й його безпосередні тести. Не змінюйте зв’язування
облікових записів, оплату або захисники маршрутів, якщо докази не показують, що callback
неможливо виправити ізольовано.

Якщо робота справді перетинає межу, асистент має пояснити чому до її розширення.

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

Запобігання: Додайте ключові інваріанти до промпту або постійних настанов проєкту.

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

Тримайте список коротким і конкретним. Довгий список побажань менш корисний, ніж кілька контрактів, які можна перевірити.

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

Запобігання: Вимагайте план перевірки до реалізації.

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

Запустіть перевірки. Перегляньте diff. Пройдіть шлях користувача. Вивід ШІ — це пропозиція, а не критерій випуску.

Великий diff приховує, чи виправлено справжню помилку. Його важко перевірити й майже неможливо безпечно відкотити.

Запобігання: Просіть послідовність невеликих контрольних точок.

Спершу відтворіть і поясніть збій. Потім внесіть лише виправлення стану й додайте
регресійний тест. Не виконуйте рефакторинг пов’язаних компонентів, доки цільовий тест
не пройде, а diff не буде перевірено.

Менша зміна може виявити, що запланований рефакторинг не був потрібен.

«Зробіть цю сторінку швидшою» може призвести до кешування, мемоїзації або поділу коду, які приховують справжнє вузьке місце й створюють нові ризики інвалідації.

Запобігання: Просіть вимірювання та альтернативи.

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

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

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

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

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

Це перетворює «приберіть бічну панель» на справжнє обмеження дизайну.

Виробничі інциденти створюють терміновість, але терміновість не є підставою дозволяти асистенту вгадувати за симптомом.

Запобігання: Використовуйте послідовність «від доказів до перевірки»:

докази -> гіпотези -> перевірка -> найменше виправлення -> регресійний тест ->
перевірка безпечного розгортання

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

Проблема: [На кого це впливає і що відбувається?]
Межі завдання: [Що слід дослідити насамперед?]
Результат: [Який спостережний результат потрібен?]
Обмеження: [Що не повинно змінитися?]
Докази: [Тест, журнал, знімок екрана, вивід команди або відтворення.]
Критерії прийняття: [Як ми дізнаємося, що це спрацювало?]
Перевірка: [Тести, ручні перевірки або вимірювання.]

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

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

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