Программируем роботов
Помните, я писал, как обстукиваю идеи об AI? Но лучше всего я думаю у доски: рисую стрелки, зачеркиваю, показываю пальцем — «вот тут что-то не сходится». Хочется, чтобы AI участвовал и в этом процессе.
Представляю Робина рядом: видит доску и мои каракули, слышит, что я объясняю, связывает это с тем, что обсуждали раньше. Я меняю схему, а он замечает, как поменялся аргумент.
Имхо, робот тут был бы очень кстати: повернуть камеру туда, где я рисую или на что показываю, а потом повернуться ко мне, когда обсуждаем идею. И показать без слов, что у него есть мысль. Захотелось разобраться, насколько сложно сделать такое.
Мы с Codex поресерчили варианты и нашли Reachy Mini: у него есть Python SDK и симулятор, поэтому можно начать с привычного кода, еще до покупки железа. Собрали демо: по обращению робот поворачивается к доске, кадр с его виртуальной камеры идет в Codex SDK, а модель задает вопрос по увиденному.
На тестовой доске были цель — понять, почему уходят пользователи, и план — выпустить пять новых фич. Агент прочитал записи и спросил, как выпуск фич поможет выяснить причины ухода. В видео — симуляция, на картинке — как хочется, чтобы это выглядело вживую.
В целом, никакого rocket science, дружбан вам поможет с этим справиться. Ключевой вопрос: что именно добавляет физическое присутствие? Например, по повороту головы видно, куда Робин смотрит, а поднятый усик может означать, что у него есть мысль.
Если тоже хотите попробовать, у Reachy есть пошаговые туториалы: движение головы и усиков, камера и звук. А Conversation App можно посмотреть как пример того, как соединить это с LLM.
Помните, я писал, как обстукиваю идеи об AI? Но лучше всего я думаю у доски: рисую стрелки, зачеркиваю, показываю пальцем — «вот тут что-то не сходится». Хочется, чтобы AI участвовал и в этом процессе.
Представляю Робина рядом: видит доску и мои каракули, слышит, что я объясняю, связывает это с тем, что обсуждали раньше. Я меняю схему, а он замечает, как поменялся аргумент.
Имхо, робот тут был бы очень кстати: повернуть камеру туда, где я рисую или на что показываю, а потом повернуться ко мне, когда обсуждаем идею. И показать без слов, что у него есть мысль. Захотелось разобраться, насколько сложно сделать такое.
Мы с Codex поресерчили варианты и нашли Reachy Mini: у него есть Python SDK и симулятор, поэтому можно начать с привычного кода, еще до покупки железа. Собрали демо: по обращению робот поворачивается к доске, кадр с его виртуальной камеры идет в Codex SDK, а модель задает вопрос по увиденному.
На тестовой доске были цель — понять, почему уходят пользователи, и план — выпустить пять новых фич. Агент прочитал записи и спросил, как выпуск фич поможет выяснить причины ухода. В видео — симуляция, на картинке — как хочется, чтобы это выглядело вживую.
В целом, никакого rocket science, дружбан вам поможет с этим справиться. Ключевой вопрос: что именно добавляет физическое присутствие? Например, по повороту головы видно, куда Робин смотрит, а поднятый усик может означать, что у него есть мысль.
Если тоже хотите попробовать, у Reachy есть пошаговые туториалы: движение головы и усиков, камера и звук. А Conversation App можно посмотреть как пример того, как соединить это с LLM.
👍11🔥8❤3🤨1
- Надо терпеть, ты же сильный
- Это все для меня не работает - я сильнее
- Надо просто отвлечься, не обращать внимания
- Не нервничай, это того не стоит
- Это мелочь, перетерпим-перебинтуем
- Как же я устал от этого всего, но я лишь муха, кусающая пятку слона
Возможно, вы или ваш близкий примерно так думает. И теряет вкус к жизни, агентность, не видит света. И может выбрать не самый созидательный путь - не потому что плохой, а потому что слишком хороший и сильный, что не хочет доставлять другим хлопот. И находит свое "решение"
Обратите внимание на них (или себя), не пропускайте мимо! Мы нереально сильны, но даже самым сильным нужен смысл и цель! И близкие, в которых можно уткнуться и расплакаться
обнимаю!
P.S. У меня все отлично - но вдруг у ваших близких по другому?
- Это все для меня не работает - я сильнее
- Надо просто отвлечься, не обращать внимания
- Не нервничай, это того не стоит
- Это мелочь, перетерпим-перебинтуем
- Как же я устал от этого всего, но я лишь муха, кусающая пятку слона
Возможно, вы или ваш близкий примерно так думает. И теряет вкус к жизни, агентность, не видит света. И может выбрать не самый созидательный путь - не потому что плохой, а потому что слишком хороший и сильный, что не хочет доставлять другим хлопот. И находит свое "решение"
Обратите внимание на них (или себя), не пропускайте мимо! Мы нереально сильны, но даже самым сильным нужен смысл и цель! И близкие, в которых можно уткнуться и расплакаться
обнимаю!
P.S. У меня все отлично - но вдруг у ваших близких по другому?
1❤71👍8🔥1🎉1🥱1
EDU
Пора поговорить - в пятницу с 17 по 19мск: После анонса Sign in with ChatGPT я вернулся к своему старому посту и поймал себя на приятном «я же говорил!» :) А потом решил пойти дальше: пересмотреть мысли об AI за последние три года — в постах, выступлениях…
запись встречи https://youtu.be/v6mEfoKTFUU
YouTube
AI за три года: что я пересмотрел | GenAI Update S3E3
Возвращаюсь к своим мыслям об AI за последние три года: что подтвердилось, где я ошибся и какие продуктовые решения теперь принимаю иначе.
Разбираем контекст, AI-плагины, стоимость принятой задачи и организацию работы с агентами — с примерами и возражениями…
Разбираем контекст, AI-плагины, стоимость принятой задачи и организацию работы с агентами — с примерами и возражениями…
🔥13❤3👍1
Сделал продолжение AI Product Engineer —> углубленная версия про то, как:
1) Решать, какому шагу пайплайна нужна большая LLM, а какому хватит маленькой модели, правил или кода, и строить роутинг между ними
2) Учить агента работать с данными, которые не влезают в контекст модели
3) Собирать агентные системы на durable execution
4) Проверять собственного LLM-судью
5) Строить агента, который улучшается сам
6) Внедрять агента у реальных пользователей и измерять его использование
Подробнее тут: https://empatika.com/courses/ai-product-engineer-vol2
1) Решать, какому шагу пайплайна нужна большая LLM, а какому хватит маленькой модели, правил или кода, и строить роутинг между ними
2) Учить агента работать с данными, которые не влезают в контекст модели
3) Собирать агентные системы на durable execution
4) Проверять собственного LLM-судью
5) Строить агента, который улучшается сам
6) Внедрять агента у реальных пользователей и измерять его использование
Подробнее тут: https://empatika.com/courses/ai-product-engineer-vol2
Empatika EDU
Курс AI Product Engineer Vol. 2 - агенты, которым можно делегировать результат, за 6 сессий
Продвинутый курс для тех, кто уже строит AI-агентов: роутинг моделей и снижение затрат, RAG и память, durable execution, аудит LLM-судьи, самоулучшение агента по исправлениям пользователей и внедрение у новых пользователей. 6 сессий, $500-700. Старт 25 октября…
❤14🔥3
Что пилить, когда запилить можно что угодно?
.... или размышления после просмотра выступления Теренса Тао про математику 2.0
И, правда, что тогда пилить? Или делать? Куда направить свое внимание?
Теренс в своем докладе использует интересный подход: он принимает рабочую гипотезу, что
и дальше предлагает порассуждать, что будет с математикой, если гипотеза окажется верной. В итоге приходит к тому, что он назвал Математикой 2.0
В этом же стиле давайте сформулируем нашу гипотезу:
Тогда как изменится мир software продуктов? Мои мысли на этот счет ниже + еще 2 поста в ближайшую неделю
Что такое успех?
Я думаю, что первый вопрос, на который надо ответить: что такое успех в разработке продукта? Продукт работает как надо? Или продукт зарабатывает деньги? Или продуктом пользуется много людей?
Тао в докладе говорит, что в математике доказательства были способом достигать множество коррелирующих целей - решение проблем как таковых, прикладное применение, развитие коммьюнити и тп (лучше посмотрите доклад)
Есть ли такое же в software индустрии? Мне кажется, что да: когда разработка была сложной и дорогой, это создавало стимул заранее разобраться, кому нужен продукт, какую пользу он принесет и за что люди будут платить. Это не гарантировало успеха, но высокая стоимость реализации заставляла серьезнее относиться к вопросу: а зачем мы вообще это делаем? Проблема vs полезная функция 😉
Но если запилить можно что угодно, не вкладывая достаточного количества ресурсов, то работающий продукт может появиться раньше, чем мы выясним, кому и насколько он полезен. Сам факт его создания все меньше говорит о достижении остальных целей...
Тут в тему мой любимый вопрос про разницу между verification и validation:
- verification - продукт работает в соответствии с требованиями
- validation - продукт выполняет ту цель и в тех условиях, которые ставились перед ним
Попробую пояснить: для меня успех продукта определяется тем, скольким людям он улучшил жизнь и насколько сильно. Финансовый результат тоже важен, и он, по-моему, обычно следует из предыдущего определения.
AI все лучше и лучше делает софт, который работает как надо (читай verification) - ну, или точнее, как сформулировал (или оставил на усмотрение AI) этот софт его создатель. НО работающая программа сама по себе еще не гарантирует, что пользователь достигнет нужного результата (validation).
Тогда как же меняется бизнес software продуктов? Очевидно, что:
1) Мы можем делать временный софт - как одноразовые фотоаппараты - под 1 конкретную задачу 1го конкретного юзера. Например, игра для открытого вебинара 😉 И это будет целесообразно. То есть мы можем ожидать длинный хвост продуктов, которых никогда не существовало, как поисковых запросов. И скорее всего в ближайшие годы эти продукты будут скорее писаться на лету (см пост про нейрософт)
2) Мы можем делать больше вариаций одного продукта под разные условия: другой сегмент пользователей, неполнота данных, немного другой процесс. Например, CRM-ку, которую можно подстроить под специфику бизнеса и менять вместо с его [бизнеса] развитием. А не загонять нас и наши сейлз процессы в стандартные рамки и/или заставлять нанимать дорогих консультантов для этой адаптации, при этом повышая нашу зависимость от оных.
Получается, мы можем искать пользу там, где раньше разработка просто не оправдывала затрат - вплоть до одной задачи одного человека.
А как выбирать, какие из этих возможностей стоит пробовать? Как проверять пользу и чему учиться в процессе? Что изменится в самой разработке, какие навыки понадобятся, какие исчезнут, и куда направлять свое внимание? Останется и нужно ли понимание того, что написано? Как изменятся стандарты качества? И чем мы и продукты будем "болеть" в эпоху изобилия кода?
Об этом - в следующих постах.
.... или размышления после просмотра выступления Теренса Тао про математику 2.0
И, правда, что тогда пилить? Или делать? Куда направить свое внимание?
Теренс в своем докладе использует интересный подход: он принимает рабочую гипотезу, что
AI тулы достаточно скоро смогут выполнять существенный набор сложных математических задач с приемлемым уровнем успеха, качества, супервизии и затрат
и дальше предлагает порассуждать, что будет с математикой, если гипотеза окажется верной. В итоге приходит к тому, что он назвал Математикой 2.0
В этом же стиле давайте сформулируем нашу гипотезу:
AI тулы достаточно скоро смогут выполнять значительную часть задач по разработке software продуктов с приемлемым уровнем скорости, качества, супервизии и стоимости
Тогда как изменится мир software продуктов? Мои мысли на этот счет ниже + еще 2 поста в ближайшую неделю
Что такое успех?
Я думаю, что первый вопрос, на который надо ответить: что такое успех в разработке продукта? Продукт работает как надо? Или продукт зарабатывает деньги? Или продуктом пользуется много людей?
Тао в докладе говорит, что в математике доказательства были способом достигать множество коррелирующих целей - решение проблем как таковых, прикладное применение, развитие коммьюнити и тп (лучше посмотрите доклад)
Есть ли такое же в software индустрии? Мне кажется, что да: когда разработка была сложной и дорогой, это создавало стимул заранее разобраться, кому нужен продукт, какую пользу он принесет и за что люди будут платить. Это не гарантировало успеха, но высокая стоимость реализации заставляла серьезнее относиться к вопросу: а зачем мы вообще это делаем? Проблема vs полезная функция 😉
Но если запилить можно что угодно, не вкладывая достаточного количества ресурсов, то работающий продукт может появиться раньше, чем мы выясним, кому и насколько он полезен. Сам факт его создания все меньше говорит о достижении остальных целей...
Тут в тему мой любимый вопрос про разницу между verification и validation:
- verification - продукт работает в соответствии с требованиями
- validation - продукт выполняет ту цель и в тех условиях, которые ставились перед ним
Попробую пояснить: для меня успех продукта определяется тем, скольким людям он улучшил жизнь и насколько сильно. Финансовый результат тоже важен, и он, по-моему, обычно следует из предыдущего определения.
AI все лучше и лучше делает софт, который работает как надо (читай verification) - ну, или точнее, как сформулировал (или оставил на усмотрение AI) этот софт его создатель. НО работающая программа сама по себе еще не гарантирует, что пользователь достигнет нужного результата (validation).
Тогда как же меняется бизнес software продуктов? Очевидно, что:
1) Мы можем делать временный софт - как одноразовые фотоаппараты - под 1 конкретную задачу 1го конкретного юзера. Например, игра для открытого вебинара 😉 И это будет целесообразно. То есть мы можем ожидать длинный хвост продуктов, которых никогда не существовало, как поисковых запросов. И скорее всего в ближайшие годы эти продукты будут скорее писаться на лету (см пост про нейрософт)
2) Мы можем делать больше вариаций одного продукта под разные условия: другой сегмент пользователей, неполнота данных, немного другой процесс. Например, CRM-ку, которую можно подстроить под специфику бизнеса и менять вместо с его [бизнеса] развитием. А не загонять нас и наши сейлз процессы в стандартные рамки и/или заставлять нанимать дорогих консультантов для этой адаптации, при этом повышая нашу зависимость от оных.
Получается, мы можем искать пользу там, где раньше разработка просто не оправдывала затрат - вплоть до одной задачи одного человека.
А как выбирать, какие из этих возможностей стоит пробовать? Как проверять пользу и чему учиться в процессе? Что изменится в самой разработке, какие навыки понадобятся, какие исчезнут, и куда направлять свое внимание? Останется и нужно ли понимание того, что написано? Как изменятся стандарты качества? И чем мы и продукты будем "болеть" в эпоху изобилия кода?
Об этом - в следующих постах.
❤18👍11🔥5
В субботу на AI Sales играли в руководителя отдела продаж: у вас три продавца, CRM, и процесс от холодных продаж через встречи до закрытой сделки. Одно из решений, которое надо было принять - куда, в первую очередь, внедрить AI.
Было 3 варианта:
1) AI SDR —> чтобы в 3 раза получать больше тёплых лидов за те же деньги
2) Агент, который доводит заинтересованного лида до встречи, потому что сейчас лишь 1 из 3х это делает
3) Агент, который разбирает "спящие" сделки, пингует "молчунов", возвращает их.
Не вдаваясь в цифры, которые безусловно сильно влияли на выбор решения, я сделал одну штуку, которая имхо очень жизненная: "подложил" в игру продавца Майка, который постоянно жаловался, что у него 4 часа уходит на пинги по спящим сделкам, и что, мол, за фигня такая.
Не знаю, насколько это повлияло на решение, но большинство решило выбрать именно 3ю опцию.
Например, один из участников так обьяснял свой выбор:
В целом, логика понятная, но в ситуации когда у продавцов было 30+ часов свободного времени - эта информация отражалась на ключевом экране игры + я ее голосом озвучивал - это точно не самое важное решение... Высвободив 4 часа Майку и его коллегам мы точно ничего глобально не изменим. А вот эффективнее доводить лидов до встречи или увеличить исходящие в 3 раза - точно повысило бы результаты отдела.
Прошу не судить строго участников: во-первых, были те, кто голосовал за 2ю опцию, во-вторых - как я уже выше сказал, я специально направлял их внимание не туда.
И вот почему, имхо, это жизненно: я часто вижу, как самые "шумные" отвлекают внимание на не самые важные части системы. Мы, люди, хотим помочь другим людям, спрашиваем у них что болит, и направляем свое внимание туда, зачастую упуская из виду более эффективные рычаги. Приподняться над проблемой, увидеть лес за деревьями, взвешивать важность - очень важный навык, который надо тренировать.
Поэтому хороший вопрос перед автоматизацией не "что мы можем автоматизировать" или "кому сделать жизнь легче", а "какую метрику мы хотим сдвинуть и что ее ограничивает" (привет Голдратт!).
Удачи нам всем!
Было 3 варианта:
1) AI SDR —> чтобы в 3 раза получать больше тёплых лидов за те же деньги
2) Агент, который доводит заинтересованного лида до встречи, потому что сейчас лишь 1 из 3х это делает
3) Агент, который разбирает "спящие" сделки, пингует "молчунов", возвращает их.
Не вдаваясь в цифры, которые безусловно сильно влияли на выбор решения, я сделал одну штуку, которая имхо очень жизненная: "подложил" в игру продавца Майка, который постоянно жаловался, что у него 4 часа уходит на пинги по спящим сделкам, и что, мол, за фигня такая.
Не знаю, насколько это повлияло на решение, но большинство решило выбрать именно 3ю опцию.
Например, один из участников так обьяснял свой выбор:
Высвободим время и встреч должно стать больше.
В целом, логика понятная, но в ситуации когда у продавцов было 30+ часов свободного времени - эта информация отражалась на ключевом экране игры + я ее голосом озвучивал - это точно не самое важное решение... Высвободив 4 часа Майку и его коллегам мы точно ничего глобально не изменим. А вот эффективнее доводить лидов до встречи или увеличить исходящие в 3 раза - точно повысило бы результаты отдела.
Кстати, в реальной жизни нигде вы не увидите обьем свободного времени у сейлзов, но эта уже другая историяПрошу не судить строго участников: во-первых, были те, кто голосовал за 2ю опцию, во-вторых - как я уже выше сказал, я специально направлял их внимание не туда.
И вот почему, имхо, это жизненно: я часто вижу, как самые "шумные" отвлекают внимание на не самые важные части системы. Мы, люди, хотим помочь другим людям, спрашиваем у них что болит, и направляем свое внимание туда, зачастую упуская из виду более эффективные рычаги. Приподняться над проблемой, увидеть лес за деревьями, взвешивать важность - очень важный навык, который надо тренировать.
Поэтому хороший вопрос перед автоматизацией не "что мы можем автоматизировать" или "кому сделать жизнь легче", а "какую метрику мы хотим сдвинуть и что ее ограничивает" (привет Голдратт!).
Удачи нам всем!
👍18❤8🔥3👏1
Что просить у агента, кроме кода?
На AI Natives участник рассказывал, как с помощью AI учился играть в одну из разновидностей покера. Получить расчёт хорошего хода было лишь частью задачи: ему самому надо научиться принимать решения за столом.
Но запомнить тысячи ситуаций и вложенных «если» сложно. Поэтому он с AI выделял понятные правила: сначала определить тип раздачи (одна пара, две пары, без пары), затем пройти несколько шагов для этого типа. Где правило получалось слишком сложным, разбирали примеры. А потом сделали тренажёр: человек выбирает ход, получает объяснение ошибки и чаще встречает ситуации, в которых ошибается.
Это в тему размышлений в посте про изобилие кода. В Математике 2.0 есть две схемы: в одной AI получает решения, обходя человеческое понимание; в другой - помогает это понимание развивать.
В разработке похожая история: пока делаешь фичу, уточняешь требования, замечаешь исключения, узнаёшь что-то о пользователе, или о работе ранее неизвестного тебе модуля. Если эта работа уходит к агенту, понимание уже не обязательно появляется по дороге. Значит, стоит отдельно устроить процесс, в котором мы его приобретаем.
В первом посте был пример одноразового софта —> глубина понимания очевидно зависит от срока жизни продукта, цены ошибки и того, насколько легко всё откатить.
Для игры под один вебинар мне важно понимать правила модели и где она может ввести участников в заблуждение. А масштабирование на миллионы пользователей и архитектура на десять лет ей точно не нужны :)
В CRM, от которой зависят работа команды и данные клиентов, уже важно понимать правила процессов, как обнаружить ошибку и восстановить данные.
На больших задачах я стараюсь получать это понимание по ходу работы агента:
1) Сначала прошу план в виде артефакта, который можно читать и комментировать: варианты, ключевые решения, данные и допущения. Задаю вопросы и оставляю правки до реализации.
2) Проверяю важные допущения. Например, агент с помощью regex-а пытается отлавливать ответы клиента и обновлять CRM.
3) Прошу уменьшить зависимость от неизвестного. Допустим, размер компании не найден: можно оставить «неизвестно», попробовать другой источник или передать человеку. Или вместо regex-ов заюзать jev/decisions api.
4) После реализации прошу отчёт о тесте и прогоне на реальных кейсах: GIF-ки, скриншоты и описание процедуры. Так я вижу, что проверяли и какие сценарии выпали. Например, что сделал агент с лидом, размер компании которого неизвестен? Или «22-го подойдёт?» ещё не значит, что встреча согласована. Разбираем ошибку, уточняем правило, добавляем тест.
Что хочу сделать системнее: часть случаев заранее оставлять за пределами настройки, а потом разбирать расхождения на них. Где ошибся агент, где не хватило данных, а где стоит пересмотреть само правило?
И план, и отчёт мне удобнее оформлять в HTML и оборачивать в артефакт, со схемами и возможностью покрутить сценарии. Особенно удобно и полезно комментировать конкретный кусок документа и получать мгновенную обратную связь или апдейт от дружбана. Антропики публиковали по теме полезное, кстати
Попробуйте на следующей большой задаче попросить два артефакта: план с ключевыми решениями и отчёт о проверках. Выберите одно важное допущение, попросите показать, что изменится, если оно неверно, и проверьте, есть ли этот случай в отчёте.
А потом задайте себе вопрос: улучшилось ли ваше понимание?
На AI Natives участник рассказывал, как с помощью AI учился играть в одну из разновидностей покера. Получить расчёт хорошего хода было лишь частью задачи: ему самому надо научиться принимать решения за столом.
Но запомнить тысячи ситуаций и вложенных «если» сложно. Поэтому он с AI выделял понятные правила: сначала определить тип раздачи (одна пара, две пары, без пары), затем пройти несколько шагов для этого типа. Где правило получалось слишком сложным, разбирали примеры. А потом сделали тренажёр: человек выбирает ход, получает объяснение ошибки и чаще встречает ситуации, в которых ошибается.
Это в тему размышлений в посте про изобилие кода. В Математике 2.0 есть две схемы: в одной AI получает решения, обходя человеческое понимание; в другой - помогает это понимание развивать.
В разработке похожая история: пока делаешь фичу, уточняешь требования, замечаешь исключения, узнаёшь что-то о пользователе, или о работе ранее неизвестного тебе модуля. Если эта работа уходит к агенту, понимание уже не обязательно появляется по дороге. Значит, стоит отдельно устроить процесс, в котором мы его приобретаем.
В первом посте был пример одноразового софта —> глубина понимания очевидно зависит от срока жизни продукта, цены ошибки и того, насколько легко всё откатить.
Для игры под один вебинар мне важно понимать правила модели и где она может ввести участников в заблуждение. А масштабирование на миллионы пользователей и архитектура на десять лет ей точно не нужны :)
В CRM, от которой зависят работа команды и данные клиентов, уже важно понимать правила процессов, как обнаружить ошибку и восстановить данные.
На больших задачах я стараюсь получать это понимание по ходу работы агента:
1) Сначала прошу план в виде артефакта, который можно читать и комментировать: варианты, ключевые решения, данные и допущения. Задаю вопросы и оставляю правки до реализации.
2) Проверяю важные допущения. Например, агент с помощью regex-а пытается отлавливать ответы клиента и обновлять CRM.
3) Прошу уменьшить зависимость от неизвестного. Допустим, размер компании не найден: можно оставить «неизвестно», попробовать другой источник или передать человеку. Или вместо regex-ов заюзать jev/decisions api.
4) После реализации прошу отчёт о тесте и прогоне на реальных кейсах: GIF-ки, скриншоты и описание процедуры. Так я вижу, что проверяли и какие сценарии выпали. Например, что сделал агент с лидом, размер компании которого неизвестен? Или «22-го подойдёт?» ещё не значит, что встреча согласована. Разбираем ошибку, уточняем правило, добавляем тест.
Что хочу сделать системнее: часть случаев заранее оставлять за пределами настройки, а потом разбирать расхождения на них. Где ошибся агент, где не хватило данных, а где стоит пересмотреть само правило?
И план, и отчёт мне удобнее оформлять в HTML и оборачивать в артефакт, со схемами и возможностью покрутить сценарии. Особенно удобно и полезно комментировать конкретный кусок документа и получать мгновенную обратную связь или апдейт от дружбана. Антропики публиковали по теме полезное, кстати
Попробуйте на следующей большой задаче попросить два артефакта: план с ключевыми решениями и отчёт о проверках. Выберите одно важное допущение, попросите показать, что изменится, если оно неверно, и проверьте, есть ли этот случай в отчёте.
А потом задайте себе вопрос: улучшилось ли ваше понимание?
👍12❤3🔥1👏1
Не решается задача? Попробуйте сделать её больше
Смотрел The Rainmaker, и зацепил совет, который один из героев называет «принципом Эйзенхауэра»:
Сетап там такой: юристы ведут дело о смерти пациента в больнице. Есть сведения о других похожих смертях, но суд запрещает использовать документы, которые добыла свидетель (HIPAA и все такое). Кажется, дело зашло в тупик. И, собственно, они применяют этот принцип и решают взять в работу дела других пострадавших семей: представляя их интересы, юристы смогут получить медицинские документы этих пациентов, и тогда показания свидетеля будут приняты в работу.
В ТРИЗ есть похожий ход - цитируя Альтшуллера:
Следом он предлагает сравнить исходную задачу с обходной и выбрать, какую целесообразнее решать.
То есть конечный результат сохраняется, а вот условия, которые мы привыкли считать неизменными, можно пересмотреть. Имхо, в этом и смысл «сделать проблему больше»: включить в рассмотрение то, что мы до этого оставляли за её границами.
У меня недавно был кейс, что изначальная постановка задачи и продуктовый эксперимент, который мы реализовали, не дал ожидаемых результатов. Поэтому, попробовали с дружбаном применить этот метод в 3 шага:
1) Сформулировать конечный результат, пока без привязки к конкретному способу его получить.
2) Выписать, что мы считаем неизменным: кто, когда и как должен действовать. Какие ограничения обязательны, а какие мы сами себе задали?
3) Посмотреть, что можно изменить в соседних процессах, в частях системы или во времени, чтобы получить тот же результат.
Например, возьмём сервис для выставления счетов. Его пользователь отправляет счёт контрагенту, и тому при просмотре счета предлагаем зарегаться —> виральный трафик. Собственно, у нас недостаточно хорошие цифры конверсии, поэтому начинаем крутить кнопочки, тексты, и тп.
Теперь, применим алгоритм выше:
1) Фиксируем результат: больше новых регистраций через счета, которые отправляют существующие пользователи.
2) Замечаем границу нашей постановки: получатель уже открыл страницу счёта, и мы работаем только с его регистрацией — текстами, формой, условиями доступа. Число таких получателей мы пока считаем заданным.
3) Разрешаем себе менять и то, что происходит раньше: как отправитель передаёт счёт контрагенту. Например:
- сделать доставку через сервис стандартным продолжением выпуска любого счёта: отправлять по подтверждённому адресу по умолчанию, оставляя отправителю возможность отказаться или выбрать другой способ.
- добавить альтернативный канал доставки: whatsapp, sms, telegram.
- продолжите список? 😉
Цель прежняя - больше завершённых новых регистраций. Но теперь можно работать ещё и с тем, сколько потенциальных пользователей вообще доберётся до сервиса.
А вот тут скилл по теме этого и других методов ТРИЗ - enjoy!
Смотрел The Rainmaker, и зацепил совет, который один из героев называет «принципом Эйзенхауэра»:
Если не можешь решить проблему, сделай её больше.
Сетап там такой: юристы ведут дело о смерти пациента в больнице. Есть сведения о других похожих смертях, но суд запрещает использовать документы, которые добыла свидетель (HIPAA и все такое). Кажется, дело зашло в тупик. И, собственно, они применяют этот принцип и решают взять в работу дела других пострадавших семей: представляя их интересы, юристы смогут получить медицинские документы этих пациентов, и тогда показания свидетеля будут приняты в работу.
В ТРИЗ есть похожий ход - цитируя Альтшуллера:
Допустим, задача принципиально нерешима; какую другую - более общую - задачу надо тогда решить, чтобы получить требуемый конечный результат?
Следом он предлагает сравнить исходную задачу с обходной и выбрать, какую целесообразнее решать.
То есть конечный результат сохраняется, а вот условия, которые мы привыкли считать неизменными, можно пересмотреть. Имхо, в этом и смысл «сделать проблему больше»: включить в рассмотрение то, что мы до этого оставляли за её границами.
У меня недавно был кейс, что изначальная постановка задачи и продуктовый эксперимент, который мы реализовали, не дал ожидаемых результатов. Поэтому, попробовали с дружбаном применить этот метод в 3 шага:
1) Сформулировать конечный результат, пока без привязки к конкретному способу его получить.
2) Выписать, что мы считаем неизменным: кто, когда и как должен действовать. Какие ограничения обязательны, а какие мы сами себе задали?
3) Посмотреть, что можно изменить в соседних процессах, в частях системы или во времени, чтобы получить тот же результат.
Например, возьмём сервис для выставления счетов. Его пользователь отправляет счёт контрагенту, и тому при просмотре счета предлагаем зарегаться —> виральный трафик. Собственно, у нас недостаточно хорошие цифры конверсии, поэтому начинаем крутить кнопочки, тексты, и тп.
Теперь, применим алгоритм выше:
1) Фиксируем результат: больше новых регистраций через счета, которые отправляют существующие пользователи.
2) Замечаем границу нашей постановки: получатель уже открыл страницу счёта, и мы работаем только с его регистрацией — текстами, формой, условиями доступа. Число таких получателей мы пока считаем заданным.
3) Разрешаем себе менять и то, что происходит раньше: как отправитель передаёт счёт контрагенту. Например:
- сделать доставку через сервис стандартным продолжением выпуска любого счёта: отправлять по подтверждённому адресу по умолчанию, оставляя отправителю возможность отказаться или выбрать другой способ.
- добавить альтернативный канал доставки: whatsapp, sms, telegram.
- продолжите список? 😉
Цель прежняя - больше завершённых новых регистраций. Но теперь можно работать ещё и с тем, сколько потенциальных пользователей вообще доберётся до сервиса.
А вот тут скилл по теме этого и других методов ТРИЗ - enjoy!
20❤35👍6🔥4
Очевидные (и не очень) последствия изобилия кода
Окей, мы поговорили о том, что пилить, если можно запилить что угодно, и как при этом не потерять понимание —> давайте теперь порассуждаем про очевидные и не очень последствия изобилия кода.
Теренс Тао приводит интересную аналогию - изобилие еды - что изобилие всяко лучше, чем дефицит, и мир точно стал лучше. Но оно же привело и к ряду проблем - ожирение, новые заболевания и тп - и нам пришлось адаптироваться к этому. То есть будет и больше апсайда (выгод), и больше даунсайда (проблем). С софтом, имхо, тоже потребуется перестроить многое вокруг производства. Некоторые мысли по теме:
1) Нагрузка на инфраструктуру увеличивается в разы. У нас месячного лимита GitHub Actions стало не хватать, а Anthropic вообще написал свою систему контроля версий Scion : в монорепозиторий вливается 30K+ изменений в день, и архитектура не совсем была готова к нагрузке от always on агентов. Больше кода —> больше сборок, проверок, хранения, пуллов и пушей и тп. Продолжите список элементов инфраструктуры, которые начинают трещать от изобилия кода?
2) Приходится менять процессы проверки и выпуска. Если каждое изменение ждёт человека, очередь растёт вместе с аутпутом агентов. Команда Claude Code уже разрешает мержить часть низкорисковых изменений без обязательного человеческого ревью. Постепенный роллаут и откат - тоже в ту же тему. Если помните, мы как раз разбирали это на Фестивале Фонарей. Какие еще процессы надо поменять, чтобы пожинать плоды AI разработки, и при этом не разломать все к чертям?
3) Неожиданно для меня пришли к выводу, что может появиться целый сервис по удалению софта. Признавайтесь, у кого было так, что после очередного хакатона забыл погасить сервак и потом получил $1000 счет на клауд? :) . Признаться, я иногда сам не помню, где что осталось. При этом полезные старые версии, поддержку которых раньше было экономически нецелесообразно продолжать, теперь вполне можно.
4) Меняется круг конкурентов. Теперь сотрудник нашего лучшего клиента может вполне собрать приемлемое решение на пару с дружбаном. Бухгалтерская или логистическая компания может включить такой софт в свою основную услугу и покрывать стоимость из её дохода. У вендоров появляется целый новый пласт конкурентов с другой экономикой, которому не обязательно зарабатывать на продаже софта. Что тогда такое продукт и его конкурентное преимущество - экспертное знание? данные? ответственность за результат? отношения с регуляторами? бренд? Как это дело обстоит в индустрии производства еды? o__O
5) Выбор софта становится отдельной задачей. Если его предложение вырастет в 10-100 раз, найти подходящее, проверить и встроить в свой процесс тоже будет стоить времени и денег. Стоит ожидать появления эдакого YouTube для приложений, и возможно даже новых Mr. Beast-ов :) А тот, кто помогает выбирать, может получить больше влияния на то, каким продуктам достанутся пользователи.
При этом выбирать и использовать софт будут и агенты. Им тоже нужно найти инструмент, понять, для чего он подходит, вызвать его и проверить результат. Возможно, частью приложений мы будем пользоваться, даже не зная их названий - их будет подбирать дружбан под нашу задачу.
Мой критерий успеха из первого поста не меняется: скольким людям продукт улучшил жизнь и насколько. Но если полезный софт можно собрать самому или получить вместе с другой услугой, польза для клиента уже не обязательно превращается в выручку отдельного софтверного вендора.
Отсюда главный вопрос: если наш клиент сможет сам собрать приемлемый аналог нашего продукта, за что он всё ещё захочет платить нам?
Окей, мы поговорили о том, что пилить, если можно запилить что угодно, и как при этом не потерять понимание —> давайте теперь порассуждаем про очевидные и не очень последствия изобилия кода.
Теренс Тао приводит интересную аналогию - изобилие еды - что изобилие всяко лучше, чем дефицит, и мир точно стал лучше. Но оно же привело и к ряду проблем - ожирение, новые заболевания и тп - и нам пришлось адаптироваться к этому. То есть будет и больше апсайда (выгод), и больше даунсайда (проблем). С софтом, имхо, тоже потребуется перестроить многое вокруг производства. Некоторые мысли по теме:
1) Нагрузка на инфраструктуру увеличивается в разы. У нас месячного лимита GitHub Actions стало не хватать, а Anthropic вообще написал свою систему контроля версий Scion : в монорепозиторий вливается 30K+ изменений в день, и архитектура не совсем была готова к нагрузке от always on агентов. Больше кода —> больше сборок, проверок, хранения, пуллов и пушей и тп. Продолжите список элементов инфраструктуры, которые начинают трещать от изобилия кода?
2) Приходится менять процессы проверки и выпуска. Если каждое изменение ждёт человека, очередь растёт вместе с аутпутом агентов. Команда Claude Code уже разрешает мержить часть низкорисковых изменений без обязательного человеческого ревью. Постепенный роллаут и откат - тоже в ту же тему. Если помните, мы как раз разбирали это на Фестивале Фонарей. Какие еще процессы надо поменять, чтобы пожинать плоды AI разработки, и при этом не разломать все к чертям?
3) Неожиданно для меня пришли к выводу, что может появиться целый сервис по удалению софта. Признавайтесь, у кого было так, что после очередного хакатона забыл погасить сервак и потом получил $1000 счет на клауд? :) . Признаться, я иногда сам не помню, где что осталось. При этом полезные старые версии, поддержку которых раньше было экономически нецелесообразно продолжать, теперь вполне можно.
4) Меняется круг конкурентов. Теперь сотрудник нашего лучшего клиента может вполне собрать приемлемое решение на пару с дружбаном. Бухгалтерская или логистическая компания может включить такой софт в свою основную услугу и покрывать стоимость из её дохода. У вендоров появляется целый новый пласт конкурентов с другой экономикой, которому не обязательно зарабатывать на продаже софта. Что тогда такое продукт и его конкурентное преимущество - экспертное знание? данные? ответственность за результат? отношения с регуляторами? бренд? Как это дело обстоит в индустрии производства еды? o__O
5) Выбор софта становится отдельной задачей. Если его предложение вырастет в 10-100 раз, найти подходящее, проверить и встроить в свой процесс тоже будет стоить времени и денег. Стоит ожидать появления эдакого YouTube для приложений, и возможно даже новых Mr. Beast-ов :) А тот, кто помогает выбирать, может получить больше влияния на то, каким продуктам достанутся пользователи.
При этом выбирать и использовать софт будут и агенты. Им тоже нужно найти инструмент, понять, для чего он подходит, вызвать его и проверить результат. Возможно, частью приложений мы будем пользоваться, даже не зная их названий - их будет подбирать дружбан под нашу задачу.
Мой критерий успеха из первого поста не меняется: скольким людям продукт улучшил жизнь и насколько. Но если полезный софт можно собрать самому или получить вместе с другой услугой, польза для клиента уже не обязательно превращается в выручку отдельного софтверного вендора.
Отсюда главный вопрос: если наш клиент сможет сам собрать приемлемый аналог нашего продукта, за что он всё ещё захочет платить нам?
1🔥24❤2👍2😁1
EDU
Наука управления агентами? Недавно на AI Natives рассказывал, как я изучаю bias-ы агентов, чтобы дизайнить интересные задачки, в которых излишнее доверие агентам приводит к плохим выводам. А Илья К. пошутил: мол, вместо курса по системному мышлению мне надо…
В пятницу, собственно, поговорим про команды агентов: когда их применять и как координировать
https://luma.com/bqh7rac1
https://luma.com/bqh7rac1
Luma
Один агент или команда: как довести задачу до результата · Zoom · Luma
Когда с задачей лучше справится один AI-агент, а когда стоит собрать команду? И как организовать её работу, чтобы самому не тратить всё время на координацию и…
❤8🔥4👍3🙏1
Кто проверяет вашего LLM-судью?
Разбирали недавно учебный кейс: один агент пишет статьи для базы знаний по мотивам обращений в саппорт, а LLM-as-a-judge оценивает, можно ли их публиковать.
Одной статье судья поставил 5 из 5. Она уверенно сообщала, что у продукта нет определённой функции. Но документация об этом молчала: правильным действием было направить клиента в поддержку за уточнением.
Оказалось, судья читал только саму статью. Ни документации, ни исходных обращений клиентов он не видел. Откуда ему было знать, что уверенное «нет» взялось из отсутствия информации?
У меня похожие ситуации возникали с проверками кода: агент говорил, что всё готово, а на вопрос «ты это запускал?» отвечал, что нет. В итоге в CLAUDE.md появилось правило:
После этого стало находиться много проблем, которые до этого оставались незамеченными.
В свежей работе про Interaction-as-a-Judge похожая идея: судье давали не только код приложения, но и запись взаимодействия с ним. Пример требования из статьи: Марио должен побеждать противника, прыгая на него. Судья видит действия и их результат в игре. На их наборах задач это помогало точнее проверять выполнение требований.
У Карпатого в лекции была тоже наглядная иллюстрация: GPT по просьбе изображает Linux-терминал с выводом команд, хотя реального выполнения за этим текстом нет. И если LLM судья видит лишь этот текст, то может принять выполнение за чистую монетку.
Имхо, с судьёй важно так же разбираться: что именно он проверил и на основании чего? Особенно если по его оценкам мы выбираем модель, меняем промпт или разрешаем агенту самому себя улучшать.
Anthropic в своём прошлогоднем гайде по эвалам тоже рекомендует проверять самого проверяющего: калибровать LLM-судей по оценкам экспертов и разбирать расхождения, в том числе случаи, когда судья бракует корректное решение. Вот с чего можно начать аудит своего судьи:
1. Взять реальные результаты агента и разметить вслепую: скрыть названия моделей и версий, не смотреть на вердикты судьи. Зафиксировать, что принимаем, что отклоняем и почему. Если не хватает знаний предметной области, здесь нужен человек, у которого они есть.
2. Сопоставить решения. Где судья пропускает плохой результат, а где бракует хороший? Посмотреть отдельно на разные типы задач и ошибок: например, статьи, для которых в документации есть ответ, и те, где его нет. Общая высокая оценка может скрывать провал именно во второй группе.
3. Разобрать расхождения. Судье не хватило источников? Критерий был размыт? Он принял отчёт агента о проверке за свидетельство её выполнения? Или мы сами только на примере поняли, что хотим считать хорошим результатом?
4. Поправить проверку и испытать её на других случаях. Если исправлять судью и проверять улучшение на одних и тех же примерах, легко подогнать его под знакомые ответы.
Кстати, одно из лучших пособий по тому, как разбирать ошибки моделей, вышедшее еще до эры chatgpt - Andrew Ng-овское Machine Learning Yearning. Идеи и подходы актуальны и сейчас
На AI Product Engineer Vol.2, стартующем в выходные, этому как раз посвящена отдельная сессия: аудит судьи по ручной разметке, поиск слепых зон и повторная оценка решения, которое мы раньше приняли по его вердиктам. Возможно, «лучшая» модель или архитектура после такой проверки окажется уже не лучшей.
Разбирали недавно учебный кейс: один агент пишет статьи для базы знаний по мотивам обращений в саппорт, а LLM-as-a-judge оценивает, можно ли их публиковать.
Одной статье судья поставил 5 из 5. Она уверенно сообщала, что у продукта нет определённой функции. Но документация об этом молчала: правильным действием было направить клиента в поддержку за уточнением.
Оказалось, судья читал только саму статью. Ни документации, ни исходных обращений клиентов он не видел. Откуда ему было знать, что уверенное «нет» взялось из отсутствия информации?
У меня похожие ситуации возникали с проверками кода: агент говорил, что всё готово, а на вопрос «ты это запускал?» отвечал, что нет. В итоге в CLAUDE.md появилось правило:
When I ask you to test something - especially "from the user's / student's POV" - actually RUN and USE the real artifacts the person would touch: execute every skill/command, click through every prototype/link, follow every exercise end-to-end, open every deck/video/file. Do NOT just read, summarize, or reason about them.
После этого стало находиться много проблем, которые до этого оставались незамеченными.
В свежей работе про Interaction-as-a-Judge похожая идея: судье давали не только код приложения, но и запись взаимодействия с ним. Пример требования из статьи: Марио должен побеждать противника, прыгая на него. Судья видит действия и их результат в игре. На их наборах задач это помогало точнее проверять выполнение требований.
У Карпатого в лекции была тоже наглядная иллюстрация: GPT по просьбе изображает Linux-терминал с выводом команд, хотя реального выполнения за этим текстом нет. И если LLM судья видит лишь этот текст, то может принять выполнение за чистую монетку.
Имхо, с судьёй важно так же разбираться: что именно он проверил и на основании чего? Особенно если по его оценкам мы выбираем модель, меняем промпт или разрешаем агенту самому себя улучшать.
Anthropic в своём прошлогоднем гайде по эвалам тоже рекомендует проверять самого проверяющего: калибровать LLM-судей по оценкам экспертов и разбирать расхождения, в том числе случаи, когда судья бракует корректное решение. Вот с чего можно начать аудит своего судьи:
1. Взять реальные результаты агента и разметить вслепую: скрыть названия моделей и версий, не смотреть на вердикты судьи. Зафиксировать, что принимаем, что отклоняем и почему. Если не хватает знаний предметной области, здесь нужен человек, у которого они есть.
2. Сопоставить решения. Где судья пропускает плохой результат, а где бракует хороший? Посмотреть отдельно на разные типы задач и ошибок: например, статьи, для которых в документации есть ответ, и те, где его нет. Общая высокая оценка может скрывать провал именно во второй группе.
3. Разобрать расхождения. Судье не хватило источников? Критерий был размыт? Он принял отчёт агента о проверке за свидетельство её выполнения? Или мы сами только на примере поняли, что хотим считать хорошим результатом?
4. Поправить проверку и испытать её на других случаях. Если исправлять судью и проверять улучшение на одних и тех же примерах, легко подогнать его под знакомые ответы.
Кстати, одно из лучших пособий по тому, как разбирать ошибки моделей, вышедшее еще до эры chatgpt - Andrew Ng-овское Machine Learning Yearning. Идеи и подходы актуальны и сейчас
На AI Product Engineer Vol.2, стартующем в выходные, этому как раз посвящена отдельная сессия: аудит судьи по ручной разметке, поиск слепых зон и повторная оценка решения, которое мы раньше приняли по его вердиктам. Возможно, «лучшая» модель или архитектура после такой проверки окажется уже не лучшей.
❤14👍1🔥1👏1😁1🙏1💯1
EDU
В пятницу, собственно, поговорим про команды агентов: когда их применять и как координировать https://luma.com/bqh7rac1
Запись встречи:
00:00 Коротко о встрече
00:28 Один агент или команда
01:58 Где участники используют команды
05:19 Отдельный контекст и независимая проверка
08:50 Параллельность и разные модели
11:45 Как наблюдать и проверять агента
16:12 Затраты на координацию
21:15 Передача контекста и кэш
31:01 Передавать данные без пересказа
37:03 Три задачи: один агент или команда
48:16 Учебный инцидент: оплата есть, бронь отклонена
58:10 Шесть источников и правило бронирования
1:07:28 Предсказываем семь результатов
1:19:43 Выбираем способ работы A, B или C
1:34:19 Запуск команды C
1:40:56 Запуск одного агента A
1:44:59 Сравниваем ответы, время и токены
1:47:51 Цена ошибки и стоимость выбора
2:04:53 Исследования и вопросы аудитории
2:11:29 Вывод и завершение
https://youtu.be/pjeFT_yhe80?si=EhnkV-ec7yi8ZDAQ
P.S. Если тема актуальна, то вы знаете что делать
00:00 Коротко о встрече
00:28 Один агент или команда
01:58 Где участники используют команды
05:19 Отдельный контекст и независимая проверка
08:50 Параллельность и разные модели
11:45 Как наблюдать и проверять агента
16:12 Затраты на координацию
21:15 Передача контекста и кэш
31:01 Передавать данные без пересказа
37:03 Три задачи: один агент или команда
48:16 Учебный инцидент: оплата есть, бронь отклонена
58:10 Шесть источников и правило бронирования
1:07:28 Предсказываем семь результатов
1:19:43 Выбираем способ работы A, B или C
1:34:19 Запуск команды C
1:40:56 Запуск одного агента A
1:44:59 Сравниваем ответы, время и токены
1:47:51 Цена ошибки и стоимость выбора
2:04:53 Исследования и вопросы аудитории
2:11:29 Вывод и завершение
https://youtu.be/pjeFT_yhe80?si=EhnkV-ec7yi8ZDAQ
P.S. Если тема актуальна, то вы знаете что делать
🔥15❤5👍2
Фрагмент встречи про оптимизацию затрат на LLM пайплайны и AI агентов - enjoy!
00:00 Код, кэш и реальные замеры
00:21 Lead Scout: бизнес-задача
01:52 Onsa: какую работу можно убрать
08:47 Перенос идеи на Lead Scout
15:53 Качество, скорость и полная стоимость
21:24 Prompt caching: стабильный префикс
25:25 Компактный output
33:26 До эксперимента: ожидаемый эффект и границы
35:16 Кэш: проверяем реальные usage и стоимость
39:23 Компактный input: замер и проверка
42:54 Почему кэш не сработал
43:10 Что проверять в своём агенте
https://www.youtube.com/watch?v=ccmlQoVLxRc
00:00 Код, кэш и реальные замеры
00:21 Lead Scout: бизнес-задача
01:52 Onsa: какую работу можно убрать
08:47 Перенос идеи на Lead Scout
15:53 Качество, скорость и полная стоимость
21:24 Prompt caching: стабильный префикс
25:25 Компактный output
33:26 До эксперимента: ожидаемый эффект и границы
35:16 Кэш: проверяем реальные usage и стоимость
39:23 Компактный input: замер и проверка
42:54 Почему кэш не сработал
43:10 Что проверять в своём агенте
https://www.youtube.com/watch?v=ccmlQoVLxRc
🔥6❤2👍1👏1
Такой маленький лайфхак, прилично повышающий удовольствие от прослушивания NotebookLM подкастов: попросите дружбана написать промпт при генерации подкаста для того, чтобы задать контекст (см. отрывок ниже). Особенно интересен эффект, когда хосты называют твое имя, обращаются к тебе, дают рекомендации
Create an ENGLISH two-host Deep Dive, using Long length. Audience: Bayram, a practitioner and teacher preparing to remember consequential GenAI developments for quarterly discussions. This is the October 23, 2026 edition, new material since the completed October 15 edition. Use briefing-verified.md as the editorial spine and original sources for evidence. Explain mechanisms in plain spoken English; do not read a link list or promote courses. Open with the question: when does more agent activity become more verified value?
....
Throughout, connect to PUBLIC writing on one agent versus teams, abundant code moving bottlenecks, preserving understanding and auditing judges, and the refreshed public course topics: engineering/harnesses, model routing/cost, memory/durable execution, judge audit, team skills, Personal OS delegation, measured sales/analyst outcomes, founder economics and systems feedback
❤8😁2
В январе я рассказывал, как юзаю Claude Code —> в пятницу сделаем апдейт
Обсудим в пятницу: https://luma.com/i1i4k9qq
Обсудим в пятницу: https://luma.com/i1i4k9qq
Luma
How I AI — Oct 2026 Update · Zoom · Luma
Как я использую AI в работе и жизни — на реальных задачах.
В январе я показывал, как работаю с Claude Code. С тех пор в моей практике появились новые…
В январе я показывал, как работаю с Claude Code. С тех пор в моей практике появились новые…
🔥23❤10👍2😁2
Как понять, что агент умеет делать продукт?
В первом посте про изобилие кода мы приняли рабочую гипотезу:
Как выяснить, какую часть этой работы уже можно отдавать агентам?
Окей, мы с вами знаем, что писать код они могут. Но при этом всем нам очевидно, что создать продукт это не только про написать код. Собственно в эту тему прикольный новый бенчмарк/среда для оценки того, насколько агенты могут понимать проблему, взаимодействовать со стейкхолдерами, принимать продуктовые решения и тп.
FDE-Gym - 95 задач на основе 20 сценариев внедрения AI. Агент получает запрос заказчика, существующий код, документы и историю работы системы. Можно задавать вопросы виртуальным сотрудникам, выяснять ограничения, менять и проверять систему. Запрос при этом может предлагать решение, которое не поможет достичь цели.
Результат оценивают по изменению бизнес-метрики внутри симуляции, с учётом нарушений и стоимости общения с сотрудниками. Уточнить всё у всех тоже не бесплатная стратегия :)
Если посмотреть, как frontier модели справляются с задачками из этого бенча, то более всего они лажают, когда ограничения приходилось выяснять самостоятельно, а не было задано заранее. Причем даже получение всех ключевых фактов не гарантировало хорошего результата. Очень жизненно имхо.
Это, по моему мнению, еще и про насмотренность: знать, куда смотреть, кого спрашивать, и при этом не особо их раздражать :)
Мы с дружбаном тоже попробовали один из общедоступных кейсов: ночного AI-дежурного, который должен уменьшить число ненужных пробуждений инженеров и ускорить устранение инцидентов. Получилось не очень, хотя я и не согласен с оценкой, но это уже другая история. Сама идея мне очень понравилась и, разумеется, отозвалась с моими постами про симуляции и Frontier Academy
Из таких экспериментов имхо могла бы вырасти общая коллекция кейсов и разборов: какую работу получается делегировать, какая информация нужна агенту, где окупается участие человека?
Разумеется, здесь мы пока измеряем пользу внутрисферического коня в вакууме симуляции; перенос в реальный мир ещё нужно проверять. Реальная компания - это гораздо более сложная (complex) и адаптивная система: она взаимодействует с клиентами и конкурентами, а люди учатся и меняют поведение в ответ на наши решения и действия друг друга. Внедрение продукта само меняет условия, в которых мы проверяем его пользу, и такие эффекты сложнее уложить в симуляции. Но тем не менее я считаю, что это уже лучше, чем ничего
К примеру, я сейчас работаю над одной симуляцией - небольшой тизер тут в первом комментарии. Сыграли бы в такое?
В первом посте про изобилие кода мы приняли рабочую гипотезу:
AI сможет выполнять значительную часть задач по разработке продуктов с приемлемым качеством, стоимостью и супервизией.
Как выяснить, какую часть этой работы уже можно отдавать агентам?
Окей, мы с вами знаем, что писать код они могут. Но при этом всем нам очевидно, что создать продукт это не только про написать код. Собственно в эту тему прикольный новый бенчмарк/среда для оценки того, насколько агенты могут понимать проблему, взаимодействовать со стейкхолдерами, принимать продуктовые решения и тп.
FDE-Gym - 95 задач на основе 20 сценариев внедрения AI. Агент получает запрос заказчика, существующий код, документы и историю работы системы. Можно задавать вопросы виртуальным сотрудникам, выяснять ограничения, менять и проверять систему. Запрос при этом может предлагать решение, которое не поможет достичь цели.
Результат оценивают по изменению бизнес-метрики внутри симуляции, с учётом нарушений и стоимости общения с сотрудниками. Уточнить всё у всех тоже не бесплатная стратегия :)
Если посмотреть, как frontier модели справляются с задачками из этого бенча, то более всего они лажают, когда ограничения приходилось выяснять самостоятельно, а не было задано заранее. Причем даже получение всех ключевых фактов не гарантировало хорошего результата. Очень жизненно имхо.
Это, по моему мнению, еще и про насмотренность: знать, куда смотреть, кого спрашивать, и при этом не особо их раздражать :)
Мы с дружбаном тоже попробовали один из общедоступных кейсов: ночного AI-дежурного, который должен уменьшить число ненужных пробуждений инженеров и ускорить устранение инцидентов. Получилось не очень, хотя я и не согласен с оценкой, но это уже другая история. Сама идея мне очень понравилась и, разумеется, отозвалась с моими постами про симуляции и Frontier Academy
Из таких экспериментов имхо могла бы вырасти общая коллекция кейсов и разборов: какую работу получается делегировать, какая информация нужна агенту, где окупается участие человека?
Разумеется, здесь мы пока измеряем пользу внутри
К примеру, я сейчас работаю над одной симуляцией - небольшой тизер тут в первом комментарии. Сыграли бы в такое?