Я сделал эту схему для серьёзных доработок существующего проекта. Для проектов "на вечер" я бы не стал её использовать - это 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, маркетинг становится все более и более эффективным. Я не буду настаивать на своей точке зрения, но полагаю, что уже сейчас многие люди совершают покупки по «приказу» алгоритмов продвижения товаров и услуг. И чем дальше, тем эта тенденция будет усиливаться. У людей очень много когнитивных искажений, которые можно эффективно использовать и таким образом проактивно формировать спрос.
К сожалению, сейчас алгоритмы используются для формирования рынка массового потребления. Но я бы хотел, чтобы со временем, когда мы все «наедимся», и будет больше излишков энергии, которую надо куда-то направлять, функция, которую алгоритмы смогут максимизировать, будет все больше из области науки и исследований. Моя статья, я надеюсь, показывает, как можно иначе и более результативно использовать ресурсы, которые нам предоставляет наша планета.
Я сделал эту схему для серьёзных доработок существующего проекта. Для проектов "на вечер" я бы не стал её использовать - это 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, маркетинг становится все более и более эффективным. Я не буду настаивать на своей точке зрения, но полагаю, что уже сейчас многие люди совершают покупки по «приказу» алгоритмов продвижения товаров и услуг. И чем дальше, тем эта тенденция будет усиливаться. У людей очень много когнитивных искажений, которые можно эффективно использовать и таким образом проактивно формировать спрос.
К сожалению, сейчас алгоритмы используются для формирования рынка массового потребления. Но я бы хотел, чтобы со временем, когда мы все «наедимся», и будет больше излишков энергии, которую надо куда-то направлять, функция, которую алгоритмы смогут максимизировать, будет все больше из области науки и исследований. Моя статья, я надеюсь, показывает, как можно иначе и более результативно использовать ресурсы, которые нам предоставляет наша планета.