Ранок понеділка. Ти вбиваєш промпт у Cursor, Claude Code або Copilot. Через три хвилини фіча приземляється у твоєму PR — pull request, який твій код створює перед мержем у головну гілку. CI зелений. Тікет закритий. Дофаміновий удар. Ти тепер 10x-розробник.

Через тиждень та сама фіча падає о третій ночі. Ти відкриваєш файл. Не можеш відстежити баг. Ти не писав цей код. Це зробив ШІ. І не залишив жодного сліду. Тобі потрібен дебагер. Але не всі дебагери тепер означають одне й те саме.

Два дебагери заходять в один тиждень

Між 14 і 16 квітня, поки решта індустрії продовжувала клепати швидші генератори коду, два інструменти нарешті визнали: код, написаний ШІ, ламається інакше, ніж людський — і потребує інших інструментів для фіксу.

14 квітня Cursor 3.1 випустив одночасно CLI-команду /debug і фонових агентів, що автоматично створюють PR з GitHub-ішʼюсів — один реліз верхи на обох сторонах барикади. 16 квітня Visual Studio 18.5 показав агентний дебагер, що генерує гіпотези збоїв і ставить брейкпоінти за тебе. Тим часом генераційна сторона не відставала: Claude Code запустив Routines 14 квітня, а OpenAI оновив Codex 16 квітня до 3 мільйонів щотижневих користувачів з desktop computer use і 90+ плагінами.

Співвідношення генерації до дебагу за тиждень: 3:2 (Cursor-івські фонові агенти — на стороні генерації, /debug — на стороні дебагу). Прогрес, мабуть.

Одне слово — дві різні філософії

Cursor-івський /debug і агентний дебагер Visual Studio обидва заявляють, що дебажать. Роблять вони принципово різні речі.

Cursor-івський /debug читає вивід помилок з терміналу — стек-трейси, зафейлені ассерти, крики компілятора — зіставляє їх з відкритими файлами й контекстом проєкту, а потім генерує патч. Під капотом це ре-промптинг з кращим контекстом. ШІ поглинає помилку, вгадує, що зламалось, і видає замінний код. Якщо патч не прижився — ре-промптиш. Якщо й це не спрацювало — видаляєш функцію й перегенеровуєш з нуля. Воркфлоу оптимізований під швидкість: помилка → патч → шіп. Твоя робота — оцінити результат, а не зрозуміти шлях.

Це легітимний дизайн-чойс. Ті фонові агенти в тому ж релізі Cursor 3.1 — що крутяться в хмарних пісочницях і перетворюють GitHub-ішʼюси на PR без людського втручання — чітко розкривають продуктову філософію. Код одноразовий, важливий результат, ітерація дешева. /debug консистентний з цим світоглядом. Не розумій зламаний код. Заміни його на робочий. Їдь далі.

Агентний дебагер Visual Studio робить протилежну ставку. Коли ти описуєш баг або вставляєш ексепшн, агент не генерує фікс. Він генерує гіпотези — ранжований список пояснень, чому стався збій. Потім інструментує твій код: ставить умовні брейкпоінти в місцях, де кожна гіпотеза передбачає проблему, конфігурує watch-вирази на підозрілих змінних і веде тебе крок за кроком через реальний шлях виконання.

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

Ключова механічна різниця: Cursor-івський /debug працює з текстом — вихідний код як рядок для переписування. Дебагер Visual Studio працює з виконанням — стан рантайму як доказ для дослідження. Один трактує код як документ. Інший — як механізм.

Чому ця різниця реально має значення

Для null pointer в утилітній функції — не має. Cursor-івський /debug пофіксить за секунди. Дебагер Visual Studio був би оверкілом.

Але баги згенерованого ШІ коду — це зазвичай не null pointer. Дослідження накопичуються — дані GitClear про якість коду, численні академічні реплікації — і показують, що код, написаний у співавторстві з ШІ, несе значно більше логічних помилок і проблем з продуктивністю, ніж написаний вручну. Баги, які реально болять — це не синтаксичні проблеми. Це тонкі поведінкові невідповідності: API-хендлер, що працює в тестах, але робить подвійний запис під конкурентними запитами; запит до бази, що повертає правильні результати на малих датасетах, але генерує O(n²) джойни на масштабі; стейт-машина, що тримає happy path, але тихо корапчить дані при ретраї.

