Наткнулся на интересную Брошюрку "Как получать радость от вайбкодинга" и с удовольствием делюсь ею с вами (спасибо автору канала Делай RAG за такую глубокую работу).

Сегодня хочется поговорить с вами на эту тему. Сразу обозначу, что я мало пробовал именно vibe-coding, но мой опыт, пока скорее получился отрицательный. Не исключено, что я просто не умею варить его.

Совсем недавно для одной моей апки (об этом я обязательно скоро так же поделюсь) потребовалось быстро, без смс, но с регистрацией поднять бэк. Стек довольно стандартный: FastAPI + Keyсloak + PostgreSQL. Написал несколько ручек, подключил Pydantic, все аккуратно сложил в котейнерочки, прикуртил CI. Все было почти готово и пришло время "подружить" Keycloak с FastAPI. На этом этапе, я решил, что это отличная возможность попробовать Codex от OpenAI (а зря...).

Задача довольно тривиальная с кучей примеров в интернете, но мне стало лень "мудохаться" самостоятельно со всеми этими разменами токенов и прочими настройками. Codex с минуту подумав, написал мне кучу кода, который конечно же не работал. И вот тут началось, почти 3 часа я ему отправлял ошибки, а взамен слушал читал его извинения, что он накосячил. Мне было принципиально добить, а портянка с какими-то невообразимыми абстракциями только росла. В какой-то момент уже и мой изначальный код разломался, а то что нагородил Codex я уже принципиально не смог даже осилить прочитать. Плюнул, откатился к началу, скопировал из интернета первый попавшийся пример на 10 строк кода и за 20 минут все завел. Свет. Занавес. 🍆

Второй момент который нужно было решить: у Keycloak отдельная база пользователей. Мне нужно было, сделать так, чтобы у моего бэка они тоже были. Я дал Codex’у второй шанс, но в этот раз я решил, что прежде чем писать код, он будет рассказывать, что он собирается делать. И вот мы снова пошли по всем кругам ада. Он начал мне рассказывать про какие-то плагины к Keycloak, которые я должен написать, причем обязательно на Java и прочие танцы с бубном. Думать мне было лень, я просто мучал его, пока он не даст мне какое-то супер простое и элегантное решение. 2 часа коту под хвост (и сожженых GPU офк). В итоге опять забил и просто на ручку /me, в которую гарантировано сходит фронт, повесил проверку: есть ли у меня этот пользователь и если нет, то создать (не претендует на идеальное инженерное решение). Итого: 3 строчки кода и пять минут времени. 🤪

Все как в известном меме "Я уважаю то, что они делают, но..." 😛 Если серьезно, очень круто, что непрограммисты могут реально быстро и на коленке создавать приложения и делать MVP продуктов. Да, пока скорее всего настоящему программисту, на этапе скейлинга и нормального продакшена будет тяжело разбираться с тем как оно работает (и работает ли вообще), но если подумать, то технология не будет развиваться если не пытаться ее внедрять.

У меня есть еще до конца не сформулированная мысль, что когда-то мы придем в точку, что каждый человек сможет написать любой продукт под себя и тогда рынок приложений окончательно девальвируется и тут возникает резонные вопросы: Во что же теперь инвестировать и какие стартапы теперь будут нужны рынку? Предлагаю пообсуждать это в комментариях.

Ну и поделюсь парой классных каналов про vibe coding, за которыми я с удовольствием слежу.
- Канальчик Делай RAG, Где Катя, как раз автор той книжки, которая вдохновила меня на этот пост делится своим опытом кодинга с нейросетями.
- Канал Zero to Vibe[coding] от Лиды, которая тоже активно делится своими успехами на этом сложном пути.

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

Термины и определения для мамы:
- Vibe coding — метод программирования, при котором разработчик описывает задачу на естественном языке, а искусственный интеллект (ИИ) генерирует соответствующий код
- FastAPI — веб-фреймворк для создания API на языке Python.
- Keycloak — проект для управления идентификацией и доступом (Identity and Access Management, IAM)

