Vibe coding — это одновременно и мем, и реальность 2025-2026 года. Кто-то называет это будущим разработки. Другие считают, что это способ генерировать технический долг со скоростью света.
Мы решили попробовать создать коммерческий проект с нуля полностью с помощью вайбкодинга. В результате: 46 000 строк кода, полтора месяца, два человека. Проект работает, клиент пользуется.
Вообще как бы нифига себе – написать рабочую CRM, которая автоматизирует обработку входящих запросов и может автоматически работать по сделкам: отвечать на письма, ставить задачи, проводить сделку по воронке.

Сделали мы это в два лица – один из созвонов, записанных ReadAi собирал задачи, немного редактировал и из Claude Code Cli используя MCP декомпозировал таски в Jira. Короче такой менеджер и аналитик в одном лице. И разработчик, который собственно управлял всем оркестром, разбирал таски, реализовывал и тестировал.
Стек: NestJS, NextJS, ShadCN UI, PostgreSQL
Но эта статья не про то, как круто всё получилось. Она про то, как организовать работу с Claude Code (и аналогами), чтобы получить рабочий результат, а не кашу.
Часть 1: Настройка рабочего места
Структура проекта для AI
Главная ошибка – думать, что AI сам разберётся в вашем проекте. Не разберётся. Точнее, разберётся, но потратит на это ваши токены и контекст.
Claude.md – главный файл
Это точка входа. Здесь храним минимум информации и максимум ссылок. Не пишите сюда всё подряд. Напишите:
Что это за проект (2-3 предложения)
Какой стек
Ссылки на файлы документации по модулям
Базовые правила (что обновлять, куда смотреть)
Почему это важно: claude.md читается при каждом запросе. Всё, что там написано – это токены, которые вы тратите всегда. Чем меньше там мусора, тем больше места для реальной работы.

Документация по модулям
Каждая крупная сущность – отдельный md-файл. В нашем случае, например:
docs/deals.md — как работают сделки
docs/email-processing.md — логика обработки почты
docs/api.md — структура API
AI читает только то, что нужно для текущей задачи. Если вы работаете с корзиной, ему не нужно знать про систему уведомлений.
Агенты
Это md-файлы с инструкциями для конкретных областей. Например:
agents/backend.md:
Какую архитектуру используем
Какие паттерны обязательны
Типичные ошибки, которых избегать
Best practices для этого проекта
agents/database.md:
Какая ORM
Правила работы с миграциями
Оптимизация запросов (N+1, индексы)
AI сам поймёт, к какому агенту обращаться, если в claude.md это прописано.
Часть 2: Работа с контекстом
Один контекст = одна задача
Это главное правило. Не пытайтесь в одном контексте сделать весь модуль. Сделали задачу – clear. Нужно вернуться – resume.
Почему: когда контекст переполняется, Claude делает compact – сжимает историю. После этого он помнит примерно что было, но теряет детали. Если в этот момент он был на середине задачи, результат будет непредсказуемым.
Plan mode для больших задач
Если задача явно не влезает в один контекст (инициализация проекта, большой модуль), включайте plan mode. AI декомпозирует задачу на подзадачи, каждая будет решаться в своём контексте.
Сколько это в цифрах
На базовой подписке ($20) хватает на 3-5 часов активной работы. Потом лимиты сбрасываются. Мы планировали работу окнами. С хорошей документацией и правильной работой с контекстом этого достаточно для большинства задач.
Часть 3: Типичные проблемы и решения
AI не понимает вашу библиотеку
Симптом: пишет код с ошибками, использует несуществующие методы
Решение: создайте md-файл с документацией этой библиотеки. Можно попросить AI самого сгенерировать – дать ссылку на официальную документацию и попросить структурировать.
AI забывает контекст
Симптом: начинает переспрашивать то, что уже обсуждали
Решение: вы вышли за рамки контекста. Делаете Clear и начинаете с чёткой постановки задачи. Если задача большая, разбиваете на части.
AI пишет дублирующийся код
Симптом: создаёт новые компоненты вместо переиспользования существующих
Решение: в запросе указывайте “проверь, есть ли уже похожий компонент”. В агенте backend/frontend пропишите правило про переиспользование.
AI предлагает странные решения
Симптом: архитектурные решения, которые вам не нравятся
Решение: не соглашайтесь сразу. Спросите, какие ещё есть варианты, предложите свой, попросите сравнить. AI часто знает несколько подходов, просто выдаёт первый.
Часть 4: Интеграции
Перед работой с любым внешним API:
Попросите AI сгенерировать md-файл с документацией
Дайте ему ссылку на официальные доки
Пусть структурирует: методы, параметры, типичные сценарии
Потом работайте с этим файлом. AI не потребуется каждый раз лезть в интернет, т.к. у него уже будет контекст. Это сэкономит токены и снижает количество ошибок.

