Тут есть нюанс. Механики действительно помогают выполнять типовые действия и не допустят отклонение от процесса. Однако интеллектуальная часть управленческой работы никуда не денется, и её тоже надо регламентировать. И кроме как через контекст это не сделать.
Да, модели имеют свой "здравый смысл" - те знания, которые в них были заложены при обучении. Это как образование у человека. Но на одном образовании при решении реальных задач не выехать, нужен навык. Поэтому сотрудники с опытом, даже при худшем базовом оборазовании, могут работать эффективнее неопытных коллег, которые получили более качественное оборазование.
Качество модели и оптимально подобранный контекст совместно дают выигрыш в качестве результатов. Мехники помогают освободить контекст от действий, которые не требуют интеллектуальной работы, но не заменят саму интеллектуальную работу.
Да, за рамками статьи остались некоторые детали, которые помогли бы полнее ответить на этот вопрос.
В первую очередь ИИ-продакт нужен для того, чтобы разгребать бэклог, не теряя фокуса на продуктовых целях, — то есть снимать с человека значительную часть рутины. Именно на этом сделан акцент в статье.
Но есть и второй ключевой способ его использования, который существует параллельно с работой по бэклогу: мы вместе прорабатываем идеи и гипотезы. В отличие от обычного ИИ-агента, с которым можно работать в режиме вопрос-ответ с каким-то контекстом, ИИ-продакт уже обладает именно тем контекстом и набором навыков, которые нужны для такой работы. Он знает продукт, историю принятых решений, план развития и пользовательские задачи, которые продукт должен решать. Качество анализа, которое он выдаёт с таким контекстом, действительно потрясающее. Этот способ работы с ИИ-продактом в статье практически не упоминается.
Показательный пример — сама статья. Я написал её своими руками, но она проходила проверку ИИ-продактом, и он же генерировал схемы. Между написанием и публикацией прошло несколько дней; за это время продакт в том числе работал над оптимизацией собственного процессного контура. Когда я принёс ему на рецензию финальную версию, он не просто поправил опечатки и сверил факты, но и напомнил, что последние версии схем уже не отражают всех сделанных улучшений. При этом сами схемы я ему повторно не показывал — передал только текст. Обычный ИИ-агент не располагал бы таким контекстом и, скорее всего, не сделал бы этого вывода.
При этом диапазон решений, которые может принимать ИИ-продакт, и перечень доступных ему действий специально ограничены.
Он не может самостоятельно:
менять назначение продукта или его целевую аудиторию;
выбирать между сопоставимыми продуктовыми вариантами, если у одного из них нет очевидного преимущества;
расширять круг доступа к рабочим системам или чувствительным данным и выдавать новые права;
совершать действия, требующие расхода реальных денег, если бюджет и границы такого расхода не были согласованы заранее;
совершать необратимые или юридически значимые действия без отдельного подтверждения человека.
При этом у него есть права:
запускать задачи из бэклога, которые включены в принятый план;
проверять работу системы вживую в заранее разрешённых контурах — например, отправлять тестовые запросы через мой Telegram от моего имени;
заводить задачи в рамках плана, если обнаружен продуктовый гэп или дефект;
останавливать работу и блокировать выкатку результатов, которые технически корректны, но ухудшают пользовательский опыт или не решают задачу, ради которой создавались;
в рамках заданных ограничений самостоятельно принимать решения, у которых нет разумной конкурирующей альтернативы;
писать мне по почте или в мессенджер: задавать вопросы, сообщать о проблемах, предлагать варианты решения и присылать результаты исследований.
Из-за того, что буквально пишется каждый шаг и контролируются запущенные процессы, состояние репозиториев и т.п., продакт прекрасно осведомлён о происходящем и не выполнит одно и то же действие дважды. В этом смысле система получилась очень надёжная. Цена, как я отметил - контекст.
По части эффективности: "обычные" доработки система выполняет надёжно. Но особенность моих продуктовых направлений в том, что это инновационные продукты со сложной технической составляющей, где "правильного" решения просто нет. Поэтому приходится постоянно ставить эксперименты и оценивать эффект. Что касается проведения анализа по заданному направлению и реализации готовых идей - продакт справляется отлично.
Но в части самостоятельной генерации идей, как оказалось, положиться на него нельзя - уйдёт не туда. То есть условно задачу "сделай классный продукт" он не осилит. Но если сказать "у меня есть такая-то идея, нужно её проанализировать и предложить варианты решения", продакт берёт на себя всю рутину и приходит с реально работающими вариантами.
И поскольку все решения записываются, ретроспективно можно всегда проанализировать эффективность по всем аспектам работы продакта и команды агентов-исполнителей.
Задумано так, что codex (или cursor) ищет релевантные части предыдущих задач, чтобы понять контекст. Но это не значит, что все предыдущие задачи попадают в контекст. В контекст добавляется только часть информации, которая может пригодиться для выполнения текущей задачи.
Мы использовали другие бенчмарки, поскольку по ним набор задач более сбалансированный, есть более сложные и более простые задачи, легче увидеть градиент. Также там лучше формализован процесс оценки результатов (промпт и модель судьи). По BrowseComp все задачи достаточно высокой сложности, поэтому до определенного порога результаты получаются близко к нулю, и шум от самой модели и судьи мешают оценить прогресс.
Я сделал эту схему для серьёзных доработок существующего проекта. Для проектов "на вечер" я бы не стал её использовать - это overkill, очень накладно по токенам. Также небольшие доработки, где нет зависимостей из разных модулей, я запускаю обычным способом одним промптом по той же причине.
На практике я всегда самостоятельно проверяю написанные агентами ТЗ и архитектуру. Это позволяет не уйти в разработку не по тому пути.
Также есть важные нюансы, которые учтены в промптах, но я не стал делать акцент на них в статье:
"Память проекта", которую вы упомянули, критически важна для того, чтобы агенты могли вносить адекватные изменения в большие проекты. Когда кода много, он не помещается в контекст, и агенты просто не в состоянии увидеть все зависимости. Поэтому в каждом каталоге очень желательно иметь файл .AGENTS.md, в котором содержится описание структуры каталога и назначение файлов, классов и методов. Также важно иметь актуальный README.md, а ещё лучше заточенный под агентов .AGENTS.md для всего проекта, по которому агенты смогут быстро понять, про что проект и как он устроен. Но стоит упомянть, что агенты не всегда строго следуют правилам ведения .AGENTS.md.
Оркестратор не становится мега-агентом, но всё равно достаточно быстро набирает контекст. Мой вариант промпта рабочий, но не идеальный. Тут ещё есть простор для оптимизации, чтобы оркестратор не читал лишние документы.
На примере моего проекта, который очень часто дорабатывается, ТЗ очень быстро теряют актуальность. Лучше не запускать параллельные доработки, касающиеся одного и того же кода. В отличие от человека, который может сопоставить имеющийся документ и новые изменения в коде, для агентов это достаточно ресурсоёмкая задача, и они скорее всего что-то упустят. Если такая ситуация возникает, то лучше перезапустить весь процесс заново, с этапа проектирования. Поэтому я стараюсь все доработки доводить до конца как можно быстрее.
Вообще, всю эту историю я затеял с целью иметь возможность стартовать разработку через мессенджер, даже не заходя в Cursor. И через него же проводить ревью ТЗ, архитектуры и т.п. Скажем так: это схема рабочая, доработки будут сделаны и функционал будет работать. Но рано или поздно технический долг накопится, и надо будет проводить рефакторинг с ручным вмешательством. Всё-таки агенты пока не настолько умные, чтобы полностью избежать дублирования кода и создания разных сущностей, которые делают похожие вещи.
Если изменение не тривиальное, то чтобы агент-разработчик мог сделать что-то правильно, как раз и требуется предварительная цепочка анализа и декомпозиции задачи.
Также важно помочь агентам разобраться в том, что уже есть в проекте. Я не стал делать на это фокус в статье, но в промте, возможно, обратили внимание на путь к файлу с описанием проекта. Это важно, т.к. для более-менее большого проекта никакого контекста не хватит переварить весь код - нужна выжимка, чтобы аналитик и архитектор знали, куда смотреть в первую очередь.
Вероятность получить приемлемый результат также повышается за счёт этапов ревью. Да, на ревью требуются дополнительные токены, но практически всегда ревьюеры находят замечания, по которым выполняются исправления.
И конечно самое важное для получения хорошего результата - это обратная связь, т.е. результаты тестов. Можно рассматривать процесс решения задачи как своеобразный RL (reinforcement learning*): делаем → получаем обратную связь → дорабатываем. Чем тесты будут более приближенными к реальным сценариям использования системы, тем качественнее будет результат. Модели часто любят тривиальные юнит-тесты типа проверки наличия полей в классе. А вот более вдумчивые тесты они ленятся делать. В своих промтах я делаю акцент именно на как можно более реалистичные тесты, чтобы они действительно показывали, насколько доработки соответствуют требованиям. Плюс обязательные регрессионные тесты.
Конечно, результат невозможно гарантировать, бывают неудачные решения, которые приходится откатывать или рефакторить. Но всё равно стабильность разработки по описанной схеме намного выше, чем без каких-либо специальных приёмов.
Добавил скриншот, где видно, как Cursor запускает субагента. Видно, что от вызывает CLI утилиту cursor-agent с передачей содержимого файла с промптом с ссылкой на файл с задачей.
В приведённом в статье шаблоне промпта есть ссылки на файлы с описанием общей схемы работы оркестратора и промптами для отдельных ролей. Пример файлов есть на github. Каталог с этими файлами нужно расположить либо в самом проекте (это имеет смысл, если там есть специфичные для данного проекта инструкции), либо где-то рядом, но в доступном для Cursor месте. И в промте указать актуальное расположение файла с инструкциями для оркестратора и файлов с промптами.
Именно, но тут Cursor ведет себя аналогично другим CLI-агентам. Можно либо проверять все изменения через git в конце, либо просить после завершения каждой задачи делать коммит, чтобы видеть этапность изменений и иметь возможность откатиться на несколько шагов назад.
Я предпочитаю первый вариант: ревьюить сразу финальный код.
С этой сферой я слабо знаком, но на мой дилетантский взгляд, потребность в специалистах по 3D моделированию должна расти со временем (медиа-контент, индустрия 2.0 и т.п.)
Расходы на поддержание бренда «нормальных» кроссовок также заложена в цену. Если бы маржа выпуска «абидас» была бы сильно ниже маржи выпуска «нормальных» кроссовок, то не думаю, что кто-то стал бы гнать фейк.
Касаемо плана, не поддерживаемого спросом. Какой был спрос на Айфоны в 2006 году?
Спрос рождает предложение только на идеальном рынке, в теории. В реальности люди покупают в основном то, что им предлагается на рынке.
Важно видеть картину в целом: из каких товаров и услуг состоит рынок и как определяется их стоимость.
Какую часть своего бюджета мы тратим на новогодние открытки? Полагаю, что меньше 1%.
Вопрос в том, какие товары и услуги занимают в экономике наиболее значимую часть, и как определяется их стоимость.
Я пробовал найти хорошие статистические данные по глобальному потреблению. Проблема в том, что стоимость многих конечных продуктов складывается из большого набора промежуточных составляющих. Например, покупая помидоры в магазине, мы платим не столько за сами помидоры, сколько за труд продавцов, аренду помещения, транспортировку и т.п. И каждая из этих составляющих также раскладывается на много других составляющих. И когда мы пробуем получить данные по мировому объему рынков товаров и услуг, мы видим цифры с учетом промежуточных составляющих, которые мы, как конечные потребители, непосредственно не потребляем. Т.е. в такого рода отчетах имеет место дублирование стоимости.
Более адекватную картину можно получить, если проанализировать свои собственные расходы, на что люди как конечные потребители тратят деньги. Существенная часть — это продукты питания, одежда, жилье (включая коммунальные услуги), транспорт, медицина, образование. Также не стоит забывать про часть денег, которую мы тратим не по своей воле, но без которой практически невозможно обойтись — это государственные расходы, которые мы оплачиваем через налоги. Соотношение указанных категорий зависит от уровня жизни, но расходы большинства людей ограничиваются этим списком, остальные категории товаров и услуг составляют существенно меньшую долю.
Тезис сказанного выше в том, что подавляющая доля расходов потребителей идет на жизненно необходимые товары и услуги, стоимость которых в современном мире очень сильно оптимизирована и по своей сути состоит в основном из труда, вложенного в их создание.
Я не буду спорить, что есть категории товаров, цены на которые не имеют ничего общего с вложенными трудозатратами. Но современный рынок потребительских товаров и услуг очень высококонкурентный, и цена подавляющей доли товаров и услуг оптимизирована настолько, что состоит в основном из стоимости вложенного труда.
Что касается планирования. Алгоритмы максимизируют ту функцию, которая в них заложена. На текущий момент методы машинного обучения прекрасно зарекомендовали себя в маркетинге. Вряд ли кто-то будет спорить, что уже давно спрос формируется не столько потребительскими качествами товаров и услуг, сколько успешным продвижением. И если раньше маркетологи были вынуждены полагаться на свои мозги, скромные наборы данных и более тривиальные алгоритмы, то сейчас, с ростом роли big data и machine learning, маркетинг становится все более и более эффективным. Я не буду настаивать на своей точке зрения, но полагаю, что уже сейчас многие люди совершают покупки по «приказу» алгоритмов продвижения товаров и услуг. И чем дальше, тем эта тенденция будет усиливаться. У людей очень много когнитивных искажений, которые можно эффективно использовать и таким образом проактивно формировать спрос.
К сожалению, сейчас алгоритмы используются для формирования рынка массового потребления. Но я бы хотел, чтобы со временем, когда мы все «наедимся», и будет больше излишков энергии, которую надо куда-то направлять, функция, которую алгоритмы смогут максимизировать, будет все больше из области науки и исследований. Моя статья, я надеюсь, показывает, как можно иначе и более результативно использовать ресурсы, которые нам предоставляет наша планета.
Тут есть нюанс. Механики действительно помогают выполнять типовые действия и не допустят отклонение от процесса. Однако интеллектуальная часть управленческой работы никуда не денется, и её тоже надо регламентировать. И кроме как через контекст это не сделать.
Да, модели имеют свой "здравый смысл" - те знания, которые в них были заложены при обучении. Это как образование у человека. Но на одном образовании при решении реальных задач не выехать, нужен навык. Поэтому сотрудники с опытом, даже при худшем базовом оборазовании, могут работать эффективнее неопытных коллег, которые получили более качественное оборазование.
Качество модели и оптимально подобранный контекст совместно дают выигрыш в качестве результатов. Мехники помогают освободить контекст от действий, которые не требуют интеллектуальной работы, но не заменят саму интеллектуальную работу.
Да, за рамками статьи остались некоторые детали, которые помогли бы полнее ответить на этот вопрос.
В первую очередь ИИ-продакт нужен для того, чтобы разгребать бэклог, не теряя фокуса на продуктовых целях, — то есть снимать с человека значительную часть рутины. Именно на этом сделан акцент в статье.
Но есть и второй ключевой способ его использования, который существует параллельно с работой по бэклогу: мы вместе прорабатываем идеи и гипотезы. В отличие от обычного ИИ-агента, с которым можно работать в режиме вопрос-ответ с каким-то контекстом, ИИ-продакт уже обладает именно тем контекстом и набором навыков, которые нужны для такой работы. Он знает продукт, историю принятых решений, план развития и пользовательские задачи, которые продукт должен решать. Качество анализа, которое он выдаёт с таким контекстом, действительно потрясающее. Этот способ работы с ИИ-продактом в статье практически не упоминается.
Показательный пример — сама статья. Я написал её своими руками, но она проходила проверку ИИ-продактом, и он же генерировал схемы. Между написанием и публикацией прошло несколько дней; за это время продакт в том числе работал над оптимизацией собственного процессного контура. Когда я принёс ему на рецензию финальную версию, он не просто поправил опечатки и сверил факты, но и напомнил, что последние версии схем уже не отражают всех сделанных улучшений. При этом сами схемы я ему повторно не показывал — передал только текст. Обычный ИИ-агент не располагал бы таким контекстом и, скорее всего, не сделал бы этого вывода.
При этом диапазон решений, которые может принимать ИИ-продакт, и перечень доступных ему действий специально ограничены.
Он не может самостоятельно:
менять назначение продукта или его целевую аудиторию;
выбирать между сопоставимыми продуктовыми вариантами, если у одного из них нет очевидного преимущества;
расширять круг доступа к рабочим системам или чувствительным данным и выдавать новые права;
совершать действия, требующие расхода реальных денег, если бюджет и границы такого расхода не были согласованы заранее;
совершать необратимые или юридически значимые действия без отдельного подтверждения человека.
При этом у него есть права:
запускать задачи из бэклога, которые включены в принятый план;
проверять работу системы вживую в заранее разрешённых контурах — например, отправлять тестовые запросы через мой Telegram от моего имени;
заводить задачи в рамках плана, если обнаружен продуктовый гэп или дефект;
останавливать работу и блокировать выкатку результатов, которые технически корректны, но ухудшают пользовательский опыт или не решают задачу, ради которой создавались;
в рамках заданных ограничений самостоятельно принимать решения, у которых нет разумной конкурирующей альтернативы;
писать мне по почте или в мессенджер: задавать вопросы, сообщать о проблемах, предлагать варианты решения и присылать результаты исследований.
Из-за того, что буквально пишется каждый шаг и контролируются запущенные процессы, состояние репозиториев и т.п., продакт прекрасно осведомлён о происходящем и не выполнит одно и то же действие дважды. В этом смысле система получилась очень надёжная. Цена, как я отметил - контекст.
По части эффективности: "обычные" доработки система выполняет надёжно. Но особенность моих продуктовых направлений в том, что это инновационные продукты со сложной технической составляющей, где "правильного" решения просто нет. Поэтому приходится постоянно ставить эксперименты и оценивать эффект. Что касается проведения анализа по заданному направлению и реализации готовых идей - продакт справляется отлично.
Но в части самостоятельной генерации идей, как оказалось, положиться на него нельзя - уйдёт не туда. То есть условно задачу "сделай классный продукт" он не осилит. Но если сказать "у меня есть такая-то идея, нужно её проанализировать и предложить варианты решения", продакт берёт на себя всю рутину и приходит с реально работающими вариантами.
И поскольку все решения записываются, ретроспективно можно всегда проанализировать эффективность по всем аспектам работы продакта и команды агентов-исполнителей.
Задумано так, что codex (или cursor) ищет релевантные части предыдущих задач, чтобы понять контекст. Но это не значит, что все предыдущие задачи попадают в контекст. В контекст добавляется только часть информации, которая может пригодиться для выполнения текущей задачи.
По BrowseComp результат 1,66%.
Мы использовали другие бенчмарки, поскольку по ним набор задач более сбалансированный, есть более сложные и более простые задачи, легче увидеть градиент. Также там лучше формализован процесс оценки результатов (промпт и модель судьи). По BrowseComp все задачи достаточно высокой сложности, поэтому до определенного порога результаты получаются близко к нулю, и шум от самой модели и судьи мешают оценить прогресс.
Нет, он пока проходит обкатку среди "friends&family". Но очень ждём, когда станет доступен широкой аудитории.
На практике это проще, чем кажется. А эффект, наоборот, превзошёл ожидания. Успехов!
Я сделал эту схему для серьёзных доработок существующего проекта. Для проектов "на вечер" я бы не стал её использовать - это overkill, очень накладно по токенам. Также небольшие доработки, где нет зависимостей из разных модулей, я запускаю обычным способом одним промптом по той же причине.
На практике я всегда самостоятельно проверяю написанные агентами ТЗ и архитектуру. Это позволяет не уйти в разработку не по тому пути.
Также есть важные нюансы, которые учтены в промптах, но я не стал делать акцент на них в статье:
"Память проекта", которую вы упомянули, критически важна для того, чтобы агенты могли вносить адекватные изменения в большие проекты. Когда кода много, он не помещается в контекст, и агенты просто не в состоянии увидеть все зависимости. Поэтому в каждом каталоге очень желательно иметь файл .AGENTS.md, в котором содержится описание структуры каталога и назначение файлов, классов и методов. Также важно иметь актуальный README.md, а ещё лучше заточенный под агентов .AGENTS.md для всего проекта, по которому агенты смогут быстро понять, про что проект и как он устроен. Но стоит упомянть, что агенты не всегда строго следуют правилам ведения .AGENTS.md.
Оркестратор не становится мега-агентом, но всё равно достаточно быстро набирает контекст. Мой вариант промпта рабочий, но не идеальный. Тут ещё есть простор для оптимизации, чтобы оркестратор не читал лишние документы.
На примере моего проекта, который очень часто дорабатывается, ТЗ очень быстро теряют актуальность. Лучше не запускать параллельные доработки, касающиеся одного и того же кода. В отличие от человека, который может сопоставить имеющийся документ и новые изменения в коде, для агентов это достаточно ресурсоёмкая задача, и они скорее всего что-то упустят. Если такая ситуация возникает, то лучше перезапустить весь процесс заново, с этапа проектирования. Поэтому я стараюсь все доработки доводить до конца как можно быстрее.
Вообще, всю эту историю я затеял с целью иметь возможность стартовать разработку через мессенджер, даже не заходя в Cursor. И через него же проводить ревью ТЗ, архитектуры и т.п. Скажем так: это схема рабочая, доработки будут сделаны и функционал будет работать. Но рано или поздно технический долг накопится, и надо будет проводить рефакторинг с ручным вмешательством. Всё-таки агенты пока не настолько умные, чтобы полностью избежать дублирования кода и создания разных сущностей, которые делают похожие вещи.
Согласен.
Сейчас в качестве описания общей схемы можно использовать файл https://github.com/rdudov/agents/blob/master/00_agent_development.md.
Если изменение не тривиальное, то чтобы агент-разработчик мог сделать что-то правильно, как раз и требуется предварительная цепочка анализа и декомпозиции задачи.
Также важно помочь агентам разобраться в том, что уже есть в проекте. Я не стал делать на это фокус в статье, но в промте, возможно, обратили внимание на путь к файлу с описанием проекта. Это важно, т.к. для более-менее большого проекта никакого контекста не хватит переварить весь код - нужна выжимка, чтобы аналитик и архитектор знали, куда смотреть в первую очередь.
Вероятность получить приемлемый результат также повышается за счёт этапов ревью. Да, на ревью требуются дополнительные токены, но практически всегда ревьюеры находят замечания, по которым выполняются исправления.
И конечно самое важное для получения хорошего результата - это обратная связь, т.е. результаты тестов. Можно рассматривать процесс решения задачи как своеобразный RL (reinforcement learning*): делаем → получаем обратную связь → дорабатываем. Чем тесты будут более приближенными к реальным сценариям использования системы, тем качественнее будет результат. Модели часто любят тривиальные юнит-тесты типа проверки наличия полей в классе. А вот более вдумчивые тесты они ленятся делать. В своих промтах я делаю акцент именно на как можно более реалистичные тесты, чтобы они действительно показывали, насколько доработки соответствуют требованиям. Плюс обязательные регрессионные тесты.
Конечно, результат невозможно гарантировать, бывают неудачные решения, которые приходится откатывать или рефакторить. Но всё равно стабильность разработки по описанной схеме намного выше, чем без каких-либо специальных приёмов.
Добавил скриншот, где видно, как Cursor запускает субагента. Видно, что от вызывает CLI утилиту cursor-agent с передачей содержимого файла с промптом с ссылкой на файл с задачей.
В приведённом в статье шаблоне промпта есть ссылки на файлы с описанием общей схемы работы оркестратора и промптами для отдельных ролей. Пример файлов есть на github. Каталог с этими файлами нужно расположить либо в самом проекте (это имеет смысл, если там есть специфичные для данного проекта инструкции), либо где-то рядом, но в доступном для Cursor месте. И в промте указать актуальное расположение файла с инструкциями для оркестратора и файлов с промптами.
Тогда всё заработает.
Именно, но тут Cursor ведет себя аналогично другим CLI-агентам. Можно либо проверять все изменения через git в конце, либо просить после завершения каждой задачи делать коммит, чтобы видеть этапность изменений и иметь возможность откатиться на несколько шагов назад.
Я предпочитаю первый вариант: ревьюить сразу финальный код.
С этой сферой я слабо знаком, но на мой дилетантский взгляд, потребность в специалистах по 3D моделированию должна расти со временем (медиа-контент, индустрия 2.0 и т.п.)
Касаемо плана, не поддерживаемого спросом. Какой был спрос на Айфоны в 2006 году?
Спрос рождает предложение только на идеальном рынке, в теории. В реальности люди покупают в основном то, что им предлагается на рынке.
Какую часть своего бюджета мы тратим на новогодние открытки? Полагаю, что меньше 1%.
Вопрос в том, какие товары и услуги занимают в экономике наиболее значимую часть, и как определяется их стоимость.
Я пробовал найти хорошие статистические данные по глобальному потреблению. Проблема в том, что стоимость многих конечных продуктов складывается из большого набора промежуточных составляющих. Например, покупая помидоры в магазине, мы платим не столько за сами помидоры, сколько за труд продавцов, аренду помещения, транспортировку и т.п. И каждая из этих составляющих также раскладывается на много других составляющих. И когда мы пробуем получить данные по мировому объему рынков товаров и услуг, мы видим цифры с учетом промежуточных составляющих, которые мы, как конечные потребители, непосредственно не потребляем. Т.е. в такого рода отчетах имеет место дублирование стоимости.
Более адекватную картину можно получить, если проанализировать свои собственные расходы, на что люди как конечные потребители тратят деньги. Существенная часть — это продукты питания, одежда, жилье (включая коммунальные услуги), транспорт, медицина, образование. Также не стоит забывать про часть денег, которую мы тратим не по своей воле, но без которой практически невозможно обойтись — это государственные расходы, которые мы оплачиваем через налоги. Соотношение указанных категорий зависит от уровня жизни, но расходы большинства людей ограничиваются этим списком, остальные категории товаров и услуг составляют существенно меньшую долю.
Тезис сказанного выше в том, что подавляющая доля расходов потребителей идет на жизненно необходимые товары и услуги, стоимость которых в современном мире очень сильно оптимизирована и по своей сути состоит в основном из труда, вложенного в их создание.
Я не буду спорить, что есть категории товаров, цены на которые не имеют ничего общего с вложенными трудозатратами. Но современный рынок потребительских товаров и услуг очень высококонкурентный, и цена подавляющей доли товаров и услуг оптимизирована настолько, что состоит в основном из стоимости вложенного труда.
Что касается планирования. Алгоритмы максимизируют ту функцию, которая в них заложена. На текущий момент методы машинного обучения прекрасно зарекомендовали себя в маркетинге. Вряд ли кто-то будет спорить, что уже давно спрос формируется не столько потребительскими качествами товаров и услуг, сколько успешным продвижением. И если раньше маркетологи были вынуждены полагаться на свои мозги, скромные наборы данных и более тривиальные алгоритмы, то сейчас, с ростом роли big data и machine learning, маркетинг становится все более и более эффективным. Я не буду настаивать на своей точке зрения, но полагаю, что уже сейчас многие люди совершают покупки по «приказу» алгоритмов продвижения товаров и услуг. И чем дальше, тем эта тенденция будет усиливаться. У людей очень много когнитивных искажений, которые можно эффективно использовать и таким образом проактивно формировать спрос.
К сожалению, сейчас алгоритмы используются для формирования рынка массового потребления. Но я бы хотел, чтобы со временем, когда мы все «наедимся», и будет больше излишков энергии, которую надо куда-то направлять, функция, которую алгоритмы смогут максимизировать, будет все больше из области науки и исследований. Моя статья, я надеюсь, показывает, как можно иначе и более результативно использовать ресурсы, которые нам предоставляет наша планета.