Что такое вайбкодинг и почему о нём так много говорят?

Битрикс24 выпустил бесплатный курс для гуманитариев из 11 уроков, где простым языком разбирают вайбкодинг и показывают, как делать первые проекты с ИИ без знания языков программирования.

Курс будет полезен руководителям, маркетологам, HR, менеджерам — всем, кому интересна тема. Формат практический: минимум теории, первые проекты, разбор ошибок, работа со структурой и сценариями.

Пройти курс можно на любой платформе:
YouTube / VK / RuTube

Каждая фича старого SaaS теперь переосмыслена ИИ

Подумай же и ты об этом:

– Old school SaaS полагался на жёсткие предопределённые правила и данные. Теперь ИИ заменяет их контекстной логикой.

– Сбор данных раньше был в виде статичных форм с фиксированными полями, которые нужно было заполнять руками (своими или пользователей). С ИИ это а) автозаполнение; б) обогащение данных за секунды.

– Workflows раньше строились руками менеджеров и разрабов как цепочки «If-This-Then-That», где люди проектировали каждый шаг. Теперь ты описываешь всё текстом и ИИ собирает и проводит процессы.

– Импорт данных раньше был по жёстким шаблонам CSV, который ломался на любой ошибочной строке и приходилось тратить часы на её поиск и исправление. Теперь ИИ ест данные за минуты.

– Поиск внутри продукта... Помню, на заре 2010-ых был целый сегмент продуктов по поиску внутри продуктов. Где они сейчас, где будут завтра?

– Обучение/документация были протухшей базой знаний FAQ. С ИИ документация жива и актуальна.

– Аналитика была взглядом на месячную задержку данных. ИИ анализирует онлайн.

– Дизайн был делом вкуса и времени. Теперь с ИИ остался только вкус.

– Старый спам уведомлений. ИИ-саммари и группировка.

– Онбординг? ИИ-адаптация!

– API? MCP!

– SaaS теперь источник данных для ИИ.

– Новые фичи = интеграция данных, а не фич

– Новый UI/UX = голос-чат

Мой старый знакомый не смог пройти мимо и прислал такой коммент к предыдущему посту. С его разрешения, дополняю пост своим ответом и накину на вентилятор свежей аналитеки от a16z (TLDR между строк: сокращайте операционку всех ещё сильнее)

>>>

Привет. Огромное спасибо за столь развернутый комментарий :) Дело в том, что я с ним и согласен и не согласен одновременно. Объясню почему.

Разрабы сейчас и разрабы пару лет назад — совершенно разные специалисты.

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

И я думаю, что именно в этом всегда было главное недовольство к разрабам со стороны менеджеров и руководства, а не что-то личное непереносимое (с этим у большинства продактов проблем нет).

Сейчас с ИИ всё меняется (люди и процессы).

Те разрабы, кто оказался не такими и сохранили и пронесли до эпохи ИИ в себе немного пользовательской эмпатии, они поняли, что теперь с ИИ и агентами они могут СОЗДАВАТЬ продукты для пользователей, а не просто писать код для продуктов.

И такие спецы выстраивают вокруг себя на работе целую сеть из ИИ-агентов, которые работают и кодят и проверяют за них (и это видит руководство), либо... они уже пилят свои продукты. Самые хитрые делают и то и другое. А те, кто этого ещё не понял и кто по старинке с самодовольным видом пытается кодить код, их, к сожалению, оптимизируют.

А с корпами просто – в корпах всегда всё было сломано: здравый смысл, процессы, стратегия, псевдо-культура, даже монетизация и та через одно место из-за влияния фондового рынка, инвестиций, кокаинума и оторванного от реальности восприятия мира вокруг (я не говорю уже о том, что мира внутри продукта под названием пользователи и их лояльность для корпы не существует в природе). Так задумано, в этом "дух" корпы.

Всё это было сломано до нас, и с приходом ИИ будет ломаться дальше, больше, сильнее и безумнее. Мы это уже сейчас видим в виде увольнений и сокращений и рандомного перекладывания работы уволенных на плечи кривого ИИ и разных там оркестров.