Часть 5: Чего не делать
Не скипайте discovery
Мы попробовали – не прокатило, описанные требования к проекту всё равно нужны, иначе потом есть риск раздувания скоупа.
Напоминайте клиенту валидировать свои ТЗ, если он генерит его через AI
Хорошо, если клиент сам четко может объяснить, что он хочет и как это будет выглядеть, в противном случае придется потратить время на разборы. Готовьтесь обсуждать непонятные и плавающие моменты и доводить их до конкретики. Например, не “построить дашборд”, а “обсудить конкретные метрики”.
Не ожидайте идеального кода с первого раза
AI ошибается. Особенно в edge cases, оптимизации, специфичных для вашего проекта вещах. Ревью обязательно.
Часть 6: Плагины и расширения MCP
Sequential thinking
Заставляет AI думать пошагово, а не сразу кидаться писать код. Полезно для сложных задач.
Если работать без этого плагина, Claude, получив задачу, сразу пишет код и часто промахивается, потому что не продумывает зависимости между частями. Sequential thinking заставляет его сначала выстроить цепочку рассуждений.
Мы включали его при планировании архитектуры и работе с большими модулями. Разница заметна: без него Claude мог начать реализацию, а на середине понять, что выбранный подход не стыкуется с остальным проектом. С Sequential thinking он сначала проходил по шагам: какие сущности затронуты, какие зависимости, какой порядок реализации. И только потом писал код.
Для мелких задач вроде “поправь валидацию в одном поле” он не нужен, но для всего, что затрагивает несколько файлов или требует архитектурного решения — must have.
Serena
Навигация по проекту. Держит структуру файлов, помогает AI быстрее находить нужное.
Когда на проекте аж 46K строк, Claude тратит значительную часть контекста просто на то, чтобы найти нужный файл и понять структуру проекта. Serena решает эту проблему — она даёт ему навигацию по кодовой базе.
После подключения Claude стал быстрее находить нужные файлы и тратить меньше контекста на ориентирование. В рамках одного контекстного окна можно было не тратить токены на «поиск», а сразу переходить к работе.
Для небольших проектов Serena, возможно, избыточна, но когда файлов становится много, без неё ощутимо сложно.
Официальные плагины
В Claude Code появился marketplace плагинов. Есть для Laravel, React, NestJS и других популярных технологий. Они содержат документацию в оптимизированном для AI формате.
Команда: /plugins — выбираете нужный.
Итого: чеклист для старта
Перед началом проекта:
Создать claude.md с базовой информацией
Определить структуру документации по модулям
Создать агентов для основных областей (backend, frontend, database)
Установить нужные плагины
В процессе работы:
Одна задача = один контекст
Clear после завершения задачи
Обновлять документацию при изменениях
Ревьюить результат
При работе с интеграциями:
Сначала документация в md-файл
Потом работа с API
Заключение
Пускай для кого-то вайбкодинг останется чисто мемом, но мы считаем, что это норм инструмент, который при должной настройке и дисциплине будет хорошим подспорьем в работе. Главное – понимать, что ты хочешь получить на выходе и не генерировать хаос.
Комментарии (9)

aborouhin
19.03.2026 08:14Я для каждой одноразовой утилиты для собственных нужд использую GitHub Spec-Kit и провожу полный цикл specify-clarify-plan-tasks-analyze-implement-verify, а тут такая куча кода, коммерческий проект и всего лишь plan mode и пара плагинов :)
Кстати, для актуальной документации примерно ко всему Context7 MCP очень неплох.

bashka-pro
19.03.2026 08:14И сколько Клод съел денег? Ясно что не бесплатный тариф. Одна копия используется?

dev_family Автор
19.03.2026 08:141 месяц была подписка Pro за 20$. Когда кончились лимиты, попробовали их увеличить. За 5 минут улетело 10 баксов, поэтому решили лучше взять подписку другую. Поэтому во второй месяц работы - оплатили Max за 100$ и уже жара пошла. С ней уже почти в лимиты не уходили. Там их х5, они еще и обновляются каждые 5 часов. Больше ничего не потратили.

yokotoka
19.03.2026 08:14https://github.com/gsd-build/get-shit-done
Рекомендую*
*актуальность гарантирована только в течение марта 2026 :)

aborouhin
19.03.2026 08:14Я пару маленьких проектов с GSD сделал - и хотя работать с ним приятно, но, по моему субъективному ощущению, на фоне Spec-Kit при одинаковых усилиях сложнее удержать код от превращения в неподдерживаемую кашу. Все эти этапы в Spec-Kit неспроста. Хочу ещё BMAD Method погонять на чём-то более или менее серьёзном, выглядит многообещающе, и они как раз закончили рефакторинг на скиллы.

Dhwtj
19.03.2026 08:14существенная сложность домена никуда не делась, она просто спрятана в 46k строках, которых никто не понимает
Что будет через год? Не знаю. Нет достаточной статистики по проектам, которые прошли хотя бы год поддержки после вайбкодинга. Напишите через год - два.
Оптимистичный сценарий: LLM к тому времени станут лучше понимать существующую кодовую базу, и поддержка будет тоже вайбкодиться. Проект живёт.
Пессимистичный (и более вероятный по историческим аналогиям): Классическая кривая - через 6-12 месяцев каждое изменение начинает ломать что-то в другом месте. Без архитектуры, без тестов, без понимания кода людьми - скорость изменений падает экспоненциально. Брукс описал это в 1975, ничего нового.
Вероятный исход для конкретного кейса: Либо перепишут с нуля (уже понимая домен), либо наймут нормальных разработчиков чинить, либо проект умрёт когда клиенту понадобится что-то нетривиальное
Harconnen
Я сейчас тоже работаю над создание очень сложной CRM, правда использую Codex.
Использую подход парного программирования, так как сам разработчик и заставляю писать модель такой код который нужен мне. Скорость возросла минимум раз в 5 ))
Саму спецификацию по проекту для модели прошу писать нейронку, сейчас она практически меня понимает с полуслова ))