Последние полтора года я использую 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.
Также может быть интересно:
