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

[AI]

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

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