Product Management & AI
ChatGPT в петле смерти сломанной юнит-экономики 1. ИИ требует всё больше токенов ↓ 2. Больше токенов → больше затрат ↓ 3. Больше затрат → сложнее окупать ИИ ↓ 4. Сложнее окупать ИИ → нужно чтобы больше юзали ИИ ↓ 5. Больше юзают → больше токенов → больше…
Экономика ИИ работает в долг, эпоха дешёвого ИИ заканчивается на наших глазах 👀
На этой неделе Microsoft аннулировала свои лицензии Claude Code после того, как Anthropic перешли на тарификацию по количеству токенов, сделав эти расходы для Microsoft непомерными (бедный Билл).
Тех дир Uber разослал внутреннее письмо, предупреждая, что компания всего за четыре месяца сожгла весь свой годовой бюджет на ИИ.
Цены на ПО с ИИ под капотом в США выросли на 20–40%, а тот же GitHub (принадлежащий Microsoft) отказывается от фиксированных тарифных планов в пользу оплаты по факту pay per usage во всех своих продуктах.
Тарификация на основе токенов вынуждает каждого столкнуться с реальной стоимостью эксплуатации ИИ в масштабах своего продукта, команды и рынка, и случайным образом вдруг оказалось, что эта сумма намного выше фиксированных тарифов.
Два сценария развития событий:
1) Либо компании сократят использование ИИ, чтобы уложиться в свои ИИ-бюджеты;
2) либо сами ИИ-лаборатории снизят цены на ИИ и возьмут убытки на себя (что ухудшит их юнит-экономику когда это наименее желательно).
Рыночек и экономика беспощадны, поэтому оба пути ведут к одному результату: циферкиперестают перестали сходиться, и кому-то придётся списывать активы и фиксировать убытки. Кому? Правильный ответ: Всем
– За счёт спасибо AbstractDL 🫠
На этой неделе Microsoft аннулировала свои лицензии Claude Code после того, как Anthropic перешли на тарификацию по количеству токенов, сделав эти расходы для Microsoft непомерными (бедный Билл).
Тех дир Uber разослал внутреннее письмо, предупреждая, что компания всего за четыре месяца сожгла весь свой годовой бюджет на ИИ.
Цены на ПО с ИИ под капотом в США выросли на 20–40%, а тот же GitHub (принадлежащий Microsoft) отказывается от фиксированных тарифных планов в пользу оплаты по факту pay per usage во всех своих продуктах.
Тарификация на основе токенов вынуждает каждого столкнуться с реальной стоимостью эксплуатации ИИ в масштабах своего продукта, команды и рынка, и случайным образом вдруг оказалось, что эта сумма намного выше фиксированных тарифов.
Два сценария развития событий:
1) Либо компании сократят использование ИИ, чтобы уложиться в свои ИИ-бюджеты;
2) либо сами ИИ-лаборатории снизят цены на ИИ и возьмут убытки на себя (что ухудшит их юнит-экономику когда это наименее желательно).
Рыночек и экономика беспощадны, поэтому оба пути ведут к одному результату: циферки
– За счёт спасибо AbstractDL 🫠
Product Management & AI
Всё что нужно – это пустой родмэп (с) Я намеренно держу план проекта пустым. Недавно ко мне в офис зашла вице-президент по продажам. Она хотела к пятнице создать панель управления отчётностью. Я сказал ей, что это уже есть в плане проекта. Она стала выглядеть…
Дорожная карта более чем на месяц всегда была ошибочным артефактом в управлении продуктом и ИИ это доказал
А суть и изначальная концепция дорожной карты как путеводителя по пространствурынка с развитием корпоративных норм, правил и культур, была заменена на пошаговую инструкцию по ремонту и эксплуатации самоката/автомобиля/самолёта или на чём там передвигаются по рынку на картинке с MVP.
Аналогичным образом были сломаны и все процессы, стоящие далее за дорожной картой: аналитика на старых данных, планирование задач на день/квартал/неделю задним числом, такая же разработка и бесконечно замкнутые внутри себя этапы проверок и согласований. Незаметно, так эти процессы и стали самой дорожной картой.
И всё это рушится прямо сейчас и все волны тысячных сокращений в айти прямое подтверждение этому – Система не любит оптимизировать Хаос и ей легче очистить и перезагрузить себя, начав всё новое с нуля. Чтобы восстановить всё вновь.
Тоже самое с рынком аутсорсинга разработки/маркетинга/аккаунтинга, причем как снаружи, так и внутри.
Всё то, что раньше покупали потому что "почему бы не получить откат быстрее/проще будет на аутсорсе", теперь:
а)можно нужно делать ещё быстрее/дешевле внутри себя с ИИ-аутсорсом; б) можно нужно делать быстрее/дешевле даже на аутосорсе с ИИ.
Что самое забавное – и заказчики и исполнители (и все, кто там ещё между ними), все стороны уже прекрасно понимают, что с ИИ растягивание этих процессов и обоснование раздутых сроков, команд и бюджетов становится всё сложнее чем каких-то 3 года назад без ИИ.
TLDR: ИИ обнажил очередную правду – дорожная карта была превращена в скучный график самоконтроля, составленным из расчёта на искусственные ограничения, которых... больше не существует из-за искусственного ИИ.
Удачной всем недели (и без ограничений) 🫱✨✨
А суть и изначальная концепция дорожной карты как путеводителя по пространству
Аналогичным образом были сломаны и все процессы, стоящие далее за дорожной картой: аналитика на старых данных, планирование задач на день/квартал/неделю задним числом, такая же разработка и бесконечно замкнутые внутри себя этапы проверок и согласований. Незаметно, так эти процессы и стали самой дорожной картой.
И всё это рушится прямо сейчас и все волны тысячных сокращений в айти прямое подтверждение этому – Система не любит оптимизировать Хаос и ей легче очистить и перезагрузить себя, начав всё новое с нуля. Чтобы восстановить всё вновь.
Тоже самое с рынком аутсорсинга разработки/маркетинга/аккаунтинга, причем как снаружи, так и внутри.
Всё то, что раньше покупали потому что "
а)
Что самое забавное – и заказчики и исполнители (и все, кто там ещё между ними), все стороны уже прекрасно понимают, что с ИИ растягивание этих процессов и обоснование раздутых сроков, команд и бюджетов становится всё сложнее чем каких-то 3 года назад без ИИ.
TLDR: ИИ обнажил очередную правду – дорожная карта была превращена в скучный график самоконтроля, составленным из расчёта на искусственные ограничения, которых... больше не существует из-за искусственного ИИ.
Удачной всем недели (и без ограничений) 🫱✨✨
Product Management & AI
Дизайн продуктов наконец-то переходит от создания артефактов (рисования кнопочек по 6 недель) к созданию: 1) Дизайн-Систем; 2) систем дизайн-процессов. Всё потому, что с ИИ: – Процессы пре-дизайна стали проще. Потому что контекст для дизайна продукта…
Если вы дизайните с ИИ, ей не хватает вкуса и она отвечает "I know this looks terrible, but I have no idea why", держите подборку вкусных дизайн-скиллов для агентов:
– http://tasteskill.dev
– http://impeccable.style
– http://layers.jamiemill.com
– http://app.superdesign.dev
– http://github.com/gnurio/refactoring-ui-plugin
Free, open-source💅
– http://tasteskill.dev
– http://impeccable.style
– http://layers.jamiemill.com
– http://app.superdesign.dev
– http://github.com/gnurio/refactoring-ui-plugin
Free, open-source
Please open Telegram to view this post
VIEW IN TELEGRAM
Product Management & AI
Практические советы по вайбкодингу глазами и словами продакта, часть 3 (часть 2 и 1) 1) Мысли UX/UI, переводя слова на код От того, насколько правильно сформулировано и построено предложение в твоём промпте, будет зависеть то, насколько правильно будет спроектирована…
Галлюцинации ИИ – это твои галлюцинации: испытываем их вместе с ИИ (вайбкодинг ч.4)
Подбираемся с ИИ уже к сотне фич, багов,целому параду планет различных стимуляторов, транков и всего такого всех цветов и заметил, что:
если в первых версиях ИИ часто выдавала бред из-за недообученных моделей, то нынешние версии начинают глючить и впадать в бесконечные рассуждения по одной причине – ТЫ делаешь что-то не так, а не ИИ.
Понять, что ИИ попала в петлю просто – она начинает рассуждать 3+ минут вне зависимости от переформулирований и не сдвигается в рассуждениях ни на шаг, лишь проливая воду на экран и память. Тонны объяснений и перебираний вариантов, все эти "Wait, but" и... ничего.
В то время как при правильно сконструируемой (и поддерживаемой!!!) архитектуре и механиках, ИИ находит решение с первого промпта, сразу находит исполняемые функции и файлы и пишет работающий с первого пуша код за те самые 1-3 минуты.
КАК ДЕЛАТЬ КОД:
– проси системный подход;
– проси фрактальное подобие;
– проси общие утилитарные модули.
– Проси сначала проверить и описать архитектуру решения по таким условиям и только после твоего апрува писать код.
– Проси комментить все допущения, которые ИИ будет делать а) во время обсуждений; б) в комментах коде. Так ты увидишь, что она додумала за тебя и сможешь исправить это как: а) до релиза; б) так и после.
– Ведите в CLAUDE .MD словарь терминов и оперируй по нему в промптах и новых сессиях. "Термин / определение + сущности" через которые вы с ИИ должны оба понимать о чём говорите. Иначе через 10 итераций у тебя "вдруг" окажется две сущности типа UserManager с разной логикой.
– Лучший способ проверить, что ИИ понимает механики и зависимости фич и кода это попросить объяснить их через "что в системе сломается, если это убрать".
Если ты видишь дальше/больше ИИ, объясни ей это и попроси обновить: а) доку в CLAUDE .MD; б) комменты в коде. Проси, чтобы писала, что код принимает, возвращает, какие сайд-эффекты. Всё это спасёт тебяи её от галлюцинаций при следующих сессиях, когда контекст предыдущих сбросится.
ЧТО НЕ ДЕЛАТЬ:
1) Думать, что ИИ всё поймёт. Она поймёт, только но по своему, по своему напишет код и не сообщит тебе об этом. А ты потом будешь тупить и пытаться отловить несуществующую багу.
И вы не найдёте её, потому что ИИ будет глючить и пропускать это место, считая его нормой работающего кода/механики, и для неё это будет "не бага, а фича". Так легендарный мэм сыграет для тебя в обратку новой краской.
– Не давать ИИ полный 360° контекст вокруг изменения или апдейта фичи. Какие механики затрагиваются фичей; какие ещё (всегда есть место для ЕЩЁ); где ещё эта фича вылезает; с какими сущностями она ещё связана и в каком контексте (снова где ещё).
– Проси ИИ выстроить приоритет задач самой, в противном случае рискуешь словить то, что один код будет создавать костыль и ломать другой, причём это будет незаметно сразу.
– Не проси фиксить баги, не объяснив их симптомы и ожидаемое ТОБОЙ поведение. У меня было много раз, когда ИИ чинила только то, что я ей описывал, и ломала то, что не упоминал.
А ещё она чинила несуществующие баги, потому что я плохо сформулировал баг-репорт и не дал весь контекст. Пришлось перепроверять и тестить половину кода и назвать это красивым словом рефакторинг.
– Не давай ИИ рефакторить и добавлять фичу в одном промпте, это два абсолютно разных намерения с разными подоходами мышления и реализации! Смешаешь и ИИ добавит багу и отрефакторит уже работающую фичу как в предыдущем случае.
– Не копите. Технический. Долг. Молча. Если что-то допускаете как "ну ок, оставим пока вот так" – закомментите это в коде и claude md.
– И не продолжай сессию после третьего долгого ответа подряд. Это сигнал, что ИИ не улавливает суть, не видит багу в фиче (считая это нормой), контекстное окно замусорено, ИИ потеряла нить, попала в петлю, вы делаете что-то не так, вы оба начали галлюцинировать...
...Relax. Breath...
Новое окно. И новый взгляд.
Вайбкодинг он про то, чтоб ТЫ не потерял все нити.
Но, если что – режь всё, пиши фичу с нуля с начала.
Подбираемся с ИИ уже к сотне фич, багов,
если в первых версиях ИИ часто выдавала бред из-за недообученных моделей, то нынешние версии начинают глючить и впадать в бесконечные рассуждения по одной причине – ТЫ делаешь что-то не так, а не ИИ.
Понять, что ИИ попала в петлю просто – она начинает рассуждать 3+ минут вне зависимости от переформулирований и не сдвигается в рассуждениях ни на шаг, лишь проливая воду на экран и память. Тонны объяснений и перебираний вариантов, все эти "Wait, but" и... ничего.
В то время как при правильно сконструируемой (и поддерживаемой!!!) архитектуре и механиках, ИИ находит решение с первого промпта, сразу находит исполняемые функции и файлы и пишет работающий с первого пуша код за те самые 1-3 минуты.
КАК ДЕЛАТЬ КОД:
– проси системный подход;
– проси фрактальное подобие;
– проси общие утилитарные модули.
– Проси сначала проверить и описать архитектуру решения по таким условиям и только после твоего апрува писать код.
– Проси комментить все допущения, которые ИИ будет делать а) во время обсуждений; б) в комментах коде. Так ты увидишь, что она додумала за тебя и сможешь исправить это как: а) до релиза; б) так и после.
– Ведите в CLAUDE .MD словарь терминов и оперируй по нему в промптах и новых сессиях. "Термин / определение + сущности" через которые вы с ИИ должны оба понимать о чём говорите. Иначе через 10 итераций у тебя "вдруг" окажется две сущности типа UserManager с разной логикой.
– Лучший способ проверить, что ИИ понимает механики и зависимости фич и кода это попросить объяснить их через "что в системе сломается, если это убрать".
Если ты видишь дальше/больше ИИ, объясни ей это и попроси обновить: а) доку в CLAUDE .MD; б) комменты в коде. Проси, чтобы писала, что код принимает, возвращает, какие сайд-эффекты. Всё это спасёт тебя
ЧТО НЕ ДЕЛАТЬ:
1) Думать, что ИИ всё поймёт. Она поймёт, только но по своему, по своему напишет код и не сообщит тебе об этом. А ты потом будешь тупить и пытаться отловить несуществующую багу.
И вы не найдёте её, потому что ИИ будет глючить и пропускать это место, считая его нормой работающего кода/механики, и для неё это будет "не бага, а фича". Так легендарный мэм сыграет для тебя в обратку новой краской.
– Не давать ИИ полный 360° контекст вокруг изменения или апдейта фичи. Какие механики затрагиваются фичей; какие ещё (всегда есть место для ЕЩЁ); где ещё эта фича вылезает; с какими сущностями она ещё связана и в каком контексте (снова где ещё).
– Проси ИИ выстроить приоритет задач самой, в противном случае рискуешь словить то, что один код будет создавать костыль и ломать другой, причём это будет незаметно сразу.
– Не проси фиксить баги, не объяснив их симптомы и ожидаемое ТОБОЙ поведение. У меня было много раз, когда ИИ чинила только то, что я ей описывал, и ломала то, что не упоминал.
А ещё она чинила несуществующие баги, потому что я плохо сформулировал баг-репорт и не дал весь контекст. Пришлось перепроверять и тестить половину кода и назвать это красивым словом рефакторинг.
– Не давай ИИ рефакторить и добавлять фичу в одном промпте, это два абсолютно разных намерения с разными подоходами мышления и реализации! Смешаешь и ИИ добавит багу и отрефакторит уже работающую фичу как в предыдущем случае.
– Не копите. Технический. Долг. Молча. Если что-то допускаете как "ну ок, оставим пока вот так" – закомментите это в коде и claude md.
– И не продолжай сессию после третьего долгого ответа подряд. Это сигнал, что ИИ не улавливает суть, не видит багу в фиче (считая это нормой), контекстное окно замусорено, ИИ потеряла нить, попала в петлю, вы делаете что-то не так, вы оба начали галлюцинировать...
...Relax. Breath...
Новое окно. И новый взгляд.
Вайбкодинг он про то, чтоб ТЫ не потерял все нити.
Но, если что – режь всё, пиши фичу с нуля с начала.
Причина, по которой любая традиционная мудрость, от даосизма до современной нейронауки, определяет толерантность к неопределённости как фундаментальный навык, заключается в том, что неопределённость составляет саму Суть Бытия.
Когда Будда говорил о непостоянстве как об источнике страдания; когда квантовая физика открыла бесконечную вероятностную природу реальности; когда предприниматели обнаруживают, что рынки по своей сути непредсказуемы, то все они указывают на одну и ту же истину:
Религиозное сознание называет это верой; предпринимательское – смелостью; а нейробиологическое – регуляцией миндалевидного тела со стороны префронтальной коры головного мозга.
Но все они описывают одну и ту же способность действовать эффективно, признавая при этом, что вы не знаете и не можете контролировать то, что произойдёт дальше.
И любой прорыв в истории человечества совершался благодаря тому, что кто-то делал шаг вперёд, не зная предстоящего исхода, в то время как все остальные выжидали определённости, которая так и не наступала.
Суть здесь не в том, чтобы победить страх, а в том, чтобы осознать простые вещи:
Развитие этой способности требует понимания того, что невозможно обрести комфорт в условиях неопределённости, просто обдумав и спланировав ситуацию.
К этому состоянию нужно прочувствовать Путь.
Практика проста. Замечай моменты, когда ты пытаешься избежать мелкой неопределённости: навязчиво проверяя телефон, чрезмерно готовясь к незначительным беседам, ища подтверждения своей правоты и безопасности снова, снова и снова.
Вместо этого сделай паузу, чтобы ощутить телесный и подсознательный дискомфорт, не пытаясь при этом немедленно его устранить.
Дыши. Пропускай. Чувствуй.
Далее, начни действия: вступи в разговор, не планируя заранее, что именно ты скажешь; начни проект, ещё не чувствуя его полной готовности; выбери другой маршрут, не сверившись с картой.
Каждый раз, когда ты, несмотря на чувство неопределённости, успешно действуешь с таким Намерением, ты накапливаете эмпирические доказательства, опровергающие "пессимистические" прогнозы своего обманутого мозгом сознания.
Именно это древние стоики называли "добровольным дискомфортом". Именно этот принцип лежит в основе экспозиционной терапии.
И именно это предприниматели называют умением «чувствовать себя комфортно в дискомфортных условиях» — намеренное, многократное переживание тревоги в ситуациях, когда на самом деле ничего страшного не происходит, но это постепенно приучает вашу нервную систему воспринимать неопределённость не как опасность.
Трансформация же происходит за счёт накопления такого опыта.
После сотен повторений сценария «я чувствовал неопределённость, но продолжил действовать, выжил и даже преуспел» твой мозг переклассифицирует неопределённость, переводя её из разряда угрозы в категорию... нормального рабочего состояния.
Comfortable with Uncertainty: 108 Teachings on Cultivating Fearlessness and Compassion by PEMA CHÖDRÖN
И это именно тот зазор между причиной~и~следствием, где таятся все возможные варианты развития событий
Когда Будда говорил о непостоянстве как об источнике страдания; когда квантовая физика открыла бесконечную вероятностную природу реальности; когда предприниматели обнаруживают, что рынки по своей сути непредсказуемы, то все они указывают на одну и ту же истину:
Контроль — это иллюзия, а попытка обрести полную определённость в бесконечной Вселенной, где царит неопределённость, порождает именно то страдание, которого мы пытаемся избежать
Религиозное сознание называет это верой; предпринимательское – смелостью; а нейробиологическое – регуляцией миндалевидного тела со стороны префронтальной коры головного мозга.
Но все они описывают одну и ту же способность действовать эффективно, признавая при этом, что вы не знаете и не можете контролировать то, что произойдёт дальше.
И любой прорыв в истории человечества совершался благодаря тому, что кто-то делал шаг вперёд, не зная предстоящего исхода, в то время как все остальные выжидали определённости, которая так и не наступала.
Суть здесь не в том, чтобы победить страх, а в том, чтобы осознать простые вещи:
неопределённость – это базовое состояние Вселенной-Реальности, и именно сопротивление ей (а вовсе не сама неопределённость) порождает паралич воли
Развитие этой способности требует понимания того, что невозможно обрести комфорт в условиях неопределённости, просто обдумав и спланировав ситуацию.
К этому состоянию нужно прочувствовать Путь.
Практика проста. Замечай моменты, когда ты пытаешься избежать мелкой неопределённости: навязчиво проверяя телефон, чрезмерно готовясь к незначительным беседам, ища подтверждения своей правоты и безопасности снова, снова и снова.
Вместо этого сделай паузу, чтобы ощутить телесный и подсознательный дискомфорт, не пытаясь при этом немедленно его устранить.
Дыши. Пропускай. Чувствуй.
Далее, начни действия: вступи в разговор, не планируя заранее, что именно ты скажешь; начни проект, ещё не чувствуя его полной готовности; выбери другой маршрут, не сверившись с картой.
Каждый раз, когда ты, несмотря на чувство неопределённости, успешно действуешь с таким Намерением, ты накапливаете эмпирические доказательства, опровергающие "пессимистические" прогнозы своего обманутого мозгом сознания.
Именно это древние стоики называли "добровольным дискомфортом". Именно этот принцип лежит в основе экспозиционной терапии.
И именно это предприниматели называют умением «чувствовать себя комфортно в дискомфортных условиях» — намеренное, многократное переживание тревоги в ситуациях, когда на самом деле ничего страшного не происходит, но это постепенно приучает вашу нервную систему воспринимать неопределённость не как опасность.
Трансформация же происходит за счёт накопления такого опыта.
После сотен повторений сценария «я чувствовал неопределённость, но продолжил действовать, выжил и даже преуспел» твой мозг переклассифицирует неопределённость, переводя её из разряда угрозы в категорию... нормального рабочего состояния.
Comfortable with Uncertainty: 108 Teachings on Cultivating Fearlessness and Compassion by PEMA CHÖDRÖN
Flibusta
Спокойствие в неопределённости. 108 учений о развитии бесстрашия и сострадания читать онлайн бесплатно Пема Чодрон
Пема Чодрон Спокойствие в неопределённости. 108 учений о развитии бесстрашия и сострадания читать онлайн бесплатно целиком (полностью) без регистрации ✔ на телефоне или компьютере.
Марк вчера запустил премиум подписки для Instagram, Facebook и WhatsApp
$4/месяц для каждой аппы за стату, суперреакции, долгие сторис и всё такое, но интересно в этом всём причины и время, когда Марк решил это раскатить.
А видятся они в простом:
1) Бесплатная версия социалок с рекламой работала, пока предельные вычислительные затраты на инфру и код социалки ≈ 0. Код и код, крутится себе на серверах в Калифорнии, реклама, рожь, VR-Вселенная без ног, кайеф.
2) Пришла эпоха ИИ, и социалки теперь не просто код, а ИИ-монолиты, в которых каждая функция ИИ это колоссальная нагрузка на новую(!) ИИ-инфру, имеющая собственную стоимость в $ за каждый ИИ-запрос (новый термин – AI ROI).
Теперь представьте на масштабах всех трёх социалок Марка. Поэтому одна лишь реклама теперь не может окупать ТАКОЕ (бедный Марк).
– 2023 год: Эпоха массовых бесплатных продуктов подходит к своему логическому завершению с введением подписки на синюю галочку в Твиттере.
Хочешь получать профит от Х в виде приоритета в реплаях и рекомендациях в ленте (то есть, быть на виду)? Значит твой продукт это ты сам, ты перепродаешь себя, а значит... это B2B, поэтому ты должен плотитьнологи.
– 2026 год: Теперь и Инста с Фб официально конвертнулись в сознании юзеров из B2C в B2B продукт. Вместе с юзерами.
А экономика ИИ пытается перестать работать в долг
$4/месяц для каждой аппы за стату, суперреакции, долгие сторис и всё такое, но интересно в этом всём причины и время, когда Марк решил это раскатить.
А видятся они в простом:
1) Бесплатная версия социалок с рекламой работала, пока предельные вычислительные затраты на инфру и код социалки ≈ 0. Код и код, крутится себе на серверах в Калифорнии, реклама, рожь, VR-Вселенная без ног, кайеф.
2) Пришла эпоха ИИ, и социалки теперь не просто код, а ИИ-монолиты, в которых каждая функция ИИ это колоссальная нагрузка на новую(!) ИИ-инфру, имеющая собственную стоимость в $ за каждый ИИ-запрос (новый термин – AI ROI).
Теперь представьте на масштабах всех трёх социалок Марка. Поэтому одна лишь реклама теперь не может окупать ТАКОЕ (бедный Марк).
– 2023 год: Эпоха массовых бесплатных продуктов подходит к своему логическому завершению с введением подписки на синюю галочку в Твиттере.
Хочешь получать профит от Х в виде приоритета в реплаях и рекомендациях в ленте (то есть, быть на виду)? Значит твой продукт это ты сам, ты перепродаешь себя, а значит... это B2B, поэтому ты должен плотитьнологи.
– 2026 год: Теперь и Инста с Фб официально конвертнулись в сознании юзеров из B2C в B2B продукт. Вместе с юзерами.
А экономика ИИ пытается перестать работать в долг
Product Management & AI
"Ты знаешь, какой у нас тех. долг?" — вопрос, который однажды слышит продакт от своих разрабов и ситуация, в которую может попасть каждый продукт. Разберемся сегодня, почему до определенного момента в этом ничего страшного, что случается когда он наступает…
This media is not supported in your browser
VIEW IN TELEGRAM
Причина тех долгов в продукте – продакт
А в эпоху ИИ не должно быть никакого тех. долга вообще.
ИИ должен устранить весь технический долг: а) который был накоплен ранее; б) любой последующий планируемый тех долг ещё до того, как представить свой готовый код.
В отличие от людей, ИИ может продолжать работать над чем-то пока это не будет сделано, а не предлагать идти на уступки и компромиссы из-за человеческих ограничений и времени.
И если ИИ говорит вам, что "оставляет что-то на потом", это первый шаг к галлюцинациям и сигнал, что ты:
1) неверно определил проблему пользователя → 2) придумал несуществующий userflow → 3) спроектировал кривой UX/UI, механику решения и фичу = поэтому ИИ тупит с логикой и архитектурой кода и предлагает взять тех. долг.
А в эпоху ИИ не должно быть никакого тех. долга вообще.
ИИ должен устранить весь технический долг: а) который был накоплен ранее; б) любой последующий планируемый тех долг ещё до того, как представить свой готовый код.
В отличие от людей, ИИ может продолжать работать над чем-то пока это не будет сделано, а не предлагать идти на уступки и компромиссы из-за человеческих ограничений и времени.
И если ИИ говорит вам, что "оставляет что-то на потом", это первый шаг к галлюцинациям и сигнал, что ты:
1) неверно определил проблему пользователя → 2) придумал несуществующий userflow → 3) спроектировал кривой UX/UI, механику решения и фичу = поэтому ИИ тупит с логикой и архитектурой кода и предлагает взять тех. долг.
Причина тех долгов в продукте – продакт
Claude Code выкатили Dynamic Workflows
Новая фича позволяет запускать динамические рабочие процессы с участием сотен параллельных субагентов.
Некоторые задачи слишком велики для одного прохода одним ИИ-агентом, особенно в сложных легаси-кодбейсах: поиск багов по всему сервису, рефакторинг, миграции, затрагивающие сотни файлов, или план, который нужно проверить с каждого угла перед тем, как принять решение.
Dynamic Workflow — это JavaScript-скрипт, который оркестрирует субагентов в масштабе. Claude пишет этот скрипт под конкретную задачу, а рантайм выполняет его в фоне. План переходит в код, а не в контекстное окно Claude, все промежуточные результаты живут в переменных скрипта, и в контексте оказывается только финальный ответ. Тем самым ваша сессия с ИИ остаётся отзывчивой и неперегруженной контекстом, пока все агенты работают над большой задачей.
Попросите Claude Code создать воркфлоу напрямую через промпт, например, "Create a workflow...", либо включите новую настройку в ultracode) и и Claude динамически сформирует план оркестрации, которого будет неукоснительно придерживаться, что позволит ИИ и вам быть абсолютно уверенными в том, что каждый этап выполняется в правильной последовательности даже при участии сотен ИИ-агентов.
– Одна фича из коробки и 80% рынка оркестрации ИИ-агентов схлопнулось. Claude – As Above, So Below
Новая фича позволяет запускать динамические рабочие процессы с участием сотен параллельных субагентов.
Некоторые задачи слишком велики для одного прохода одним ИИ-агентом, особенно в сложных легаси-кодбейсах: поиск багов по всему сервису, рефакторинг, миграции, затрагивающие сотни файлов, или план, который нужно проверить с каждого угла перед тем, как принять решение.
Dynamic Workflow — это JavaScript-скрипт, который оркестрирует субагентов в масштабе. Claude пишет этот скрипт под конкретную задачу, а рантайм выполняет его в фоне. План переходит в код, а не в контекстное окно Claude, все промежуточные результаты живут в переменных скрипта, и в контексте оказывается только финальный ответ. Тем самым ваша сессия с ИИ остаётся отзывчивой и неперегруженной контекстом, пока все агенты работают над большой задачей.
Попросите Claude Code создать воркфлоу напрямую через промпт, например, "Create a workflow...", либо включите новую настройку в ultracode) и и Claude динамически сформирует план оркестрации, которого будет неукоснительно придерживаться, что позволит ИИ и вам быть абсолютно уверенными в том, что каждый этап выполняется в правильной последовательности даже при участии сотен ИИ-агентов.
– Одна фича из коробки и 80% рынка оркестрации ИИ-агентов схлопнулось. Claude – As Above, So Below
Product Management & AI
The Company Graph Когда говорят, что ИИ/человек не может выполнить ту или иную работу, на самом деле говорят, что им "не предоставили весь контекст". Всё дело всегда в контексте. И источник проблемы не в том, что контекста не существует (он существует)…
I think the reason so many people don't understand how big AI is going to be is that they don't understand that
Specifically, they don't realize that companies are just a collection of algorithms
– Think about that very carefully 👆
everything is an algorithm
Specifically, they don't realize that companies are just a collection of algorithms
– Think about that very carefully 👆
Product Management & AI
Галлюцинации ИИ – это твои галлюцинации: испытываем их вместе с ИИ (вайбкодинг ч.4) Подбираемся с ИИ уже к сотне фич, багов, целому параду планет различных стимуляторов, транков и всего такого всех цветов и заметил, что: если в первых версиях ИИ часто выдавала…
Синхронность и фрактальность в userflow→UX→UI→коде
Никогда не думал, что скажу такое, но...
Простыми словами:
– Баги в коде (я не про баги со скобками и запятыми, а про ошибки логики и архитектуры кода) = баги в пользовательской проблеме/решении. То, что было не продумано/забыто в коде, аналогично этого же не будет хватать пользователям в механиках продукта.
– У любой механики → фичи → кода есть обратная сторона, которая является логическим продолжением и завершением петли механики. Логика, вообще, любимое слово наших друзей-программестов )))
Примеры: экшены "Добавить/Исключить", функции "Follow/Ignore" и т.п. Забыл что-то одно, и вот уже код кривой и вылезут баги когда спустя время решите делать и программист будет писать противоположную фичу по другому → userflow неполный → фича неполноценная → и, что главное для продакта/продукта – пользовательский сценарий будет не закрыт. И будут баги и пробелы, но уже в продукте/решении/процессах.
– Фрактальное подобие механик/функций/кода. Моё любимое и весьма сложное даже для разрабов (на самом деле, очень просто, в этом суть Фрактала).
Реакция (не лайк) на пост, реакция на пост-комментарий (комментарий это пост, не комментарий), реакция на ответ на комментарий-пост — всё сущности должны быть максимально общими/простыми/гибкими, чтобы использовать самим себя на разных уровнях систем.
И если у вас 3 разные сущности и типа записей контента и 3 разных типа лайка для них, то вот у тебя уже 6 зависимостей вместо 2 и 27 потенциальных вариантов багов. 1х1=1, а 2х2=4. Красиво.
Чем больше сущностей в архитектуре - тем больше рамок, функций, зависимостей и ограничений они все в себе несут. И тем больше ограничены все наши фичи, сценарии, механики и пользователи в продукте. Мы сталкиваемся с этим, когда слышим от разрабов: "Ууу, у нас архитектура этого не позволяет". Вот, это оно!
– У всего должен быть (есть) Один-Источник-Правды ☉
Статус пользователя, статус заказа, статус объекта, чего угодно – если оно хранится и проверяется в двух местах (зачем? почему? в чем причина этого? в процессе? а может быть, что-то не так с таким процессом?), то вы внедряете несколько несколько вызовов, несколько зависимостей, несколько проверок, 2+ логики и 2+ функции, 27 не дважды два четыре, и уж точно не 1.
И однажды, 100%, они разойдутся, Система для себя сделает одно, а пользователь увидит иное и это превратит их/ваш userflow→UX→UI→код с продуктом в Хаос...
Смотри в продукты сердцем продакта душой дизайнера глазами программиста. Всё это – бесценно!
КАК ЖЕ СИЛЬНО техническое мышление разрабов может помогать продакту в осознании и познании механик продукта и пользователей
Простыми словами:
– Баги в коде (я не про баги со скобками и запятыми, а про ошибки логики и архитектуры кода) = баги в пользовательской проблеме/решении. То, что было не продумано/забыто в коде, аналогично этого же не будет хватать пользователям в механиках продукта.
– У любой механики → фичи → кода есть обратная сторона, которая является логическим продолжением и завершением петли механики. Логика, вообще, любимое слово наших друзей-программестов )))
Примеры: экшены "Добавить/Исключить", функции "Follow/Ignore" и т.п. Забыл что-то одно, и вот уже код кривой и вылезут баги когда спустя время решите делать и программист будет писать противоположную фичу по другому → userflow неполный → фича неполноценная → и, что главное для продакта/продукта – пользовательский сценарий будет не закрыт. И будут баги и пробелы, но уже в продукте/решении/процессах.
– Фрактальное подобие механик/функций/кода. Моё любимое и весьма сложное даже для разрабов (на самом деле, очень просто, в этом суть Фрактала).
Реакция (не лайк) на пост, реакция на пост-комментарий (комментарий это пост, не комментарий), реакция на ответ на комментарий-пост — всё сущности должны быть максимально общими/простыми/гибкими, чтобы использовать самим себя на разных уровнях систем.
И если у вас 3 разные сущности и типа записей контента и 3 разных типа лайка для них, то вот у тебя уже 6 зависимостей вместо 2 и 27 потенциальных вариантов багов. 1х1=1, а 2х2=4. Красиво.
Каждая (всякая ((Единая))) сущность в коде и в Системе должна быть собой, порождая своё фрактальное подобие, то есть использовать саму себя
Чем больше сущностей в архитектуре - тем больше рамок, функций, зависимостей и ограничений они все в себе несут. И тем больше ограничены все наши фичи, сценарии, механики и пользователи в продукте. Мы сталкиваемся с этим, когда слышим от разрабов: "Ууу, у нас архитектура этого не позволяет". Вот, это оно!
– У всего должен быть (есть) Один-Источник-Правды ☉
Статус пользователя, статус заказа, статус объекта, чего угодно – если оно хранится и проверяется в двух местах (зачем? почему? в чем причина этого? в процессе? а может быть, что-то не так с таким процессом?), то вы внедряете несколько несколько вызовов, несколько зависимостей, несколько проверок, 2+ логики и 2+ функции, 27 не дважды два четыре, и уж точно не 1.
И однажды, 100%, они разойдутся, Система для себя сделает одно, а пользователь увидит иное и это превратит их/ваш userflow→UX→UI→код с продуктом в Хаос...
Смотри в продукты сердцем продакта душой дизайнера глазами программиста. Всё это – бесценно!
Telegram
Product Management & AI
👆 Концепции, архитектура, механики и UI/UX Продуктов и Систем будущего (Настоящего)
Product Management & AI
Почему разрабы мы все факапим сроки? Посвящается всем разрабам и продактам Причина №1 – у нас искажено системное мышление, из-за чего мы видим код продукт мир как цепочку причинно-следственных связей и параметров: – Требование → Инструкция → Решение – Input…
This media is not supported in your browser
VIEW IN TELEGRAM
Гипотезы, задачи, фичи – всё начинается как план. Сначала план (но это всё не точно)
0) Сначала сохрани контекст, что в голове, потом планируй. Помни о главном – цель.
Промпт (люблю писать для ИИ капсом):
1) Кидай в обработку ИИ сырые данные/транскрипты, даже если это часовой колл. Кинешь саммари и ИИ пропустит и потеряет контекст сразу на 2 этапах: на этапе создания саммари и на этапе работы с саммари.
Не жмись на токены – лишнее фильтруется само, значения есть в каждом слове/фразе.
2) Требуй у ИИ 3+1 вариантов с трейд-офами, а не один. Сначала разведи варианты и смотри на них сверху, послевыбирай, далее фильтруй через: «Почему сейчас и почему это, а не другое», после собирай из элементов нужный вам.
Явные non-goals (что мы НЕ делаем) выписывай отдельным блоком.
3) Pre-mortem в план, чтоб хоронить фичи вначале и не хоронить в конце. Проси описать 3 варианта, как твоя затея провалится. Сужай область мышленияИИ через "какое одно предположение в плане, если оно неверно, рушит всё?" + "опиши условия, при которых этот проект стоит остановить, а не продолжать".
Реалистичые сроки начинаются со здоровых и реалистичных задач. Срыв сроков – кривые и нездоровые задачи.
4) Реверс-планирование от дедлайна это когда планирование идёт от конечной даты назад (вперёд): что должно быть готово за неделю до релиза, за две, за месяц. С помощью этой штуки вылезают неявные, узкие и избыточные куски функционала и механик, которые при классическом планировании наперёд скрываются за оптимизмом сроков.
5) RACI прямо в плане. На каждый блок указывай кто делает, с кем советоваться, кто апрувит, кого просто информировать. Хорошо помогает увидеть слабые места не только в фичах, но и в людях.
6) Рисуй Линии-и-Точки. Лучший план должен быть таким, чтобы после каждого этапа его реализации на руках уже была ценность, с которой можно было как минимум остановиться, как максимум эту ценность передать.
7) 20% усилий закрывают 80% боли, и облегчённый вариант гипотезы/идеи/фичи/продукта оказывается самым успешным.
8) 80% плана(ов) не нужны. Ценность – это цель 😎
0) Сначала сохрани контекст, что в голове, потом планируй. Помни о главном – цель.
Промпт (люблю писать для ИИ капсом):
Задача: ___ Аудитория:___ Контекст:___ бла-бла-бла
НО СНАЧАЛА ОТДЕЛЬНО СФОРМУЛИРУЙ ПЛАН: как ты будешь разбирать и что проверишь перед задачей, прежде чем писать предложение. Прежде чем составлять сам план, задай мне 5–7 уточняющих контекст и ситуации вопросов, ответы на которые сильнее всего повлияют на результат (по одному за раз).
1) Кидай в обработку ИИ сырые данные/транскрипты, даже если это часовой колл. Кинешь саммари и ИИ пропустит и потеряет контекст сразу на 2 этапах: на этапе создания саммари и на этапе работы с саммари.
Не жмись на токены – лишнее фильтруется само, значения есть в каждом слове/фразе.
2) Требуй у ИИ 3+1 вариантов с трейд-офами, а не один. Сначала разведи варианты и смотри на них сверху, после
Явные non-goals (что мы НЕ делаем) выписывай отдельным блоком.
3) Pre-mortem в план, чтоб хоронить фичи вначале и не хоронить в конце. Проси описать 3 варианта, как твоя затея провалится. Сужай область мышления
Реалистичые сроки начинаются со здоровых и реалистичных задач. Срыв сроков – кривые и нездоровые задачи.
4) Реверс-планирование от дедлайна это когда планирование идёт от конечной даты назад (вперёд): что должно быть готово за неделю до релиза, за две, за месяц. С помощью этой штуки вылезают неявные, узкие и избыточные куски функционала и механик, которые при классическом планировании наперёд скрываются за оптимизмом сроков.
5) RACI прямо в плане. На каждый блок указывай кто делает, с кем советоваться, кто апрувит, кого просто информировать. Хорошо помогает увидеть слабые места не только в фичах, но и в людях.
6) Рисуй Линии-и-Точки. Лучший план должен быть таким, чтобы после каждого этапа его реализации на руках уже была ценность, с которой можно было как минимум остановиться, как максимум эту ценность передать.
7) 20% усилий закрывают 80% боли, и облегчённый вариант гипотезы/идеи/фичи/продукта оказывается самым успешным.
8) 80% плана(ов) не нужны. Ценность – это цель 😎
Так майский дайджест протекает по Колумбии огнём
– Алхимическая задача
– Настройки мышления
– Гольф глазами продакта
– Галлюцинации ИИ твои
– Не пользователи, а люди
– Personas это JTBD
– 55 когнитивных искажений
– Библиотека идей, законов и концепций
– Минимализм умер
– Postmortems for UX
– Единство аффекта и интеллекта
– Почему мы делаем разные выводы
– Теория карьерных якорей
– 8 часов работы делают тупее
– Продакшен — ничто
– Про первый лайк
– Причина тех долгов – продакт
– ИИ психоз у CEO и у компаний
– AI-native Startup Founder's Playbook
– The “Bug-Free” Workforce
– Agent Memory That Survives
– Промпт-инжиниринг для не-инженеров
– Structured-Prompt-Driven Development
– Как экономить токены
– State of AI 2025–2026
– Design Systems Report
– Why research needs to research itself
– Контроль — это иллюзия
– Пытаясь спланировать непонятное
– Решение уравнения без решений
– Почему близнецы не симметричны
😌 Persistent Visions by Mark Seelig
🧘♂️ Ya-man from The Disciple's Path
Ad: Если нужен английский для работы, то AgileFluent – лучшее решение
– Алхимическая задача
– Настройки мышления
– Гольф глазами продакта
– Галлюцинации ИИ твои
– Не пользователи, а люди
– Personas это JTBD
– 55 когнитивных искажений
– Библиотека идей, законов и концепций
– Минимализм умер
– Postmortems for UX
– Единство аффекта и интеллекта
– Почему мы делаем разные выводы
– Теория карьерных якорей
– 8 часов работы делают тупее
– Продакшен — ничто
– Про первый лайк
– Причина тех долгов – продакт
– ИИ психоз у CEO и у компаний
– AI-native Startup Founder's Playbook
– The “Bug-Free” Workforce
– Agent Memory That Survives
– Промпт-инжиниринг для не-инженеров
– Structured-Prompt-Driven Development
– Как экономить токены
– State of AI 2025–2026
– Design Systems Report
– Why research needs to research itself
– Контроль — это иллюзия
– Пытаясь спланировать непонятное
– Решение уравнения без решений
– Почему близнецы не симметричны
😌 Persistent Visions by Mark Seelig
🧘♂️ Ya-man from The Disciple's Path
На PeopleSense'26 одна из панелей была посвящена тому, как ИИ меняет работу ИТ-руководителей. В своем выступлении управляющий директор направления первичной недвижимости Авито Недвижимости Дмитрий Алексеев показал, как смещается акцент с контроля процессов на ответственность за результат.
Происходит вот что:
1) Еще недавно руководителем считался тот, кто контролирует процессы и держит все под контролем.
2) С появлением ИИ‑агентов стало понятно, что именно этот слой работы автоматизируется первым. Как раз для этого такие инструменты и создаются — забирать рутину и контролировать поток задач.
То, что не автоматизируется, — это ответственность.
Полномочия можно передать алгоритму, ответственность — нет. И чем выше уровень ответственности, которую человек готов нести, тем выше его ценность — независимо от должности и количества прямых подчиненных.
Еще один сдвиг: эпоха руководителя, который только управляет процессами, уходит. Останутся те, кто умеет сочетать управление с личной вовлеченностью в создание результата, а не только в согласование планов и отчетов.
Рецепт от Алексеева на понедельник утром, чтобы к пятнице не оказаться не у дел: разберитесь в экономике своего продукта — где он создает ценность, а где теряет деньги. Выберите одну бизнес-метрику, за которую готовы отвечать лично, и выстройте вокруг нее продуктовую, коммерческую и финансовую части. Рутину отдайте ИИ, а сами занимайтесь решениями.
Происходит вот что:
1) Еще недавно руководителем считался тот, кто контролирует процессы и держит все под контролем.
2) С появлением ИИ‑агентов стало понятно, что именно этот слой работы автоматизируется первым. Как раз для этого такие инструменты и создаются — забирать рутину и контролировать поток задач.
То, что не автоматизируется, — это ответственность.
Полномочия можно передать алгоритму, ответственность — нет. И чем выше уровень ответственности, которую человек готов нести, тем выше его ценность — независимо от должности и количества прямых подчиненных.
Еще один сдвиг: эпоха руководителя, который только управляет процессами, уходит. Останутся те, кто умеет сочетать управление с личной вовлеченностью в создание результата, а не только в согласование планов и отчетов.
Рецепт от Алексеева на понедельник утром, чтобы к пятнице не оказаться не у дел: разберитесь в экономике своего продукта — где он создает ценность, а где теряет деньги. Выберите одну бизнес-метрику, за которую готовы отвечать лично, и выстройте вокруг нее продуктовую, коммерческую и финансовую части. Рутину отдайте ИИ, а сами занимайтесь решениями.
Product Management & AI
Исследование настоящего и будущего робототехники 2025 Чуваки из Твиттора три месяца изучали тему роботов общего назначения, перечитали кучу свежих научных публикаций, поговорили с ключевыми игроками рынка и собрали всё в одном документе. Современная робототехника…
This media is not supported in your browser
VIEW IN TELEGRAM
Жизнь робота в 2026: пассажир авиакомпании Southwest Airlines в США решил взять с собой в салон андроида, и вот что из этого получилось
Аарон Мехдизаде летел из Лас-Вегаса в Даллас и взял в салон своего робота Стьюи, который не пролезал по габаритам ручной клади, а отравлять багажом выходило дорого. Поэтому Аарон просто взял и оформил роботу... билет на соседнее кресло (услуга, которую обычно заказывают для перевозки хрупких вещей).
В аэропорту робот успешно прошёл предполётный досмотр: специально для этого на него была установлена батарея уменьшенной ёмкости, сам дошёл до гейта, а потом и в самолёте до своего места возле иллюминатора.
PS. После полёта Southwest Airlines быстро опубликовала новые правила перевозки, в которых прописала запрет на перевозку роботов в салоне или зарегистрированном багаже вне зависимости от их размера и назначения. Причина банальна — безопасность при перевозке литий-ионных аккумуляторов.
Лёгкой недели 👉✨✨
Аарон Мехдизаде летел из Лас-Вегаса в Даллас и взял в салон своего робота Стьюи, который не пролезал по габаритам ручной клади, а отравлять багажом выходило дорого. Поэтому Аарон просто взял и оформил роботу... билет на соседнее кресло (услуга, которую обычно заказывают для перевозки хрупких вещей).
В аэропорту робот успешно прошёл предполётный досмотр: специально для этого на него была установлена батарея уменьшенной ёмкости, сам дошёл до гейта, а потом и в самолёте до своего места возле иллюминатора.
PS. После полёта Southwest Airlines быстро опубликовала новые правила перевозки, в которых прописала запрет на перевозку роботов в салоне или зарегистрированном багаже вне зависимости от их размера и назначения. Причина банальна — безопасность при перевозке литий-ионных аккумуляторов.
Лёгкой недели 👉✨✨
Product Management & AI
Марк Цукерберг желает всем нам успешной рабочей недели с борта своей новой 87-метровой мегаяхты LAUNCHPAD. По слухам, новая игрушка обошлась Зуку примерно в $300M, что делает её одной из самых дорогих яхт в мире. Морская архитектура – De Voogt Naval Architects.…
Сотрудники Anthropic едут на работу после IPO
Product Management & AI
Subagents vs. Agent Teams: в чём между ними разница + 5 паттернов оркестрации Субагенты – это параллелизм через изоляцию Субагент – это специализированный экземпляр в Claude/ChatGPT, работающий в собственном изолированном окне контекста. Представьте, что…
Что такое циклическая работа ИИ-агентов (agent looping) и открытые/закрытые циклы (по мотивам Anthropic Workshop: Build Agents That Run for Hours)
Последние два года ИИ-агентам давали задания пошагово: одна задача = один промпт. Сейчас этот подход меняется и вместо того чтобы просить ИИ-агента создать условный кусок кода или документ, а затем самому контролировать каждый этап, вы настраиваете цикл, который берёт на себя всё: исследование, планирование, выполнение, проверку и итерации до тех пор, пока цель не будет достигнута.
Её может запустить практически любая платформа для работы с ИИ-агентами; всё зависит от того, как именно вы настроите связи между ними.
В самом простом варианте цикл — это работа агента над собственным результатом:
> проводит исследование
> создает черновик
> сверяет черновик с поставленной целью
> исправляет слабые места
> повторяет цикл, пока результат не начнет соответствовать требованиям
Более масштабный вариант — это циклическая работа целой группы ИИ-агентов. Вы ставите задачу агенту-оркестратору; он разбивает её на части, передает каждую часть профильному агенту, а те, в свою очередь, поручают более мелкие задачи своим субагентам.
Вся эта иерархия продолжает циклически проходить этапы исследования, планирования, выполнения и проверки, пока цель не будет достигнута.
Вы задаете цель, и система выполняет цикл до тех пор, пока работа не будет завершена в соответствии с установленными вами требованиями.
Открытые и закрытые циклы:
ОТКРЫТЫЙ ЦИКЛ носит исследовательский характер. У него есть условия и цель, но вы предоставляете ИИ-агенту или группе агентов широкое пространство для манёвра. Система может пробовать разные пути, делать открытия и создавать то, что вы не описывали в деталях.
Проблема в стоимости – открытый цикл, дающий реальную свободу для исследований, потребляет безумное количество токенов. Для 90% команд, не имеющих неограниченного бюджета, такой подход недоступен, а при работе над проектами с нечёткими стандартами такая Система рискует превратиться в генератор некачественного «мусора».
ЗАКРЫТЫЙ ЦИКЛ имеет чёткие границы в котором ИИ-архитектор сначала проектирует весь маршрут работы:
> ясная цель
> определённые этапы
> проверка на каждом этапе
> точка остановки или возврата результата вам (с передачей данных об эффективности)
Агенты по-прежнему работают циклически, но делают это в рамках созданной вами структуры. С каждым циклом результаты улучшаются, так как каждый этап подпитывает следующий, а затраты остаются в рамках обычного бюджета благодаря чётко выстроенному процессу.
> за цель отвечает архитектор
> за конкретные шаги отвечают специалисты
> узкопрофильные исполнители выполняют частные задачи
> контрольный этап гарантирует качество и исключает небрежность
Последние два года ИИ-агентам давали задания пошагово: одна задача = один промпт. Сейчас этот подход меняется и вместо того чтобы просить ИИ-агента создать условный кусок кода или документ, а затем самому контролировать каждый этап, вы настраиваете цикл, который берёт на себя всё: исследование, планирование, выполнение, проверку и итерации до тех пор, пока цель не будет достигнута.
Циклический процесс — это выстроенная вами Система
Её может запустить практически любая платформа для работы с ИИ-агентами; всё зависит от того, как именно вы настроите связи между ними.
В самом простом варианте цикл — это работа агента над собственным результатом:
> проводит исследование
> создает черновик
> сверяет черновик с поставленной целью
> исправляет слабые места
> повторяет цикл, пока результат не начнет соответствовать требованиям
Более масштабный вариант — это циклическая работа целой группы ИИ-агентов. Вы ставите задачу агенту-оркестратору; он разбивает её на части, передает каждую часть профильному агенту, а те, в свою очередь, поручают более мелкие задачи своим субагентам.
Вся эта иерархия продолжает циклически проходить этапы исследования, планирования, выполнения и проверки, пока цель не будет достигнута.
Вы задаете цель, и система выполняет цикл до тех пор, пока работа не будет завершена в соответствии с установленными вами требованиями.
Открытые и закрытые циклы:
ОТКРЫТЫЙ ЦИКЛ носит исследовательский характер. У него есть условия и цель, но вы предоставляете ИИ-агенту или группе агентов широкое пространство для манёвра. Система может пробовать разные пути, делать открытия и создавать то, что вы не описывали в деталях.
Проблема в стоимости – открытый цикл, дающий реальную свободу для исследований, потребляет безумное количество токенов. Для 90% команд, не имеющих неограниченного бюджета, такой подход недоступен, а при работе над проектами с нечёткими стандартами такая Система рискует превратиться в генератор некачественного «мусора».
ЗАКРЫТЫЙ ЦИКЛ имеет чёткие границы в котором ИИ-архитектор сначала проектирует весь маршрут работы:
> ясная цель
> определённые этапы
> проверка на каждом этапе
> точка остановки или возврата результата вам (с передачей данных об эффективности)
Агенты по-прежнему работают циклически, но делают это в рамках созданной вами структуры. С каждым циклом результаты улучшаются, так как каждый этап подпитывает следующий, а затраты остаются в рамках обычного бюджета благодаря чётко выстроенному процессу.
> за цель отвечает архитектор
> за конкретные шаги отвечают специалисты
> узкопрофильные исполнители выполняют частные задачи
> контрольный этап гарантирует качество и исключает небрежность