Павел Булкин – Вайб-кодинг. Практический курс (страница 3)
Практическое задание
Выполните один и тот же запрос двумя способами в вашем любимом ИИ-инструменте:
ленивым промптом («Сделай мне сервис задач»);
инженерным запросом с ограничениями (из примера выше).
Затем сравните оба результата по пяти критериям и заполните таблицу. Отвечайте честно — «да», «нет» или «частично»:
Критерий
Ленивый промпт
Инженерный запрос
Права доступа учтены?
Есть тесты?
Есть edge cases?
Есть план?
Агент изменил лишнее?
УСЛОЖНЕНИЕ
Дайте инженерный запрос дважды с интервалом — например, в начале и в конце рабочего дня — и сравните оба плана между собой. Где агент «доехал» до разных решений? Это ваш первый личный замер дрейфа намерений, к которому мы вернёмся в главе 4.
Артефакт введения: BASELINE_COMPARISON.md
Зафиксируйте результат сравнения в первом артефакте курса — файле BASELINE_COMPARISON.md в корне проекта. Это ваша точка отсчёта: к ней вы вернётесь в конце книги, чтобы увидеть, насколько изменился ваш способ работать с ИИ. Используйте такой скелет:
# BASELINE_COMPARISON.md
## Дата
## Инструмент и модель
## Запрос 1: ленивый промпт
Текст запроса:
Наблюдения:
- что сгенерировал агент;
- что пошло не так.
## Запрос 2: инженерный запрос
Текст запроса:
Наблюдения:
- что изменилось;
- какие риски агент назвал сам.
## Таблица сравнения
| Критерий | Ленивый | Инженерный |
| --- | --- | --- |
| Права доступа учтены? | | |
| Есть тесты? | | |
| Есть edge cases? | | |
| Есть план? | | |
| Агент изменил лишнее? | | |
## Вывод
Один абзац: что я понял про разницу между вайбом и инженерией.
Пора протрезветь
Похмелье — это неприятно, но это признак того, что вечеринка закончилась и пора браться за серьёзную работу. Мы больше не играем с ИИ. Мы строим с его помощью системы, за которые отвечаем.
Ваша ценность как разработчика больше не измеряется тем, как быстро вы печатаете функцию sort(). Она измеряется тем, насколько точно вы умеете ставить задачу, проектировать контекст и сохранять критический взгляд в мире бесконечной генерации. ИИ — гениальный, но забывчивый стажёр со склонностью срезать углы. Ваша работа — быть взрослым в этой паре.
В следующей главе мы добавим в TaskFlow AI первую фичу — создание задач — но не «навайбим» её, а проведём через управляемую генерацию: контекст, план, ревью, минимальный diff. Переверните страницу. Начинаем строить по-настоящему.
ЧАСТЬ 1
Инструменты новой эры
Соблазн первой части любой книги про ИИ-разработку — устроить парад инструментов: вот Cursor, вот Devin Desktop (бывший Windsurf), вот Claude Code, вот spec-first инструменты вроде Traycer, у каждого свои кнопки. Проблема в том, что такой обзор устаревает быстрее, чем читатель дойдёт до середины. Кнопки переименуют, меню переедет, появится новый модный редактор.
Поэтому мы смотрим на инструменты не как на продукты, а как на рабочие режимы. У каждого режима — своя сильная сторона, и важно не «какой инструмент лучше», а «какой режим нужен под текущую задачу»:
• Cursor — контролируемая генерация: понятная задача, ограниченный контекст, предсказуемый diff.
• Devin Desktop (бывший Windsurf) — глубокий контекст: понять чужой, плохо документированный код (глава 2).
• Claude Code — автономный терминальный цикл: запустить тесты, найти причину, починить (глава 3).
• Traycer и подход «спецификация до кода» — заморозить намерение раньше, чем оно поплывёт (глава 4).
Названия поменяются. Режимы — нет. Начнём с самого частого: управляемой генерации новой фичи.
ЧАСТЬ 1 · ГЛАВА 1
Cursor: первая фича через управляемую генерацию
Добавляем создание задач в TaskFlow AI — без хаоса
Вайб-кодинг: Практический курс
Что Cursor делает хорошо
Не будем пересказывать историю инструмента. Достаточно знать главное: Cursor удобен, когда агенту нужно работать не с изолированным фрагментом, а с контекстом проекта — открытыми файлами, правилами, поиском по кодовой базе и текущим diff. В актуальных версиях у Cursor есть Plan Mode: режим, в котором агент сначала формирует проверяемый план реализации. Не считайте это магической защитой от ошибок; считайте это удобной точкой контроля, где человек должен остановиться и прочитать план до изменения кода.
Практический вывод одной фразой:
КОГДА CURSOR В СВОЕЙ СТИХИИ
Cursor хорош, когда у вас есть понятная задача, ограниченный контекст и вы хотите получить контролируемый diff — конкретный набор изменений, который можно прочитать и принять или отклонить целиком.
И обратное тоже важно. Cursor — не лучший выбор, когда нужно разобраться в огромной чужой системе, где правка в одном сервисе каскадом роняет три других (это работа для главы 2), или когда задача — не добавить код, а удалить лишний (глава 10). Каждому режиму своё.
Почему «сделай фичу» — плохая команда
Самый частый способ испортить себе день — открыть Composer и написать что-то вроде: