Последние полтора года я использую Cursor IDE в качестве основной среды разработки. Сначала использовал её как среду с просто удобным автодополнением строк (относительно GitHub Copilot). Потом AI стал умнее, удобнее, появился режим планирования и Claude стал базовым атрибутом моего рабочего дня.

Неделю назад мой open source проект Databasus (инструмент для резервного копирования PostgreSQL, ~6k звёзд ⭐️ и ~275k Docker pulls) получил поддержку от Anthropic в рамках OSS программы: и теперь у меня есть бесплатный Claude Code Max на ��лижайшие полгода.

Следовательно, я переключился на него... и осознал, что очень сильно привык к UX в Cursor IDE. Самые умные безлимитные модели — это, конечно, классно. Но удобство и контроль за изменениями для меня в приоритете.

Поэтому я взял Opus и навайбкодил расширение для VS Code, которое приближает взаимодействие с CLI агентами к опыту Cursor IDE: когда ты видишь изменения и можешь точечно их корректировать. Пара потраченных часов сделали работу в ближайшие полгода для меня ощутимо комфортнее.

Что и как я делал — ниже.

Дисклеймеры

Есть большая разница между «вайбкодингом» и «использованием AI как инструмента»:

• «Вайбкодинг» — это создание программы через промпты, когда не смотришь, что именно нейросеть изменила в коде и не оцениваешь адекватность решения «под капотом». Причём делаешь это большими кусками. Т.е. человек, фактически, не несет ответственности за качество кода.

• «Использовать AI как инструмент» — это когда AI помогает планировать, писать рутинный код, перепроверяет решение и выполняет действия, которые говорит человек. Т.е. человек контролирует каждое изменение в коде и несет за него ответственность.

В работе и open source'е я использую второй подход. Потому что даже самые умные AI не справляются с задачей «понять требования» и «оценить последствия» (например, что код станет неподдерживаемым примерно через пару дней). Хотя и радикально повышают скорость и КПД работы.

Когда нужно собрать PoC, простенький скрипт или что-то для теста — можно и повайбкодить. Как, например, с расширением, о котором статья. При этом я всё равно не знаю и не понимаю, как можно «оркестровать агенты», давая им часами работать. Мой мозг способен держать в контексте всего лишь одну задачу (то есть чат) одновременно ?.

Ну и для справки:

1) Я ~11 лет в разработке и, как мне кажется, я умею хорошо писать код.

Я успел:

• выработать насмотренность, когда говнокодил миллионы строк кода;

• позадавать глупые вопросы на StackOverflow (тогда это было мейнстримом, хе-хе);

• почитать месяцами справочники, нудные книги, а ещё умею заходить в JDK документацию из IDE и не брезгую покопаться в исходниках библиотек;

• понять, как оценивать trade off'ы решений, потому что много раз видел последствия плохих решений;

• поустанавливать драйвера на принтер в Debian, когда ещё не было ChatGPT (сейчас мне даже страшно такое вспоминать);

• много-много лет писал пописать тесты руками и понять, что тестировать нужно, а что нет.

В общем, у меня достаточно экспертизы, чтобы понимать сильные и слабые стороны AI (но не так много, как у самых опытных комментаторов, которым AI только мешает, разумеется ?). И для меня AI полноценный инструмент, дополняющий мою собственную экспертизу, а не компенсирующий её отсутствие.

2) У Databasus есть дисклеймер прямо в README.md, как AI используется в проекте и как AI НЕ используется в проекте. Можно почитать тут. Там про то, какие quality gates у кода, какие требования (что к человеку, что к AI) и т.д. Отдельно есть пункт, что вайбкодеров там не ждут.

Как я работаю с AI?

Для начала, немного контекста, как выглядит моя работа, когда я пишу код с AI (и сразу уточню, что я использую только последние платные Thinking модели от Claude и OpenAI):

1) Определяюсь, какую задачу мне нужно решить и как её нужно решить. Бывает, я не знаю, как решается задача или у меня есть сомнения, что моё представление самое рациональное. Тогда я иду в Claude или ChatGPT, и просто общаюсь с ними в формате «Я хочу сделать X способом Y, но мне кажется, что можно Z. Что думаешь?» или «А как работает X или обычно делается Y? Есть полезная документация или примеры?».

