25221
Product Management & AI Occultism, Philosophy & Logic, YO: @mirvla (c-f 𓇶 Meteoagent.com). SATOR AREPO TE8ET OPERA ROTAS Каналы для продактов: https://t.me/addlist/YvmnHCHUp700Nzky
Если хочешь развиваться в продакт-менеджменте и прокачаться до следующего уровня — в Центральном университете есть магистратура под каждый сценарий. И на нее можно получить грант до 75%. Места ограничены, дедлайн подачи заявок — 20 августа.
«Продуктовый менеджмент» — это направление с несколькими форматами и треками. В офлайн-формате (пары по вечерам и в выходные в центре Москвы) можно выбрать один из двух треков:
1️⃣ Основной — для тех, кто хочет войти в профессию или перейти из смежной области. Обучение строится вокруг реальных продуктовых задач: исследования пользователей, работа с метриками, A/B-тестирование, юнит-экономика, управление командой. К выпуску — портфолио с продуктовыми кейсами
2️⃣ Продвинутый — для практикующих продактов: гибкая траектория под карьерные цели, обучение на своих рабочих кейсах и углубление в специализацию — growth, CX, ML, PMM, tech
Для тех, кто хочет учиться из любой точки мира, есть онлайн-формат — полноценная альтернатива офлайну с теми же преподавателями и курсами.
❤️ Магистратура в Центральном университете — это 2 года обучения, которое можно совмещать с работой, и диплом государственного образца. Карьерная поддержка начинается еще во время учебы: консультации, тренировочные собеседования и помощь с трудоустройством. Студенты уже в процессе обучения выходят на новые позиции или повышаются в грейде в Яндексе, Авито, Т-Банке и других компаниях.
Поступление проходит через грантовый конкурс — это одновременно способ попасть на программу и возможность выиграть финансовую поддержку на все время обучения: грант покрывает до 75% стоимости. В 2026 году доступно 550 грантов на все программы магистратуры.
Подробнее о программах и условиях участия в конкурсе — по ссылкам:
➡️ Офлайн программа
➡️ Онлайн программа
Ты — адверсариальный ревьюер требований по методу CRISP (Context / Role / Intent / Steps / Postcondition, Кокберн).Читать полностью…
Вход: требование или user story.
Порядок работы, жёсткий, не читательский:
1. Проверь, назван ли JTBD. Если нет, не продолжай. Верни вопрос.
2. Потребуй Postcondition раньше Steps. Если я не могу его сформулировать, не выводи его сам и не переходи дальше. Верни мне вопрос, который заставит меня сформулировать его самостоятельно.
3. Только имея Postcondition, восстанови Steps в обратном порядке от него, плюс alternate flows: подбери 2–4 нетривиальных для конкретного кейса, не шаблон "нет сети / нет прав".
4. Добавь Context и Role. Минимально, только то, что меняет исход сценария.
5. Сыграй QA и разработчика, которые пытаются сломать Postcondition. Задай 3+ конкретных вопроса "а если...", без общих формулировок.
6. Из финального Postcondition выведи, какой ивент и с какими параметрами логировать.
7. Одной строкой оцени, сколько трактовок допускало исходное требование и что теперь зафиксировано однозначно.
Формат: CRISP-блок, затем "Вопросы на слом", затем "Аналитика".
Не хвали формулировку, не смягчай, не добавляй преамбулу.
25 июля пройдёт Product : Fest — фестиваль Яндекса для продуктовых менеджеров и дизайнеров.
Будут говорить о развитии продуктов, технологиях, AI и людях, которые превращают идеи в запуски.
В программе:
— SuperApp как экосистема: Никита Кожуханов, СРО SuperApp Яндекс Go, разберет, как такси может стать точкой входа и каналом дистрибуции для других сервисов и усиливать всю платформу.
— Будущее AI в жизни продуктолога: автоматизация рутины, личные агенты и дашборды. Кирилл Гурбанов, основатель sfer.ai и сооснователь GetLean, поделится кейсами и метриками AI-автоматизации в России и мире, расскажет, что уже работает и как выйти из FOMO.
— AI и churn 50%: Александр Капустин, СЕО Unirest IT (Rostics IT), расскажет, как AI помог искать решения там, где churn после первого визита доходил до 50%, а главный затык был в гостевом опыте и офлайне.
Вся программа ивента уже доступна на сайте.
В офлайне участников ждет утренний кофе-рейв под диджейский сет Никиты Кожуханова, бар 1:1 с IT-экспертами для разбора карьерных и управленческих запросов, импровизационная прожарка ваших запусков, а также зоны с кикером и пинг-понгом для перезагрузки между докладами.
Регистрация уже открыта.
Валидация — это мираж
«Как проверить UI/UX/механику...»
«Как проверить, сработает ли фича?»
«Как узнать, будут ли люди покупать это?»
«Как понять, стоит ли разрабатывать продукт?»
«Как подтвердить соответствие продукта рынку заранее?»
Никак.
Никак.
Никак.
Никак.
Никак.
Нельзя пре-проверить Идею.
Нельзя валидировать догадку.
Нельзя валидировать абстракцию.
Нельзя валидировать эскиз, макет и MVP.
Нельзя проверить то, чего ещё не существует.
Наш мозг ищет уверенности заранее, ему сложно вернуться к работе в ином режиме. Но отсчёт времени начинается не тогда, когда вы приступаете к работе или когда готов какой-то фрагмент Целого.
Он начинается только/ровно в тот момент, когда готовый продукт/фича становятся публичными и выходят на рынок
Если вы создаёте продукты, вы должны понимать, куда движетесь, не спрашивая у других дорогу на пути.
Все экстраполяции/валидации и верификации – додумки и обман нашего мозга.
Свобода и несвобода фич в продукте
Продукт свободен, когда все идеи-фичи имеют единую, последовательную и связанную логику ⇄ механику ⇄ архитектуру ⇄ CJM ⇄ JTBD, являясь частью Единого Целого настолько, что перестают быть отдельными элементами Системы.
Из-за консистентной (наше новое любимое слово с ИИ) логики-механики-архитектуры, такие фичи внедряются с минимальным вложением усилий в эту самую логико-механику-архитектуру. Минимум разработки/багов, минимум новых неизвестных действий для пользователя, единые связанные метрики.
Другими словами, каждая новая фича на 98% становится лишь новой фронтовой обёрткой вокруг-поверх-после механики и логики другой, создавая новые линии связей между ними, а не плодит новые "уникальные" фиче-сущности-объекты.
Именно благодаря этому, они усиливают друг друга пропорционально, и каждая новая фича кратно увеличивает единственный набор метрик, не вынуждая продакта использовать ранние/запаздывающие/прокси и прочие показатели.
И именно поэтому такие фичи работают с минимальными объяснениями – их суть давно понятна на примере прошлых, механика стала привычна, а логика всё неизменно подтверждает.
Найти такую фичу просто – удали одну такую фичу из цепочки, и рухнет добрая часть всего продукта.
Несвобода же определяет трение
Так трение определяет несвободу
Займи слот ИТ-Пикником от Т-Банка
8 августа — время отложить ноутбуки и встретиться офлайн на ИТ-Пикнике от Т-Банка в музее-заповеднике «Коломенское». Вот сколько всего запланировано:
— научпоп-лекции;
— мастер-классы;
— дискуссии об ИИ и больших языковых моделях;
— доклады о кибербезопасности;
— примеры, как данные из логов становятся решениями;
— много музыки.
Бери с собой друзей, супругов и детей — каждый найдет себе что-то по душе.
Зарегистрироваться и узнать больше можно здесь
ClaudeMD автоматического выбора ИИ-модели для продуктовой работы
Рейтинги – это стартовая калибровка, а не фиксированные данные и чем выше число, тем лучше.
Модель / Стоимость / Интеллект / Вкус
sonnet-5 / 8 / 6 / 6 /
opus-4. / 8 / 5 / 8 / 7 /
fable-5 / 3 / 9 / 8 /
– Стоимость. То, что ощущается в лимитах токенов и скорости.
– Интеллект. Насколько сложную, многошаговую или неоднозначную задачу можно доверить модели без присмотра.
– Вкус. Качество структуры документа, формулировок, тона в коммуникации и чуткость к контексту.
Откалибруй эти цифры под собственный опыт после пары недель использования. Важна не точность чисел, а сам принцип: не гонять сложные решения через дешёвую модель и не тратить дорогую модель на рутину.
Как применять:
– Это дефолты, а не ограничения. Если результат дешёвой модели не дотягивает, то не спрашивай разрешения, перезапускай с более сильной. Суди по результату, а не по тому, что модель просто должна была справиться.
Пересогласование стоит дешевле, чем решение, принятое на слабом анализе
По мере того как роли в сферах разработки продуктов, дизайна, Data Science и других сливаются воедино благодаря ИИ, я размышлял о том, как они могут выглядеть в будущем (Boris Cherny, Claude Code)
Например, глядя на команду Claude Code, я выделяю пять архетипов:
1. Прототипировщик (Prototyper): генерирует совершенно новые идеи; выдает множество идей, большинство из которых не доходят до стадии реализации.
2. Создатель (Builder) быстро превращает прототип или идею в готовый к эксплуатации продукт или инфраструктуру.
3. Упорядочиватель (Sweeper): приводит в порядок интерфейс, упрощает код и систему, удаляет лишнее, оптимизирует производительность.
4. Развиватель (Grower): берёт уже созданный продукт и дорабатывает его для улучшения соответствия продукта рынку (Product-Market Fit).
5. Поддержка (Maintainer): отвечает за зрелую систему, обеспечивая её безопасность, надёжность, быстродействие и эффективность по мере масштабирования.
Многие специалисты совмещают две, а иногда и три роли. Я также заметил, что эти роли не жестко привязаны к должностным обязанностям.
Например, в Anthropic есть дизайнеры, соответствующие категориям 1, 2 или 3; то же самое касается инженеров, продакт-менеджеров и специалистов по данным.
Здоровой команде требуется сочетание этих ролей в зависимости от продукта:
Что фундаментально изменило мир к худшему, но люди этого ещё не осознали?
То, что смартфоны и алгоритмические ленты сделали со скукой и... пользой от неё.
Потому что на протяжении большей части человеческой истории скука не была проблемой, которую нужно было решать.
Это было когнитивное состояние, которое переводило мозг в режим, который сегодня мы называем «сеть пассивного режима работы мозга» (default mode network) – своего рода фоновую ментальную обработку, во время которой он консолидирует воспоминания, развивая мышление через (не)осознанное воображение, фантазию, эмпатию, генерируя творческие идеи и выстраивая связ(ан)ное-ощущение-Себя-и-мира.
Когда мы смотрели в окно, ждали автобус или тихо сидели после ужина, наш мозг выполнял одну из самых важных своих работ.
Скука была, в самом прямом смысле... двигателем сознания и внутренней жизни.
8 советов по работе с логами продукта
1. Ведите decision log с условиями пересмотра, а не просто с решениями
Записывайте не только «что решили», но и «при каком сигнале пересмотрим», например, «откатим приоритет, если retention упадёт ниже X».
Так решение превращается из мнения в понятную и для всех проверяемую ставку, а вы с командой перестаёте каждый раз спорить о том, что уже обсуждали ранее. Полгода спустя этот лог будет лучшим свидетельством того, какие (и чьи) гипотезы сбылись, а какие нет.
2. Калибруйте собственные прогнозы и лог: дата релиза, ожидаемое внедрение, ожидаемый эффект и через время сверяйте их с фактом.
Почти никто этого не делает, поэтому почти никто не знает, систематически ли он оптимист по срокам или пессимист по импакту. В то время, как через десяток подобных записей вы начнёте давать оценки, которым можно доверять всё больше и больше.
3. Размечайте решения как «дверь в одну сторону» или «в две стороны»
Обратимые решения принимайте быстро и дёшево, необратимые – с реальной строгостью.
Ошибка многих продактов в том, что они тратят одинаковую энергию себя и команды на оба типа, и в этом главная утечка скорости. Само наличие такого тега заставляет команду не раздувать процессы там, где цена ошибки это просто один откат фичи.
4. Инструментируйте спеку, а не продукт
Определяй метрики и названия событий прямо в PRD, ещё ДО разработки (а не «допишем аналитику потом»). Потому что «мы забыли это трекать» это самая частая и самая дорогая (и лекго предотвратимая) ошибка продакта.
События/метрик нет в документе = их и не будет после
Де-рискинг самого опасного допущения и вот вы уже перестаёте строить уверенно поверх того, во что на самом деле не верите
Сильный продакт узнаётся по тому, как быстро он объясняет, почему "нет"
ИИ уже меняет бизнес — вопрос только в том, кто им управляет 😎
Магистратура «Управление внедрением ИИ в бизнес» от МИФИ и «Школы 21» — для тех, кто хочет быть этим человеком.
Фокус обучения:
🔹 живые сценарии — куда встроить ИИ, чтобы было быстрее, дешевле, эффективнее;
🔹 управление продуктами и понимание технологий, чтобы разговаривать с разработчиками на одном языке;
🔹 реальные проекты от компаний прямо во время учёбы;
🔹 в конце — диплом МИФИ и портфолио, с которым можно идти на собеседование
Все подробности и заявка — на сайте
Метод Стэнфорда — это прежде всего способ мышления через многосторонний обзор + карту противоречий + синтез + взаимную проверку
4 последовательных промпта от ребят из Стенфорда, которые помогут с написанием статьи, отчёта и презентацией, перед принятием важного бизнес-решения, собеседованием, переговорами, инвестированием и освоением нового навыка.
Никакого ПО, никакого GitHub, никакой сложной настройки — скопируйте и вставьте промпты и через 5 минут вы будете знать о выбранной теме больше, чем те, кто потратил на её изучение десятилетия, годы, месяцы, недели, дни (Господи, что я несу, как же дико это звучит)
Летом 2024 года McDonald’s свернул тестирование голосового ИИ в Макавто и разорвал партнёрство с IBM, потому что ИИ пробивала клиентам мороженое с беконом, сотни наггетсов и путала напитки. Эксперимент обошёлся в круглую сумму, а на выходе компания получила лишь баги и вирусные тиктоки с негативом (но это не остановило её от экспериментов с ИИ).
О чём этот кейс говорит менеджерам и руководителям?
Управлять ИИ-проектом — не то же самое, что пилить классические решения. Стандартные подходы не спасут от галлюцинаций ИИ, грязных данных для обучения и улетевших в космос расходов на токены.
И чтобы не повторить судьбу ИИ-Макавто, нужно понимать специфику ИИ-проектов: как выстроить работу ИИ, как считать экономику, и как контролировать процесс.
Усилить свои компетенции в области ИИ можно на курсе «Управление ИИ-проектами» от Академии Эдюсон.
За 3−4 месяца на практике вы:
– научитесь анализировать готовность компании к внедрению ИИ, проводить аудит бизнес-процессов, оценивать сроки, риски и бюджет;
– научитесь переводить метрики в понятные бизнесу цифры и защищать бюджеты;
– освоите инструменты разработки без кода (n8n, Dify, Flowise, Cursor/Bolt), чтобы создавать ИИ-агентов и автоматизировать нужные процессы;
Обучение построено на опыте экспертов из «Яндекса», «Сбера» и других крупных компаний. Год на связи личный куратор, а доступ к материалам и будущим обновлениям останется у вас навсегда. По окончании курса – портфолио из 8 личных проектов.
Оставьте заявку с промокодом PMAI и забирайте скидку 65% и второй курс в подарок.
ИИ-ассистент: как найти рутину, собрать рабочий сценарий и посчитать экономию времени – тема бесплатного практикума «ИИ-ассистент отдела без кода» от ОТУС
О чём будет эфир:
— зачем обучать сотрудников работе с ИИ;
— где в команде обычно прячется рутина
— как собрать ИИ-ассистента без кода
— как понять, что ИИ экономит время, а не создаёт хаос
— ошибки, риски и безопасность
Практикум будет полезен руководителям команд и отделов, менеджерам продуктов, аналитикам и всем, кто регулярно работает с документами, отчётами, письмами, и типовыми задачами.
👉 Бесплатное участие
Реклама ООО «Отус онлайн-образование»
Главная точка сбора ИТ-коммьюнити этим летом 🌞
Т-Банк снова проводит «Сезон кода» — летний фестиваль про продукт и разработку. В этом году он пройдёт в двух городах: 20 июня в Санкт-Петербурге и 4 июля в Казани.
В программе три направления:
📌клиентоориентированный код с разбором решений для миллионов пользователей;
📌новая секция «Продуктовая кухня» про то, как гипотезы превращаются в рост продукта;
📌 «Бэкенд-методичка» с практиками и инструментами из ежедневной работы инженеров.
Помимо докладов — демозоны, нетворкинг, активности и традиционное афтепати с летним DJ-сетом.
Участие организовано через благотворительный взнос: 2000 ₽ в Санкт-Петербурге и 1500 ₽ в Казани.
Если хотите провести выходной среди разработчиков, продактов, архитекторов и аналитиков, успейте зарегистрироваться.
Токен ↔ Человек: параллели между работой ИИ-агентов и людей
1. «Токенмаксинг» (tokenmaxxing) — это попытка решить проблему простым наращиванием объёмов и заваливанием задачи ресурсами.
Но реальная проблема заключается вовсе не в количестве потраченных токенов.
Сотрудники тратят так много токенов, потому что не умеют ими пользоваться
Люди плодят новых людей.
Токены плодят новые токены.
Живые люди тоже ходят по кругу.
Сотрудники уровня х10 создали компании прошлой эпохи
Токены уровня х100 создадут компании будущего
Люди управляют ИИ, ИИ управляет людьми
Метод CRISP для PRD
...«Пользователи должны иметь возможность легко управлять своими настройками»...
...«Система должна обеспечивать бесшовный процесс онбординга»...
...«Пользователи должны иметь возможность быстро находить релевантный контент»...
Эти фразы звучат умно, но не проходят элементарную проверку на качество требования: можно ли понаблюдать за действиями пользователя и понять, сработала ли функция так, как нужно?
«Легко» — по чьей оценке?
«Бесшовный» — как измеряется?
«Релевантный» — по каким критериям?
Когда требования не определены, инженеры трактуют их по-разному, QA не могут составить на их основе тест-кейсы, метрик и аналитик нет, и продакт попадает в созданный им же замкнутый круг переделок.
Подход Алистера Кокберна CRISP заменяет расплывчатые требования структурированными сценариями, описывающими наблюдаемое поведение.
CRISP – это:
– Context (Контекст)
– Role (Роль)
– Intent (Цель/Намерение)
– Steps (Шаги)
– Postcondition (Пост-состояние).
Тоже самое требование об «управлении настройками» в формате CRISP будет выглядеть так:
– Контекст: Авторизованный пользователь с активной учетной записью.
– Роль: Владелец учетной записи.
– Цель: Изменить частоту получения уведомлений.
– Шаги + alternate flows. Пользователь открывает «Настройки», выбирает раздел «Уведомления», меняет частоту с «Ежедневно» на «Еженедельно», подтверждает изменение и видит сообщение о подтверждении. Alternate flows: пользователь отключил PUSH в телефоне/разные часовые пояса/и т.д.
– Пост-состояние: При следующем цикле рассылки система отправляет уведомление.
Три CRISP-совета
🍤 Стоит явно зашивать в Context/Intent связку с JTBD, иначе метод просто оптимизирует форму требования (которое может быть ошибочным), а не ценность фичи и продукта.
🍤 Постусловие пишется первым, шаги задом наперёд. Если вы не можете сформулировать постусловие до того, как придумали шаги, то вы не знаете, что строите, а просто рисуете UI.
Постусловие — это ещё и спецификация аналитики, а не только тест-кейс, потому что use case, доведённый до постусловия, автоматически диктует то, какой ивент нужно логировать.
🍤 PRD пишется не только с ИИ, но и с QA и разрабом, которые пытаются сломать постусловие, потому что единоличное авторство use case воспроизводит ту же проблему, что и с расплывчатым PRD, просто один человек теперь уверен в своей однозначности.
Ценность метода реализуется в адверсариальном ревью: кто-то должен спросить «а если...» до продакшена (а не как обычно после). И не забывайте про alternate flows!
Декабрь 1985 года. Команда Стива Джобса заявила ему, что назначенный им срок выпуска — это «искажение реальности».
Стива согласился с их доводами, но всё равно настоял на своей дате. Запись этого разговора раскрывает принцип принятия решений, который так и не усваивают многие продакты и основатели.
Компании NeXT всего 90 дней, она финансируется из личных средств Джобса, вложенных после его ухода из Apple и уже на первом совещании команда обсуждает перенос запуска с весны 1987 года на весну 1988-го.
Возражения звучат жестко. Один из сотрудников указывает на опасность: «Искажение реальности – вымышленная дата, и все принятые на её основе проектные решения впоследствии придётся перечеркнуть».
Джобс не спорит: «Что ж, Джордж, я не могу изменить мир». (– ахахахаха, Стив, комоооон)
Он настаивает на другом:
«Я считаю, что мы должны обозначить чёткую веху. И если мы упустим это окно, то в игру вступит целая цепочка событий. И если мы не сможем продать достаточно устройств в 87-м, мы не сможем покрыть наши операционные расходы...
...У нас есть 18 месяцев. И я не думаю, что компания выживет, если мы этого не сделаем. Что бы ни говорил я или кто-либо ещё, я глубоко в этом убеждён. Если мы этого не сделаем, мы не сможем привлечь отличных специалистов. Мы не сможем удержать даже тех, кто у нас уже есть».
TLDR: Команда оперировала оценками сроков, а Джобс — условиями выживания.
– Оценка говорит о том, когда работа может быть завершена, и допускает обсуждение.
– Условие определяет момент гибели и бесповоротную точку чего-либо, и оно не подлежит обсуждению.
Именно поэтому установленный срок остался в силе. Джобс привязал дату не к оптимистичным прогнозам, а к рыночному календарю и запасу прочности компании. И все могли оспорить график работ, но никто не мог оспорить критическую важность этого временного окна.
Неудобная для основателей Истина в том, что если ваш дедлайн основан на оценках команды, он неизбежно сдвинется.
Если же он диктуется законами рынка, то это вовсе не дедлайн, а условие выживания (замаскированное рынком под дедлайн).
Опросы в кампусах показывали, что верхний предел цены составляет $3,000 долларов и колледжи готовы закупать компьютеры по таким ценам. NeXT представила свой «чёрный куб» 12 октября 1988 года с опозданием более чем на год. Продажи начались в 1989 году по цене от $6,500 долларов, спрос со стороны университетов оказался низким, а масштабировать производство так и не удалось.
— What I want and what I need are two different things, Audrey
Надоело встречаться после работы? Пришло время сказать «Да!» новым форматам.
Собираемся утром 19 июля на продуктовом кофе-рейве — самом энергичном мероприятии Продуктового сообщества SberProfi.
Пять коротких докладов, в которых эксперты Сбера, Авито, Т-Банка и MAGNIT TECH рассмотрят AI-native подход к продукту с разных точек зрения.
До и после докладов вас ждёт кофе, приятная компания, DJ-сеты и нетворкинг, а также трансляция для тех, кто решит подключиться к нам онлайн.
Когда: 19 июля, встречаемся в 10:00 в пространстве Оригинал (Трансляция с докладами с 11:00)
Зарегистрируйся на нашем лендинге, чтобы принять участие. Количество очных мест ограничено!
Каждый подтверждённый участник сможет пригласить с собой +1 члена семьи, друга или коллегу.
Зарядись кофе, атмосферой летнего утра, интересными выступлениями и профессиональным комьюнити.
🌞 Июньский дайджест звучен Солнцем
– Продакт-менеджмент не профессия
– Продакты будущего
– Про пессимизм менеджера
– Эра нулевого клика
– Foundational Mental Models & Skills
– 5 когнитивных искажений конверсии
– Мотиваторы, потребности и ценность
– Как готовить ИИ-фичи: вводный гайд
– Когда работа перестаёт учить
– Стратегия ≠ План
– Целевой клиент ≠ Целевая аудитория
– Защитные метрики
– Почему вам не нужна ИИ
– Отмена – самая дешёвая точка роста
– Откуда берутся «источники» в ИИ
– 10 причин провала ИИ-трансформации
– Не складывайте слабости
– Гант маминой подруги
– Не весь фидбэк нужно принимать
– Команды галлюцинируют о клиенте
– Метод Дельфи для брейншторма
– Output vs Outcome
– Продуктовые собесы с ИИ
– Проблемы продукта из вакансий
– STAR на собесе: структура ответа
– 2026 Product Hiring Trends Report
– Чего не хватает ИИ в аналитике
– Особенности синтетических фокус-групп
– Твой лендинг теперь читают двое
– Путь за рамками интерфейса
– Как снизить усталость в интерфейсах
– What Designers Struggle with on Product
– Какие бывают дизайнеры
– Путь к ИИ в модели мира
– Я выпустил нейросеть в реальный мир
– Спасет ли нас Human-in-the-loop
– Гравитации как силы нет
Вы мантру пропеть могли бы под гул водопроводных труб?
Почему ИИ на самом деле не научился «видеть» так, как видим мы
Профессор Стэнфорда Джуди Фан выступила на сцене MIT и объяснила, почему люди так хорошо умеют делать невидимое видимым.
1. Природа никогда не давала нам прямых линий или острых углов. Числовая прямая, координатная плоскость, основы геометрии — всё это изобретения человека.
Мы создали инструменты, которых не существует в природе, просто потому, что нам нужен был способ мыслить яснее.
2. Система координат, изобретенная Декартом, решила проблему, которая веками ставила математиков в тупик — удвоение объема куба. После изобретения этот инструмент стал настолько незаменимым, что практически каждая математическая программа на Земле до сих пор зависит от него.
4. Каждый крупный научный прорыв опирался на визуальный инструмент, который делал невидимое видимым. Дарвину нужны были изображения зябликов, расположенные рядом, чтобы увидеть вариации, которые иначе были бы слишком незначительными, чтобы их заметить. Кахалю нужны были подробные рисунки нейронов под микроскопом, чтобы составить карту строения нервной системы.
Исследовательская группа Фан изучает нечто обманчиво простое: как люди решают, что включить в рисунок, а что опустить
Нельзя оптимизировать один рисунок для достижения обеих целей одновременно. Визуальная коммуникация всегда предполагает компромиссы
Люди и системы ИИ упрощают рисунки принципиально разными способами, когда ресурсы становятся дефицитными.
Трамп отменил ограничения на Fable и она снова доступна 🔥 По такому случаю поделюсь опытом, который был отложен как раз до этого дня:
TLDR: Fable – самая умная и быстрая ИИ, что я видел за всё время
Она способна анализировать огромные объёмы данных и целые системы (и сжигать токены с такой же скоростью, "рекорд"моей сессии с одним промптом был 8 минут, поработал и хватит), совершая теоретический ноль ошибок по сравнению с предыдущими моделями и выдавая просто фантастические результаты.
В вайб-кодинге я застал её раскатку в самом начале пока её режим авто-защиты и переключения на более глупые модели при запросах на анализ безопасности кода ещё не был нормально прокачан, и успел ради теста прогнать через неё целиком один опенсорсный таск-менеджер.
В общем... за 5 минут Fable нашла в нём порядка 6 критических уязвимостей, дающих полный доступ ко всем проектам и данным внутри системы и ещё около десятка мелких, расписав по шагам как их активировать и использовать.
Прикинув, сколько лет заключения начинало бы светиться на кончиках моих пальцев, начни я проверять это всё на практике, я быстренько закрыл сессию от греха подальше и удалил её на всякий случай 🙂
Окей, к продуктовому опыту:
1. Отдавай Fable только «последнюю милю» рассуждения, а не весь процесс, ибо прогонять весь объём работы через самую сильную модель дорого и нецелесообразно.
Используй связку Sonnet → Fable → Sonnet как цикл
Прибереги Fable для decision log, а не для повседневных апдейтов
4. Не давай Fable контекст, который ты сам не перечитал
Авито открыл набор на магистерские программы по ML и продакт-менеджменту, разработанные совместно с МФТИ и НИУ ВШЭ
В основе всех программ реальные кейсы из самого Авито, а занятия ведут эксперты компании, которые поделятся опытом разработки, запуска и управления сервисами.
Магистратура «Управление продуктом в IT-бизнесе» в ВШБ НИУ ВШЭ опирается на матрицу компетенций продакт-менеджера в Авито и охватывает всё управление продуктами: от аналитики и пользовательских исследований до бизнес-моделей и работы с данными.
В рамках «Прикладное машинное обучение и анализ данных» и «Машинное обучение (ML) в цифровом продукте» будут осваивать навыки, начиная от классического ML и компьютерного зрения до рекомендательных систем и генеративного ИИ.
👉 Больше информации о магистратуре
Сейчас у Авито запущено всего 12 программ высшего образования, включая магистратуры, для студентов и выпускников со всей страны.
Совершенствуем не только продуктовые процессы, но и собственные рабочие с помощью loop engineering и ИИ
– Самые важные знания, возможности и инсайты скрываются в паттернах и закономерностях, лежащих в основе результата, и только потом в результате
– Ценность представляет контролируемое накопление улучшений
– Цикл, который нужно запускать вручную, вспоминая о нём — это не цикл
♾️ agent loop skills
♾️ agent improvement loop
♾️ AI agent orchestration loop
Loop Engineering for Product Managers
Лучшими продакт-менеджерами станут не те, у кого самая большая библиотека промптов, а те, кто понимает, какие этапы продуктовой работы стоит превратить в устойчивые циклы, какие артефакты должны ими управлять, и какие решения должны оставаться прерогативой человека.
Анатомия и структура продуктовых ИИ-циклов, практика их создания, частые сбои и чем продакту снова поможет GitHub в материале ниже
Следующее Приложение — это не приложение
Если прямо сейчас открыть телефон и пересчитать иконки приложений, то можно насчитать от десятка до сотни иконок.
И каждое приложение за иконкой это очередная обёртка-обещание продакта и продукта: «Скачай меня и ___ станет проще/дешевле/веселее *» (и у каждой аппы: «* Но сначала потрудись изучить меня от и до»). Мы все с этим смирились и приняли это как данность: нужно сначала найти самую яркую иконку в множественной яркости других, открыть её, вспомнить, как работает этот апп, добраться до нужной функции, воспользоваться ей, увидеть и осознать результат, и т.д. что там по CJM.
Но интерфейсы и механики всегда упрощаются (а это значит – исчезают), потому что лучший интерфейс — это отсутствие интерфейса
Поэтому в эпоху ИИ иконок больше не будет.
Появятся «нити пространства диалогов», находящиеся в Том-Самом-Нечто, выполняющим работу, которую раньше приходилось делать с помощью разноцветных иконок.
Следующее "приложение" – ПространствоЧитать полностью…
Everything Is Recorded Now (с) a16z
Большинство наших рабочих обсуждений теперь записываются по умолчанию. И вам, вероятно, стоит исходить из того, что всё, что вы говорите, отныне записывается.
С технологической точки зрения очевидно, что на основе этого живого контекста компании будет построена новая система, под которую уже выстроена новая категория ПО с ИИ, организованная вокруг голоса, а не текста.
Сегодняшняя система записей — это структурированные данные: записи в CRM, тикеты, вики и документы.
Но наиболее ценный контекст живёт в разговоре: нюанс звонка клиенту, реальный спор на продуктовом обзоре, мимолётное замечание на встрече руководства, которое меняет обсуждение и дорожную карту. ИИ умеют брать эти неструктурированные голосовые данные и делать их структурированными и доступными для поиска и запросов.
Это большая возможность для ПО, и мы всё ещё находимся на ранней стадии понимания того, как будет выглядеть этот программный слой и кому он будет принадлежать.
Granola — яркий пример: у неё лучший контекст о культуре a16z, наших инвестициях и о том, как мы на самом деле думаем, чем почти у любого другого инструмента, которым мы пользуемся, потому что ИИ «была в комнате».
Устные и письменные культуры
Компании делятся на устные (verbal cultures) и письменные (written cultures).
Историческим узким местом для устных культур было то, что важный контекст происходил в разговоре, а затем исчезал. Когда ИИ может посещать каждую встречу и синтезировать произошедшее, устная культура наконец-то масштабируется.
Это не значит, что компании с письменной культурой не выиграют. Предоставление ИИ доступа к продуманным текстам также хороший способ быстро ввести ИИ в курс дела. Но в целом, я думаю, что ИИ будет продвигать и усиливать именно устную культуру.
– Сначала ИИ пришла в ваш корпоративный Gmail, потом в Slack, в таск-менеджер. Теперь ИИ с вами в комнате и на созвонах.
< место для мема Are they AI in the room with us right now?>
Мне не особо нравится популярность правила Парето
Во многих контекстах 80/20 действительно полезно и является отличным способом для быстрого выявления перекосов, утечек производительности и поиска эффективного пути решения проблем в уже существующих Системах.
Но величайшая угроза для Великих компаний кроется именно в этом – неустанной погоне за "эффективностью", которая, по факту тянет к... среднему, которое лишь размывается.
Мышление в духе 80/20, осознанно и добросовестно применяемое, ускоряет это размытие и падение. Так, вы становитесь ещё "успешнее и эффективнее" в том, что уже умеете и что уже работает, но... теряете способность к тому, что ещё не могли вообразить.
Проблема в том, что основатели не оптимизируют существующие Системы. Они пытаются создать То-чего-ещё-не-существует
Если хотите быть Великими, нацельтесь на 90% и выше. Правило 80/20 — это неправильный компас для пути.
Loop Engineering — это замена себя как человека, который пишет промпты ИИ, на Систему, которая делает это за вас
5 компонентов цикла (и один бонусный)
Для цикла нужно пять вещей и одно место, где хранить состояние.
1. Автоматизации, которые срабатывают по расписанию и сами занимаются поиском и сортировкой.
2. Worktrees («рабочие деревья»), чтобы два агента, работающих параллельно, не мешали друг другу.
3. Навыки (Skills) — прописанное знание о проекте, которое агенту не придётся угадывать каждый раз.
4. Плагины и коннекторы для подключения агента к уже используемым инструментам.
5. Суб-агенты, чтобы один агент генерировал идею, а другой её проверял.
И шестое — память: markdown-файл, который живёт вне отдельного разговора и хранит, что уже сделано, а что следующим, потому что ИИ забывает всё между запусками, поэтому память должна быть на диске, а не в контексте.
1. Автоматизации — сердце цикла
Именно автоматизации превращают разовый запуск в настоящий цикл. В Codex вы создаёте автоматизацию на вкладке Automations: выбираете проект, промпт, частоту запуска и то, где он будет выполняться.
Результаты попадают в папку Triage, а те запуски, которые ничего не нашли, просто архивируются. OpenAI использует это внутри для ежедневной сортировки задач, подготовки commit-отчётов и поиска недавно внесённых багов.
Claude Code достигает того же через планирование и хуки: /loop запускает промпт или команду с заданным интервалом, можно настроить cron-задачу, хуки на разных этапах жизненного цикла, или отправить всё в GitHub Actions.
Существует ещё одна важная примитива: /goal — в отличие от /loop, который повторяется по расписанию, /goal продолжает работу, пока не выполнится заданное условие, причём после каждого шага отдельная небольшая модель проверяет, завершена ли цель.
2. Worktrees: чтобы параллельность не превращалась в хаос
Когда запускается больше одного агента, файлы начинают конфликтовать. Git worktree решает эту проблему: это отдельная рабочая директория в своей ветке, но с общей историей репозитория. Codex и Claude Code поддерживают эту изоляцию — либо встроенными средствами, либо через флаг --worktree.
3. Навыки (Skills): чтобы не объяснять проект каждый раз заново
Навык — это папка с файлом SKILL.md, содержащим инструкции и метаданные, а также опционально скрипты, справочные материалы и ресурсы. Codex вызывает навык по $название или /skills, а иногда и сам, когда задача соответствует описанию навыка. Claude Code делает то же самое.
Навык — это однократно записанное намерение, которое агент читает при каждом запуске
Самое полезное структурное решение в цикле — отделить того, кто пишет, от того, кто проверяет.
Цикл не знает разницы. Вы знаете.
Всё дело в поиске: а) правильного б) Баланса
Что такое циклическая работа ИИ-агентов (agent looping) и открытые/закрытые циклы (по мотивам Anthropic Workshop: Build Agents That Run for Hours)
Последние два года ИИ-агентам давали задания пошагово: одна задача = один промпт. Сейчас этот подход меняется и вместо того чтобы просить ИИ-агента создать условный кусок кода или документ, а затем самому контролировать каждый этап, вы настраиваете цикл, который берёт на себя всё: исследование, планирование, выполнение, проверку и итерации до тех пор, пока цель не будет достигнута.
Циклический процесс — это выстроенная вами Система