15541
Мои мысли про стартапы и продукты. Байрам Аннаков, фаундер and CEO onsa.ai - автоматизация B2B продаж Мой YouTube: https://www.youtube.com/BaykaAnnakov Мой LinkedIn: https://linkedin.com/in/bayramannakov
Запись встречи - enjoy! youtube.com/watch?v=CKicV_syHMM&feature=youtu.be
Главы:
00:00 Приветствие и что изменилось у участников
05:04 Январь → октябрь: что изменилось в моей работе
08:06 Новые навыки: чистая среда, followthrough и персонализация
14:09 Правила, которые появились после ошибок
20:11 Карта задач: где я использую AI
25:42 Петля: контекст → попытка → проверка → исправление
26:42 Навыки и подключенные инструменты за картой
31:12 Независимые рецензенты и проверка чужих отчетов
34:14 HTML и точечные комментарии к артефакту
39:14 Еженедельный обзор и аномалии в отчете
44:17 Clean-slate: проверить навык на машине участника
51:48 Модель и harness простыми словами
57:49 Что происходит после вебинара
1:00:18 Как рождается пост: живая переписка в Codex
1:07:50 Робототехника: метрики не заменяют любопытство
1:13:22 FDE-Gym: исследование и исправления автора
1:16:53 Followthrough: вернуться и измерить эффект
1:19:23 Затраты GCP, теневой режим и решение о включении
1:22:54 Четыре модификации Claude Code
1:27:55 Голос и обучение: Lean, вопросы и эксперименты
1:32:55 Игра, чтобы разобраться в пенсионном фонде
1:34:56 Персонализированный NotebookLM и сбор источников
1:36:27 Какой процесс попробовать после встречи
1:37:57 Robin и следующий шаг к постоянно работающему агенту
1:44:51 Вопрос: как координировать несколько агентов
1:46:26 Ответ: пока исследование, а не готовая лучшая практика
Одиночество фаундера 2.0?
Как-то писал здесь про одиночество руководителя. Кажется, у этой темы появляется новая версия: если всё больше работы можно сделать с агентами, как меняется само ощущение от работы?
В недавнем разговоре у Лекса Фридмана Анкур Мойтра сформулировал интересное чувство:
So I feel very excited, but maybe more intellectually lonely than I felt before.
Такой маленький лайфхак прилично улучшающий удовольствие от прослушивания 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
Запись встречи:
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. Если тема актуальна, то вы знаете что делать
В пятницу, собственно, поговорим про команды агентов: когда их применять и как координировать
https://luma.com/bqh7rac1
Не решается задача? Попробуйте сделать её больше
Смотрел The Rainmaker, и зацепил совет, который один из героев называет «принципом Эйзенхауэра»:
Если не можешь решить проблему, сделай её больше.
Допустим, задача принципиально нерешима; какую другую - более общую - задачу надо тогда решить, чтобы получить требуемый конечный результат?
В субботу на AI Sales играли в руководителя отдела продаж: у вас три продавца, CRM, и процесс от холодных продаж через встречи до закрытой сделки. Одно из решений, которое надо было принять - куда, в первую очередь, внедрить AI.
Было 3 варианта:
1) AI SDR —> чтобы в 3 раза получать больше тёплых лидов за те же деньги
2) Агент, который доводит заинтересованного лида до встречи, потому что сейчас лишь 1 из 3х это делает
3) Агент, который разбирает "спящие" сделки, пингует "молчунов", возвращает их.
Не вдаваясь в цифры, которые безусловно сильно влияли на выбор решения, я сделал одну штуку, которая имхо очень жизненная: "подложил" в игру продавца Майка, который постоянно жаловался, что у него 4 часа уходит на пинги по спящим сделкам, и что, мол, за фигня такая.
Не знаю, насколько это повлияло на решение, но большинство решило выбрать именно 3ю опцию.
Например, один из участников так обьяснял свой выбор:
Высвободим время и встреч должно стать больше.
Кстати, в реальной жизни нигде вы не увидите обьем свободного времени у сейлзов, но эта уже другая история
Сделал продолжение AI Product Engineer —> углубленная версия про то, как:
1) Решать, какому шагу пайплайна нужна большая LLM, а какому хватит маленькой модели, правил или кода, и строить роутинг между ними
2) Учить агента работать с данными, которые не влезают в контекст модели
3) Собирать агентные системы на durable execution
4) Проверять собственного LLM-судью
5) Строить агента, который улучшается сам
6) Внедрять агента у реальных пользователей и измерять его использование
Подробнее тут: https://empatika.com/courses/ai-product-engineer-vol2
- Надо терпеть, ты же сильный
- Это все для меня не работает - я сильнее
- Надо просто отвлечься, не обращать внимания
- Не нервничай, это того не стоит
- Это мелочь, перетерпим-перебинтуем
- Как же я устал от этого всего, но я лишь муха, кусающая пятку слона
Возможно, вы или ваш близкий примерно так думает. И теряет вкус к жизни, агентность, не видит света. И может выбрать не самый созидательный путь - не потому что плохой, а потому что слишком хороший и сильный, что не хочет доставлять другим хлопот. И находит свое "решение"
Обратите внимание на них (или себя), не пропускайте мимо! Мы нереально сильны, но даже самым сильным нужен смысл и цель!
обнимаю!
P.S. У меня все отлично - но вдруг у ваших близких по другому?
Наука управления агентами?
Недавно на AI Natives рассказывал, как я изучаю bias-ы агентов, чтобы дизайнить интересные задачки, в которых излишнее доверие агентам приводит к плохим выводам. А Илья К. пошутил: мол, вместо курса по системному мышлению мне надо сделать такой же по агентному :)
И вообще-то этот коммент по делу: менеджмент как наука сложился для эффективной координации людей ради достижения цели, но уже очевидно, что мы всё чаще будем организовывать для этого агентов. Тогда какой может быть эта наука и на какие вопросы она будет отвечать?
Начну с задачки, которая возникает у любого, кто имеет дело с организацией агентов: один агент vs команда? Когда эффективнее использовать одно или другое? Например, в уже упомянутом видео с Noam Brown он говорит, что пока совсем неочевидно, что рой агентов справляется с задачкой лучше/дешевле. Но на подходящих задачах может делать это быстрее, потому что работа параллелизируется.
То есть соображение скорости имеет место быть. Но я считаю, что это не только про скорость: из-за принципов работы LLM они подвержены зависимости от пути (писал об этом тут) и могут сузить пространство поиска решения. А вот несколько агентов могут независимо исследовать разные направления, то есть группы нужны ещё и поэтому. И, разумеется, размер контекстного окна никто не отменял.
Вообще наверняка кто-нибудь выведет некоторую зависимость, а-ля треугольник проджект-менеджмента, между скоростью, стоимостью и качеством решения задачи агентами.
В эту тему мне зашла статья Google Research про систему Cogentic. Там задачку эффективной координации агентов для решения математических задач решают следующим образом:
1. Оркестратор распределяет направления ресерча. Затем одни агенты - provers - предлагают доказательства, а другие проверяют оные.
2. История всех попыток хранится отдельно от проверенных результатов. Агенты видят, что уже пробовали и почему не сработало, а проверенные находки используют в следующих итерациях.
3. Есть агент-эдвайзер, который наблюдает за процессом, повторяющимися ошибками и неэффективностями агентов и советует, как реорганизовать процесс.
Мне лично подобный многоагентный процесс интересен в контексте задачи роста продукта: анализ метрик продукта, поведения пользователей, ограничений роста и потерь в воронке, ревью литературы, поиск и реализация экспериментов, фиксация результатов, в том числе неудачных, и повторный проход.
Да, проверка экспериментов на юзерах требует времени и трафика, поэтому процесс не будет таким динамичным, как хотелось бы. Но точно можно организовать постоянное экспериментирование и улучшение продукта.
В общем, как считаете - будет ли новая наука?
P.S. тут ещё подумал: в некоторых экспериментах агенты уже вырабатывают свои языки, потому что человеческий не так эффективен. Так что, возможно, желание человека всё это читать и понимать само станет причиной неэффективности в координации :)
Отрывок из 1го эпизода курса по системному мышлению - на этот раз управляли водой в городе :)
https://youtu.be/pf5EzF7qQno
Запись стрима про продуктовую аналитику
Байрам разбирает продуктовую аналитику с AI на реальном кейсе.
Ситуация: sign-up выросли в 2 раза, активация на 70%, а выручка упала. Почему?
Участники вебинара вместе с Байрамом анализируют данные продукта Grantly (AI-система для поиска грантов) с помощью Claude Opus 5 — и в процессе вскрывают ключевые ограничения AI в аналитике.
Что внутри:
— Живой анализ кейса: кто находит проблему быстрее — человек или AI?
— Парадокс Симпсона: как новый канал (Directory Strategy) сломал все метрики роста
— Почему AI констатирует факты, но избегает рекомендаций — и в чём причина на уровне архитектуры
— Как AI уцепляется за первую гипотезу и ведёт анализ только в одну сторону (path dependence)
— Почему AI не ставит под сомнение постановку вопроса
— Как кросс-проверка другой моделью улучшает качество анализа
— Решение: multi-agent workflow — оркестратор, независимые агенты, верификация
— Скилл why-tree: как структурированный workflow меняет качество продуктового анализа
— Итог: где роль AI, а где — неизбежно человек
Сегодня день рождения Анатолия, моего руководителя в VDI/EPAM, и ментора потом.
Попробовал сформулировать 3 урока, что он мне «показал»:
1) В sales презентации не должно быть х**ни (сейчас назвали бы AI слопа). Как он беспощадно разнес мою первую презу по продаже выделенного офиса разработки для крупной нефтяной компании. Мне полезно до сих пор. Будто у него внутри была чуйка на фигню, на «корпоративные плейсхолдеры», на офисспик. Знаете, вот когда слайд ради слайда, а не чтобы «гвозди забить в успешную сделку»
2) Что по почте не продают. Что [b2b] продажа это синхронное действие. У тебя должна быть возможность: задавать вопросы, показывать другие стороны вопроса, парировать, и иногда молча игнорировать. Помню как нас незаслуженно расстреливали на одном митинге, я не понимал, почему он молчит, ведь это неправда и несправедливо! После митинга он мне пояснил, и все встало на свои места, хоть и в моей (и его!) картине мира было несправедливо.
3) Что любой руководитель должен защищать своих подопечных перед клиентами/другими отделами: как-то в сапсане он мне рассказал, как на самом деле выглядел мой уход из Epam Systems, как люди были убеждены, что я никогда не уйду, как непросто ему было, когда я ушел с его проекта, но что он, как то признался он, внутри понимал, что я сделал верно, выбрав свой собственный бизнес.
Большинство из вас наверное не знает его, посмотрите видео, там плотность мудрости на минуты видео имхо зашкаливает.
Анатолий, с днем рождения Вас!
Качаем свой AEO
В продолжение тематики AEO (answer engine optimization; еще иногда AIEO - AI engine optimization; писал про это тут и тут) свежее интервью у Ленни - основные советы помимо классических SEO советов, некоторые я знал и мы уже стали воплощать в жизнь, а вот некоторые - реально новое:
1) В AEO люди задают более детальные вопросы, чем в Google: 25 слов vs 6.
2) Вопросы - ключевое, поэтому:
- просим LLM превратить наши и конкурентов кейворды в вопросы
- просим LLM нагенерить вопросы по вашей теме/сайту
- смотрим какие вопросы задают в транскриптах sales звонков и их добавляем в список - ну, вы знаете да, к кому за этим прийти? 😉
3) Настраиваем мониторинг упоминаний в AI:
- есть такие уже: от Graphite - их фаундер на подкасте как раз; я запустил ресерч у chatGPT, Claude и Gemini + сделал NotebookLM по всем сразу - enjoy
- замеряем share of voice
- смотрим LLM, популярные у ваших клиентов/гео
4) Изучаем конкурентов:
- а кто сейчас появляется по вашим релевантным вопросам?
- категоризируем их (youtube, reddit, etc) и измеряем какой тип контента более подходит вашей ЦА
5) Оптимизируем лендинги так, чтобы они отвечали на первоначальный и фоллоуап вопросы
- важно: faq/help переводим с субдоменов в субдиректории
6) Оптимизируем цитирование:
- снимаем видео —> вы поняли да, почему я делаю подобные вебинары?
- отвечаем на reddit, делаем аутентично, от своего имени и компании
- если есть бюджет, то платим авторитетным СМИ (forbes, business insider, etc.)
7) И по традиции уже: сделал промпт для AI коуча по AEO на основе этого материала
P.S. Кстати, мы сейчас активно копаем в эту тему, так как она тангенциально связана с темой B2B продаж (что подтверждает пункт 2), поэтому если вам актуально и вы работаете на западный рынок, то напишите в личку или на bayram@onsa.ai
AI и свобода ПЕРЕДУМАТЬ
Прочитал мини-эссе Джеффри Катценберга про AI и творчество. Понравилась мысль, что спор «использовать AI или нет» завёл нас не туда: полезнее обсуждать условия, на которых мы будем его использовать.
Интересный у него состоялся разговор с LLM о разнице между reasoning и creating:
Reasoning and creating are two distinct cognitive modes, though they also work together. Reasoning is fundamentally evaluative and analytical. It operates on what already exists: facts, premises, evidence. It moves toward a conclusion that was in a sense already implied by the input. Reasoning is constrained by logic and truth. Its goal is to arrive somewhere correct, not to invent somewhere new.
Creating is fundamentally generative. It produces something that didn't exist before. And crucially, there's no single right answer waiting to be found. A blank page has infinite valid responses. Creation involves choices that can't be fully justified by logic alone. Taste, intuition and vision fill the gap where deduction runs out.
Как понять, что агент умеет делать продукт?
В первом посте про изобилие кода мы приняли рабочую гипотезу:
AI сможет выполнять значительную часть задач по разработке продуктов с приемлемым качеством, стоимостью и супервизией.
В январе я рассказывал, как юзаю Claude Code —> в пятницу сделаем апдейт
Обсудим в пятницу: https://luma.com/i1i4k9qq
Фрагмент встречи про оптимизацию затрат на 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
Кто проверяет вашего LLM-судью?
Разбирали недавно учебный кейс: один агент пишет статьи для базы знаний по мотивам обращений в саппорт, а 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.
Очевидные (и не очень) последствия изобилия кода
Окей, мы поговорили о том, что пилить, если можно запилить что угодно, и как при этом не потерять понимание —> давайте теперь порассуждаем про очевидные и не очень последствия изобилия кода.
Теренс Тао приводит интересную аналогию - изобилие еды - что изобилие всяко лучше, чем дефицит, и мир точно стал лучше. Но оно же привело и к ряду проблем - ожирение, новые заболевания и тп - и нам пришлось адаптироваться к этому. С софтом, имхо, тоже потребуется перестроить многое вокруг производства. Некоторые мысли по теме:
1) Нагрузка на инфраструктуру увеличивается в разы. У нас месячного лимита GitHub Actions стало не хватать, а Anthropic вообще написал свою систему контроля версий Scion : в монорепозиторий вливается 30K+ изменений в день, и архитектура не совсем была готова к нагрузке от always on агентов. Больше кода —> больше сборок, проверок, хранения, пуллов и пушей и тп. Продолжите список элементов инфраструктуры, которые начинают трещать от изобилия кода?
2) Приходится менять процессы проверки и выпуска. Если каждое изменение ждёт человека, очередь растёт вместе с аутпутом агентов. Команда Claude Code уже разрешает мержить часть низкорисковых изменений без обязательного человеческого ревью. Постепенный роллаут и откат - тоже в ту же тему. Если помните, мы как раз разбирали это на Фестивале Фонарей. Какие еще процессы надо поменять, чтобы пожинать плоды AI разработки, и при этом не разломать все к чертям?
3) Неожиданно для меня пришли к выводу, что может появиться целый сервис по удалению софта. Признавайтесь, у кого было так, что после очередного хакатона забыл погасить сервак и потом получил $1000 счет на клауд? :) . Признаться, я иногда сам не помню, где что осталось. При этом полезные старые версии, поддержку которых раньше было экономически нецелесообразно продолжать, теперь вполне можно.
4) Меняется круг конкурентов. Теперь сотрудник нашего лучшего клиента может вполне собрать приемлемое решение на пару с дружбаном. Бухгалтерская или логистическая компания может включить такой софт в свою основную услугу и покрывать стоимость из её дохода. У вендоров появляется целый новый пласт конкурентов с другой экономикой, которому не обязательно зарабатывать на продаже софта. Что тогда такое продукт и его конкурентное преимущество - экспертное знание? данные? ответственность за результат? отношения с регуляторами? бренд? Как это дело обстоит в индустрии производства еды? o__O
5) Выбор софта становится отдельной задачей. Если его предложение вырастет в 10-100 раз, найти подходящее, проверить и встроить в свой процесс тоже будет стоить времени и денег. Стоит ожидать появления эдакого YouTube для приложений, и возможно инфлуенсеров :) А тот, кто помогает выбирать, может получить больше влияния на то, каким продуктам достанутся пользователи.
При этом выбирать и использовать софт будут и агенты. Им тоже нужно найти инструмент, понять, для чего он подходит, вызвать его и проверить результат. Возможно, частью приложений мы будем пользоваться, даже не зная их названий - их будет подбирать дружбан под нашу задачу.
Мой критерий успеха из первого поста не меняется: скольким людям продукт улучшил жизнь и насколько. Но если полезный софт можно собрать самому или получить вместе с другой услугой, польза для клиента уже не обязательно превращается в выручку отдельного софтверного вендора.
Отсюда главный вопрос: если наш клиент сможет сам собрать приемлемый аналог вашего продукта, за что он всё ещё захочет платить вам?
Что просить у агента, кроме кода?
На AI Natives один из участников рассказывал, как с помощью AI учился играть в одну из разновидностей покера. Получить расчёт хорошего хода было лишь частью задачи: ему самому надо научиться принимать решения за столом.
Но запомнить тысячи ситуаций и вложенных «если» сложно. Поэтому он с AI выделял понятные правила: сначала определить тип раздачи (одна пара, две пары, без пары), затем пройти несколько шагов для этого типа. Где правило получалось слишком сложным, разбирали примеры. А потом сделали тренажёр: человек выбирает ход, получает объяснение ошибки и чаще встречает ситуации, в которых ошибается.
Это в тему размышлений в посте про изобилие кода. В Математике 2.0 есть две схемы: в одной AI получает решения, обходя человеческое понимание; в другой - помогает это понимание развивать.
В разработке похожая история: пока делаешь фичу, уточняешь требования, замечаешь исключения, узнаёшь что-то о пользователе, или о работе ранее неизвестного тебе модуля. Если эта работа уходит к агенту, понимание уже не обязательно появляется по дороге. Значит, стоит отдельно устроить процесс, в котором мы его приобретаем.
В первом посте был пример одноразового софта —> глубина понимания очевидно зависит от срока жизни продукта, цены ошибки и того, насколько легко всё откатить.
Для игры под один вебинар мне важно понимать правила модели и где она может ввести участников в заблуждение. А масштабирование на миллионы пользователей и архитектура на десять лет ей точно не нужны :)
В CRM, от которой зависят работа команды и данные клиентов, уже важно понимать правила процессов, как обнаружить ошибку и восстановить данные.
На больших задачах я стараюсь получать это понимание по ходу работы агента:
1) Сначала прошу план в виде артефакта, который можно читать и комментировать: варианты, ключевые решения, данные и допущения. Задаю вопросы и оставляю правки до реализации.
2) Проверяю важные допущения. Например, агент с помощью regex-а пытается отлавливать ответы клиента и обновлять CRM.
3) Прошу уменьшить зависимость от неизвестного. Допустим, размер компании не найден: можно оставить «неизвестно», попробовать другой источник или передать человеку. Или вместо regex-ов заюзать jev/decisions api.
4) После реализации прошу отчёт о тесте и прогоне на реальных кейсах: GIF-ки, скриншоты и описание процедуры. Так я вижу, что проверяли и какие сценарии выпали. Например, что сделал агент с лидом, размер компании которого неизвестен? Или «22-го подойдёт?» ещё не значит, что встреча согласована. Разбираем ошибку, уточняем правило, добавляем тест.
Что хочу сделать системнее: часть случаев заранее оставлять за пределами настройки, а потом разбирать расхождения на них. Где ошибся агент, где не хватило данных, а где стоит пересмотреть само правило?
И план, и отчёт мне удобнее оформлять в HTML и оборачивать в артефакт, со схемами и возможностью покрутить сценарии. Мне особенно удобно комментировать конкретный кусочек. Антропики публиковали по теме полезное, кстати
Попробуйте на следующей большой задаче попросить два артефакта: план с ключевыми решениями и отчёт о проверках. Выберите одно важное допущение, попросите показать, что изменится, если оно неверно, и проверьте, есть ли этот случай в отчёте.
А потом задайте себе вопрос: улучшилось ли ваше понимание?
Что пилить, когда запилить можно что угодно?
.... или размышления после просмотра выступления Теренса Тао про математику 2.0
И, правда, что тогда пилить? Или делать? Куда направить свое внимание?
Теренс в своем докладе использует интересный подход: он принимает рабочую гипотезу, что
AI тулы достаточно скоро смогут выполнять существенный набор сложных математических задач с приемлемым уровнем успеха, качества, супервизии и затрат
AI тулы достаточно скоро смогут выполнять значительную часть задач по разработке software продуктов с приемлемым уровнем скорости, качества, супервизии и стоимости
AI напарник у доски
Помните, я писал, как обстукиваю идеи об AI? Но лучше всего я думаю у доски: рисую стрелки, зачеркиваю, показываю пальцем — «вот тут что-то не сходится». Хочется, чтобы AI участвовал и в этом процессе.
Представляю Робина рядом: видит доску и мои каракули, слышит, что я объясняю, связывает это с тем, что обсуждали раньше. Я меняю схему, а он замечает, как поменялся аргумент.
Имхо, робот тут был бы очень кстати: повернуть камеру туда, где я рисую или на что показываю, а потом повернуться ко мне, когда обсуждаем идею. И показать без слов, что у него есть мысль. Захотелось разобраться, насколько сложно сделать такое.
Мы с Codex поресерчили варианты и нашли Reachy Mini: у него есть Python SDK и симулятор, поэтому можно начать с привычного кода, еще до покупки железа. Собрали демо: по обращению робот поворачивается к доске, кадр с его виртуальной камеры идет в Codex SDK, а модель задает вопрос по увиденному.
На тестовой доске были цель — понять, почему уходят пользователи, и план — выпустить пять новых фич. Агент прочитал записи и спросил, как выпуск фич поможет выяснить причины ухода. В видео — симуляция, на картинке — как хочется, чтобы это выглядело вживую.
В целом, никакого rocket science, дружбан вам поможет с этим справиться. Ключевой вопрос: что именно добавляет физическое присутствие? Например, по повороту головы видно, куда Робин смотрит, а поднятый усик может означать, что у него есть мысль.
Если тоже хотите попробовать, у Reachy есть пошаговые туториалы: движение головы и усиков, камера и звук. А Conversation App можно посмотреть как пример того, как соединить это с LLM.
Внедрение AI тоже надо тренировать
На днях Anthropic анонсировали Claude Frontier Academy: $100M и план подготовить 10K инженеров по внедрению AI к концу 2027. И интересен тут формат:
1) Три дня внедряют Claude в симуляции компании: от запроса клиента до security review и передачи системы.
2) На четвертый день - экзамен на новом сценарии.
3) Потом 12 недель внедряют Claude уже в своей компании с менторами, и снова практическая проверка.
Причем приходят туда уже сильные инженеры с опытом LLM. От них ждут, что они выберут полезную задачу, встроятся в существующие системы и данные, изменят работу команды и научат других пользоваться AI.
Я уже писал про симуляции как способ прожить последствия: имхо Anthropic делает именно это. Но здесь мне интереснее следующий шаг - как научиться связывать то, что ты построил, с реальной системой, в которой это будут использовать.
Андрей П. после поста про Рыболовство прокомментировал как раз в тему:
Байрам, крутой опыт — у меня похожие игры были, но эта зашла по-другому. Главное что вынес: сток неизвестен, но его можно оценивать косвенно — через изменение потока. И это не просто теория — после игры минимум в двух ситуациях поймал себя на том, что думаю именно этой моделью. Один раз объяснял почему надо прямо сейчас остановиться и переключиться — сток уже падает, смысла держаться нет. Второй раз в проекте казалось что буксуем — построил простую модельку по velocity задач и тревога подтвердилась объективно. Про человека согласен — AI может подсказать структуру модели, но связать её со своей реальностью это пока только сам. В игре я про падающий сток понял уже постфактум — и вот этот разрыв не делегируешь.
Системное мышление + AI: второй поток
Что говорят участники первого потока:
"Открыла для себя системное мышление по-новому... Применение AI было супер полезно: появляется инструмент проверки и как бы ментор, который с одной стороны прокачивает тебя и даёт обратку, а с другой исправляет ошибки" - Ника Штефан
"Поможет обратить внимание на новые составляющие системы, о которых не догадывался ранее... думать за разных игроков системы" - Аким Халилов
"Помогает анализировать сложные задачи, видеть взаимосвязи между процессами и принимать более обоснованные решения" - Jahongir Rôzimatov
Про применение AI в продуктовой аналитике - запускаю AI Product Analyst в августе:
1) как искать узкие места в продукте на пару с дружбаном, при этом не попав в ловушку галлюцинаций и неверных выводов
2) какие эксперименты поставить, чтобы подтвердить или опровергнуть гипотезу, и как их оценивать
3) и advanced часть: как научиться анализировать и улучшать поведение не людей, а AI агентов, так как, по моему мнению, этот скилл будет востребован с ростом продуктов, основу которых составляют агенты.
Лучше всего участвовать, если у вас есть работающий продукт и хотя бы 3 мес данных (с 100+ юзеров) с продакшна, но предусмотрена и игра-симуляция; в лучших традициях этого и этого постов
https://empatika.com/courses/ai-product-analyst
(продолжение)
6) Поэтому нам нужны механизмы защиты: аукционы, репутация, атрибуция вклада в конечный результат, пулы агентов, которые объединяют свои ресурсы, чтобы “говорить на равных” с агентами с большим объемом компьюта и доступа к информации. В эту тему очень крутая серия лекций про mechanism design (1,2), настойчиво рекомендую интересующимся такими экономиками или дизайнерам маркетплейсов. Кстати, в статье мне очень понравилась ссылка на исследование, почему центральное планирование неэффективно в системе управления движением автономных автомобилей (обязательно напишу про нее, но в эту же тему мои мысли про AI госплан). Детальнее про работу таких механизмов - читайте в самой статье
В общем, увлекательнейшее чтиво для людей на стыке экономики и computer science, я может даже сделаю вебинар по теме, ставьте + если актуально
Как оценить LinkedIn кампанию?
В одном чатике по founder-led sales делились уроками холодного аутрича в LinkedIn (писал об этом тут и тут) и я решил собрать все уроки в виде вот такого AI ассистента: он поможет вам оценить вашу кампанию, написать или улучшить сообщения, и подсказать, какие метрики трекать.
В аттаче пример переписки с ним, а попробовать можно тут: https://onsa-monetization-coach.fly.dev/linkedin-outreach
Надеюсь, будет полезно!