После чего у меня формируется представление, а в какую сторону двигаться.

2) Беру нужную мне задачу (допустим, фича X) и декомпозирую её до логически обособленных подзадач. Которые можно сделать и протестировать отдельно. Например, «добавить модель X в код, репозиторий, сервис и контроллер, написать миграцию, написать тесты Y и Z».

3) Прошу AI приготовить план для решения задачи с вводными от себя, если это требуется. Добавляю в контекст плана, какие файлы относятся к задаче, как я вижу решение, чтобы AI понял, что нужно читать, менять, с чем и как взаимодействовать.

4) Корректирую и детализирую план, пока у меня не будет уверенности, что ничего важного не упущено. Кстати, это самый важный пункт в работе с AI (который занимает ~40% времени). Обычно те, кто жалуется на «AI генерирует мне фигню» — не прописывают план или не доводят его до адекватного уровня детализации. В процессе прошу AI перепроверять свой же план.

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

5) Отправляю AI агента писать код по плану. Тут он меняет код, запускает тесты и т. д.

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

Если вижу, ч��о кривой нейминг, дублирование кода, не хватает паттернов, что-то можно сделать лучше — рефакторю вручную. Если вижу, что получилось сильно не то, что мне нужно или я понял, что решение вышло кривое — отменяю изменения и возвращаюсь на этап подготовки плана или даже декомпозции задачи. Этот шаг тоже занимает ~40% времени, примерно как и планирование.

Тут важно отказываться от того, что вышло, если вышло не совсем то, что нужно. Или есть ощущение, что решение вроде и работает, но создаст проблемы с maintainability в будущем.

Существенная часть разработки субъективная, зависит от субъективного опыта, от насмотренности и понимания контекста проекта (с точки зрения продукта, а не кода) самим разработчиком. И именно в этом AI плох.

7) Если задача связанна с security или reliability, прошу AI ещё раз перепроверить, что всё надёжно, ничего не упущено, не нужно улучшить и не упущены тестовые сценарии.

Все эти шаги удобно проходить в Cursror IDE. Под всё это внутри есть инструменты, причём действительно интуитивные и удобные.

Чего мне не хватило в Claude Code?

Claude Code имеет CLI интерфейс. Он умеет планировать, он умеет писать код. У него даже есть расширения для VS Code и JetBrains IDE (я сначала пробовал вернуться к GoLand, но не вернулся, потому что удобно открывать и фронт, и бек в одном месте).

Однако, мне не хватило двух функций:

1) Возможности перетягивать файлы прямо в AI чат (п. 3 "планирование" выше), чтобы задавать контекст во время планирования, подсказывать, где мне нужны изменения и что принять во внимание. Что терминал, что расширение не имеют drag-n-drop области.

Руками прописывать каждый раз путь к файлам — долго и неудобно (когда привык к удобному Cursor'y). Так ещё и в Go принято называть файлы 1-2 словами, и даже в моих маленьких проектах по 30+ model.go , service.go, controller.go с одинаковыми названиями. Т.е. без полного пути к пакету нужный файл подсвечивается редко.

2) Подсветки изменений Diff прямо в файле и возможности принять\отклонить кусок изменений после изменений от Claude Code (п. 6 «ревью изменений» выше). Т.е. вот такой подсветки прямо в файле нет:

Да, Claude Code показывае�� изменения в чате вот так:

Но мне тяжело понять контекст кода, когда я не вижу файл целиком и файлов много. Я не могу:

• перемещаться по референсам;

• видеть usage переменных;

• видеть подсветку синтаксиса;

• видеть код вокруг (точнее сверху и снизу).

А значит, что я не могу качественно ревьюить изменения от AI (точнее это занимает намного больше времени). Что равносильно тому, что я неэффективно работаю.

P.S. Через Git diff это тоже неудобно, потому что в рамках коммита у меня обычно больше одной итерации изменений от AI.

Как я делал расширение?

В отслеживании изменений через расширение есть нюанс: «извне» я не могу залезть напрямую в Claude Code и понять, что именно он меняет. Поэтому нужно делать снэпшот кодовой базы и сравнивать с тем, что поменялось. Такое отслеживание находит правки от AI, но и подсвечивает мои собственные изменения. Так что я принял решение сделать кнопку «вкл. \ выкл.».

