Вайб-кодинг с отладкой

Этот пост — для тех, кто пишет свои скрипты для автоматизации. Делюсь граблями и, возможно, приёмом, который помогает наступать на них реже.

Недавно выяснилось: я писал свои скрипты неправильно. Раньше как было?

1. Пишу запрос: «Сделай мне Python-скрипт, который делает то-то и то-то. И ещё вот это, это и это».
2. Дипсик что-то выкатывает. Пробегаю глазами по коду. Похоже на то, что я хотел, — вставляю в VS Code, запускаю. Поехали.
3. Вылазят ошибки. Они всегда вылазят. Скидываю лог, Дипсик думает, выдвигает версию и пишет что-нибудь в духе: «Ну вот теперь-то 200% заработает».
4. Запускаю снова. Что-то начинает работать, что-то перестаёт. Дальше — тяни-толкай: Дипсик правит две ошибки, попутно сносит логику двух других функций, появляются ещё две ошибки.

В эту игру можно играть долго. Каждый раз Дипсик авторитетно заявляет: «Ну вот сейчас я ВАЩЕ ВСЁ-ВСЁ-ВСЁ учёл, стопудово заработает». Ты запускаешь код — и он опять через минуту, пять, пятнадцать или сорок выбрасывает ошибку.

• • •

Как вы помните, я недавно писал статью для своего клиента про эксперимент с вайб-кодингом (статья, кстати, даже залетела в топ Хабра) , где клиент мне описывал фанатов ИИ, гоняющихся за линией горизонта за шансом ухватить версию работающего кода, глядя на обещания ИИ. Я узнал себя.

В разговоре, когда мы обсуждали саму статью, клиент сказал: реализовать тот или иной алгоритм программно — никаких проблем, с этим справится junior-разработчик.

Проблема не в этом. Проблема в том, что вокруг программной реализации алгоритма и «идеального сценария его использования» (happy path) нужно написать кучу сценариев того, как всё пойдёт не по плану. А это уже 95% оставшегося кода.

Выходит, сначала надо проговорить с ИИ основную логику. Потом подолгу обсуждать краевые/запасные варианты развития событий. И только потом давать команду на выкатывание кода.

Выглядит это так. Пишу промпт:

1. Хочу Python-скрипт, который делает то-то и то-то (далее пошаговый идеальный алгоритм).
2. Проанализируй предложенную реализацию, выяви слабые и спорные места, предложи оптимизации.
3. Никогда не выводи код, пока не прояснишь все уточняющие вопросы. Код выводи только после моей команды «Выводи полный код».

• • •

И тут начинается нудный многочасовой допрос. Примеры из обсуждения скрипта для дедупликации книг в библиотеке:

— Хэширование текста без полного извлечения — принципиально? Предлагаю такую-то реализацию. Согласен?
— Что значит «уникальный файл»?
— Где живёт индекс? Как скрипт узнаёт, что файл «новый»?
— Что если имя файла уже содержит [Число_страниц]_? Убирать старый префикс и ставить новый? Или оставлять как есть?
— По твоему правилу выживает PDF (он в LIB\), а EPUB удаляется. Это правильно? Или EPUB всё-таки должен выжить — он ведь более редактируемый?
— Дубликаты внутри LIB\ тоже идут в _duplicates, а не в _trash?

Вопросы идут бесконечным, как кажется, потоком. Ответишь на двадцать — он найдёт слабые места в твоих ответах и сгенерирует ещё двадцать. Таких сессий вопросов-ответов может быть 20-30.

Главное — не давать себе слабину. Каждый раз, отправляя пачку ответов, снова и снова спрашивать:

Если есть ещё уточняющие вопросы, задавай.

• • •

В итоге Дипсик выдаёт заветное «Вопросов больше нет, я готов вывести код» — и выкатывает код, который работает почти сразу.

У меня возник всего один косяк: библиотеку Дипсик импортировал чуть позже, чем положено. Исправилось легко.

Эксперимент с таким допросом я провёл дважды: апдейтил скрипт для извлечения глоссария и вот этот, для дедупликации книг в библиотеке. Результатом пока доволен (на скриншоте лог работы скрипта, работает уже 12 часов без единой ошибки, со скоростью обработки примерно 32 файла/книги в минуту):

Таким образом, хоть ИИ и выкатывает за 2-3 минуты — это, как вы понимаете, самая финальная операция. А вот обсуждение параметров, ограничений и уточнений занимает 2-3 часа и больше даже на мелкий скрипт.

Надеюсь, кому-нибудь мой опыт помог.