Содержание

Введение. Похмелье после вечеринки

ЧАСТЬ 1. ИНСТРУМЕНТЫ НОВОЙ ЭРЫ

Глава 1. Cursor: первая фича через управляемую генерацию

Глава 2. Devin Desktop (бывший Windsurf): глубокий контекст и ИИ-археология

Глава 3. Claude Code: безопасный терминальный агент

Глава 4. Спецификация как код: от желания к контракту

ЧАСТЬ 2. МЕТОДОЛОГИЯ ВАЙБ-КОДИНГА 2.0

Глава 5. Контекстная инженерия: строим среду, а не промпт

Глава 6. Plan Mode: как читать и править планы ИИ

Глава 7. MCP: подключаем ИИ к реальности

ЧАСТЬ 3. КРИЗИС ДОВЕРИЯ

Глава 8. Security Lab: почему ИИ пишет дырявый код

Глава 9. AI Code Review: аудит чёрного ящика

Глава 10. Техническая инфляция: учим ИИ удалять код

ЧАСТЬ 4. БУДУЩЕЕ ПРОФЕССИИ

Глава 11. От джуниора к архитектору: дирижируем флотом агентов

Глава 12. Командный стандарт: дисциплина, которая работает без вас

Заключение. Похмелье прошло. Начинается ремесло.

Мы научились генерировать, но разучились понимать

Февраль 2025-го был временем почти детской эйфории. Мы все чувствовали себя волшебниками. Термин «вайб-кодинг», который Andrej Karpathy (Андрей Карпати) бросил в одном твите, за пару месяцев превратился из шутки в религию индустрии. Мы описывали желание словами, жали «Generate» в Cursor или тогдашнем Windsurf (с июня 2026-го — Devin Desktop) — и получали рабочее приложение. Прототип за обеденный перерыв. Стартап за выходные. Казалось, что синтаксис скоро станет таким же архаизмом, как перфокарты.

Это была грандиозная вечеринка. Но к началу 2026-го эйфория сменилась инженерным похмельем. Публичные опросы разработчиков показывают: ИИ-инструменты стали массовой частью рабочего процесса, но доверие к их точности остаётся ограниченным. Например, Stack Overflow Developer Survey 2025 фиксирует, что 46% разработчиков скорее не доверяют точности AI tools, 33% доверяют, а полностью доверяют только около 3%. Узкое место всё чаще переезжает из написания кода в его чтение, ревью, проверку безопасности и сопровождение. Мы научились очень быстро бежать — и всё чаще вынуждены останавливаться, чтобы понять, куда именно бежим и какой груз несём за спиной.

Похмелье у всех одинаковое. Симптомы такие:

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

• пул-реквесты пухнут до тысяч строк, которые невозможно осмысленно проверить;

• люди принимают код, который не понимают, нажимая не «Merge», а «верю на слово»;

• тесты проверяют не бизнес-правила, а то, что ИИ сам решил проверить;

• архитектура тихо расползается — пока в три часа ночи что-то не падает в продакшене из-за пограничного случая, который никто не продумал.

Проблема не в том, что ИИ пишет плохой код. Проблема в том, что он может писать слишком много кода быстрее, чем команда успевает его понять. Раньше технический долг копился месяцами из-за лени и сроков. Теперь он может появиться за один сеанс генерации — и стоимость чтения, отладки и поддержки никуда не делась. Она просто стала заметнее.

Договор с читателем

Эта книга не будет сборником магических промптов и не будет обзором модных IDE, который устареет через полгода. Обзоры инструментов гниют быстрее, чем выходят из печати. Эта книга — практический курс по управлению ИИ-разработкой. Курс, после которого вы не «знаете про ИИ», а умеете им управлять.

Чтобы между нами не было недопонимания, договоримся на берегу. Прочитав книгу и проделав упражнения, вы получите ответы на пять вопросов:

Какую проблему она решает. Как генерировать код с помощью ИИ и при этом не терять контроль над системой, безопасностью и архитектурой.

Кому она подходит. Разработчикам, тимлидам и архитекторам, которые уже пользуются ИИ-агентами и устали от хаоса. Не нужно быть сеньором; нужно быть готовым работать руками.

Что вы будете делать руками. Писать спецификации, читать и править планы ИИ, ревьюить чужой сгенерированный код, атаковать собственные фичи, заставлять агента удалять лишнее.

