Три баги, які я шукав годинами — і як AI знаходив їх за хвилини
За півроку соло-розробки я витратив десятки годин на баги, які в підсумку виявлялись дрібницею. Розбираю три найпоказовіші — не щоб похвалити AI, а щоб показати, де він реально допомагає, а де без людини не обійтись. Про такі випадки ретально пишу в своему каналі t.me/byti_boty
Баг перший: чорний екран замість особистого кабінету
Кабінет просто переставав відкриватись. Чорний екран, ніяких помилок для користувача, нічого в інтерфейсі.
Кинув задачу в чат. Перше, що почув: чорний екран — це майже завжди краш при рендері компонента, а не проблема мережі чи бекенду. І одразу пішов дивитись саме у файл кабінету.
Знайшов за хвилини: функція була оголошена поза межами компонента, а всередині неї використовувалась змінна, яка існує тільки в самому компоненті. React намагався відрендерити — натикався на змінну «з нізвідки» — і падав мовчки.
П’ять хвилин на пошук, дві на фікс. Що тут спрацювало: модель одразу знала, де шукати, за самим симптомом — це класичний патерн, який вона бачила тисячі разів.
Баг другий: анімація, яку хтось невидимо вбивав
Додав дрібницю: коли приходить нове повідомлення, іконка чату має підстрибнути. Дві години роботи, думав я.
Не працює. Причому взагалі — ні анімації, ні бейджа з лічильником, який я додав окремо для перевірки.
Далі було три хибні гіпотези поспіль. Може, у користувача вимкнені анімації в системі? Ні. Може, чат автоматично відкривається і бейдж зникає раніше, ніж спрацює? Логічно — прибрав автовідкриття. Не допомогло. Знайшов другий такий самий рядок в іншому обробнику, прибрав і його. Знову ні.
Розгадку дала одна фраза від людини, яка тестувала: «коли натискаю одну кнопку — анімація є, а коли просто пишу далі — немає».
Це змінило все. Якщо на одну подію анімація працює, а на іншу ні — справа не в анімації. Справа в тому, що другу подію хтось перехоплює.
І там справді був другий обробник тієї самої події, а в ньому рядок:
socket.off(eventName)
Виглядає невинно. Але socket.off() без другого аргументу знімає всі слухачі події, не тільки свій. Мій обробник реєструвався — і за мить його мовчки вбивав інший файл. Без помилки, без варнінга, консоль абсолютно чиста.
socket.off(event) знімає всіх. socket.off(event, myHandler) знімає тільки твій. Одне слово різниці, пів дня пошуку.
Баг третій: фікс, який не діяв тричі поспіль
У чаті плутався бейдж ролі співрозмовника — показувалась не та роль. Попросив виправити, поправили логіку в сторі, задеплоїли. Не спрацювало.
Копнули глибше — виявилось, та сама логіка завантаження була продубльована в іншому файлі, і саме той дубль реально використовувався на сторінці, перезаписуючи правильні дані. Виправили і його. Не спрацювало знову.
Копнули ще — третій дубль, той самий фетч, скопійований у ще один компонент. Він спрацьовував останнім і затирав усе.
Що мене тут вразило найбільше: щоб знайти всі три копії, треба було тримати в голові структуру всього проєкту — файли, які я показував ще на старті роботи, задовго до цього конкретного бага. Модель це втримала і послідовно перевіряла кожне місце, де могла ховатись та сама логіка.
Врешті прибрали дублі й лишили один спільний виклик — тепер ця помилка просто не може повторитись вчетверте.
Що з цього виніс
AI сильний там, де треба швидко зіставити симптом із відомим патерном («чорний екран → шукай краш рендера») і там, де треба методично перевірити багато місць у великому проєкті, не втрачаючи контексту.
Але жоден із цих багів не розкрився з першого запиту. У другому випадку ключ дала людська фраза «тут працює, а тут ні» — вона відсікла половину гіпотез за секунду, чого не зробили години автоматичного пошуку. У третьому довелось не здаватись після двох невдалих фіксів поспіль і копати далі.
Тобто працює не «AI знаходить баги», а зв’язка: людина правильно описує симптом → модель швидко перевіряє гіпотези → людина не приймає перший невдалий результат за остаточний.
Пишу такі розбори регулярно в Telegram-каналі Байти і Боти — заходьте, якщо цікаві реальні кейси, а не загальні поради.
8 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівБо запити невірні. Нічого, скоро всі мамкіни аішники прийдуть до CLI та skills :)
Проблема у тому, що модель «знає» про відомий(!) патерн, а розробник про нього не знає. Що з’являлися дублікати, що не було перевірено ще на етапі їх появни. Рев’ю коду (у будь-якій формі), юніт тести — все це прорпущено. До якості ставлення вкрай погане.
Головне питання у тому, що якщо розробник не знає навіть відомих патернів, то що він знає? У сенсі, які ще баги існують в системі, про які розробник не здогадується? Як може він вірити моделі з її фіксами, якщо кваліфікації для оцінки рішень немає? Суто чорна скриня. Наче працює, і ок.
Це нормально для прототипування, для петпроєкту в етапі розробки, а головне — для власного навчання, коли такі випадки спонувають розробника «підняти» знання, яких він раніше не мав. Тут LLM може дуже класно допомогти. Якщо ж йдеться просто про передачу моделі рішень і такому повернхневому ставленні до якості, то це... просто не продакшн підхід.
Автор зміни назву, оскільки АІ не займався пошуком багів, а допомагав у їхній ідентифікації та локалізації, тобто проводив аналіз першопричин (roote cause analysis). Саме ти виявив баги :-(
Саме він і шукав баги та парсив код, а я тестував його білди, бо ШІ не бачить, що відбувається на екрані.
Хм... А почему бы не использовать норм агент и дать ему задачу «пофикси баг»?
Зачем бросание в чатик без контекста проекта?
Він знає весь контент проекту, тому що я не знав в чому баг логи були чистими
Если были точные steps to reproduce — можно было попросить его написать красный тест и пофиксить проблему, через TDD.
Но вообще странно, что в логах молчок. Я не оч знаю специфику react, но неужели он ничего не выводит вообще в случае падения рендерера?
По першому кейсу взагалі IDE повинен казати щось накшталт «Cannot find name», а в консолі «Uncaught ReferenceError», або тут є специфіка збірки проєкта.