А кто рулит этим процессом? Кто решает кого нанимать, кого заменять, кого увольнять? Те же, кто раньше нанимал десятки тысяч сотрудников просто "потому что можем себе это позволить".

А значит их самодурство и недальновидность будут иметь место и дальше и будут только лишь усиливаться и одобряться ИИ. Просто потому что ИИ всегда говорит им «да».

И в один момент, ИИ+консультанты скажут "настало время управления с ИИ". и они согласятся, потому что: а) это легко/удобно/контролируемо; б) это выгодно; в) их ИИ не будет заменять (но это не точно, читай меж строк аналитику a16z про оптимизацию уровней + там ещё и статейка хорошая на десерт в ретвите).

А системы всегда стремятся к максимальному упрощению, строгости и автоматизации. Не просто же так в Матрице Архитектор сидит один в комнате 👨🏼‍💻

Вкус. Видение. ИИ

Вещи, которые должен уметь игнорировать продакт для сохранения своего внимания, видения и намерения (времени-энергии):

0. 100%-ый перфекционизм
1. Дословные требования пользователей
2. Громкость голосов стейкхолдеров
3. Авторитет "экспертных" мнений
4. Блеск фич и метрик конкурентов
5. Нужда совещаний и ответов
6. Просто срочность
7. Ожидание момента
8. Мнимая определённость планов
9. Запрос на определённости извне
10. Одержимость рационализаций
11. Процесс ради процесса
12. Потребность в одобрении командой
13. Стремление к консенсусу со всем(и)
14. Шёпот. Шум рыночного хайпа
15. Страх от признания пустых работ
16. Чувство вины за фичи (те работы)
17. Сравнение себя с другими
18. Свой собственный "успех"

Безупречность не про идеальность

70% гипотез сгорают уже после запуска, просто потому, что их проверяют слишком поздно и чаще всего всё идёт по сценарию: идея → задачи → разработка → запуск и только в конце становится понятно, что что-то в этой цепочке было неправильным... с самого начала

📍30 марта, 18:00 пройдёт бесплатный воркшоп
«ИИ в исследовании продукта: как за 1 час собрать карту проверяемых гипотез»

Расскажут, как с помощью ИИ:

— превращать идеи в чёткие гипотезы
— собирать и анализировать данные заранее
— фильтровать и расставлять приоритеты
— собрать план проверки под реальные ресурсы

За 1 час у тебя будет карта гипотез, структура "проблема → аудитория → эффект → метрика" и план проверки с приоритетами, сроками и метриками.

Разберут как анализировать интервью и находить паттерны за минуты, генерировать гипотезы и принимать решения на основе данных, а не ощущений. Бонус: чек-лист «10 вопросов к гипотезе перед спринтом»

Эксперты: Дамир Байжуминов (продакт-менеджер Альфа-Банка по внедрению ИИ) и Артём Астапенко, эксперт по ИИ и архитектуре AI-решений

Если хочешь быстрее проверять идеи, а не тратить на них недели — приходи.

Бесплатное участие
👉 https://product-ai.ru/workshop

Бэдтрип эпохи Web 2.0

Поймал вчера короткий бэдтрип в попытке начать работать с чистым Wordpress. В сознании сразу пронеслась куча воспоминаний из эпохи web 2.0, когда всё делалось руками: от контента до кода. А бэдтрип возник даже не из-за боязни чистого листа или сложности с кодом, нет (нет ничего прекраснее чем чистый белый лист).

Устанавливая нулёвую сборку WP, вдруг осознал (вспомнил), что большинство продуктов эпохи 2.0 характерны одним свойством – структурностью и ограниченностью во всём: от кода до механик работы с данными, которая лишала нас, как пользователей, той «магии» ПО и данных, на которую, на самом деле, они способны. И нам приходилось всё допиливать руками разработчиков, постоянно выслушивая сначала про те или иные технические ограничения тех времён, а после них и просто про ограничения времени.

