ИИ делает ответы дешевыми. Дорогим становится мышление
Главный дефицит новой эпохи — не генерация текста или кода, а способность человека задать направление, оценить результат и не принять убедительную ошибку за решение.
Эфир начинался как разговор о вайб-кодинге, но довольно быстро вышел за пределы программирования. Центральная мысль автора проста: чем умнее становится искусственный интеллект, тем больше требуется собственного, естественного интеллекта. Модель умеет быстро производить ответы, презентации, сценарии и код. Однако скорость производства не гарантирует, что результат решает задачу бизнеса.
В этой логике человек должен быть не пассажиром, а пилотом. Пилот понимает, куда летит, замечает отклонение от курса и может проверить показания приборов. Пассажир видит уверенный ответ системы и принимает его на веру. Именно здесь возникает риск: языковая модель говорит убедительно даже тогда, когда опирается на неполный контекст, неверную гипотезу или выдуманную деталь.
Чем умнее становится искусственный интеллект, тем больше требуется своего естественного интеллекта.
Поэтому новая производительность складывается не из одного инструмента. Она появляется на пересечении трех вещей: предметной экспертизы, четко описанного контекста и системы проверки. Если опыт уже есть, ИИ его усиливает. Если опыта нет, он способен лишь замаскировать пробелы гладкой формулировкой.
От вайб-кодинга к смыслокодингу
Вайб-кодинг легко свести к эффектной демонстрации: написал запрос — получил приложение. Смыслокодинг начинается там, где в код переводят не настроение, а продуманную бизнес-логику.
Автор предлагает переименовать сам подход. Вайб-кодинг ассоциируется с импровизацией: человек описывает желание, а модель строит что-то похожее на продукт. Смыслокодинг — более зрелая дисциплина. Сначала формулируется смысл: для кого создается решение, какую проблему оно устраняет, каким должен быть итог и как его измерить. Только потом смысл переводится в интерфейс, процесс и код.
Это принципиальная смена оптики. Сайт, CRM или бот перестают быть целью. Они становятся формой, в которой реализуется экономически значимый процесс. Бизнес, по формулировке автора эфира, покупает не «вайб-кодинг» и не строки кода, а решение, которое сокращает затраты, ускоряет работу, повышает выручку или позволяет небольшой команде выполнять работу большой.
- Идея отвечает на вопрос «что хочется создать».
- Фундамент определяет стек, контекст и правила работы.
- Агентная среда превращает разовые запросы в повторяемый процесс.
- Методология удерживает качество, безопасность и связь с бизнес-результатом.
Именно поэтому зрелищный «Джарвис», который якобы думает за владельца, в эфире подвергается критике. За красивым интерфейсом обычно находятся обычные документы, ссылки между ними, подключение к данным и агент, который действует по инструкции. Магии нет. Есть архитектура и качество исходных знаний.
Второй мозг: не замена человеку, а память системы
Хороший агент не должен каждый раз заново расспрашивать о компании. Но и угадывать он не должен: знания требуется хранить в понятной, обновляемой структуре.
Под «вторым мозгом» в эфире понимается не отдельное приложение и не цифровой двойник, способный думать вместо владельца. Это локальная база знаний: набор текстовых файлов в формате Markdown, связанных между собой ссылками. Агент читает нужные документы перед работой и получает факты, которые иначе пришлось бы заново пересказывать в каждом запросе.
В папке бизнеса могут лежать сведения о юридическом лице, позиционировании, продуктах, тарифах, целевой аудитории, ее болях и возражениях, целях квартала, экономике, маркетинге и правилах коммуникации. Документы не обязаны быть огромными. Их задача — дать агенту маршрут к источнику истины: где взять цену, где посмотреть актуальные метрики, где проверить формулировку обещания клиенту.
Контекст должен обновляться
База знаний быстро превращается в архив, если ее только пополнять. Автор эфира описывает обратный процесс: отдельные агенты анализируют вопросы аудитории, результаты публикаций, показатели продаж и рабочие ретроспективы, а затем предлагают обновления контекста. Человек принимает или отклоняет эти изменения. Так второй мозг остается живым, но не получает права переписывать факты без контроля.
Файл правил проекта: короткая конституция для агента
Контекст отвечает на вопрос «что мы знаем», а файл проекта — «как здесь принято работать».
В экосистеме Claude таким файлом служит CLAUDE.md; в других инструментах используются аналогичные файлы инструкций. Он читается в начале работы и задает проекту устойчивые нормы. Автор советует держать его коротким: после примерно двух сотен строк агент хуже удерживает начало документа, а действительно важные правила растворяются среди подробностей.
Хороший файл проекта не пересказывает историю компании. Он дает одно-три предложения о продукте, карту репозитория, таблицу навигации «если нужен X — смотри сюда», ключевые запреты и обязательные действия, соглашения об именовании и форматировании, способ выкладки и проверки, а также порядок работы с планами и ретроспективами.
Правило и хук — не одно и то же
Текстовая инструкция остается пожеланием: модель может забыть или обойти ее. Хук — это исполняемый скрипт, который срабатывает на конкретное действие агента. Он способен остановить опасную команду, запретить публикацию без разрешения, проверить утечку ключей или автоматически запустить форматирование.
Скиллы и MCP: инструкция плюс доступ к действию
Скилл объясняет агенту, как выполнять повторяемую работу. MCP дает ему возможность обратиться к внешнему сервису. Вместе они превращают рассуждение в действие.
Скилл — это подробная рабочая инструкция для цифрового сотрудника. Внутри описаны условия запуска, последовательность шагов, необходимые проверки и образ готового результата. Если одну и ту же задачу приходится объяснять агенту третий раз, процесс уже просится в скилл.
Однако готовый скилл из каталога нельзя считать подходящим только потому, что он запускается. Он мог быть написан под другой бизнес, другую терминологию и иной уровень риска. Показательный вопрос прозвучал прямо в чате: участница собрала команду из пяти «сотрудников» Claude и подобрала им навыки из публичного каталога, но не была уверена, подходят ли они. Правильный ответ начинается не с доверия каталогу, а с теста на собственных данных и критериях.
Навыки должны учиться на результате
По методологии эфира каждому важному скиллу полезен «проверяющий»: отдельный процесс, который анализирует результат, находит дефекты и предлагает улучшения инструкции. Но предложения не должны применяться бесконтрольно. Если позволить модели оптимизировать саму себя без внешнего критерия, она может начать подгонять оценку под удобный ей результат.
MCP, или Model Context Protocol, в этой архитектуре выступает как стандартный разъем. Через подключенный сервер агент может прочитать календарь, получить метрики, обратиться к базе, поставить публикацию в очередь или забрать данные из другого приложения. Каждый активный коннектор занимает контекст и расширяет поверхность риска, поэтому автор советует подключать только то, что нужно для текущей работы.
Субагенты и рутины: много рук и работа без постоянного надзора
Автономность появляется не тогда, когда агенту дают длинный запрос, а когда работу можно безопасно разделить, запустить и принять по понятным признакам.
Главный агент может выступать оркестратором: раздать независимые части задачи субагентам, следить за состоянием плана и собрать результаты. Параллельность экономит время, но только если куски действительно независимы. Если каждая следующая фаза зависит от предыдущей, искусственное распараллеливание создаст конфликты и повторную работу.
Рутины — это процессы по расписанию или событию: ночная проверка, еженедельная ретроспектива, регулярная публикация, сбор метрик. В техническом смысле это может быть cron-задача или другой механизм автоматического запуска. В содержательном смысле рутина обязана иметь тот же набор, что и ручная задача: инструкцию, доступы, ограничения, критерий готовности и способ сообщить о сбое.
План как отдельный артефакт, а не сообщение в чате
Ошибка в плане исправляется за минуту. Та же ошибка, уже размноженная в коде и данных, может стоить дня работы.
Одна из самых практичных идей эфира — хранить планы в проекте отдельными файлами. План, оставшийся внутри чата, исчезает вместе с контекстом окна. На следующий день новый агент видит задачу иначе и начинает с нуля. Файл сохраняет решения, промежуточное состояние и историю проекта.
Рабочий план начинается не с перечня технологий, а с образа результата. Нужно описать словами, что должно получиться и по какому наблюдаемому признаку работа считается завершенной. Затем задача делится на фазы, каждая фаза получает собственный результат и проверку. Галочки в файле позволяют оркестратору и субагентам видеть, что уже сделано.
Три захода вместо одного промпта
Автор предлагает собирать серьезный план минимум в три прохода. В первом описывается желаемый результат и агент предлагает черновой путь. Во втором план проверяется на недостающие решения, зависимости и будущую нагрузку. В третьем он делится на фазы: независимые — для параллельного выполнения, зависимые — в правильной очередности.
Для интерфейсной задачи между замыслом и планом полезен макет. Сначала человек видит будущий экран, голосом исправляет структуру, а уже затем агент описывает реализацию функций. Такой порядок уменьшает риск детально спланировать не тот продукт.
Реализация по фазам
Когда план утвержден, каждую фазу передают агенту вместе с ограничением области работы. Независимые фазы можно раздать нескольким субагентам. После завершения ставится отметка и создается небольшой коммит. Итог собирается и проверяется в свежем контексте.
Git как страховка и журнал решений
Небольшие коммиты после законченных фаз дают точку возврата. Если агент сломал часть проекта, не приходится вручную распутывать все изменения: можно вернуться к предыдущему рабочему состоянию, понять границу ошибки и продолжить. Тот же принцип полезен для базы знаний и правил — история изменений показывает, когда и почему появилось решение.
Правила должны включаться только там, где они нужны
Один гигантский файл инструкций быстро перестает помогать. Устойчивее — короткое ядро и специализированные наборы правил, которые подключаются по контексту.
Юридические ограничения, стиль текста, дизайн, работа с платежами и запросы к базе требуют разных норм. Если загрузить все сразу, контекст переполнится, а важное затеряется. Поэтому рядом с проектом создаются отдельные файлы правил с масками путей или другими условиями включения.
Такой подход делает поведение агента предсказуемее. При редактировании клиентского текста подключаются лексика и юридические ограничения. При работе с оплатой — правила денег и доступов. При запросе к базе не расходуется контекст на дизайн и рекламный стиль.
«Готово» — это начало приемки, а не конец задачи
Агент сообщает о завершении работы, но это еще не доказательство. Нужны проверки решения, устойчивости, безопасности и фактического запуска.
В эфире предложена последовательность из четырех команд. Сначала агент должен доказать, что выбранное решение лучше рассмотренных альтернатив. Затем — подумать на несколько шагов вперед и оценить, что произойдет при росте данных или появлении следующей задачи. Третья проверка касается ошибок и безопасности. Четвертая требует запустить результат и показать, что он действительно работает.
Проверяет тот, кто не писал
Самопроверка полезна, но недостаточна: автор кода склонен защищать собственное решение, даже если автором выступает модель. Поэтому законченный фрагмент лучше передать в новое окно без истории обсуждения. Проверяющий получает только изменения — например, git diff — и задачу искать уязвимости, логические разрывы и непроверенные допущения.
Одно окно — одна задача
Чем больше в диалоге накопилось истории, тем труднее агенту удерживать цель, а человеку — понимать, на каком основании принято очередное решение.
Окно чата следует воспринимать как рабочий стол для одной ограниченной задачи. Планирование, реализация, тестирование и независимая проверка не обязаны жить в одном разговоре. Завершили задачу — закрыли окно. Переход к новому этапу начинается со свежего контекста и ссылки на зафиксированный план или результат.
Автор эфира приводит собственные ориентиры заполнения контекста: до 60% — рабочий режим, в районе 60–70% — сжатие, выше 70% — новое окно. Эти числа зависят от инструмента и не являются универсальным стандартом. Важнее сам сигнал: если агент забывает ранние условия, повторяет вопросы или начинает противоречить плану, пора сменить окно.
Сильная модель — на решения, доступная — на рутину
Планирование, исследование и архитектурные выборы требуют модели, которая лучше удерживает длинную причинно-следственную цепочку. Поиск, механическая реализация, сверка и повторяемые операции часто можно делегировать более доступной модели. Затем результат возвращается на сильную проверку. Такая лестница снижает стоимость без отказа от качества на критических этапах.
Каждое исправление должно становиться правилом
Если человек ежедневно повторяет агенту одно и то же замечание, система не учится. Исправление нужно превращать в сохраненное правило с понятной областью действия.
Полезный цикл выглядит так: ошибка замечена, причина сформулирована, правило записано, область применения определена, следующий результат проверен. Для устойчивости правило удобно оформлять по схеме «что запрещено или требуется — почему — как действовать правильно». Тогда оно не превращается в безадресный список претензий.
Особенно ценны правила, появившиеся из реальных потерь: неверной юридической формулировки, случайной публикации, утечки секрета, лишнего обещания клиенту или стилистического провала. Но и здесь нужен уход: устаревшие или конфликтующие правила следует пересматривать, иначе накопленная память начнет мешать работе.
Что в итоге покупает бизнес
Технологический навык становится ценным только тогда, когда связан с измеримым результатом и надежным процессом.
По позиции автора эфира, рынок быстро обесценивает сам факт умения «попросить модель написать сайт». Такой навык легко повторить. Значительно труднее построить систему, которая знает контекст компании, действует по правилам, подключается к нужным данным, распределяет работу, проверяет себя и оставляет человеку понятные точки контроля.
Отсюда меняется и профессиональная роль. Специалист по смыслокодингу не продает набор промптов. Он проектирует процесс: определяет образ результата, документирует ограничения, выбирает степень автономности, выстраивает приемку и считает экономику. Чем дороже ошибка, тем больше в системе должно быть технических ограничителей и независимых проверок.
- Для контента важны фактичность, тон, юридические обещания и реакция аудитории.
- Для продаж — качество лида, стоимость контакта, конверсия и корректность работы с данными.
- Для кода — надежность, безопасность, возможность отката и стоимость сопровождения.
- Для автоматизации — устойчивость расписания, обработка сбоев и понятный владелец процесса.
Автономия в этой модели не означает исчезновение человека. Она означает перенос человеческого внимания туда, где оно дороже всего: к постановке задачи, исключениям, конфликтам целей и оценке результата.
Рабочая памятка: 20 правил смыслокодинга
Финальный слайд эфира сводит методологию в короткий список. Ниже — редакционная расшифровка, которую можно использовать как контроль перед стартом проекта.
- Храните знания бизнеса рядом с проектом и ведите их как рабочую систему, а не архив.
- Соберите ключевые правила проекта в одном коротком файле.
- Критические запреты обеспечивайте хуками, а не только текстовыми просьбами.
- Подключайте специализированные правила лишь для подходящих задач и файлов.
- Сохраняйте планы в файлах, а не оставляйте их в истории чата.
- Выносите чужие и найденные методики в отдельную папку с указанием источника и области применения.
- Описывайте, что должно получиться и как увидеть готовность, прежде чем обсуждать реализацию.
- Разбирайте план вопросами, пока изменения еще дешевы.
- Повторяемое объяснение превращайте в скилл.
- После слова «готово» начинайте приемку, а не доверяйте заявлению.
- Для крупной задачи используйте несколько окон и четко фиксируйте назначение каждого.
- Пусть оркестратор сам распределяет подготовленные части работы между субагентами.
- Закладывайте итерацию: агент улучшает результат, пока не выполнены критерии.
- Проверку поручайте свежему агенту, который не создавал решение.
- Проверяйте с разных сторон и исправляйте именно ту часть, где обнаружен дефект.
- Делайте маленькие коммиты и сохраняйте возможность точечного отката.
- Соблюдайте правило «одно окно — одна задача».
- Автоматизируйте рутины только после того, как ручной процесс стал понятным и проверяемым.
- Используйте сильную модель для планирования и решений, более доступную — для рутины.
- Каждое повторяющееся исправление оформляйте как правило и позже проверяйте его актуальность.
С чего начать завтра
Не нужно сразу строить «я-компанию» из сотен агентов. Выберите одну частую, хорошо знакомую и обратимую задачу. Опишите результат, соберите минимальный контекст, вручную выполните процесс вместе с агентом и зафиксируйте удачную последовательность в скилле. Затем добавьте независимую проверку. Только после нескольких стабильных повторов подключайте расписание или внешние сервисы.
Смыслокодинг начинается не с выбора идеального редактора или модели. Он начинается с ответственности за смысл. Человек определяет, что важно; система хранит контекст; агенты выполняют и проверяют; история проекта позволяет учиться. Именно эта связка превращает ИИ из эффектной игрушки в рабочую инфраструктуру.