Byndyusoft

«Я сам разберусь» — этому тоже нужно учиться Вышел мой самоучитель по стратегическому мышлению для школьников и студентов! Через несколько лет ваши дети и ученики начнут самостоятельную жизнь. Им придётся выбирать профессию, искать работу, договариваться с людьми и принимать решения, от которых многое зависит. Планы будут срываться, обстоятельства меняться, а готового правильного ответа может не оказаться. И вы не всегда будете рядом, чтобы подсказать следующий шаг. Самостоятельность стоит тренировать уже сейчас. Этот самоучитель даёт ребёнку такую практику: самому выбрать важную цель, разобраться, что мешает её достичь, придумать решение и проверить его в деле. Получить первый собственный опыт: «Я могу разобраться и действовать». Пока вы рядом и можете поддержать. Школьники и студенты уже попробовали: понравилось и говорят, что мозг поломался в нужную сторону 😄 Начали замечать, сколько предположений стоит за привычным «давайте просто сделаем». В основе самоучителя — Карта гипотез. Внутри — семь коротких глав, разобранный пример и рабочие листы для собственной цели.

Как работать с самоучителем: скачайте PDF, распечатайте на ЦВЕТНОМ принтере и заполняйте ОТ РУКИ. Выберите то, чего действительно хочется добиться, и проходите задания с этой целью.

Учителям и преподавателям: в конце самоучителя есть рекомендации для вас. Сначала прочитайте их — они помогут подготовиться к занятиям и работе с вопросами учеников. Скачать бесплатно: https://картагипотез.рф/resources Поделитесь с родителями и преподавателями, которым это может пригодиться.

На последней встрече мини-курса по КРИ мы традиционно делимся вмечатлениями с участниками потока. Всё чаще стали поступать отзывы о пользе метода в работе с код-агентами:

При работе с агентом у человека ограниченное количество внимания — агент сам что-то пишет и фиксирует, а что-то обязательно должен решить человек. КРИ в этом месте, сильно помогает: требования фиксируются короткими кусочками, каждый с обоснованием, зачем он вообще нужен. Такую пачку кусочков удержать в голове и проверить получается куда легче, чем простыню требований без разметки.

КРИ формировалась ещё до эпохи агентов под ту же задачу — речь идёт сплошным потоком, и отфильтровать её в моменте крайне трудно. Сейчас, когда машины разогнали свою «речь» до несусветных скоростей, это стало бить ещё заметнее и больней. Агент напечатает вам с три короба, а вам разбираться. Нужны специальные средства сжимающие смысл без потери качества и здесь рабочие истории оказались крайне полезными. В видео к посту — несколько кускочков отзывов с двух потоков и пара живых реакций прямо с созвона. 12 октября стартует новый поток. Если работаете с агентами, тонете в требованиях или давно хотели разложить замысел и реализацию системы так, чтобы они помещались в голову — приходите.

Представьте: вечером вы оставили ИИ-агентов работать на ночь. Утром они отчитываются, что система готова: код написан, тесты зелёные, можно в прод. Вы будете это релизить? А отвечать за результат всё ещё вам. 17 октября в Екатеринбурге у меня закрывающий keynote на HardFest: «Переход в проектировании от системного подхода к средовому». Продолжаю развивать тему, про которую писал на Хабре. Мы много лет учились проектировать и создавать системы, продумывать их устройство, выбирать компромиссы. А что будем делать мы, белковые айтишники, если всё больше этой работы станут делать агенты? ) Меня интересует следующий шаг: проектировать среду, в которой агенты сами создают и изменяют системы. Как садовник, который умеет вырастить дерево, хотя ни одного листа к нему не приклеивал. При этом на выходе может получиться обычный софт — хоть монолит, хоть микросервисы, решать, возможно, уже не нам. И тогда придётся задуматься, какую часть своего опыта мы умеем превращать в условия работы других. Как задать правила, чтобы у агентов получалось то, за что мы готовы отвечать? И что делать, если они найдут решение, до которого мы сами бы не додумались? Системный подход при этом никуда не исчезает. А вот привычную роль архитектора хочется пересмотреть, и тут мне очень нужны ваши возражения ) Приезжайте на HardFest и приходите на мой доклад! Очень хочется встретиться с теми, кому тоже интересно, кем мы будем в этой профессии через несколько лет. Моя цель — заложить основу новой методологии, новых примитовов и принципов проектирования, которые пойдут дальше системного подхода, не отменяя его. 17 октября, Екатеринбург, ХардФест.

