Сейчас я занят задачей, которая ещё год назад показалась бы странной: перевожу на вайбкодинг всех инженеров агентства. И не только инженеров — аналитиков, менеджеров, всех, чья работа хоть как-то соприкасается с продуктом.
Причина простая и не самая уютная. Я верю, что в заказной разработке работа останется только у тех, кто умеет работать с ИИ. Не «слышал», не «пробовал в ChatGPT», а именно умеет: ставит агенту задачу так, что тот не разносит проект в щепки. Остальные будут проигрывать по срокам и цене — тихо, без драмы, просто перестанут проходить в тендер.
И вот тут выясняется неприятное. Вайбкодинг — совсем не «попросил и получил». Агент, которому дали волю, врёт, ломает работающее, удаляет нужное и бодро рапортует, что всё исправил. Не потому что тупой, а потому что с ним не умеют работать.
Мы набили шишек, перечитали кучу чужих гайдов и оставили четыре практики, которые работают одинаково для всех. Сеньор вы или маркетолог — разницы нет.
1. Контекст — расходник. Тратьте его как деньги
Контекстное окно — это рабочая память агента. Пока оно свободное, агент собран, точен и делает ровно то, что просили. Чем плотнее набито — тем больше тупняка: ваша инструкция теряется среди сотни страниц кода, чужих файлов, старых скриншотов и обсуждений давно решённых багов.
Отсюда два правила, которые экономят больше времени, чем любой хитрый промпт:
- Новая задача — новый чат. Сделали, проверили, закоммитили — закрывайте. Даже если контекст забит на треть. Информация между сессиями не перетекает, и это не баг, а гигиена.
- Большие задачи режьте на маленькие. Пока агент изучит двадцать файлов и составит грандиозный план, он уже забьёт себе память под завязку — и пойдёт работать с мутной головой. Просите декомпозировать и делайте по одной атомарной задаче за чат.
Да, это медленнее, чем написать «сделай по кайфу» и любоваться, как агент полчаса пишет тысячи строк. Только после такого автономного полёта проект обычно лежит, а вы вечером ищете, где именно.
И отдельно: не ругайтесь в чат. «Ты тупая железяка, я десять раз просил» — это не мотивация, это мусор в контексте. Ругайтесь вслух, агенту пишите по делу.
2. Сначала план, потом код. И пусть агент сам себя раскритикует
Опытный разработчик, упёршись в развилку, останавливается и думает. Агент не остановится — он нафигачит как получится. Оно даже запустится, а внутри будет столько всего, что разгребать вы будете дольше, чем писали.
Поэтому любая задача начинается с Plan mode: агент не трогает файлы, а обсуждает, что и как собирается делать.
Смысл двойной. Во-первых, само планирование резко снижает количество глупостей: агент идёт по маршруту, а не мечется по файлам, снося куски кода то тут, то там. Во-вторых — и это ценно даже для тех, кто код читать умеет, — план можно обсудить, а тысячу строк диффа за десять минут не осилит никто. На уровне алгоритма дыры видно невооружённым глазом.
Дальше приём, который стоит вбить в привычку: попросите агента разнести собственный план. Что тут может пойти не так? Какие подводные камни? Действительно ли это лучшее решение или просто первое, что пришло в голову? Какие есть альтернативы?
Агент внезапно оказывается неплохим критиком — особенно самого себя. Дёшево, быстро, и заметно меньше сюрпризов из серии «ой, я удалил функцию, она, оказывается, была нужна».
3. Спека живёт в файле, а не в чате
Мелкую задачу можно спланировать прямо в диалоге. Большую — нет: она не влезет ни в одно окно, и половина договорённостей растворится вместе с закрытым чатом.
Поэтому на всё крупное пишется спека — техзадание в отдельном markdown-файле: что делаем, как должно работать, из каких шагов состоит, какими инструментами, как поймём, что готово, и как ничего не сломать по дороге.
Пишет её, разумеется, не человек — человек объясняет своими словами, а агент задаёт уточняющие вопросы и оформляет. Хорошая новость: в отличие от живого коллеги, агент готов отвечать на самые идиотские вопросы бесконечно и без вздохов.
Ценность в том, что файл не исчезает вместе с сессией. Открыли новый чат, кинули спеку: «работаем по ней, пункты 1–3 сделаны, делаем четвёртый». И так до конца, без «а что мы вообще хотели».
Это и называется spec driven development. С ним у нас практически вымерли ситуации в жанре «сделал — сломал — ой, сейчас поправлю — сломал сильнее».
4. Заведите агенту память. Иначе он с амнезией
Мы договорились не сидеть в одном чате вечно. Но у этого есть обратная сторона: каждый новый чат — чистый лист. Агент не знает ни проекта, ни архитектуры, ни того, почему вот этот странный файл трогать нельзя.
Представьте разработчика, к которому после каждой задачи приходят люди в чёрном и стирают память. И так каждое утро.
Лечится это базой знаний проекта — той самой документацией для агента, которую он сам себе и пишет (/init в Cursor и Claude Code создаёт файл вроде CLAUDE.md). При старте сессии он подхватывается автоматически, и агент проходит онбординг за секунды вместо десяти минут раскопок.
Для небольшого проекта хватит одного файла. Для крупного — единый файл сам становится проблемой: чтобы поменять цвет кнопки, агенту в память падает вся бизнес-логика, схема БД и правила деплоя. Поэтому базу режут на части: отдельно архитектура, отдельно сервер, отдельно правила кода, отдельно дизайн. А в корневом файле — карта: куда идти за чем.
И маленькое правило с большими последствиями: наступили на грабли — попросите записать это в базу знаний. Иначе наступите ещё десять раз, каждый раз как в первый.
Что из этого следует
Все четыре практики, если приглядеться, про одно: агент — не волшебник, а очень способный сотрудник с амнезией и без чувства ответственности. Ему нужны чистая голова, согласованный план, письменное ТЗ и документация под рукой. Ровно то же, что нужно живому человеку, только человек хотя бы помнит вчерашний день.
Отсюда и мой ответ на вопрос, останется ли работа в заказной разработке. Останется — у тех, кто умеет её организовать. Собственно, как и всегда: инструмент сменился, а профессия — нет.