Как я перестал “вайбкодить” с 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) <ручные проверки / сценарии>
