Кто заплатит за квартал ожидания: почему платформы инкрементальных эффектов не соберутся из вайбкодеров
Логика кажется простой: бизнес все чаще хочет платить "только за результат", людей, которые умеют быстро собирать решения с помощью ИИ, стало много - значит, должен появиться новый рынок. Но из этих двух фактов рынок сам по себе не возникает. Между "хочу эффект" и "могу сделать" неизбежно появляется третья сущность - тот, кто финансирует время до момента, когда эффект станет измеримым. И именно этот вопрос решает судьбу любых платформ инкрементальных эффектов: кто оплатит квартал ожидания?
С цифрами о текущем разрыве между ожиданиями и реальной отдачей спорить не приходится. Консультанты фиксируют: около 60% компаний не получают материальной выгоды от инвестиций в ИИ. Другие исследования показывают перекос еще жестче: примерно 74% выигрыша достается 20% организаций. Параллельно в корпоративном софте закрепляется модель оплаты за outcome: одни сервисы берут порядка 0,99 доллара за тикет, закрытый без оператора, другие - около полутора долларов. Идея "платим за измеримый результат" уже перестала быть экзотикой.
Проблема в том, что эти примеры работают там, где результат фиксируется самой платформой - в единой системе событий, доступной обеим сторонам. Когда закрывается тикет, это "видно" внутри продукта: событие записано, проверяемо, не требует отдельного расследования. Но как только мы выходим за пределы платформы и пытаемся монетизировать "инкремент" в бизнес-процессах компании - начинается реальная экономика ожидания, рисков и ответственности.
Я пишу об этом не из позиции наблюдателя. Мой опыт - около пятнадцати лет продуктовой разработки, корпоративной архитектуры и инженерного менеджмента в банках, ретейле, телекоме и ИТ. А в последний год я в одиночку, фактически с ИИ вместо команды, собирал платформу, которая живет в продакшене и проводит реальные деньги: прием платежей через эквайринг, идентификация получателей, выдача электронных сертификатов через агрегатор, функция налогового агента по НДФЛ и отчетность. Именно эта "встреча с продом" и показывает: между прототипом и операционным контуром лежит не код - а ответственность.
Квартал "бесплатной" работы - не оговорка, а базовая цена доказательства эффекта
Чтобы честно сказать "конверсия выросла на три пункта", недостаточно красивого дашборда. Нужна статистическая значимость: контрольная группа, корректная методика, достаточное число наблюдений, учет сезонности и внешних факторов. На практике это недели, а чаще - квартал. В течение этого времени исполнитель делает работу, поддерживает интеграцию, отвечает на инциденты и улучшает решение, но не может предъявить заказчику "железный" результат, за который тот согласен платить.
Отсюда вытекает простой вывод: в модели "оплата только за эффект" участвовать способен тот, у кого есть финансовая подушка на несколько месяцев. Одиночка с ноутбуком обычно приходит на такие платформы как раз потому, что подушки нет. Подушка есть у агентства, интегратора, продуктовой студии - то есть у тех игроков, которые и сейчас живут в корпоративных закупках.
Вход в операционный контур - это не "сделать скрипт", а пройти режим допуска
Даже если предположить, что эффект можно мерить быстро, исполнителя отсекают еще на входе. Доступ к данным и системам крупной компании дают не тому, кто предложил "крутую идею", а тому, кто выдержал процедуру: аккредитация, проверка службой безопасности, договор с материальной ответственностью, соглашение об обработке персональных данных, требования к опыту аналогичных проектов, иногда - к обороту и численности штата.
По этим фильтрам часто не проходит не только "вайбкодер-одиночка", но и небольшая аутсорс-студия на 10-15 человек. Поэтому платформа, которая задумывается как "рынок для армии независимых исполнителей", почти неизбежно превращается в новый интерфейс для старых участников тендеров. Поменяется форма контракта, но не состав игроков.
Негативный отбор: на "платформу эффекта" уходит то, в чем заказчик сам не уверен
Есть и вторая точка поломки - на стороне бизнеса. Компания охотно отдаст на схему "платим только за результат" именно те процессы, где сама не уверена в результате. А там, где эффект очевиден заранее, ей выгоднее сделать внутри: нанять сотрудника на фикс, встроить решение в команду и забрать весь upside себе.
В итоге на платформе скапливается "остаток" задач - с низкой вероятностью успеха и высоким числом скрытых переменных. Несколько бесплатных кварталов подряд быстро объяснят исполнителям экономику происходящего. Уйдут те, кто считает деньги и время. Останутся либо те, кто не умеет оценивать риски, либо те, кто планирует "отбить" затраты серыми способами - и это самый опасный сценарий для корпоративного контура.
Верификацию нельзя отдавать заинтересованной стороне
Еще одна ключевая проблема таких моделей - кто именно подтверждает результат. Если эффект мерит заказчик, у исполнителя появляется страх "недосчитают" или поменяют методику по ходу. Если мерит исполнитель, заказчик не доверяет цифрам. Нужна нейтральная инфраструктура событий и правил, иначе любые споры превращаются в бесконечные согласования: что считать конверсией, как учитывать возвраты, что делать с параллельными изменениями в продукте, как вычесть влияние промо, сезона и рекламного давления.
И здесь становится ясно, почему в классических outcome-моделях побеждают продукты, а не "биржи исполнителей". Там, где платформа сама является источником правды, оплата за результат естественна. Там, где "истина" лежит в разрозненных системах компании, оплата за инкремент превращается в юридико-аналитический проект, а не в быстрый контракт.
---
Что должно появиться между вайбкодером и бизнесом, чтобы модель вообще заработала
Ниже - несколько условий, без которых "платформы инкрементальных эффектов" останутся красивой идеей на слайде.
1) Финансирование периода доказательства (тот самый квартал).
Нужен механизм, который оплачивает работу до наступления измеримого эффекта: фонд платформы, кредитная линия, аванс с возвратом, подписка на пилот. Пока этого нет, модель держится на энтузиазме исполнителя - а энтузиазм не является масштабируемой экономикой.
2) Ступенчатая схема оплаты, а не бинарное "получилось/не получилось".
Реальные внедрения лучше дробятся на этапы: интеграция, корректность данных, стабильность процесса, достижение целевой метрики. Тогда исполнитель не живет три месяца в нуле, а заказчик платит за проверяемые промежуточные результаты.
3) Песочница и ограниченный контур для пилотов.
Если компания не готова сразу открыть доступ к боевым данным и операциям, платформе нужен стандартный "безопасный коридор": синтетические данные, обезличенные выгрузки, sandbox-окружение, минимальные права. Без этого каждый пилот будет утыкаться в службу безопасности еще до первой строчки кода.
4) Единый протокол измерений и арбитраж.
Должны быть заранее описаны правила: методика, окна сравнения, минимальный объем данных, контроль внешних факторов, допустимые исключения. И отдельный контур арбитража - иначе спор о том, был ли рост "реальным", съест больше ресурсов, чем само решение.
5) Пакет ответственности: данные, деньги, налоги, инциденты.
Войти в операционный контур - значит отвечать за то, чтобы процесс не "встал" в пятницу вечером. Значит иметь регламенты, мониторинг, дежурства, журналирование, план отката, работу с персональными данными и юридическую рамку. Это не отменяет ценности вайбкодеров - но показывает, что одиночный режим тут почти всегда проигрывает системной организации.
6) Страхование рисков и гарантийный слой.
Если платформа хочет подключать много мелких исполнителей к крупным компаниям, ей придется взять на себя часть рисков: страхование ответственности, гарантийные депозиты, типовые условия компенсаций. Иначе корпоративный заказчик просто не подпишет договор.
7) Модель, где "агент" не один.
Даже если решение пишет один человек, эксплуатация требует минимум ролей: аналитик, инженер по интеграции, специалист по безопасности, юрист/комплаенс, поддержка. Платформа должна либо предоставлять эти роли как сервис, либо признать, что ее основными поставщиками станут команды, а не одиночки.
8) Четкий ответ на вопрос: кому приходит счет за инфраструктуру?
В outcome-моделях легко забыть: токены, вычисления, хранение, логирование, мониторинг, тестовые среды - это постоянные расходы. Если "счет за модель" и инфраструктуру внезапно оказывается на исполнителе, экономика для него рушится. Если на заказчике - он потребует предсказуемости и контроля, что снова приближает нас к классическому контракту.
---
Итог получается прозаичным. "Вайбкодеры" действительно могут ускорять прототипирование и снижать стоимость экспериментов. Но платформа инкрементальных эффектов - это не витрина задач и не каталог талантов. Это финансово-юридико-аналитическая машина, которая должна: (а) оплатить ожидание доказательства, (б) обеспечить нейтральную фиксацию результата, (в) закрыть вопросы допуска и ответственности, (г) пережить реальные инциденты в продакшене.
Пока не появится тот, кто готов платить за квартал до видимого эффекта - массового рынка "платим только за инкремент" не будет. Будут точечные истории там, где результат фиксируется самой платформой, и корпоративные внедрения там, где у исполнителя уже есть ресурсная база, репутация и способность нести ответственность. Именно поэтому такие платформы не "соберутся" из одиночек по щелчку - им нужен слой капитала, доверия и операционной зрелости, а не только быстрый код.
