Как я перестал “вайбкодить” с LLM и собрал процесс разработки, который не разваливает проект
Я бэкенд-разработчик (10+ лет опыта). Больше года использую LLM каждый рабочий день: сначала это был ChatGPT, сейчас работаю с Claude Opus 4.6.
В статье не претендую на “единственно верный путь” — это мой рабочий процесс, который помог снизить хаос в кодовой базе и сделать результат более предсказуемым и колнтролируемым.
Кому будет полезно:
-
если вы уже пробовали LLM для кодинга и столкнулись с деградацией качества на дистанции;
-
если хотите внедрить LLM в проект так, чтобы сохранялись архитектурные паттерны и единый стиль.
Почему “вайбкодинг” плохо масштабируется
На старте кажется, что всё отлично: отдельные фрагменты кода выглядят аккуратно, и все работает как надо. Но по мере роста проекта у меня начали повторяться типовые симпто��ы:
-
дублирование логики (модель локально оптимизирует ответ и легко “изобретает” второй вариант того же решения);
-
разъезд стиля и подходов — как будто один файл писали разные люди без договорённостей;
-
“заглушки” вместо полноценной реализации;
-
дорогая отладка: больше времени уходит не на разработку, а на распутывание несогласованностей.
Вывод: LLM полезна, но ей нужен процесс и контекст-менеджмент, иначе она усиливает энтропию проекта.
Основная идея: разложить контекст по чатам внутри проекта и требовать проверяемые артефакты
Я начал относиться к чатам с моделью как к директориям в проекте:
-
архитектура обсуждается отдельно и не смешивается с реализацией;
-
план работ фиксируется отдельно и не переписывается в каждом диалоге заново;
-
реализация идёт по этапам в отдельных чатах;
-
документация/DevOps/security — отдельные контуры.
Так контекст не размывается, а решения становятся воспроизводимыми.
Моя структура проекта в LLM (чаты)
-
Архитектура
-
План работ
-
Реализация — Этап 1
-
Реализация — Этап 2
-
Реализация — Этап N
-
Документация
-
DevOps
-
Security review
Этап 0. Базовые инструкции в проект Claude
Я задаю рамку работы: стек/версии, ограничения, формат ответа, требования к качеству.
Вход: краткое описание проекта + стек + инфраструктурные вводные
Выход: модель понимает правила игры (в т.ч. формат выдачи изменений)
Пример таких инструкций — ниже в разделе “Шаблоны”.
Этап 1. Архитектура (чат “Архитектура”)
В этот чат я приношу архитектурное решение (ADR/черновик) и прошу провести ревью: указать риски, предложить альтернативы, уточнить границы контекстов.
Вход:
-
описание домена и ключевых сценариев;
-
архитектурный документ (еще черновик).
Выход:
-
список спорных решений;
-
уточнённые контракты/границы;
-
список “архитектурных инвариантов” (что нельзя сломать при реализации).
Критерии готовности (DoD):
-
есть карта компонентов/границ ответственности;
-
описаны основные потоки данных;
-
зафиксированы ключевые инварианты (например: идемпотентность, транзакционность, правила ретраев, модель консистентности).
Этап 2. План работ (чат “План работ”)
Сюда я приношу финальную (на текущий момент) архитектуру и ТЗ/описание требований. Прошу декомпозицию на этапы, зависимость этапов, приоритеты.
Вход: архитектура + требования
Выход: план, разбитый на этапы с артефактами и критериями готовности
DoD:
-
каждый этап имеет цель, вход/выход, риски;
-
понятны зависимости между этапами;
-
определены минимальные проверки (тесты/линтер/контракты).
Этап 3. Реализация (чат на каждый этап)
На каждый этап — отдельный чат. Это снижает перекрёстное загрязнение контекста.
Важно: я всегда вручную проверяю сгенерированный код. Модель ускоряет работу, но ответственность за качество и целостнос��ь решения всё равно на разработчике.
Как сказал мой коллега и товарищ серьор фронт: “Если ты не контролируешь код, ты не можешь работать с проектом”
Вход: описание этапа + ссылки на архитектурные инварианты + текущее состояние репозитория
Выход (артефакты этапа):
-
код;
-
тесты (минимум: unit + базовые интеграционные, где уместно);
-
короткий MD-отчёт с изменениями и инструкцией проверки.
DoD (минимальный):
-
проект собирается, тесты зелёные;
-
нет заглушек;
-
публичные контракты (API/DTO/схемы) согласованы с архитектурой;
-
изменения описаны в MD (что/зачем/как проверить).
Этап 4. Документация (чат “Документация”)
Я выношу документацию в отдельный контур и прошу сверить её с кодом:
-
что устарело,
-
где не хватает примеров,
-
где расходятся контракты.
Вход: документация по компонентам + репозиторий
Выход: актуализированная единая проектная документация
DoD:
-
документация соответствует текущим контрактам;
-
есть раздел как запустить и как проверить;
-
зафиксированы основные решения (ADR-подобно), чтобы потом не гадать “почему так”.
Этап 5. DevOps (чат “DevOps”)
Отдельно обсуждаю CI/CD, окружения, масштабирование и ресурсы.
Вход: требования к деплою + SLO/SLA (если есть) + ограничения инфраструктуры
Выход: пайплайн, окружения, базовые практики (секреты, миграции, rollback)
Этап 6. Security review (чат “Security review”)
Периодически прохожу по проекту чек-листом: безопасность, надёжность, деградации, логирование, обработка ошибок.
Вход: репозиторий + точки входа (API, интеграции, фоновые джобы)
Выход: список проблем/рисков + рекомендации + приоритеты исправлений
Почему это работает (для меня)
-
чаты не разрастаются и не превращаются в мешанину;
-
архитектура и планирование остаются стабильной “точкой опоры”;
-
реализация становится итеративной и проверяемой;
-
проще возвращаться к решениям и рефакторить, не перепридумывая контекст.
Ограничения и честные предупреждения
-
LLM не заменяет ревью и ответственность разработчика.
-
Чем больше проект, тем важнее формализовать артефакты и критерии готовности.
-
Если не задавать инварианты (архитектурные и код-стайл), модель будет “оптимизировать локально”.
Шаблоны промптов
Инструкции проекта
Ты помогаешь мне разрабатывать проект. Работай как senior backend engineer + reviewer. Контекст: - Стек: <язык/фреймворк/версии> - Инфра: docker/k8s/<host OS>, домены: <...> - Репозиторий: я присылаю текущие файлы и изменения по этапам Требования к ответам: - Выдавай ТОЛЬКО файлы, которые ты изменил/создал. - Всегда добавляй файл AI_NOTES.md с: - что сделано - почему - риски/ограничения - как проверить (команды/шаги) Качество: - Соблюдай единый стиль проекта и best practices выбранного стека. - Не дублируй код: предпочитай переиспользование и понятные абстракции. - Не оставляй заглушек/“TODO”, если это не оговорено отдельным пунктом. - Пиши тесты там, где это критично для поведения/контрактов. - Если не уверен — перечисли варианты, но не делай скрытых допущений.
Промпт для ревью архитектуры
Вот архитектурное решение (ниже). Сделай ревью как архитектор: 1) Найди слабые места: масштабирование, консистентность, отказоустойчивость, наблюдаемость. 2) Отметь спорные решения и предложи альтернативы. 3) Сформулируй "архитектурные инварианты". 4) Предложи минимальный набор диаграмм/ADR, которые стоит зафиксировать. Текст архитектуры: <...>
Промпт для плана работ
На основе архитектуры и требований составь план работ: - Разбей на этапы, укажи зависимости. - Для каждого этапа: цель, вход/выход, артефакты (код/тесты/дока), риски. - Определи приоритеты и что можно делать параллельно. - Дай минимальный Definition of Done для каждого этапа. Архитектура: <...> Требования: <...>
Промпт для code review этапа
Проведи code review изменений как строгий reviewer: - корректность, edge cases, обработка ошибок - стиль и единообразие - дублирование и лишние абстракции - тестируемость (что не покрыто тестами и почему это важно) - безопасность (инъекции, секреты, авторизация, валидация входа) - производительность (N+1, лишние аллокации, блокировки, IO) В конце дай: - список MUST FIX - список SHOULD IMPROVE - список NICE TO HAVE
Шаблон файла AI_NOTES.md
# Изменения — Этап <N>: <название> ## Что сделано - ... ## Почему так - ... ## Риски / ограничения - ... ## Как проверить 1) <команда сборки/запуска> 2) <команда тестов> 3) <ручные проверки / сценарии>
Если у вас есть более эффективные практики — буду рад фидбэку :-)
Автор: yermolaev