(моя любовь в этом плане к Wordpress была безгранична, как и безгранично кол-во комьюнити плагинов к этому чудесному движку).

Традиционным продуктам 2.0 не хватало внутренней и внешней свободы механик и данных и UGC, которую даёт (и так жаждет) ИИ.

Мы, как пользователи, это всегда чувствовали, мы были недовольны этим, но нам приходилось пользоваться старыми продуктами, потому что не было ИИ.

А бэдтрип возник из-за того, что даже спустя 20 лет, в Wordpress до сих пор нет решения, которое бы позволяло продавать статьи на сайте поштучно (я не говорю уже даже про то, чтобы их можно было поштучно сдавать для чтения в аренду).

...Основная бизнес-модель контента.
Миллионное комьюнити.
20+ лет развития продукта.
Решений нет...

...ИИ написала плагин с моих слов за 5 минут.

Во Вселенной, где единственной постоянной является Хаос перемены, метод проверки гипотез и создания продуктов должен быть настолько быстрым, что на это должна уходить всего одна минута/один час/один день/неделя.

Проверка идей, развитие продуктов и написание кода в стиле 2.0 – это не просто медленно. Это, blyat, очень медленно.

(Фух, отпустило)

Конференции про лидерство смотрю уже не первый год, субботняя Dream → Teamlead на прошлой неделе не стала исключением. Больше всего зашли два доклада: про стресс и лидерство.

Из интересного:

Евгений Антонов, ведущий технический менеджер проектов в Yandex Infrastructure, объяснил, что тимлидер(ство) – это сначала про стек навыков по управлению собой, и только потом про управление командой. При этом нужно комбинировать в себе все виды лидерства в зависимости от КОН-ТЕ-КСТА. Контекст – король. Таким образом, научившись управлять собой, научишься тимлидству как профессии.

Еще была интересная мысль о том, что в стрессе типы (грани) тимлида обостряются и либо эволюционируют, либо регрессируют, поэтому стрессом нужно уметь управлять. И иначе, стресс начнёт управлять тобой, а потом и всей командой.

Всё втекает и вытекает из другого. И в этом вся сложность и простота одновременно ☯️

Поэтому, лидер, застрявший в одном стиле управления, скорее всего провалится (и утащит за собой команду). Стресс лишь приблизит неизбежное.

Полезный совет – рост тимлида часто происходит по фидбеку команды. Спросите коллег: а) что они в тебе как лидере видят; б) чего им в тебе не хватает.

Про ИИ тоже говорили: продуктивность с ИИ растёт быстрее качества, поэтому непродуманный ИИ в процессах не только не помогает, но и создаёт дополнительное узкое горлышко в виде растущего объёма верификации и ответственности выросшего благодаря ИИ количеству результата работы.

👆 P.S. И да, о чём бы с удовольствием подискутировал про стресс в айтишке с молекулярным биологом Сергеем Харитоновым:

– Яркое холодное освещение ночью и блэкаут днём – самое плохое решение для "ночных тимлидов" какое может быть, и такой подход лишь усугубляет негативные ощущения, что, собственно, Сергей и подтвердил в конце – оно не работает на долгосрок (в отличии от тимлидов).

Долгосрок – темнота и свеча рядом с экраном/ноутом (само собой, яркость которого ночью на минимум), блики света от огня на стене которой идеально заменяют естественный(!) свет Солнца, которого нет ночью и успокаивают глаза-мозг. Просто потому что в свете Солнца много есть чего. Оно же есть в огне. Смотри в огонь, будь сам огнём, Огонь-Внутри-Тебя 🔥

– Днём можно спать при свете Солнца и блэкаут-шторы не нужны (читай – они только вредят). Спи днём также, как спишь ночью – с обычной шторой или без. Все эти попытки обмануть себя приводят лишь к одному – мозг-глаза-сознание всё равно знают, что их пытаются обмануть. Их не обманешь.

