Как я перестал “вайбкодить” с LLM и собрал процесс разработки, который не разваливает проект

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

Если у вас есть более эффективные практики — буду рад фидбэку :)

Источник