newsmode
search
Меню
arrow_back Назад

Data Is the Only Moat

auto_awesomeКраткое саммари

Арвид Каль (Arvid Kahl) утверждает, что по мере того как создание софта благодаря LLM становится дешевле и быстрее, традиционные рвы вокруг бизнеса исчезают, и единственным надёжным преимуществом остаются реальные данные, созданные людьми. Он описывает «бифуркацию данных»: человеческий контент становится всё ценнее, а синтетический — товаром. На примере собственного проекта Podscan, где транскрибировано и проанализировано 50 миллионов подкаст-эпизодов, он показывает, что ценность не в API или интерфейсе, а в самих данных: свежести, чарт-рейтингах, метаданных из неочевидных источников. Чисто трансформативные SaaS-сервисы уязвимы, поскольку агенты вроде ChatGPT справляются с ними сами, а вот массовый сбор данных агентам не по карману — это обошлось бы в десятки тысяч долларов токенов в день. Автор советует строить API-first продукты с паритетом между UI, REST API и MCP, и для этого ведёт «platform parity tracking file», обновляемый sub-agent'ом Claude Code. Главный совет: собирайте уникальные метаданные о том, как используется ваш продукт, — это и есть ваш ров.

Вот вопрос, с которым я последнее время живу: если создавать софт становится всё проще — а это очевидно так, — то на чём именно мы строим свои бизнесы?

Потому что, оставляя в стороне разговоры о качестве vibe-coded или AI-инженерного софта, очевидно: с инструментами на базе LLM писать сложный софт стало значительно проще. Полностью задача не решена. Это по-прежнему процесс, который требует оркестратора — кого-то, кто знает, чем эта штука должна стать. И на данном этапе это уже не просто техническая компетенция. Это product management и customer development, пересекающиеся с инженерией. Но довольно ясно, что по мере того как эти инструменты становятся лучше, процесс создания кодовых баз, которые после деплоя превращаются в продукты, за которые люди готовы платить, или в сервисы, за которые люди готовы платить, — этот процесс явно движется к порогу, за которым software engineering и ведение софтверного бизнеса в привычном нам виде заметно изменятся. Это всё ещё будет работа, требующая понимания и компетенции, но для создания чего-то значимого больше не нужно десять человек. Возможно, хватит трёх. Или двух. Или вообще одного.

Так что если строить продукты становится значительно проще, и сам акт создания софтверного бизнеса больше не такой затратный — потому что он быстрее и требует меньше ресурсов, — то какими будут рвы будущего? Ближайшего будущего, где эти изменения уже происходят, и через пять или десять лет, когда AI-сгенерированные софт-продукты станут обыденностью, легко создаваться, деплоиться и поддерживаться?

Раньше можно было указать на множество вещей в качестве рвов. На то, насколько трудно построить софт-продукт, который надёжен, удобен в потреблении и поддерживаем. На то, как трудно перевести знания в индустрии в продукт, который этой индустрии служит. Но AI-системы сейчас всё это в значительной мере забирают на себя. Так что же остаётся?

Я обнаруживаю, что единственное, что выделяется — сколько бы AI вы на это ни направили, — это реальные данные. Данные, созданные людьми, человеческими мозгами.

Великая бифуркация данных

Сами по себе данные сейчас переживают эту бифуркацию. С одной стороны — данные, созданные людьми. Люди записывают эпизоды подкастов, выкладывают видео, на самом деле сами пишут посты в соцсетях или в блогах — всё, что действительно сгенерировано человеком. А с другой — синтетическая сторона: AI-сгенерированные изображения, синтетические голоса из систем text-to-speech, полностью созданные AI фильмы или YouTube-ролики и, конечно, каждое спам-письмо, написанное на сегодняшний день агентными системами.

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

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

Что я вижу в Podscan

Прямо сейчас я переживаю это в Podscan. Наибольшую ценность мои клиенты извлекают из системы не благодаря моей способности ингестить все эти RSS-фиды или иметь API, который быстро отвечает на их запросы. Это умеет любая минимально проинструктированная агентная система. Реальная ценность платформы Podscan — в пятидесяти миллионах эпизодов подкастов, которые я транскрибировал и пропустил через AI-системы для анализа контента, ключевых слов, тем и тональности.

Ценность — в дополнительной работе: в работе по транскрипции, в трансформирующей работе, которая делает данные доступными другим. Я работаю поверх существующих публичных данных — а это каждый эпизод подкаста в мире — и привожу их в такую форму, в которой другие люди могут их потреблять для любых своих нужд. Возможно, они хотят отслеживать упоминания брендов. Возможно, хотят понять, о чём люди говорят прямо сейчас. Возможно, хотят увидеть, что обсуждают подкасты определённого типа, чтобы спонсировать их или разместить там рекламу. Этими данными можно пользоваться множеством разных способов.

И я обнаруживаю, что чем больше усилий я вкладываю в повышение fidelity данных — точности, актуальности, свежести этих данных, — тем большую ценность люди в них находят. И им, по сути, неважно, насколько трудно к этим данным добраться. Пока данные существуют, они найдут способ до них дотянуться. Я могу спрятать их в странных пользовательских интерфейсах. Могу сделать API неуклюжим и ограничительным. Неважно. Они найдут способ, потому что значение имеют сами данные, а не средства доступа к ним.

Почему трансформативный софт уязвим