Я взял Opus 4.6 Thinking и начал писать требования.

Мне были нужны:

• кнопка «начать отслеживать изменения» и «перестать отслеживать изменения», чтобы изменения от AI подсвечивались, а изменения от меня — нет;

• подсвечивать изменения прямо в редакторе (так, чтобы был виден весь файл и подсвечен измененный участок в рамках файла);

• сделать так, чтобы я мог применять \ отклонять изменения по кускам;

• мне нужны стрелочки для навигации по измененным файлам и их счётчик (чтобы убедиться, что я проверил все файлы);

• мне нужны кнопки, чтобы принять \ отклонить все изменения в файле за раз;

• когда я выбираю много файлов через Ctrl, мне нужен пункт в дропдауне «Copy as @ references».

После формализации требований, Opus пошёл писать код. Он сделал структуру, написал файлы, дал мне инструкцию по установке расширения и я пошёл тестировать.

Вылезли проблемы:

1) Даже с 3-й попытки не вышло сделать красивую подсветку измененного (а не дополненного) кода: до сих пор он отображается как добавленный + красный комментарий, как было «до» с соединенными строками через join:

Умеренно удобно, но намного лучше, чем когда код прыгал по экрану, перерендеривался или изменения совсем не отображались. Как именно исправить — пока не знаю. Когда будет время, пойду открою документацию по CodeLens и разберусь, а как именно устроенно отображение кода в VS Code. Тут уже AI нужно подсказать, что делать.

2) Если в проекте много бинарников (а это как раз специфика Databasus), расширение долго запихивало их в оперативку. Добавил ограничение, что можно трекать файлы размером до 1-го МБ и пропускать те, которые в .gitignore.

3) Само расширение установилось после ~5 попыток и изменений package.json. Из-за чего так получилось, я тоже не понял. Просто перебирал варианты от Opus'a методом тыка — издержки вайбкодинга.

Что получилось в итоге?

Теперь расширение умеет копировать ссылку на выделенные файлы, чтобы я мог подставить их в чат с Claude Code через @. Ещё не Drag-n-Drop, но и не прописывать пути руками.

Расширение отслеживает изменения, подсвечивает измененные куски кода в файле, даёт принять и отменить изменения:

Итого, перед запуском Claude Code в кодовую базу, я нажимаю "Start tracking" и VS Code начинает мне показывать всё, что поменял агент. Теперь я могу относительно комфорто ревьюить изменения, передвигаться по измененным файлам и видеть контекст вокруг измененных участков кода (пусть и не настолько же удобно, как в Cursor'e).

Заключение

Пара часов вайбкодерства помогли мне приблизить опыт использования Claude Code к Cursor IDE. Поскольку я вижу, что именно AI меняет — я теперь могу продуктивно работать с Claude Code'ом. Если бы такой опции не было, я бы не смог качественно ревьюить изменения и вернулся бы к Cursor'у за ~$200 в месяц, променяв безлимитный Opus на хороший UX с Sonnet'ом.

Это лишний раз напоминание для меня, что мелкие тулзы теперь можно делать очень быстро. Два года назад такое же расширение у меня бы заняло, наверное, неделю. А теперь рабочее (пусть и кривоватое) решение есть всего за ~3-4 часа.

Расширение доступно на GitHub — https://github.com/RostislavDugin/diffus

Ну и не забывайте: используйте AI с умом, это просто инструмент наравне с IDE, а не возможность хальтурить и меньше думать. Просто теперь можно думать с более высоким КПД на единицу времени ?.

У меня есть Telegram канал, где я сейчас пишу в основном про разработку Databasus и open source.

Также может быть интересно:

• Как я пришёл в open source в 2025-м (с утилитой для бекапа PostgreSQL), чуть не потеряв проект на ~$1500\мес в 2023-м

• Как я встроил процесс тренировок в свою жизнь (и собрал спортзал дома, вложив $400 в течение 2-х лет)

• Постмортем: 4 мои ошибки во время отражения DDOS атаки (спойлер — выкуп в $250 мы все-таки не заплатили)

• 10 непривычных моментов в Go для Java разработчика

• Мои 7 правил при собеседовании разработчиков