Лучший свой MVP и сразу внедрение я сделал в ~2002 году, у меня был компьютерный салон (ну где школота за деньги могла рубиться в контру и прочие радости).

Я нанял работников, и выручка упала (стали воровать).

Тогда я сел и за две недели, не выходя из салона, написал систему управления компьютерным залом под Windows. TCP/IP, клиент-сервер и т.д.

Каждый день (ну, может, кроме первых 2-3 дней) я выкатывал новую версию на все компы и на комп админа. И сразу в бою тестировал. Были баги, глюки, хитрая школота находила способы убить мой процесс и разлочить комп. Но спустя две недели всё заработало как надо.

Больше таких скоростных внедрений и решения проблем бизнеса я не видел никогда. Была реальная понятная мне проблема, я смог посвятить этому 200% своего времени, не было необходимости в коммуникации, все было в одной голове: Заказчик + Product + Designer + Front/Back Developer + DevOps + QA.

Теперь я понимаю, что так и будут выглядеть команды будущего. Один продукт = один человек. Дальше я расскажу, почему я так думаю.

За последние 3 года к нам пришли LLMки, а с ними пришел vibe coding. Я достаточно несерьезно относился к концепции vibe coding, потому что сам уже 25+ лет в ИТ и программирую на большом количестве языков. Но последние 16 лет моя основная задача - это управление командами для создания ИТ-продуктов.

Большую часть времени я теперь трачу не на программирование, а на то, чтобы "заставить" других сделать то, что нужно, как можно быстрее, качественнее и эффективнее. 50% успеха здесь лежит в найме, 50% в построении процессов и команд под конкретные цели. И еще 50% на то, чтобы остановить Product Owner'а в его фантазиях ???

Я все еще обожаю кодить - делаю pet-проекты. Иногда что-то кожу для боевых проектов.

Главное, что я понял про эффективность - это то, что разделение труда приводит к катастрофическим потерям в результативности.

Проблема ИТ команд

Любая Senior Full Stack команда всегда рвет по производительности любую специализированную команду. А если в специализированной команде в цепочке еще есть подрядчик, то все становится еще хуже.

Почему так происходит? Потому что основная потеря времени происходит при передаче дел и смыслов от одних к другим. Потеря времени здесь – это не человеко-часы, а продолжительность-длительность: дни, недели, иногда месяцы.

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

Команда старого типа
Команда старого типа

Если дизайнер здесь заболеет или уйдет в отпуск, то все встанет. Решение - нанять еще одного дизайнера? Ну тогда узкое место будет в Front End разработке, он у нас один. И так при любом масштабировании команды, узкое место просто смещается в разные области.

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

Реальное решение, которое всегда работало, - это нанимать full stack-разработчиков. А в идеале - full stack-разработчика с дизайнером в одном флаконе. Такие вообще есть?

А еще лучше - full stack-разработчик + дизайнер + аналитик. "Так не бывает," скажете вы. Но я ведь был "Заказчик + Product + Designer + Front/Back Developer + DevOps + QA" в своем проекте и сделал продукт за 2 недели, потом еще продавал его в другие компьютерные залы.

Продукт за 3 дня

Ладно - сейчас такой fullstack монстр уже и не нужен. Есть нейросети, они могут сделать хороший дизайн, front+back. И могут помочь с аналитикой, например, я на последнем проекте больше информации о том, как работает бизнес, для которого мы делаем софт, получил от нейросетей, чем от самого бизнеса. То есть я сам стал аналитиком.

30, 31 декабря и 1 января я потратил, чтобы окунуться на 100% в vibe coding. За три дня я сделал продукт для одной компании которой нужно делать много контента для ведения контент маркетинга.

Детали по продукту описал тут.

Я использовал онлайн-решение типа Bolt.new. Все было сделано за ~30 промтов. У меня не было проблем с environment и deploy. Просто купил домен и прикрепил к проекту, который выкатил за 1 секунду. К коду на JS/TS я обращался 5-6 раз, когда были микроправки, и когда надо было посмотреть структуру, чтобы дать более точный промт.

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

Я 25+ лет в ИТ и очень хорошо себе представляю жизненный цикл проектов и все тонкости. Это я к тому, что человек без моего опыта, возможно, и сделает тоже все за 3 дня, но он наверняка упрется в сложности, которых не ожидает, и ему рано или поздно понадобится настоящий разработчик.

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

Масштабирование продукта через увеличение числа людей в команде становится дорогостоящим и создает новые бутылочные горлышки.

AI инструменты полного цикла позволяют создать продукт одному человеку. В будущем каждый должен будет стать Super Product Owner, самое близкое к этому понятию - это Indy Developer в GameDev. Super Product Owner должен совмещать роли продуктового менеджера, аналитика, дизайнера, разработчика, DevOps.