Я большой любитель коллекционировать истории о том, как на самом деле происходит AI-адопшен. Недавно я разбирал гайд от OpenAI. Там говорилось, что успех зависит не от моделей, а от способности организации учиться, повторять, адаптироваться и интегрировать AI во все процессы. Все по классике: делайте много экспериментов с дешёвыми ошибками и масштабируйте то, что работает. Это bottom-up подход, когда adoption происходит снизу вверх.

Недавно в Harvard Business Review я наткнулся на статью Stop Running So Many AI Pilots и на первый взгляд она показалась мне немного противоречащей, но это просто дополнительный уровень рассмотрения.

Поэтому сегодня про Bottom-up vs. Top-down (ну и если хотите adoption vs стратегия).

Если говорить по-честному, то большинство AI-пилотов вообще не про трансформацию. Это уже приевшиеся всем нам презентации, саммари встреч, чат-боты, автоматизация саппорта. Да, это экономит время и даёт быстрый ROI, но важно то, что это совершенно не меняет бизнес и легко копируется конкурентами.

Часто это выглядит так: «Давайте Запустим десяток AI пилотов в маркетинге, финансах, HR, саппорте и посмотрим, что взлетит», но это довольно плохая стратегия, потому что по сути это работа над офисной продуктивностью и автоматизацией рутины, и по факту получается:
🟣AI используется в 5–10% задач
🟣Никто не готов перестраивать процессы
🟣Возникает усталость от инициатив
🟣Сотрудники разочаровываются

Главный тезис статьи в HBR: Проблема не в том, что компании мало экспериментируют с AI. Проблема в том, что они экспериментируют не там и не глубоко
🔜 Хорошая стратегия выглядит так: «Мы выберем один критичный домен и перестроим его работу вокруг AI»

Лучше один AI-проект, который меняет бизнес и приводит к глубокой трансформации чем 50 пилотов, которые создают иллюзию прогресса.

Давайте взглянем на этот пирог:
🟡 Офисная продуктивность. Здесь нет конкурентного преимущества. Очень мелкие и, по-сути, не влияющие на бизнес изменения.
🟡 Доменные процессы и трансформация - это устойчивый источник конкурентного преимущества, позволяющий изменять ключевые бизнес-процессы, а не его косметика
🟡 Новые бизнес-модели. Да, изменения становятся труднокопируемыми для конкурентов, но они уже более рискованны

Хороший вопрос для любой компании, который стоит задать для диагностики: Если убрать этот AI-кейс станет ли бизнес снова прежним?Если ответ «да», то это не трансформация.

Вместо Shallow & Broad предлагается подход Deep & Narrow, с выводами на примере кейсов Reckitt (маркетинг), L’Oréal (customer journey, IKEA (дизайн интерьеров) и ипотечный процесс целиком на примере одного банка, который не раскрывается.

1️⃣ Step 1: Identify the most promising opportunity.
Выбрать один стратегически важный домен: функцию (маркетинг, дизайн, риск-менеджмент) или end-to-end процесс (ипотека, supply chain, onboarding клиента), который имеет наиболее перспективную возможность и сильнее всего влияет ли на выручку / маржу / удержание

2️⃣Step 2: Identify areas of lasting advantage.
Нужно выбрать такую область, в которой есть долгосрочные преимущества в виде данных, экспертизы и возможностей масштабирования. Так, чтобы внутри было много связанных друг с другом задач, использующую информацию полученную из одних и тех же данных, данных о клиентах и маркетинговых исследованиях.

3️⃣ Step 3: Choose the right sequence.
Чтобы составить правильную последовательность действий нужно как-то приоритизировать инициативы. В статье предлагается разложить их по двум осям: степень возможной автоматизации и размер возможностей для компании, да хоть классическим Impact vs Effort. Важно, что на этом этапе нормально делать эксперименты, но главное чтобы они были сфокусированы.

4️⃣ Step 4: Monitor the competitive landscape.
Базовый принцип ИИ должен усиливать существующее конкурентное преимущество или создавать новое, труднокопируемое.

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