– Спать можно дважды в сутки по 4 часа без вреда для здоровья. Говорю об этом как практик с 10+ летним опытом стабильной работы с полуночи и до 8 утра. Со здоровьем всё в порядке (тьфу х3). Спать 10+ часов я тоже могу и люблю, при правильном мышлении и подходе, переключение между режимами вообще не чувствуется, потому что режимов-не-существует.

– Пить магний вредно, как и пить любые витамины. Пить витамины – это дисбаланс. Лучше витамины есть органикой через постоянно полезную пищу и пить через травы/ягоды/коренья/этовсё, качая то самое "нейробиотическое чувство" (но я называю это по-другому).

А магний лучше всего усваивается нервами через кожу водой в ванне с английской солью, которая его и содержит (рекомендую миксовать с розовой гималайской). Добавь темноту и снова огонь, и вот уже эффект Х10.

– Физические тренировки и мышцы – очень тонкая тема в контексте разгрузки ими от стресса. Знаю много случаев, когда под воздействием стресса физическое переходило в фанатическое и люди гробили своё пошатнувшееся здоровье ещё больше с мыслью "сожгу стресс спортом". В итоге, выгорание и стресс уходят на более глубокий ментально-физиологический уровень и бетонируются там тренировками.

Ключ в медитации, дыхании и фасциях. Баланс и Тишина внутри тебя 😌

Ты слышишь? Дайджест мартовских постов перетекает в воздухе деревьев

– Почему время то летит, то ползёт
– Почему сильные команды посредственны
– Почему все встречи назначаются на час
– Что продакту включить в игнор

– Три уровня познания исследований
– Инкрементальность продуктовой разработки
– Обзор любого рынка 360
– The Company Graph

– Google Search Console для исследований
– 800 инструментов для исследований
– CIRCLES для продуктовых кейсов

– Джуны не нужны
– GitHub для продакта
– Продакты-решалы
– Когда менеджер должен вмешиваться

– Как понятно объяснять свои мысли
– Даём обратную связь по BOFF
– Насмотренность — ловушка
– Subagents vs. Agent Teams

– Что происходит с AI от a16z
– Грамотность пользователей с ИИ
– ИИ лишь увеличивает количество работы

– Ваш проект умрёт не из-за разработки
– Смерть отслеживания задач
– О ясности и сложности
– Идея множественности «Я»

🏔️ Gorillaz - The Mountain, The Moon Cave and The Sad God

Вайбкодинг продукта глазами продакта

Продолжаю кодить создавать некий-довольно-объемный по продуктовым и техническим меркам продукт с Claude, поделюсь наблюдениями:

– Не парь себе и ИИ мозги, не пиши на вайбе продукт с нуля, юзай опенсорс/CMS с уже: а) продуманной; б) раздельной архитектурой.

Мой случай – Wordpress, в котором есть ядро и есть отдельно /plugins и /themes. Ядро постоянно, стабильно и ИИ его не трогает, вся работа по разработке продукта ведётся через плагины (бэк) и темы (фронт). Всё ограничено, порционно, версионно и контролируемо. Сэкономишь ИИ мозги и себе токены и не будешь тратить 80% времени/нервов/токенов на ненужную проверку и переписывание одного и того же места (ядра) ради мелких фиксов по сто раз.

– Смотри в сторону Single Page Application с раздельными .js под каждую фичу/"страницу". Это снова про ограниченность, версионность и контроль работы для тебя и ИИ. Плюс, так снова правильно для архитектуры, когда приложения общаются между собой раздельно, а не один .js управляет всем и сразу (создавая конфликты и глюки сразу во всём).

– 1 фича-апдейт = 1 чат в рамках 1 проекта и не будет никаких галлюцинаций. Апгрейдишь фичу – в первом промпте прикладывай архив с исходником последней stable версии фичи с прода (или коннекть GitHub). Апгрейднул – CHANGELOG - чат закончен.

