Вайб-кодинг: Как перестать бороться с Cursor и Windsurf

Если вы работаете с Cursor или Windsurf, то вы наверняка сталкиваетесь с тем, что они любят на ходу менять названия переменных, переписывать одни и те же куски кода по много раз, и вообще, если вы боретесь с каким-то багом, то на пятой итерации начинаете понимать, что баг так и не исправлен, но за это время вы уже получили три новых. Да, с простыми изменениями эти инструменты справляются очень неплохо, когда нужно внести сложные по изменения, затрагивающее сразу много файлов, то начинает теряться контекст, логика и мы заходим в тупик.

Хуже всего, что когда вы ходите по кругу пытаясь что-то отладить, вы тратите большое количество запросов и в итоге они у вас исчерпываются.

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

Почему начинаются проблемы при внесении крупных изменений?

Кодовые ассистенты, это wrappers around LLMs like Claude or ChatGPT. Когда генерация кода затрагивает, например, только один файл, все работает отлично, поскольку Cursor, упрощенно говоря, просто отправляет данный файл в LLM и просит внести изменения. Когда изменение касается нескольких файлов, важно, чтобы ассистент отправил в LLM все нужные файлы и при этом не потерял контекст задачи, т.е. то зачем те или иные куски кода существуют в вашем проекте. Как именно Cursor, Windsurf и другие ассистенты это делают мы не знаем, судя по всему этот процесс у всех заметно отличается. Тем не менее, все они начиная с какой-то сложности изменений начинают спотыкаться, что приводит к бегу по кругу, трате времени и лимиту запросов.

Что можно сделать?

Несколько практических советов, которые могут оказаться полезными:

Подходите к проектированию, как можно более модульно: Этот подход требует некоторых навыков системного архитектора и не всегда просто дается тем, кто не слишком много разрабатывал сложных продуктов или кто только пришел в эту индустрию благодаря вайб кодингу. Однако, попробуйте разбить всю вашу функциональность на небольшие блоки, каждый из которых отвечает за какой-то небольшой набор действий. Например, регистрация пользователя, парсинг документов итд. Так те куски кода, которые будут меняться окажутся изолированными от других частей и меньше шансов, что затронется что-то лишнее или что-то важное не попадет в контекст изменения. При этом, внутри этого логического разбиения большие файлы работают даже лучше, чем несколько маленьких. Большие файлы менее читабельны для человека, а вот для LLM, это самое то.

Применяйте микрокоммиты и постоянное быстрое тестирование: Микрокоммит, это когда мы вносим в Git даже самые незначительные изменения, в отличие от того, как это делалось раньше, когда разработчик мог довольно долго работать над своей веткой и мержить ветки после полного завершения какой-то функциональности.

Зачем это делать? Так вы банально сможете откатить свои изменения, когда обнаружите, что что ваш ассистент внес какие-то изменения, которые вы не можете выловить, но который сломал ваш продукт.

Добавляйте как можно больше контекста вручную: Cursor как-то неочевидно обращается с контекстом. Если сказать точнее, то он его забывает. Даже если ему указать использовать определенные файлы, то он может их проигнорировать.Что помогает? Явно указывать фрагменты кода, которые мы считаем важными. Формировать запрос, как “Исправь эту функцию [указание на кусок кода], с учетом этой функции [указание на кусок кода], так чтобы это работало с учетом этого кода [указание на кусок кода] и проходило данные тесты [указание на кусок кода].”

Строго говоря, это уже не вайб-кодинг, поскольку кодить совсем на чиле уже не получается и промпты становятся весьма громождкие. Но так гораздо больше шансов, что весь необходимый контекст не выпадет из внимания Cursor/Windsurf, да и вы не так быстро полностью потеряете связь с “вашим” кодом.

“Сначала проанализируй, потом имплементируй”: Этот пункт несколько противоречит задаче минимизации числа запросов, но в целом, себя оправдывает. Вместо одного запроса “Реализуй функциональность X” можно сначала попросить “Проанализируй, как реализовать функциональность X, укажи, какие изменения понадобятся, проверь, что эти изменения не затронут остальную функциональность”. В этом запросе, как обычно, можно добавить дополнительного контекста.Зачем это? Современные LLM обычно лучше работают, если им сначала дать проанализировать задачу, а потом уже просить ее решить. Соответственно, при таком двухступенчатом подходе, когда мы просим проанализировать задачу, а потом уже реализовать ее, то на втором этапе есть шанс получить более качественные изменения.

Помните, что промпт может быть длинным или коротким, но это один запрос: Не бойтесь добавлять так много контекста, как только можете. Структуру каталогов, документы, примеры кода. Вы потратите один запрос, но пропустите через Cursor/Windsurf такое количество контекста, которое в противном случае вы им сообщите за несколько запросов. Кроме того, весь этот контекст не забудется и будет учтен (по крайней мере в теории).