Какой проект соберёте. Один сквозной учебный сервис, который будет расти в сложности от главы к главе.

Что унесёте с собой. Набор файлов и навыков, которые можно в понедельник принести в свою реальную команду.

КАК ПОЛЬЗОВАТЬСЯ КУРСОМ

Каждая глава заканчивается практическим заданием и главным артефактом — иногда одним файлом, иногда небольшим набором файлов, которые вы создаёте сами. Не пропускайте их. Книгу можно прочитать за вечер, но курс нельзя «прочитать» — его можно только пройти. Артефакты складываются в один растущий репозиторий, и к финалу у вас на руках — рабочий каркас инженерной ИИ-разработки.

Как устроен этот курс

В основе книги — один принцип. Запомните его, он определяет всё остальное:

ГЛАВНЫЙ ПРИНЦИП

Один сквозной проект. Одна растущая сложность. Практический артефакт или небольшой набор артефактов после каждой главы.

Мы не будем перескакивать с примера на пример. Через всю книгу проходит один проект, и каждая глава добавляет к нему ровно столько сложности, сколько нужно, чтобы показать новый навык: роли и права, API, базу данных, авторизацию, безопасность, логи, баги, технический долг, ревью и рефакторинг. Сложность растёт вместе с вами, а после каждой главы в репозитории остаётся один главный артефакт или небольшой набор файлов.

И ещё одно важное обещание. Мы переписали этот курс так, чтобы практика не была пришита к концу теоретических глав. Каждая глава построена вокруг действия. Скелет главы один и тот же:

• плохой запрос — как сделать не надо и что при этом ломается;

• инженерный подход — как переформулировать то же самое в управляемую задачу;

• шаблоны файлов — что именно вы создаёте;

• практическое задание и усложнение;

• артефакт главы — файл или небольшой набор файлов, который остаётся у вас в проекте.

Сквозной проект: TaskFlow AI

Наш учебный проект — TaskFlow AI, сервис управления задачами для команды. Он выбран не случайно: на нём естественно вырастают все темы курса — от прав доступа до безопасной загрузки файлов. В нём будут:

• пользователи и роли admin, manager, member;

• команды: у manager и member есть teamId; для курса считаем, что пользователь состоит в одной команде;

• задачи со статусами todo, in_progress, done и отдельной архивацией через archivedAt, комментарии и вложения;

• REST API и база данных;

• права доступа и авторизация;

• тесты, аудит безопасности и рефакторинг.

Стек — Node.js + TypeScript на NestJS с базой PostgreSQL. Архитектура классическая, слоёная: контроллер принимает HTTP-запрос, сервис содержит бизнес-логику, репозиторий работает с базой. Если вы пишете на другом стеке — не страшно. Навыки этого курса (спецификация до кода, ревью плана, threat model, аудит PR) переносятся на любой язык и фреймворк с небольшой адаптацией. NestJS здесь — просто конкретные декорации, чтобы примеры были настоящими, а не «псевдокодом из вакуума».

Доменная оговорка для следующих глав: «своя команда» означает совпадение teamId у manager, задачи и assignee; archived task = archivedAt != null, а не status=done; Guard отвечает за аутентификацию, TaskAccessPolicy/TaskAccessService — за бизнес-правила доступа.

ЧТО ВАЖНЕЕ СТЕКА

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

Что вы соберёте

К концу курса в репозитории TaskFlow AI появится отдельный пласт — инженерный контекст и инструменты управления ИИ. Вот полная карта основных артефактов; пока она выглядит как список незнакомых файлов, но каждый из них появится в соответствующей главе:

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. план реализации.

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

Практическое задание

Выполните один и тот же запрос двумя способами в вашем любимом ИИ-инструменте:

ленивым промптом («Сделай мне сервис задач»);

инженерным запросом с ограничениями (из примера выше).

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

Критерий

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

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

Права доступа учтены?

Есть тесты?

Есть edge cases?

Есть план?

Агент изменил лишнее?

УСЛОЖНЕНИЕ

Дайте инженерный запрос дважды с интервалом — например, в начале и в конце рабочего дня — и сравните оба плана между собой. Где агент «доехал» до разных решений? Это ваш первый личный замер дрейфа намерений, к которому мы вернёмся в главе 4.