Это ускоряет цикл «идея → прототип → продукт → обратная связь» или «идея → прототип → фича → обратная связь» с месяцев до дней, оставляя ключевым ресурсом внимание и опыт человека, а AI становится инструментом масштабирования.

Промпты становятся новым активом. Чтобы создать качественный промпт, нужно быть одновременно опытным разработчиком, дизайнером и продуктовым менеджером. AI может выполнять промпт в фоне, пока вы заняты другой задачей. Для этого нужно перейти с промптов в стиле "запрос-ответ" к суперпромптам.

Например, для создания приложения у меня ушло ~30 промптов, но если продумать требования и архитектуру детально, то можно обойтись одним детальным суперпромптом и потом еще ~5 патч-промптов для фиксов и доделок.

OpenClaw

Раньше у меня был зоопарк лендингов. Потом помогал WordPress.

Теперь поставил DarwinClaw (B2B версия OpenClaw) на чистую машину Ubuntu и сказал ему сделать всю инфраструктуру для сайтов. Он поставил nginx + node.js. Потом попросил перенести сайты, указав ссылки на них. Он создал все сайты. 

Попросил добавить git и репозиторий для хранения этих сайтов. То есть всегда можно быстро откатить изменения.

Теперь полностью управляю этим зоопарком лендингов через TG команды типа:

  • Убери с сайта X вот это

  • Убери с сайта X вот это

  • Поменяй стиль сайта Z на ...

  • Откати последние изменения на сайте XM

  • Замени иконку на сайте XS на более современную

  • Собери статистику по заполнению форм с сайтов X, Y, Z в формате

Для B2B один этот кейс уже сильно сокращает расходы, и самое главное, сильно сокращает цикл от идеи до продукта.

Уже две очень крупные компании, с которыми мы работаем, просят перенести всех ИИ-ботов на OpenClaw, чтобы они сами добывали все знания, дообучались в процессе беседы, и чтобы им просто можно было сказать, как поменяться, и они поменялись.

Это означает, что в цикле требование от заказчика -> аналитик -> разработчик -> результат, уходит вся середина, и цикл становится почти мгновенным - только докупай и жги токены.

Как только внедрим DarwinClaw (B2B версия OpenClaw) для своих заказчиков, мы выкатим ее для общего пользования.

Сравнение DarwinClaw vs OpenClaw:

DarwinClaw (ex OpenClaw)
DarwinClaw (ex OpenClaw)

Indy команды

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

Команда будущего - это не Продукт + Дизайнер + Аналитик + Front Dev + Back Dev + QA.

Команда будущего - это Super-Product с опытом создания продуктов, навыками программирования, высокой насмотреностью в дизайне и обязательным опытом в маркетинге продуктов. Это максимальный Full Stack, когда один человек делает все, тем самым сокращая feedback loop до минимума.

Такой Super-Product может создавать и вести параллельно 3-5 проектов, манипулируя суперпромтами и вовремя заливая трафик для A/B-тестирования очередной итерации. У него нет расхода времени на коммуникацию и попытки передать смыслы. Нет задержек, когда дизайнер ушел в отпуск, а Front Dev заболел.

Мы входим в новую эру продуктового мышления. Любой продукт возникает в голове одного человека, редко это тандем из двух людей. Это как книга, которую обычно пишет один автор. В парадигме Super-Product, этот вариант максимально реализуется.

При масштабировании команды, мы просто добавляем еще одного Супер-Продукта. Супер-Продукты общаются, делятся опытом по инструментам, методам, удачам и провалам, они не блокируют друг друга на пути к появлению продуктов/фичей.

И хотя это сложный переход, я вижу в этом огромные возможности для творчества и инноваций.

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

А вместо найма и управления командами теперь важным навыком становится покупка правильных токенов в правильных объемах, промт-инжиниринг, и прокачка отсутствующих навыков до уровня Super-Product-Owner.

Больше по теме пишу тут.

Комментарии (2)


  1. exTvr
    19.03.2026 12:40

    В бан однозначно, очередной ковровый нейроспаммер.


  1. Areso
    19.03.2026 12:40

    Тогда я сел и за две недели, не выходя из салона, написал систему управления компьютерным залом под Windows. TCP/IP, клиент-сервер и т.д.

    ... все было в одной голове: Заказчик + Product + Designer + Front/Back Developer + DevOps + QA.

    Именно. Это неплохо работает, если продукт маленький, и все его аспекты умещаются в одну голову. Если продукт без хайлоада, где любая строчка в конфиге имеет значение между "работаем на 250 млн пользователей" и "у клиентов все лежит, процессор долбится в полку на СУБД".

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