Регресія у вайбкодингу: тест на баг, щоб ШІ не ламав

Чому ШІ не бачить своєї ж помилки

Уяви: ти склав контрольну і сам же її перевіряєш. Слово «карова» через «а» ти не помітиш ні першого разу, ні десятого - у твоїй голові воно так і пишеться. Перечитай хоч двадцять разів. Щоразу впевнено скажеш: «усе правильно».

ШІ - це той самий учень. Він сам пише і сам перевіряє. І спотикається він в одних і тих самих місцях. Лагодить баг, дивиться на свою роботу, каже «виглядає правильно» - а баг усе ще там. Живий і задоволений. За годину ти просиш поправити щось поруч, і він ламає те, що щойно полагодив. І знову впритул не бачить.

Навіщо це знати вайбкодеру

Ти вайбкодер. Тести руками ти не пишеш. Але ти маєш розуміти, чому ШІ наступає на ті самі граблі - і вміти попросити його підстелити соломки. Розберешся в механіці - і ось що отримаєш:

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

Різниця між «ШІ мені вічно щось ламає» і «ШІ мені більше це не ламає» - це один маленький автотест, написаний у потрібну мить.

Головна пастка: ШІ перевіряє сам себе

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

1. ШІ додав нове поле у відповідь сервера - але забув попросити його з бази. Сам перевірив, нічого не помітив.
2. Попросив із бази - вилізла інша помилка, у типах. Знову перевірив крок 1, а нову біду проґавив.
3. Поправив - але полагодив лише робочий режим, а про демо-режим забув. Перевірив - знову повз. Четвертий захід.
4. І тільки тест упіймав помилку миттєво, з першого запуску. Без суперечок і самозаспокоєння.

Як лікується: тест на впійманий баг

Лікування просте і трохи контрінтуїтивне. Тобі не потрібно вкривати тестами весь проєкт - це довго, дорого і майже марно. Потрібне інше.

Регресія Регресія - це коли щось, що раніше працювало, раптом зламалося назад після нового виправлення. «Регресійний тест» - сторож, який ловить саме такий відкат назад. - це коли вже полагоджене ламається назад. І головне правило звучить так:

Пиши тест не на код, який працює, а на баг, який уже знаходили.

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

Найчастіший повтор: полагодив одне, забув друге

У тому реальному проєкті 3 баги з 4 були одного ґатунку. У коді є два шляхи: робочий (зі справжніми даними) і демо (з приблизними, щоб швидко показати сайт). ШІ лагодить один шлях і геть забуває про другий. Класика. Як забути другу шкарпетку.

Приклад із життя: налаштування сповіщень

Ти робиш із ШІ сайт бронювання. Просиш: «додай у профіль налаштування сповіщень». Він додає, бадьоро рапортує «готово». Відкриваєш - порожньо. Просиш полагодити - полагодив, знову порожньо. І так по колу. Ти вже закипаєш і думаєш, що ШІ остаточно зламався.

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

Тямущий вайбкодер тут не просить «полагодь ще раз» ушосте. Він просить поставити сторожа:

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

Спершу напиши маленький автотест, який перевіряє, що у відповіді профілю є поле налаштувань сповіщень і воно не порожнє. Назви тест за іменем бага.
Запусти тест. Він має впасти - це доведе, що баг реальний, а не вигаданий.
Тепер полагодь баг. Важливо: перевір ОБИДВА режими - і робочий, і демо. Вони мають повертати однаковий набір полів.
Знову запусти тест. Тепер він має пройти.
Перш ніж сказати «готово» - прожени всі тести цілком, щоб переконатися, що ти не зламав щось сусіднє.

Чек-лист: перевір по-справжньому, не на словах

ШІ радісно заявляє «все працює, я перевірив»? Не вір на слово. Попроси його діяти за порядком: спершу машина, потім очі.

1. Спершу прогін тестів. Упали - це баг номер один, без жодних міркувань. Машина не сперечається.
2. Потім перевірка збірки. Код узагалі не збирається - це важливіше за будь-яку красиву думку.
3. І тільки тепер - огляд коду очима, тримаючи в умі відомі сліпі зони (два шляхи, забуті поля).
4. На кожен знайдений баг - новий тест. Щоб наступного разу впіймалося само, без тебе.

Часті помилки новачка

• Вірити «я перевірив, усе працює». Та сама голова, ті самі сліпі зони. Проси прогнати тест.
• Просити «полагодь ще раз» по колу. Без сторожа баг повернеться вшосте. Проси тест на баг.
• Вкривати тестами весь проєкт. Довго і марно. Тест потрібен там, де реально ламалося.
• Забувати про другий шлях. Полагодив робочий режим - одразу проси перевірити й демо-режим.
• Робити огляд коду до прогону тестів. Спершу бездушна машина, потім думка ШІ. Не навпаки.
• Писати тест після лагодження і забивати. Краще спершу тест (він падає), потім лагодження (тест проходить).