Иначе уже спустя 2 часа чата машина начинает путаться в данных/коде и любая попытка разрулить лишь закапывает её и тебя в галлюцинации и баги ещё больше.

– Фиксы/баги можно объединять в одном чате, ИИ лучше видит контекст и находит связи между ними, но лучше тоже не копить и делить по stable версиям.

– Объясняй всё для ИИ наглядным языком, уточняй контекст, расшифровывай механики, стейты и позиционирование объектов на странице c их идентификацией.

Помогает: а) единый словарь терминов и понятий для фич/механик в твоём продукте (определимся с терминами и понятиями, классика, 2018 год); б) через Console смотреть на название их css-стилей. Потому что даже одна оговорка или размытое понятие может быть непонятно для ИИ и она начнёт додумывать его за тебя, что приведет её к галлюцинации.

Твой промпт = тех. задание, "нет ТЗ = результат ХЗ", ещё одна классика середины нулевых передаёт привет из прошлого.

– Прикладывай к промптам скрины с выделенными ошибками, поясняя текстом что на скринах. Несколько раз Claude сама нашла на скрине места с дублирующейся багой, которые я проглядел, поняла их и это помогло ей пофиксить 2+ баги разом.

– Не торопи ИИ с кодом и не давай ей с ним торопиться, всегда проси подтверждений понимания твоих задач и уточнения со стороны ИИ и ты снова сэкономишь токены, нервы и время.

– Для сложных фич/механик вначале проси у ИИ описание двух вариантов возможных решений, потом проси третий вариант, потом проси придумать оптимальное и подходящее решение на основе этих трёх. У меня во всех случаях ИИ выбирала третий вариант и с первой итерации писала его без серьёзных ошибок, имея на руках полный контекст что ей делать и что не делать.

– CHANGELOG MD – ключ и мост между релизами. После каждого успешного апдейта (чата) проси ИИ писать: а) интро проекта с точки зрения обновлённого кода/архитектуры; б) выжимку по изменениям и включай их в него, прикладывая в новом чате и прося читать все изменения для понимания контекста.

Потому что ИЗМЕНЕНИЯ = КОНТЕКСТ. Веди его ручками, чтобы не жечь лишний раз каждым апдейтом токены на разрастающийся док (старую инфу можно нужно подчищать).

– Скиллы и прочие "ты в роли" зашей в CHANGELOG один раз, а не в системный промпт/скилс, чтобы не вызывать их скрыто в каждом промпте, прожигая твои токены (ты же не Ланнистер).

– Слышал, что рефакторить код лучше через разные модели, устраивать оркестрации, подключать тулзы и прочее. Я до этого ещё не дошел, Claude отлично справляется со всем своим добром сама прямо через окно чата и обмен файлами контекстом.

В общем, как-то так. Впервые столкнулся с тем, что код и прод убегают вперёд дизайна. Думаю скоро подрубить github, а там и до VS Code + copilot не за горами. Я знал, что рано или поздно мы перейдем и на эту дрянь.

Эпоха SaaS меняется, а вместе с ней и роль тех, кто управляет её решениями

Мы видим, что происходит с теми же Figma и Notion – ИИ-индустрия автоматизирует создание интерфейсов и функционала сервисов (и сами сервисы) за считанные дни, поэтому растет ценность специалистов, способных проектировать сложную простую логику процессов и управлять продуктом как Системой.

Чтобы стать тем самым «оператором-оркестратором», особенно в ИИ-сфере, нужны передовые знания и много практики.

22 апреля в 19:00 мск на онлайн-дне открытых дверей магистратуры «Управление продуктом в цифровом бизнесе» ИТМО в партнерстве с Яндекс Практикумом будут обсуждать, как собрать необходимые специалисту навыки системно.

👉 Зарегистрироваться на встречу

Разберут образовательные треки, дисциплины и то, как вообще сейчас выглядит актуальное обучение управлению продуктом. Для тех, кто хочет грамотно рулить продуктами в эпоху ИИ эта программа маст-хэв.