«Дай мне шесть часов, чтобы срубить дерево, и я потрачу первые четыре на заточку топора»
— Авраам Линкольн
Однажды в 1968 году программист Мелвин Конвей опубликовал скромную статью, в которой сформулировал закон: «Системы, которые создают организации, неизбежно отражают структуру коммуникаций этих организаций». Иными словами — как ты управляешь людьми, так и выглядит то, что они делают. Спустя 57 лет этот закон заработал в обратную сторону: теперь то, как ты управляешь ИИ, учит тебя, как надо управлять людьми. И никто не усвоил этот урок лучше, чем вайб-программисты.
Вайб-кодинг — это практика создания программного обеспечения, при которой человек описывает задачу на естественном языке, а ИИ (Claude, Codex, Cursor) пишет код. Термин придумал исследователь Андрей Карпатий в начале 2025 года. Сегодня так работают тысячи разработчиков по всему миру. И у них есть кое-что важное для нас, консультантов.
1. Контекст ограничен — делите слона на части
У любой языковой модели есть контекстное окно — объём информации, который она удерживает в «голове» в рамках одного сеанса. Как только информация превышает этот объём, модель начинает «забывать» начало разговора, терять нить и делать ошибки.
Опытные вайб-программисты знают: как только проект вырастает, нужно дробить работу на сессии, использовать якорные файлы (TASKS.md, ORCHESTRATOR.md, AGENTS.md), которые в начале каждой сессии напоминают системе, в чём суть проекта, что уже сделано и куда двигаться дальше.
Урок для консультанта: У вашего слушателя тоже есть контекстное окно. И оно у некоторых генеральных директоров подозрительно маленькое 😄. Когда вы делаете презентацию на 80 слайдов, вы переполняете контекст уже к тридцатому. Это не значит, что человек глупый — это значит, что у него в голове ещё 15 других проектов, звонок через час и кофе ещё не подействовал.
Что делать? Постоянно «начинать новую сессию»: возвращаться к главному вопросу, напоминать о контексте, резюмировать промежуточные выводы. Каждый крупный блок презентации должен начинаться с одного слайда-якоря: «Мы решаем вот эту проблему, и вот где мы сейчас». Точно так же, как TASKS.md напоминает ИИ, что важно.
2. Как задачу поставишь — так она и будет сделана
Это, пожалуй, самый жёсткий урок вайб-кодинга. Если вы скажете ИИ «сделай мне сайт» — получите что-то. Если вы напишете чёткое техническое задание с описанием инфраструктуры, стека, того, что уже есть, что нужно сделать, как выглядит «готово» (definition of done) — получите совсем другой результат.
Опытные вайб-программисты перед каждым большим заданием пишут что-то вроде мини-ТЗ: контекст проекта, что уже сделано, что нужно получить на выходе, какие ограничения. Это называется PRD (Product Requirements Document) или просто «проблема на листе бумаги».
Урок для консультанта: Это и есть знаменитый «problem on the sheet» — сформулируй задачу письменно, прежде чем браться за её решение. Когда менеджер говорит аналитику «разберись с операционными затратами» — аналитик делает одно. Когда он пишет: «Нам нужно понять, почему операционные затраты выросли на 15% за квартал в сравнении с планом, сосредоточившись на логистике и закупках, и предложить 3 рычага с потенциалом >$2M» — аналитик делает совсем другое.
Хорошее техническое задание для человека или ИИ содержит одно и то же: контекст, задачу, критерии готового результата, ограничения. Вайб-кодинг делает этот навык обязательным — без него система просто не работает.
3. Агенты и субагенты: каждый аналитик — руководитель проекта
В современном вайб-кодинге всё больше используется архитектура оркестратор → субагенты: один главный агент разбивает задачу на части и раздаёт их специализированным субагентам, каждый из которых видит только свой кусок работы. Оркестратор следит за общей картиной, интегрирует результаты, управляет зависимостями между задачами.
Это работает только тогда, когда задача правильно декомпозирована, интерфейсы между субагентами чётко определены, и каждый получает ровно тот контекст, который ему нужен — не больше и не меньше.
Урок для консультанта: Любой аналитик в проектной команде — это субагент. Он видит свой workstream, не видит чужого, и может принять решение, которое оптимально для его части, но разрушительно для общей картины. Задача руководителя проекта — не просто раздать задачи, а спроектировать архитектуру: кто делает что, где пересечения, кто интегрирует результаты. Если вы это не сделали в начале — получите набор несвязанных слайдов вместо связного сторителлинга. В вайб-кодинге это называется «непродуманный оркестратор». В консалтинге это называется «провальный финальный стаф».
4. Уползание контекста — следите, ту ли задачу вы решаете
Вот один из самых коварных феноменов в работе с ИИ: context drift, или уползание контекста. Вы начинаете сессию с задачей А. Через 40 сообщений система предлагает решения, которые технически красивы, но уже не имеют отношения к задаче А. Она «уползла» к задаче Б, которая кажется ей более интересной или логичной.
Разработчики борются с этим через регулярные «якоря» — вставляя в начало каждого нового блока работы напоминание о первоначальной задаче, делая /clear в Claude Code, начиная новые сессии для новых фич.
Урок для консультанта: Это происходит на каждом проекте. Началось с оптимизации цепочки поставок — через три недели команда увлечённо строит цифровую стратегию. Причём все довольны. Клиент говорит «интересно», команда говорит «глубоко», и никто не замечает, что исходный вопрос остался без ответа.
Лечение то же: регулярно возвращаться к исходному запросу. Повесить его на стену. Проверять каждую неделю: то ли мы решаем? Каждый стиринг-коми должен начинаться с повторения исходного вопроса проекта.
5. Итерация быстрее перфекционизма
Вайб-программисты очень быстро поняли: не надо пытаться написать идеальный промпт с первого раза. Лучше сделать быстрый прототип, посмотреть, что получилось, скорректировать, повторить. Итерации короткие — 5-10 минут. Качество растёт не от идеального задания, а от количества циклов обратной связи.
Это принципиально меняет подход: вместо «думай долго, делай один раз» — «думай немного, делай быстро, смотри на результат, думай снова». Исследования показывают, что разработчики с AI-ассистентами выполняют задачи на 55% быстрее именно потому, что итерируют быстрее.
Урок для консультанта: Консалтинговая культура часто воспитывает перфекционизм: не показывай до тех пор, пока не готово. В результате аналитик три дня делает «идеальный» анализ, который в итоге решает не ту задачу. Лучше показать черновик гипотезы через 4 часа, получить обратную связь и скорректировать курс. В вайб-кодинге это называется «быстрый прототип для проверки направления». В консалтинге это называется «алайнмент с клиентом на ранней стадии». Результат один: меньше потраченного времени в неправильном направлении.
6. Экстернализация знания — то, чего нет на бумаге, не существует
В хорошем вайб-проекте всё важное зафиксировано в файлах: архитектурные решения — в ARCHITECTURE.md, принятые решения — в DECISIONS.md, текущий статус — в TASKS.md. Это не бюрократия — это страховка от амнезии. Если разработчик начал новую сессию с Claude и не показал ему эти файлы — Claude «не знает» ничего из предыдущей работы и начнёт сначала.
Принцип прост: то, что не зафиксировано, не существует для системы.
Урок для консультанта: Сколько раз на проекте «знание» жило исключительно в голове одного человека? Ведущий аналитик знает, почему было принято то или иное решение. Менеджер помнит, что клиент говорил три недели назад на неформальной встрече. Директор понимает, куда клиент хочет прийти «на самом деле». А потом кто-то заболевает, уходит в отпуск или уходит с проекта — и команда теряет половину контекста.
Хороший проект, как хороший репозиторий: гипотезы, принятые решения, причины отказа от альтернатив и договорённости с клиентом должны быть письменными. Это не лишняя работа — это то, что позволяет проекту работать даже когда люди меняются.
7. Верификация важнее генерации
Вайб-программисты обнаружили парадокс: чем лучше ИИ генерирует код, тем важнее становится умение его проверять. ИИ может написать красивый, синтаксически правильный код, который делает совсем не то, что нужно — и при этом выглядит убедительно. Amazon после нескольких инцидентов ввёл правило: каждая строка AI-сгенерированного кода проходит ручной аудит.
Паттерн «уверенная неправота» — один из самых опасных в работе с AI. Система не говорит «я не уверена» — она выдаёт ответ с одинаковой интонацией вне зависимости от того, права она или нет.
Урок для консультанта: Это один в один описывает риск работы с джуниор-аналитиками (и, честно говоря, с некоторыми старшими тоже). Красиво оформленный слайд с убедительно выглядящими цифрами не означает, что анализ правильный. Навык критической верификации — умение задать правильные вопросы к чужой работе, проверить логику и данные — в эпоху ИИ становится важнее, чем умение самому делать анализ. Лучший консультант будущего — не тот, кто быстрее генерирует, а тот, кто лучше проверяет.
Если посмотреть на всё вышесказанное целиком — вайб-кодинг учит тому же, чему учит хорошая консалтинговая практика, только делает это невозможным игнорировать. Плохое ТЗ? Система сломается немедленно. Не зафиксировал решения? Потеряешь контекст уже завтра. Не проверил результат? Получишь красивый баг в проде.
В консалтинге последствия медленнее и мягче — можно годами делать плохие технические задания и списывать это на «сложных клиентов». Вайб-кодинг безжалостен: обратная связь мгновенная.
Именно поэтому я рекомендую каждому консультанту попробовать собрать что-нибудь с Claude или Cursor — не ради кода, а ради того, чтобы почувствовать на своей шкуре, что происходит, когда принципы структурированного мышления работают (или не работают) в реальном времени 🚀
Если узнали себя хотя бы в трёх пунктах — пора открывать новую сессию.
Комментарии