Вайб-пластичность компании

Сегодня зачастую быстрее собрать себе подручный инструмент и сделать всё на нём, чем работать по-старому руками. И бонус: все последующие такие задачи автоматически становятся быстрее.

Ключевая мысль: пластичность бизнес-процессов достигается через пластичность бизнес-логики в ИТ-системах. Вайб-кодинг делает это дешёвым, доступным и быстрым.

Зачем это каждому, а не только ИТ

Почему HR, финансисту, продакту, аналитику?

Во-первых, это способ каждому «прокачать» своих агентов под себя — приделать им новые руки через скрипты и интеграции.

Во-вторых, и это важнее, так убирается лишний уровень взаимодействия:

• Было: руководитель функции → программист → агент → программист → руководитель → результат.
• Стало: руководитель → агент → руководитель → результат.

Зачем посредник, если можно поставить задачу напрямую? Руководитель сам ставит задачу агенту и принимает результат в рамках своей зоны компетенции.

Мой аналитик уже умеет делать себе скрипты, которыми анализирует данные. Не программист — аналитик.

Три уровня сложности

• Простой: сохранить удачную промпт-инструкцию агента в удобном месте.
• Средний: сделать себе нужный дашборд без привлечения ИТ.
• Продвинутый: разработать приложение с интерфейсом — зачастую за час вайб-кодинга.

Рабочая лошадка для этого — агентные IDE: Cursor, Claude Code, GitHub Copilot, Windsurf.

Есть ли смысл ждать

Мы окружены рутиной и отсутствием удобных решений, интерфейсов, агентов, интеграций между ними. Мир не идеален и таковым не будет. Ландшафт будет меняться, становиться лучше — и одновременно сложнее и разнороднее, особенно на фоне радикального снижения стоимости разработки.

Ждать очередь в бэклоге перегруженного ИТ? Или ждать, пока кто-то на рынке сделает готовое решение, покупая которое мы всё равно пойдём на компромиссы?

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

Риск, который я принимаю осознанно

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

Мой выбор — идти дальше сразу. Когда кодинг-агенты станут умнее в десять раз через два-три года, посредник будет просто не нужен. Но здесь нужна платформа с рамками и правилами, чтобы всё работало устойчиво — иначе локальные решения расходятся и множат хаос.

Софт трёх уровней

Если вспомнить классификацию Андрея Карпаты — Software 1.0 (программный код), 2.0 (коэффициенты ML-моделей), 3.0 (контексты для языковых моделей) — то вайб-кодинг позволяет создавать софт на всех трёх уровнях.

MCP-интеграция для почты из P3 — это 1.0. Промпт-инструкции — 3.0. А 2.0 для большинства работает под капотом, ведь LLM и есть ML-модель.

Ставка простая: распространённость навыка вайб-кодинга в компании. Так сотрудники растут до архитекторов, способных работать на всех трёх уровнях — и агентов настроить, и руки им дать, и интерфейс сделать. Это уже P8 «Каждый — архитектор».

Что это значит на практике

P4 — про массовую доступность локальных улучшений в повседневной работе, а не про архитектурное проектирование контуров. Сотрудник не ждёт длинный бэклог, а собирает полезный инструмент под задачу и быстро его улучшает.

Артефакты: шаблоны самообслуживания, каталог типовых решений, внутренняя инструкция «как собрать первого агента».

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

Анти-паттерн «двухуровневая рабочая сила»: небольшая группа power users уходит далеко вперёд, пока остальные стоят. Разрыв в беглости означает разрыв в способности читать контексты агентов, оценивать их результаты и нести за них ответственность (P1). Методология не работает, если её воплощают три человека.

Со стороны ценности

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

Как измерить. Главный признак — ключевые эксперты, не будучи техспециалистами, собирают инструменты сами, без чужой помощи. Это значит, что навык дошёл до носителей экспертизы, а не заперт в паре энтузиастов или в ИТ.

Что легко переоценить. Что вайб-пластичность — это «строят все» или, наоборот, «строит пара энтузиастов». Оба края мимо. Обычных исполнителей проверять смысла мало: их рутина всё равно автоматизируется. Целиться нужно в ключевых экспертов — носителей ценной, но не технической экспертизы.

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

Что дальше

Вайб-пластичность открывает шлюзы: менять процессы может каждый. Но изменения не делаются сами — нужно понять, что менять, и довести до результата. Об этом P5 «Автоулучшение».