Мой опыт вайб-кодинга. Сервис за выходные
Вступление
Я занимаюсь разработкой уже больше пятнадцати лет. Наверное, меня можно отнести к «прошлому» поколению разработчиков — тем самым старперам, которые вручную писали код на высокоуровневых языках вроде Java, PHP, JavaScript, Go. Уже давно замечаю за собой, что становлюсь всё более консервативным в вопросах выбора инструментов и технологий для проектов, за которые отвечаю. Поэтому к AI-хайпу, копилотам, агентам и прочему отношусь с осторожностью и скепсисом.
Но всё же решил попробовать — и делюсь с вами своими наблюдениями: что работает, а что нет.
Сразу скажу: мне в целом понравилось. Я бы даже сказал, что впечатлён.
Инструменты
Я довольно долго пытался привыкнуть к копилотам, но так и не смог. Inline-подсказки меня скорее раздражают и тормозят. По крайней мере на моём основном языке — Go — мне кажется, что проще и быстрее написать код самому, чем перепроверять и исправлять то, что сгенерировала модель.
Cursor мне тоже не зашёл — возможно, из-за того, что я много лет использую IDE от JetBrains и не хочу отказываться от привычного интерфейса и набора инструментов. В итоге для своих экспериментов я остановился на связке: консольный клиент Claude Code и JetBrains GoLand.
Задача
Идея для pet-проекта, на котором можно поэкспериментировать, пришла внезапно. Болтал со своим давним другом — жаловались друг другу на своих «спутниц жизни», с которыми порой сложно находить общий язык. И тут меня осенило: AI Conflict Resolution!
К утру понедельника прототип был готов. (Потыкать можно тут: theudra.com)
Мой подход
Начну с дисклеймера: это мой первый серьёзный опыт использования AI в разработке, так что, скорее всего, я всё сделал неправильно. Добро пожаловать в комменты — научите, как надо.
Я начал с того, что создал проект в веб-версии Claude. Идея была такая: у меня есть «продакт», который генерирует PRD (Product Requirements Document), и «разработчик» — Claude Code, который пишет код по этой документации.
Для начала я сформировал общую концепцию: Vision, Mission, Target Audience и т.д., и сохранил полученный документ в проекте. Затем мы вместе с Claude подготовили базовый PRD с описанием основного пользовательского сценария (Main User Flow).
Итерация
Реализация очередной фичи выглядела так:
В веб-версии Claude, используя уже имеющуюся документацию, я готовлю отдельный документ с описанием фичи. Этот документ добавляется в директорию ./docs в репозитории проекта.
Прошу Claude Code составить план реализации. Далее мы вместе уточняем детали, порядок шагов и прочее.
Claude Code поэтапно выполняет план. После каждого шага я вручную валидирую результат.
В веб-версии Claude формирую список test-cases.
В Claude Code пишем тесты и допиливаем реализацию.
Коммитим — и переходим к следующей фиче.
Может показаться странным, что тесты вынесены в конец. Ниже объясню, почему я выбрал такой подход.
Сложности
Архитектура и бизнес-логика
Как только объём кода переваливает за 2–3 тысячи строк, у LLM начинаются сложности с принятием правильных архитектурных решений. Надеяться на то, что Claude Code сам поймёт, когда и как нужно разделить модели DTO и доменный уровень, где должна находиться логика — в репозитории или в сервисе — не стоит. Всё это нужно объяснять вручную, а потом ещё и самостоятельно всё подчищать. Иначе получится каша.
Сложная бизнес-логика (в моём случае — подсистема перевода контента и детекция языка входных данных) требует особенно осторожного подхода. Если фича предполагает большое количество состояний (например, комбинация выбранной локали и языка ввода), есть риск, что LLM начнёт генерировать чепуху с множеством ветвлений, запутается в логике и будет только усугублять ситуацию при попытках всё исправить.
Такую логику нужно вручную декомпозировать, продумать архитектуру, разнести по компонентам и подавать в максимально разжёванном виде.
Тесты
Этот момент я уже частично упоминал. Если попросить LLM работать в духе TDD и сначала сгенерировать тесты — результата не будет. Будет сгенерирована чепуха, а дальше Claude Code уйдёт в бесконечный, бессмысленный цикл взаимной подгонки кода и тестов.
Если же сгенерировать тесты после того, как код уже готов, — получите набор, который тестирует массу деталей реализации. Поскольку Claude Code видит код в контексте, он этим обязательно воспользуется.
У меня сработал следующий подход: подготовка тест-кейсов в веб-версии Claude на основе PRD, а затем трансформация этих кейсов в код.
Отдельно пришлось добавить инструкцию в CLAUDE.md, чтобы избежать самодеятельности со стороны помощника:
## Test Guidelines
- NEVER modify test files unless explicitly asked to do so
- Tests are used to validate code changes and ensure functionality
- Breaking tests makes it difficult to validate other changes
- If you need a test changed or updated, ask for explicit permission first
- Do not attempt to run and fix test issues yourself - wait for guidance
Без этой инструкции помощник постоянно пытался «починить» тесты, как только один из них начинал падать.
Результат
Получился вполне рабочий прототип: theudra.com.
Есть множество моментов, к которым можно придраться, но в целом — достойно.
Выводы
Связка, которую я попробовал, хорошо подходит для разработки прототипов.
Можно ли с её помощью сделать полноценный MVP? Не знаю… Возможно, при определённом опыте — да.
По ощущениям, в рамках этой задачи ускорение было примерно в 3–5 раз.
Кроме того, я заметил большой потенциал для улучшения инструментов. Например, Claude Code часто «грепает» исходники, когда нужно найти usages конкретного символа. Кажется, интеграция с LSP или подобными инструментами могла бы сильно повысить качество результата — это то, что сразу бросается в глаза.
Ну и, конечно, стоит рассчитывать на дальнейшее развитие самих LLM.
Вердикт: мне понравилось. В этом точно что-то есть.