45 минут моего вайбкодинга В течение последних пяти месяцев я развиваю ИИ-станок, который сам выращивает информационные системы на основе требований. В этом видео запись того как выглядит разработка с таким станком. Там я делаю пару фич для генератора карт КПО. И, конечно же, работа с таким станком ведётся на основе тех методов проектирования, о которых я здесь пишу. Это карты процесса-опыта, реализации историй, журнал проектирования, цепь преобразования данных. Если присмотреться, видно. что навык чтения и правки рабочих историй нужен и в работе с агентами.

Выложили AI-навыки для Социотеха на GitHub — бери и встраивай Команда Byndyusoft выложила на GitHub коллекцию скиллов для AI-агентов. Они заточены под работу с Социотехом — нашей платформой для проектирования и реализации стратегии. В репозитории — готовые промпты и инструкции для интеграции. Агент сможет читать структуру стратегии, работать с целями и инициативами, извлекать данные и встраиваться в ваши процессы. Зачем это нужно? Социотех помогает компаниям согласовать действия команд и держать фокус на реализации стратегии. Но если добавить сюда AI-агента, который понимает логику платформы, появляется новый слой автоматизации. Агент может формировать отчёты, отслеживать отклонения, подсказывать узкие места — без участия человека на каждом шаге. Это не замена аналитика, а инструмент, который разгружает команду от рутины и даёт больше времени на решения. Репозиторий открыт, можно брать и встраивать. Если хотите, чтобы Социотех заработал в вашей компании с ИИ-агентами под капотом — поможем настроить и запустить. Ссылка на репозиторий https://github.com/Byndyusoft/sociotech-ai-skills

От стратегии к IT-системе: как ИИ-агент оживляет данные проекта Часто между стратегическим планированием и реальной разработкой ПО возникает разрыв: требования теряются, а финальный продукт не отражает изначальных бизнес-целей. Посмотрите, как можно устранить этот разрыв, связав структурированные данные проекта и возможности ИИ. 🔧 Как это работает? Процесс строится на последовательном преобразовании смыслов в технические артефакты: 1. Формирование контекста: в проекте фиксируются стратегические ориентиры, тренды и ограничения. 2. Технология Карты гипотез: вместо абстрактных идей формулируются проверяемые гипотезы и конкретные пользовательские сценарии. 3. Декомпозиция: создается Карта реализации историй, где каждая функция привязывается к реальной потребности пользователя и этапу его взаимодействия с продуктом. 4. Подключение ИИ-агента: агент считывает всю структуру проекта — от стратегических установок до деталей рабочих историй. 5. Генерация артефактов: на основе этих данных ИИ автоматически формирует библиотеку компонентов, UI-экраны и дизайн-систему, которые точно соответствуют исходным требованиям. 🎯 Зачем это надо? • Синхронизация бизнеса и разработки: IT-система проектируется не на основе догадок, а напрямую из утвержденных стратегических данных. • Скорость без потери качества: рутинные операции по проектированию интерфейсов автоматизируются, высвобождая время команды для анализа и проверки гипотез. • Снижение коммуникационных рисков: минимизируется эффект «испорченного телефона» между заказчиком, аналитиком и дизайнером. 🚀 Попробуйте на практике Хотите увидеть, как данные трансформируются в готовые IT-решения? Попробуйте работу ИИ-агента в связке с Социотехом https://sociotech.center на реальном примере.

Оцените структуру и логику проекта здесь: 🔗 https://app.sociotech.center/projects/68e94978-8226-4b33-8a01-48400dc53c9b

🚀 Динамика метрик прямо в Социотехе Мы добавили инструмент визуализации прогресса. Теперь ваши карты — не просто текст на карточках, а живые данные, которые показывают, движетесь ли вы к успеху. 1. Как это работает? В блоке «Динамика метрик» вы видите графики для каждой метрики вашей стратегии. – Таймлайн: история изменений, текущее состояние и прогноз. – Сравнение с планом: система автоматически подсвечивает отклонения.

🤖 Автоматизация через ИИ: вам не обязательно вбивать цифры вручную. Данные в метриках можно автоматически заполнять через MCP Социотеха с помощью вашего ИИ-агента. Агент может выгружать данные из CRM, аналитических систем или баз данных и актуализировать графики в реальном времени.

2. Зачем это использовать? – Мгновенная диагностика: вы сразу видите, где стратегия буксует. Красные индикаторы («Вне нормы», «Не успеваем») привлекают внимание к проблемным зонам. – Прозрачность прогноза: вы видите не только то, где вы были, но и куда движетесь, если ничего не менять (пунктирная линия прогноза). – Связь гипотез и результатов: вы видите, как реализация ваших гипотез (карточки справа) влияет на конкретные цифры.

