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

docs/ai-context/

PROJECT_RULES.md

ARCHITECTURE.md

SECURITY.md

TESTING.md

DOMAIN_GLOSSARY.md

API_CONTRACT.md

features/

SPEC_TASK_ASSIGNMENT.md

SPEC_REVIEW.md

SPEC_FILE_UPLOAD.md

PLAN_CREATE_TASK.md

TASK_FEATURE_REVIEW.md

PLAN_COMMENTS.md

PLAN_REVIEW_NOTES.md

PLAN_FILE_UPLOAD.md

THREAT_MODEL_FILE_UPLOAD.md

SECURITY_REVIEW_FILE_UPLOAD.md

NEGATIVE_TEST_PLAN.md

AI_PR_REVIEW.md

REFACTORING_PLAN.md

analysis/

MODULE_MAP_TASKS.md

CONTEXT_HALLUCINATION_CHECK.md

TEST_FAILURE_INVESTIGATION.md

CONTEXT_GAP_REPORT.md

CONTEXT_BUNDLE.md

BUG_DIAGNOSIS_PLAN.md

DUPLICATION_REPORT.md

context/

# временная папка с логами, схемами, тикетами и другими источниками для диагностики

process/

AGENT_SANDBOX_RULES.md

MCP_ACCESS_POLICY.md

ARCHITECT_PLAYBOOK.md

TEAM_STANDARD.md

.github/

pull_request_template.md

BASELINE_COMPARISON.md

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

Первый контраст: ленивый вайб против инженерного запроса

Чтобы почувствовать разницу между «вайбом» и инженерией прямо сейчас, посмотрим на два запроса к одному и тому же агенту. Оба просят одно и то же — сервис задач. Но получат они разное.

Ленивый промпт

Сделай мне сервис задач.

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

Инженерный запрос

Сначала составь план реализации сервиса задач.

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

Контекст:

- есть роли admin, manager, member;

- manager может назначать задачи;

- member может менять статус только своих задач;

- admin может удалять любую задачу;

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

- member не может удалять чужие задачи;

- нужны тесты на права доступа;

- нельзя хранить секреты в коде.

Выведи:

1. модель данных;

2. API;

3. список файлов;

4. риски безопасности;

5. edge cases;

6. план реализации.

Разница не в «секретном слове» и не в вежливости. Разница в том, что во втором случае вы задали ограничения, потребовали план до кода и описали, что именно хотите получить на выходе. Вы перестали быть просителем и стали постановщиком задачи. Весь курс — про то, как делать это системно.