Ці баги не оголошують себе у виводі терміналу. Вони проявляються як повільна деградація, інтермітентні збої, інконсістентності даних, що спливають через дні. Cursor-івському /debug потрібне повідомлення про помилку для роботи. А що ти йому скормиш, коли симптом — "виручка чекауту впала на 4% у вівторок і ніхто не знає чому"?

Підхід Visual Studio через гіпотези обробляє це інакше. Ти описуєш симптом. Агент пропонує кандидатів-причини — можливо, логіка ретраю платежу подвійно списує, можливо, перевірка інвентарю рейситься з оновленням кошика, можливо, калькуляція знижки обрізає замість округлення. Ставить брейкпоінти на кожному кандидатному місці. Ти відтворюєш сценарій і спостерігаєш, як шлях виконання розкриває, яка гіпотеза тримається.

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

Роздвоєння воркфлоу

Ось тут індустрія розходиться.

Шлях А: модель Cursor. Код дешевий. Дебаг — це перегенерація. Коли щось ламається — викинь і промптни знову. /debug робить цей цикл тіснішим. Фонові агенти роблять його автономним. Логічний фінал — код, який ніхто ніколи не читає: згенерований, протестований, задеплоєний і замінений машинами в безперервному циклі. Розробники стають продакт-менеджерами, що описують намір і оцінюють результат.

Шлях Б: модель Visual Studio. Код — це інфраструктура. Дебаг — це розуміння. Коли щось ламається — зрозумій чому, перш ніж фіксити, бо та сама структурна вада з'явиться в наступній генерації, якщо ти цього не зробиш. Логічний фінал — розробники, що розуміють менше коду загалом, але розуміють його глибше — спеціалісти з поведінки систем, а не виробництва синтаксису.

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

Вгадайте, який підхід переможе

Cursor-івський, очевидно. Він швидший. Вимагає менше думання. Вписується у вайб-кодинг воркфлоу, який індустрія одноголосно прийняла. Видалити, ре-промптнути, зашіпити, повторити. Розслідування — це чиясь інша проблема. Доки прод не загориться і "хтось інший" — це ти о третій ночі, дивишся на три сервіси, які написали три різні промпти, спостерігаєш, як взаємодія між ними кладе чекаут.

Ти не можеш ре-промптнути свій вихід з розподіленого системного збою. Тобі потрібен хтось, хто змапив шляхи виконання. І якщо твоя культура дебагу — "замінюй поки не позеленіє" — такої людини у твоїй команді не існує.

Підхід Visual Studio складніше продати. "Давай я допоможу тобі подумати" програє "давай я пофікшу за тебе" в кожному демо, кожному твіті, кожному хайп-циклі. Але розуміння накопичується. Перегенерація — ні.

Незручна частина

Питання не в тому, який дебагер кращий. А в тому, яку філософію дебагу обирає твоя команда — і чи ви обрали свідомо, чи просто здефолтилися на те, що швидше.

Якщо твій стек — це stateless-функції і короткоживучі сервіси, Cursor-івський цикл перегенерації може бути справді достатнім. Заміни зламану лямбду. Їдь далі. Нікому не потрібно розуміти функцію, що живе один реліз-цикл.

Якщо твій стек має стейт, має розподілені транзакції, має поведінку, що виникає із взаємодії компонентів — хтось повинен розуміти рантайм. Не вихідний текст. Рантайм. Дебагер Visual Studio — перший ШІ-інструмент, який визнає, що ця робота існує.

Ранок понеділка — ти вб'єш ще один промпт. Щось зламається. Питання не в тому, чи ти будеш дебажити. А в тому, чи дебаг означає "згенерувати знову" чи "зрозуміти чому". Обирай свідомо. За замовчуванням — перегенерація. А о третій ночі дефолти — це все, що в тебе є.