🔗 Посмотрите живой пример метрик в стратегии сети кофеин, где можно покликать и изучить детали: https://app.sociotech.center/projects/public/79c89852-99a6-435c-805f-d464cfeb0d57

Попробуйте настроить отслеживание метрик в вашем проекте в Социотехе https://sociotech.center уже сегодня и сделайте вашу стратегию измеримой! 📈

QA-посиделки В этот раз без докладов, презентаций и заранее заданной темы. Просто встречаемся в Челябинске, берём что-нибудь попить и поесть и разговариваем про QA, работу и всё, что сейчас интересно или болит. Можно обсудить AI в тестировании, автоматизацию, процессы, инструменты, собеседования, странные баги и взаимодействие с разработкой. А можно принести вообще любую свою тему. Темы выберем прямо на месте и дальше просто пообщаемся. Можно прийти с вопросом, историей или просто послушать. 📅 [30 сентября 19-00] 📍 Челябинск — [Сидрерия, Цвиллинга 15] Ссылка на регистрацию: https://byndyusoft-event.timepad.ru/event/4213844/ Вход свободный. Еда и напитки — за свой счёт.

С 2022 года я задаю индустрии один и тот же вопрос: насколько мелко нарезать? Сначала про микросервисы, потом про модули монолита и даже про команды и отделы. Теперь настало время приложить вопрос и принципы ответа на него к большим объёмам данных и поиску по ним. Здесь он звучит так: какого размера должен быть шард индекса. Повод задуматься дал Яндекс. На конференции «Я про бэкенд» есть активность «2718» — system design наоборот. Задачи присылают зрители, жюри отбирает самую заковыристую, а решает её в прямом эфире инженер Яндекса: условие видит впервые, детали выспрашивает сам. Я не удержался и отправил свою. Если кратко: Поиск по двум миллиардам документов. Индекс на одну машину не помещается, его режут на шарды и раскладывают по двумстам серверам. Порежете мелко — каждый запрос превращается в тысячу обращений, и ответ придёт со скоростью самого медленного шарда. Порежете крупно — половина нагрузки ляжет на два-три шарда, потому что полпроцента документов дают половину всех показов в выдаче. Причём это каждый раз разные полпроцента: вышла новость — и востребованными становятся совсем другие документы, а вчерашние горячие остывают. Так что нарезать индекс по темам тоже не выйдет, горячий шард каждые несколько часов будет новый. Плюс документ (новость) должен находиться через тридцать секунд после публикации, а база документов удваивается каждый год. Кому-то наверняка знакомо? :) Нарежешь мелко — утонешь в сетевых вызовах и накладных расходах. Нарежешь крупно — пара сервисов заберёт всю нагрузку, а любая переделка растянется на недели. Тот же баланс, что с микросервисами, только искать его надо на трёх уровнях сразу: размер шарда, размер сегмента внутри шарда и размер виртуального шарда (chunk'а или таблетки) — куска, которым данные переезжают с сервера на сервер, когда база выросла и её пора перераспределять. Переносить по целому шарду долго, по одному документу — бесконечно, так что и здесь нужен свой размер. Схему сильный инженер нарисует за двадцать минут. Поэтому я попросил у решающего три вещи, которых на собеседованиях по system design обычно не спрашивают: 1. Чем сервис пожертвует первым, если нагрузка окажется выше расчётной — частью результатов, скоростью появления новых документов или временем ответа. Запроектировать этот порядок нужно заранее, до первой аварии. 2. По каким признакам архитектор поймёт, что нарезал неправильно. У микросервисов это могут быть повторы в трассировках, у шардов — например, доля запросов, в которых один шард не ответил вовремя. 3. При каких значениях этих признаков пора принимать решение о перепроектировании и перенарезке шардов. По сути я хочу спросить не только о решении, но и о возможной его доказательности (архитектура как и медицина должна быть доказательной): гипотезы, метрики, условия пересмотра решений. Об этом я как раз сейчас много пишу и рассуждаю, и мне очень любопытно увидеть такое рассуждение вживую у человека, который каждый день живёт внутри высоконагруженного поиска. Решаема ли задача за час — тоже гипотеза, проверим об эфир ) Сама конференция — про современный бэкенд вокруг AI: архитектура и эксплуатация рекомендательных систем, платформы для обучения и запуска агентов, оптимизация инфраструктуры вокруг генеративных моделей, потоковая обработка данных и отказоустойчивость под высокой нагрузкой. И тот самый «2718»: заходите, предлагайте свой кейс, команда выберет самый сложный и решит его в прямом эфире. Если выберут мою, буду болеть за решающего, ему будет нелегко 😅 3 октября, Москва и онлайн, бесплатно: регистрация

Недолго осталось 🤗

Ну что, две недели до Backlog BBQ в Британском стиле и самое время объявить, что я там выступаю. Расскажу: — как при ограниченном бюджете выбрать несколько действительно важных направлений; — как проверить, что команда работает на согласованную стратегию, а не просто создаёт активность в Jira, CRM, таблицах и чатах.

И принесу книгу в подарок для самого активного участника 🎁 https://картагипотез.рф/book

Если вы отвечаете за бюджет, команду или бизнес-результат, эту статью жизненно необходимо изучить подробно. Иначе ресурсы продолжат расходоваться на десятки «важных» инициатив, не двигающих ключевые показатели. Более подробно тут: https://blog.byndyu.ru/2026/08/blog-post_705.html 📍 Где Лофт в центре Москвы (с полноценной кухней) 🗓 Когда 24 сентября(четверг) 🕖 Начало в 19:00 💸 Стоимость 🎟 3000 ₽ — при покупке до 20 сентября 🎟 3500 ₽ — с 21 по 23 сентября 🎟 4000 ₽ — в день мероприятия В стоимость входит всё: 🍽 продукты и совместная готовка 🍺 напитки (алкогольные и безалкогольные) 🏠 аренда лофта 🤝 нетворк и новые знакомства 🎤 выступление спикера ✨ атмосфера настоящего Backlog BBQ

⚠️ Количество мест ограничено. Чем ближе дата мероприятия — тем выше стоимость билета.

🔗 КАК ПОПАСТЬ 1️⃣ Написать БОТУ https://t.me/backlogbbqbot

Тяжела и некозиста жизнь ИИшки под обвязкой

У нас тут тихо случился большой релиз Карты гипотез. Неделю назад репозиторий в основном помогал построить Карту гипотез. Теперь он описывает весь путь стратегии — от вопроса «а она нам вообще нужна?» до конкретных действий, метрик и следующего управленческого решения. — Что появилось важного? Во-первых, мы связали стратегию с операционкой. Теперь можно пройти от фактически выполненной работы до стратегического результата и проверить всю цепочку: цель/метрика ← субъект ← гипотеза ← задача ← фактическая работа и ресурс Это важно, потому что приоритет без задач и ресурсов — не настоящий приоритет. А выполненная работа, которую невозможно связать с гипотезой и целью, не позволяет понять, действительно ли мы реализуем стратегию. https://github.com/Byndyusoft/hypothesismapping/blob/main/strategyoperations.md Во-вторых, серьёзно проработали метрики. Не просто «было 10, хотим 20», а: — как меняется метрика во времени; — какие балансирующие показатели нельзя уронить по дороге; — что делать при выходе за допустимые границы; — какая гипотеза могла повлиять на результат; — какие ещё объяснения этого изменения нужно проверить. Потому что выполненная задача ещё не доказывает гипотезу. А рост метрики после запуска проекта ещё не означает, что она выросла именно благодаря гипотезе. https://github.com/Byndyusoft/hypothesismapping/blob/main/metrics.md В-третьих, описали переход от рисунка к модели данных. У элементов стратегии появляются типы, идентификаторы, состояния и связи. Благодаря этому можно сохранять историю решений, связывать стратегию с задачами и метриками, автоматически искать противоречия и подключать ИИ-агентов не к набору слайдов, а к самой логике стратегии. https://github.com/Byndyusoft/hypothesismapping/blob/main/datamodel.md ‼️ Ещё появилась модель зрелости стратегирования: от ситуации, когда стратегия существует только в разговорах и презентациях, до непрерывной системы проверки гипотез и коллективного обучения. Причём это не только про бизнес. Модель подходит человеку, семье, команде, организации или сообществу — везде, где есть цель, неопределённость и ограниченные ресурсы. https://github.com/Byndyusoft/hypothesismapping/blob/main/maturitymodel.md https://github.com/Byndyusoft/hypothesismapping/blob/main/personalstrategy.md — Для меня главный результат обновления вот в чём: Карта гипотез не заканчивается в тот момент, когда завершилась стратегическая сессия и все закрыли доску. Наоборот — именно в этот момент настоящая работа со стратегией только начинается.

Если вы давно не заглядывали в базу знаний, сейчас хороший момент: https://github.com/Byndyusoft/hypothesismapping

Продолжаю развивать свои архитектурные подходы и aact — мой открытый репозиторий для работы с архитектурой as code. Теперь хочу подключить к этому студентов и магистрантов: подал несколько проектов в AI Talent Hub ИТМО, которые можно начать на проектной практике и развить в диплом/ВКР под моим научным руководством. Да, с прошлого года я ещё и научрук 🧑‍🎓 За последние годы у меня накопилось много материала про границы компонентов, связанность, тестирование архитектуры as Code и другие архитектурные подходы и идеи. Часть из них материализуются в aact — там появляются инструменты, которыми эти идеи можно проверять. Но и сами подходы хочется дальше проверять об практику, искать ограничения и дорабатывать. Тем более, что у меня появился ещё и средовой подход, ещё более требующий какого-то воплощения в реальности и проверки своих гипотез. Из всего этого как раз и выросли темы проектов в рамках магистратуры: - Архитектурный ИИ-ревьюер. Сравнить агента, который читает ADR, проверки по правилам в aact и их связку. То есть, что лучше — просто ИИ-агент, проверяющий PR'ы, декларативные автоматизированные тесты на архитектуру (aact) или и то, и другое в связке. В проекте нужно будет измерить пропущенные нарушения, ложные тревоги и повторяемость ответов в каждом из вариантов. А лучший вариант — реализовать в виде бота для GitHub. Он пригодится командам, у которых архитектурных договорённостей уже больше, чем архитектор удерживает в голове. - Бенчмарк для архитектуры ИИ-кода. Собрать задачи, в которых отдельно проверяются работоспособность решения и соблюдение архитектурных правил. Прогнать несколько моделей, посмотреть, где они ошибаются и помогает ли явно дать им правила (принципы и паттерны). Хочется получить воспроизводимый способ выбирать и настраивать агентов с учётом того, как их код вписывается в проект. - Эксперимент со средой создания системы. К этим проектам хочу добавить эксперимент, о котором писал в августе. Одну задачу решаем двумя способами: человек пошагово управляет разработкой с ИИ или заранее готовит среду, в которой агенты работают по общим правилам и проверкам. На выходе в обоих случаях может быть детерминированная система. Затем меняем требования и сравниваем затраты человека, стоимость и качество результата, отдельно учитывая подготовку среды. Хочется проверить, удаётся ли сократить ручное управление и сохранить архитектурные ограничения при переходе на средовой подход. На семестр здесь хватит небольшого пилота. - Что происходит с архитектурой после прихода ИИ. По истории открытых репозиториев проверить ухудшается ли архитектура (например, растёт ли связанность модулей) после начала использования ИИ-ассистентов. Сравнивать с похожими проектами и учитывать, что они меняются и без нейросетей. Моя гипотеза про рост архитектурных проблем может не подтвердиться — тем интереснее будет разобраться в результатах. - Тренажёр архитектурных решений с ИИ-оппонентом. Студент предлагает решение, оппонент ищет сценарии, которые его сломают, а судья (белковый преподаватель или ИИ) оценивает обоснование. Здесь может пригодится к примеру диверсионный анализ из ТРИЗ. Если получится, тренажёр можно будет использовать на моем архитектурном курсе, чтобы студенты больше практиковались и получали обратную связь. И ещё одна тема в мою любимую, но в сторону — нейросетевой движок для шахмат с кубиками. Я для них уже написал алгоритмический движок (по ночам 🌙), теперь хочется попробовать обучение нейросети игрой с самой собой ) Проверять силу нейросети будем на длинных сериях партий, чтобы отделить качество игры от везения. В первых двух проектах и в эксперименте со средой пригодится aact. Для архитектурных исследований берём открытый код, чтобы результаты можно было перепроверить. Даже если мои гипотезы не подтвердятся на практике — это тоже будет полезно и поможет понять, куда двигаться дальше. А если у вас есть идеи проектов (необязательно архитектурных, вообще любых), которые можно предложить магистрантам — смело пишите мне. Всех с началом учебного года 🍁

Студента проще научить, чем разработчика переучить Кажется, в обучении разработчиков работе с ИИ лучше всего работает метод Моисея. Можно месяцами убеждать опытную команду, что ИИ — это не «автодополнение для ленивых», а новый подход к исследованию задач, написанию и проверке кода. И раз за разом слышать: — Я быстрее сам. — Мы всегда работали иначе. — Сначала давайте разработаем регламент использования ИИ на 80 страниц. А можно взять студента, сразу показать ему AI-first-процесс — и через неделю он не «внедряет ИИ». Он просто так работает. Похоже, некоторым компаниям придётся сорок лет водить legacy-разработку по пустыне нытингов, пока не исчезнет поколение с сакральной фразой: «Зачем мне ИИ? Я и так умею».

Купил чайник — и обнаружил, что у него нет шкалы уровня воды. Той самой прозрачной штуки сбоку, которая позволяет сразу понять, сколько воды внутри. Интересно, в какой момент инженеры решили, что эта функция больше не нужна? И как теперь определять уровень — каждый раз открывать крышку и заглядывать внутрь? Забавно, но сейчас в разработке ПО происходит нечто похожее. Раньше главной задачей разработчика было не потерять знания о системе: зафиксировать архитектурные решения, описать правила, передать контекст коллегам. Мы документировали не только то, как устроен продукт, но и то, как с ним правильно работать.

С появлением ИИ этого уже недостаточно.

Теперь после каждой выполненной задачи важно смотреть не только на результат, но и на систему, которая этот результат произвела. Допустим, я ставлю ИИ задачу и получаю решение с ошибками. Самый очевидный путь — открыть код и всё исправить вручную. Но если делать так каждый раз, никакого реального ускорения не произойдет. Я просто превращусь в редактора очень быстрого, но не всегда внимательного исполнителя. Поэтому мой главный вопрос теперь звучит иначе:

«Что нужно изменить в обвязке, чтобы в следующий раз ИИ справился лучше сам?»

Может быть, уточнить инструкции. Добавить пример. Зафиксировать архитектурное ограничение. Настроить проверку. Дать модели доступ к нужному контексту. Изменить сам процесс постановки и приемки задачи. То есть исправлять нужно не только конкретный результат — нужно перенастраивать станок, который этот результат производит. Каждая ошибка становится обратной связью для надсистемы. Каждая ручная правка — повод спросить себя: можно ли превратить её в правило, тест, инструкцию или автоматическую проверку? Именно здесь разработчик переходит на уровень выше. Он уже не просто пишет код. Он проектирует среду, в которой код создается: собирает контекст, формулирует ограничения, настраивает инструменты и строит контур обратной связи. Можно назвать эту роль ИИ-архитектором. Можно — инженером производственной системы. Название пока не так важно. Важен сам сдвиг: единицей улучшения становится не очередной фрагмент кода, а весь процесс его создания. Если остаться в прежней парадигме и продолжать молча исправлять всё руками, ускорения не будет. Более того, мы начнем регулярно терять полезные функции, знания и ограничения — просто потому, что они нигде не закреплены. И продолжим производить чайники без шкалы уровня воды.

В конце августа прошел очередной QA митап в Челябинске. Александр Прокошев выступил с небольшим докладом на тему: "MCP-сервер: как проверить, что ИИ-агент правильно работает с приложением" На митапе поговорили о том, как тестировать MCP-сервер и убедиться, что ИИ-агент действительно правильно работает с приложением, а не просто уверенно пишет в чате «Готово». Разобрали путь пользовательского запроса от агента через MCP-сервер до результата в продукте. Обсудили, почему ответ агента сам по себе не является доказательством. Поделились практикой ручной проверки через MCP Inspector и MCP Playground.

Получился очень живой разговор: много вопросов, примеров из опыта и обсуждений того, как эти подходы могут работать в разных продуктах.

Спасибо всем, кто пришёл — были рады видеть каждого и уже ждём новых встреч!

12 сентября в 14:30 выступаю на SECON 2026 в Пензе! Проведу мастер-класс «От идеи до стратегии за час: технология Карта гипотез» https://2026.secon.ru/speakers/speaker-o3w6be. Идей у команд обычно хватает. Сложнее понять, за какую браться, что мешает двигаться вперёд и какие действия действительно повлияют на результат.

На мастер-классе разберём реальные кейсы и вместе построим карту гипотез: найдём ограничения, сформулируем проверяемые гипотезы, соберём стратегию и оценим последствия решений.

Берите ноуты — будем разгонять стратегию с помощью ИИ-агентов прямо на месте. Прихватите и свою задачу, над которой давно хочется подумать: будет хороший повод сдвинуть её с места. 📍 Встречаемся в Поисковом кабинете, зал № 2.5. До встречи на SECON!

Признавайтесь, кто так делает? 🙈