Павел Булкин – Вайб-кодинг. Практический курс (страница 4)

Добавь задачи в приложение.

Команда короткая и звучит безобидно. Но вы не задали ни одного ограничения, поэтому все решения агент примет за вас — и почти наверняка не так, как нужно. Что пойдёт не так:

• создаст лишние файлы, которых вы не просили;

• выберет странную архитектуру — например, размажет логику по контроллеру;

• не добавит тесты или добавит тесты на то, что ему удобно проверять;

• смешает слои: контроллер полезет в базу мимо сервиса и репозитория;

• забудет про права доступа — кто вообще может создавать задачи?

• притащит новую зависимость «чтобы было проще», без всякой причины.

Заметьте: каждая из этих проблем — не баг модели, а пробел в вашем запросе. Вы не сказали, какая архитектура, нужны ли тесты, кто имеет права. Агент заполнил пустоты по своему усмотрению. Управляемая генерация начинается с того, что вы перестаёте оставлять пустоты.

Минимальный контекст перед генерацией

Прежде чем просить агента что-либо генерировать, дайте ему правила игры. На этом этапе достаточно трёх файлов в проекте: PROJECT_RULES.md, ARCHITECTURE.md и TESTING.md. Полноценный контекстный слой мы соберём в главе 5, а сейчас — необходимый минимум, чтобы Cursor не выдумывал архитектуру на ходу.

PROJECT_RULES.md

Это конституция проекта для агента. Не «советы», а «законы»:

# PROJECT_RULES.md

- Код не писать до утверждения плана.

- Не менять больше 5 файлов без отдельного согласования.

- Бизнес-логика должна жить в service-слое.

- Controller не должен обращаться к базе напрямую.

- Каждый endpoint должен иметь тесты.

- Новые зависимости запрещены без объяснения.

ARCHITECTURE.md

Короткая карта слоёв и явных запретов. Для NestJS она почти очевидна, но именно поэтому её и нужно записать — чтобы агент не «улучшал» её на свой вкус:

# ARCHITECTURE.md

## Слои

- Controller принимает HTTP-запрос и передаёт вход через DTO.

- Runtime-валидация DTO работает только при включённом ValidationPipe и правилах валидации.

- Service содержит бизнес-логику.

- Repository работает с базой данных.

## Запрещено

- бизнес-логика в контроллере;

- прямые запросы к базе из контроллера;

- дублирование проверки ролей в каждом endpoint.

TESTING.md

# TESTING.md

- Каждый новый endpoint покрыт тестами.

- Обязательны негативные тесты (запреты, чужие данные).

- Тест проверяет поведение, а не реализацию.

- Happy path без негативных тестов не принимается.

ПОДСКАЗКА ПО CURSOR

Эти файлы нужно подключить как правила Cursor (rules) или явно прикладывать к запросу, иначе агент может их просто не увидеть. Где именно лежит настройка — смотрите в актуальной документации инструмента; механика меняется, а смысл нет: правила проекта должны попадать в контекст без ручного копипаста.

Практика: добавляем сущность Task

Теперь — тот же самый запрос «добавь задачи», но переписанный как инженерная задача. Сравните с «Добавь задачи в приложение» из начала главы:

Нужно добавить сущность Task.

Контекст:

- пользователь может создавать задачу;

- задача имеет title, description, status, createdById;

- assigneeId пока может существовать в модели как nullable-поле, но CreateTaskDto его не принимает;

- status: todo, in_progress, done;

- пока без комментариев, вложений и назначения задачи;

- использовать текущую архитектуру проекта;

- не добавлять новые зависимости.

Сначала составь PLAN_CREATE_TASK.md.

Код не писать.

Разберём, что мы сделали:

• Сузили задачу. Только сущность Task и её создание — без комментариев и вложений. Это страховка от того, что агент «заодно» сделает половину приложения.

• Зафиксировали модель данных. Перечислили поля и значения статуса, чтобы не получить случайный набор колонок.

• Запретили вольности. «Использовать текущую архитектуру», «не добавлять зависимости» — два самых частых источника мусора.

• Потребовали план до кода. Главная фраза: Сначала составь PLAN_CREATE_TASK.md. Код не писать. Пока нет плана — нет генерации.

Как проверять план

Агент вернёт план. Не принимайте его рефлекторно. Хороший план обязан отвечать на шесть вопросов:

какие файлы будут изменены;

какие файлы будут созданы;

какие решения агент сознательно не принимает (что вне задачи);

где будет жить бизнес-логика;

какие нужны тесты;