Как выстроить рабочий процесс вайбкодинга на реальном проекте?

Question

Никита Вихров · Answer

## Как выстроить рабочий процесс вайбкодинга на реальном проекте

Вайбкодинг на пет-проекте и вайбкодинг в продакшн — разные вещи. Вот конкретный процесс который не сломается через неделю.

### Шаг 1: rules-файл до первой строки кода

Создайте `.cursorrules` в корне проекта:

```
# Стек
- Python 3.11, FastAPI 0.104, SQLAlchemy 2.0 async
- PostgreSQL, Alembic для миграций
- Pytest + pytest-asyncio для тестов
- Pydantic v2 для валидации

# Соглашения по коду
- async/await везде где есть I/O
- типизация обязательна, mypy в strict режиме
- исключения через кастомные классы из app/exceptions.py
- логирование через structlog, print() запрещён
- переменные, комментарии, docstring — на английском

# Структура
- роутеры в app/routers/, один файл — один домен
- бизнес-логика в app/services/, не в роутерах
- модели SQLAlchemy в app/models/
- Pydantic-схемы в app/schemas/

# Запреты
- не хардкодить конфиг, только os.getenv()
- не смешивать бизнес-логику с HTTP-слоем
- не использовать select * в запросах
```

Этот файл — постоянный системный промпт. Cursor подставляет его в каждый запрос автоматически.

### Шаг 2: архитектура до кода

Не просите сразу писать код. Сначала:

```
я делаю API для таск-менеджера.
стек: Python 3.11, FastAPI, PostgreSQL, Redis.
пользователи могут создавать проекты, добавлять задачи,
назначать исполнителей, получать уведомления.

помоги спроектировать:
1. структуру папок
2. модели базы данных (таблицы и связи)
3. список API endpoints
4. какие части стоит кэшировать в Redis

дай схему и объясни решения
```

Потратьте 30 минут на архитектуру. Переписывать её потом — дорого даже с ИИ.

### Шаг 3: атомарные задачи

Декомпозируйте на минимальные шаги. Каждый шаг — отдельный диалог:

```
# Вместо одного огромного промпта:
"сделай авторизацию"

# Разбейте:
1. "создай модель User: id, email, hashed_password, is_active, created_at"
2. "напиши UserService.create() и UserService.get_by_email()"
3. "напиши POST /auth/register с валидацией через Pydantic"
4. "напиши POST /auth/login, возвращает JWT через python-jose"
5. "напиши depends get_current_user для проверки JWT"
6. "напиши тесты для всех endpoint'ов"
```

Каждый шаг — проверяемый результат. Сломался шаг 4 — откатили только его.

### Шаг 4: git после каждого рабочего шага

```bash
# После каждого шага:
git add .
git commit -m "feat: add User model and UserService"

git add .
git commit -m "feat: add POST /auth/register endpoint"

git add .
git commit -m "feat: add JWT authentication"
```

Если модель сломала что-то:
```bash
git diff  # посмотреть что изменилось
git checkout -- app/services/auth.py  # откатить один файл
# или
git reset --hard HEAD~1  # откатить последний коммит
```

### Шаг 5: код-ревью перед коммитом

```
вот мои изменения:

[вывод git diff]

проверь:
- нет ли SQL-инъекций или уязвимостей
- нет ли необработанных исключений
- соответствует ли код rules-файлу
- что я мог забыть
```

Занимает минуту, часто ловит то что пропустили.

### Реальный пример: промпт для endpoint

```
напиши endpoint PATCH /tasks/{task_id} для обновления задачи.

модель Task:
class Task(Base):
    id: int
    title: str
    description: str | None
    status: str  # "todo", "in_progress", "done"
    assignee_id: int | None
    project_id: int
    created_by: int

требования:
- только автор задачи или assignee могут её обновлять
- нельзя менять project_id и created_by
- при смене статуса на "done" записывать completed_at
- возвращать обновлённую задачу в формате TaskResponse
- если задача не найдена — 404
- если нет прав — 403
```

Это конкретное ТЗ. Модель напишет рабочий код с первого раза.

### Рефакторинг с ИИ

Когда файл вырос:

```
этот сервис разросся до 400 строк, нарушает SRP.
вот код: [код]

покажи план разбивки на модули:
- каждый модуль — одна ответственность
- публичный интерфейс не должен измениться
- не меняй логику, только структуру

сначала только план, код после моего ок
```

«Сначала только план» — обязательно. Согласуйте структуру до написания кода.

### Документация без боли

```
напиши docstring для каждой публичной функции в этом файле.
стиль: Google docstring.
включай: описание, Args с типами, Returns, Raises:

[код файла]
```

И README:
```
напиши README для этого проекта.
разделы: что делает, быстрый старт, переменные окружения, API endpoints.
аудитория: разработчик который видит проект впервые.
добавь примеры curl-запросов для основных endpoints
```

### Когда вайбкодинг замедляет

- **Незнакомый стек** — сначала пройдите базовый туториал, потом вайбкодьте. Иначе не сможете проверить что модель написала
- **Нет тестов** — без тестов вы не знаете работает ли то что сгенерировала модель
- **Слишком большие задачи** — если задача занимает больше одного файла, разбейте её

Если коротко: rules-файл + атомарные задачи + частые коммиты + ревью перед коммитом. Без этой структуры проект за месяц превращается в кашу которую никто не понимает — включая вас.

Как выстроить рабочий процесс вайбкодинга на реальном проекте?

Ответы

Как выстроить рабочий процесс вайбкодинга на реальном проекте

Шаг 1: rules-файл до первой строки кода

Шаг 2: архитектура до кода

Шаг 3: атомарные задачи

Шаг 4: git после каждого рабочего шага

Шаг 5: код-ревью перед коммитом

Реальный пример: промпт для endpoint

Рефакторинг с ИИ

Документация без боли

Когда вайбкодинг замедляет