А теперь оборотная сторона. Если вы ведёте софт-бизнес, который сугубо трансформативен — берёт входящие данные, что-то с ними делает и возвращает данные обратно, — это будет проблемой. Трансформативные алгоритмы — это то, в чём агентные AI-системы исключительно хороши. Когда вы говорите: «Слушай, ChatGPT, возьми этот Excel, сгенерируй отчёт, преврати его в PDF и отправь на этот адрес», — оно может сделать это автономно. Без вашего участия, без чьего-либо ещё участия, без внешнего сервиса. Оно понимает, как разобрать Excel-файл, выполнить аналитические запросы по его содержимому, отрендерить PDF и отправить письмо. Все эти крошечные шаги кем-то уже реализованы или система может реализовать их на лету.

Не нужно строить SaaS-бизнес вокруг приёма Excel-таблиц и отправки отчётов по почте. Агентная система может сделать это сама.

Но когда речь заходит о сборе данных в масштабе, агенты этим обычно не занимаются. Это эфемерная природа агентного режима, да? Если вы запускаете сессию Cursor или инстанс Claude Code, или ведёте беседу в браузере с ChatGPT, — агент существует только во время этих коротких моментов взаимодействия. Всё остальное — просто записи в какой-то базе данных, состояние state machine, пытающейся довести вас до результата. Агент, который постоянно сканирует, постоянно работает за вас, потребляет столько токенов, что становится почти запретительно дорогим. Если бы вы запустили агента, который пытается делать то же, что делает Podscan, — принимать, транскрибировать и анализировать пятьдесят тысяч эпизодов подкастов в день, — это обошлось бы вам в десятки тысяч долларов токенов и API-вызовов в день. А в моём бизнесе я оптимизировал все эти процессы так, что они происходят в фоне и делают данные доступными для моих потенциальных потребителей: API-клиентов, людей, использующих сайт, или людей, использующих MCP-интеграцию, чтобы данные подключались напрямую к агентам.

Быть системой записи (system of record), располагать осмысленными данными — вот почему это так ценно для моих клиентов. Если бы всё, что я предлагаю, сводилось к «дай мне URL, и я его транскрибирую и проанализирую», — думаю, Podscan был бы в двух часах от того, чтобы его полностью заменили хорошо написанным skill внутри Claude Code или чего-то подобного. Но поскольку Podscan собирает все эти данные — данные о свежести, чарт-рейтинги, дополнительные метаданные отовсюду, из источников, о существовании которых большинство даже не подозревает, — это и есть природа системы записи. Это сведение данных воедино и обеспечение их полноты и доступности для других систем.

Поэтому, когда я говорю «data moat», я имею в виду, что вам действительно нужно убедиться, что то, что вы предлагаете, имеет собственный внутренний источник данных с дополнительной ценностью. А с другой стороны, вам нужно эти данные действительно использовать и делать их доступными. Иметь данные — это половина рва. Делать данные доступными — другая половина.

Сделайте свой бизнес API-first

Превратить свой софт-бизнес в API-first-бизнес — пожалуй, одна из самых разумных вещей, которые сегодня можно сделать. Нужно задать себе вопрос: есть ли в моём приложении что-то, что я мог бы выставить через API? И когда я говорю об API — MCP обычно это просто ещё один слой поверх API. Большинство фреймворков, предлагающих MCP-возможности — я думаю здесь о Laravel, — позволяют поставить его поверх REST API, который у вас уже есть. Так что говорим ли мы о программном доступе, MCP, API, webhooks, чём угодно — это всё одно и то же. Вы делаете свою систему надёжно подключаемой к другим компьютерам.

Что мне кажется всё более интересным — и я вижу, как многие основатели говорят об этом, потому что сами являются потребителями других софт-бизнесов, — это то, что люди ищут софт, в котором есть близкий паритет между тем, что можно делать в пользовательском интерфейсе, и тем, что можно делать через API. Чем больше паритета — чем больше людей могут делать через API ровно те же вещи, что и в интерфейсе, — тем выше вероятность, что они действительно «купятся» на ваш продукт, потому что это означает, что они могут автоматизировать что угодно. А каждый агент в природе хочет позволить им автоматизировать всё, что им нужно.

У меня в системе есть постоянная практика: раз в несколько дней я запускаю sub-agent Claude Code по моей кодовой базе, чтобы обновить центральный файл, который я называю своим platform parity tracking file. На каждую функцию в продукте приходится строка в таблице, и я отмечаю: могу ли я сделать это в UI? Могу ли я сделать это через REST API? Могу ли я сделать это через MCP? Если доступно во всех трёх — готово. Если нет — это кандидат на дополнительную работу. Это может быть что-то простое вроде «найти подкаст» или что-то такое сложное, как «настроить keyword alert, который автоматически добавляет новые упоминания вашего бренда в список, триггерящий webhook». Если я могу это сделать в какой-либо части платформы, это должно быть возможно в каждой из этих систем, которые я предлагаю.

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

Ваш ров — это ваши метаданные

И это не обязательно должны быть данные о подкастах. Чего бы ни касался ваш продукт, подумайте о метаданных, которые вы собираете, когда люди пользуются вашей платформой, или когда вы наблюдаете последствия использования вашего продукта. Если у вас инструмент, позволяющий публиковать в Twitter или Facebook, это может быть время, когда большинство людей публикует, или когда большинство людей вовлекается, или какой контент вызывает наибольшую вовлечённость. Вот такие штуки — эти метаданные — и есть ваш уникальный data moat.

Так что разберитесь, что это такое именно для вас. Убедитесь, что у вас это есть. Убедитесь, что оно подключено. И затем убедитесь, что вы делаете это доступным так, чтобы это улучшало то, как люди используют ваш продукт и как они ведут собственные бизнесы. Вот это и есть data moat.

Автор: Arvid Kahl

Я пишу о bootstrapping, выстраивании аудитории и построении в открытую в The Bootstrapped Founder. Ранее FeedbackPanda (exit/2019). Автор книг Zero to Sold, The Embedded Entrepreneur и проекта Find your Following.