Byndyusoft

Выложили AI-навыки для Социотеха на GitHub — бери и встраивай

Команда Byndyusoft выложила на GitHub коллекцию скиллов для AI-агентов. Они заточены под работу с Социотехом — нашей платформой для проектирования и реализации стратегии.

В репозитории — готовые промпты и инструкции для интеграции. Агент сможет читать структуру стратегии, работать с целями и инициативами, извлекать данные и встраиваться в ваши процессы.

Зачем это нужно? Социотех помогает компаниям согласовать действия команд и держать фокус на реализации стратегии. Но если добавить сюда AI-агента, который понимает логику платформы, появляется новый слой автоматизации.

Агент может формировать отчёты, отслеживать отклонения, подсказывать узкие места — без участия человека на каждом шаге. Это не замена аналитика, а инструмент, который разгружает команду от рутины и даёт больше времени на решения.

Репозиторий открыт, можно брать и встраивать. Если хотите, чтобы Социотех заработал в вашей компании с ИИ-агентами под капотом — поможем настроить и запустить.

Ссылка на репозиторий https://github.com/Byndyusoft/sociotech-ai-skills

24 сентября приглашаю вас на Backlog BBQ 🇬🇧

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

Я поделюсь своими мыслями, обсудим ваши вопросы. А ещё в лофте будет кухня, так что ужин приготовим вместе — за разговорами о работе, жизни и о том о сём. Потом всё это съедим и продолжим общаться. В общем, план — приятно провести время в хорошей компании, заодно с капелькой пользы.

📚 Обязательно принесу один бумажный экземпляр книги про карту гипотез — подарю кому-то из участников и подпишу.

В этот раз устраиваем английский вечер. Вместе приготовим:
🍟 Fish & Chips
🥗 Ploughman’s Salad
🧀 Welsh Rarebit

Из напитков — Guinness, джин-тоники, безалкогольные напитки и фирменный лимонад.

Собираются продакты, разработчики, дизайнеры, аналитики, предприниматели — и все, кому хочется познакомиться и пообщаться. Приходите!

Все детали:

📍 Лофт в центре
🗓 24 сентября, четверг
🕖 Начало в 19:00

Стоимость:

🎟 3000 ₽ — по 20 сентября
🎟 3500 ₽ — с 21 по 23 сентября
🎟 4000 ₽ — в день мероприятия

В стоимость входят продукты, совместная готовка, напитки, аренда лофта и вся программа вечера. Места ограничены.

👉 Записаться через 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

Скоро вы не поймёте, где работает SDD, а где сама модель

Разработчик поправил верстку прямо в Codex без OpenSpec, а спеки написал уже потом. Мелочь, но она показывает, куда всё движется.

Spec-driven development сейчас — это обвес вокруг модели. Мы пишем спеки, гоняем их через харнесс, страхуемся от галлюцинаций и потери контекста. Но чем сильнее становятся модели и код-агенты, тем меньше видно, где реально помог обвес, а где модель справилась сама.

Скоро мы перестанем отличать одно от другого. Спеки будут появляться не «до», как ограничитель, а «после», как документация того, что уже сработало. Граница исчезает не потому, что SDD стал не нужен, а потому что он растворяется в самом инструменте.

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

Поэтому вопрос смещается с «как заставить агента написать код» на «кто отвечает за то, что этот код выдержит рост нагрузки и требований». Это уже не про промпты, а про инженерную дисциплину.

Мы в Byndyusoft разрабатываем с ИИ MVP, который не упирается в потолок на первой же тысяче пользователей, а спроектирован под масштабирование. Модель ускоряет, экспертная команда отвечает за то, что решение переживёт этот рост.

А у вас спеки чаще пишутся до кода или уже после?

Кто виноват, когда ИИ-агент сломал вашё приложение

Model Context Protocol стал стандартом, через который ИИ-агент общается с приложением: передаёт команды, запрашивает данные, выполняет действия.

Но в этой цепочке ошибиться может каждый. Модель — неправильно понять задачу. MCP-сервер — некорректно передать параметры. Приложение — уйти в невалидное состояние. И на выходе вы получаете баг, у которого сразу три подозреваемых.

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

За этим и встречаемся. Обсудим сложные кейсы, сравним опыт, поспорим о подходах к тестированию таких систем.

Приходите со своими историями или просто послушать чужие. Вход свободный, еда и напитки — за свой счёт.

📍 Челябинск, Сидрерия, Цвиллинга, 15/1
Регистрация: https://byndyusoft-event.timepad.ru/event/4150618/

Чат в Telegram: https://t.me/qa_meetups
Чат в Max: https://max.ru/join/osPeH61resYegoyIbcKPLotu52BWttaeThkDu9FqS0M

Если у вас в проде уже крутится связка ИИ-агент — MCP — приложение и вы не уверены, где там слабое место, — это как раз повод для диагностики системы, а не только для разговора на митапе.

Как объяснить LLM-агенту архитектуру сразу нескольких репозиториев

Если проект живёт в нескольких репозиториях — фронт, бэк, воркеры — LLM-агент не видит общей картины. Он работает в контексте одного репо и не знает, какие архитектурные решения уже приняты в соседних.

ADR помогают это исправить. Но где их хранить, чтобы агент мог на них опираться?

Рассмотрели три варианта. Первый — MCP-сервер, который обходит репозитории и отдаёт нужные ADR по запросу. Гибко, но требует инфраструктуры. Второй — git-субмодуль с общими ADR, подключённый к каждому репо. Просто, но синхронизация может стать болью. Третий — инъекция контекста через npm-пакет: ADR упакованы и подтягиваются как зависимость. Работает для JS-стека, но не универсально.

У каждого варианта есть ограничения. MCP-сервер — дополнительный сервис на поддержке. Субмодуль — риск расхождения версий. npm-пакет — привязка к экосистеме.

Идеального решения нет. Выбор зависит от стека и того, насколько агент должен понимать архитектуру в реальном времени.

А как вы храните ADR в мультирепо-проектах?

AI-агенты хороши в песочнице. А на большом проекте?

AI-агенты неплохо справляются с небольшими изолированными задачами. Но стоит зайти на большой долгосрочный проект — и начинаются проблемы.

Первая — контекст. В крупном проекте его просто слишком много. Агент не может удержать всё сразу: архитектурные решения, историю изменений, договорённости между командами. Что-то неизбежно выпадает.

Вторая — неявные знания. Часть правил нигде не записана. Почему сделано именно так, знает только Вася, который ушёл два года назад. Агент этого не вытащит.

Третья — противоречия в требованиях. На интеграционных проектах разные команды хотят разного. Агент не всегда замечает конфликт, а если замечает — не знает, чья сторона важнее.

Это не значит, что AI-агенты бесполезны. Они помогают на конкретных, ограниченных задачах. Но ждать, что агент разберётся в сложной системе с многолетней историей — пока не стоит.

А вы уже пробовали запускать агентов на чём-то большом? Как прошло?

⚽️ Футбол, в котором можно буквально влететь в игру!

Питерский офис Byndyusoft проверил на себе необычный формат — футбол в огромных надувных шарах. Было много смеха, столкновений и непередаваемых ощущений 😄

Кто-то поймал азарт, а кто-то понял: наблюдать за таким футболом всё-таки приятнее, чем участвовать 😅

Завершили вечер в уютном ресторане: вкусно поели, вдоволь наговорились и восстановили силы после этого спортивного эксперимента.

А вы бы решились выйти на поле в таком шаре? 👇

Комментарии в коде пишет ИИ. А читает их кто

GLM, Opus и Codex комментируют код по-разному. Одна модель объясняет каждую строчку, другая — только сложные места, третья добавляет комментарии там, где сама не уверена в логике.

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

Возникает разрыв. Код меняется, комментарий от ИИ остаётся прежним. Или наоборот: модель обновляет комментарии при каждой правке, и в истории изменений тонет реальная логика решений.

Ещё сложнее с ревью. Если комментарий сгенерирован, а не продуман, ревьюер тратит время на проверку текста, который никто не писал осознанно. Формально документация есть. По факту она ничего не объясняет о решении.

Это не вопрос стиля. Это вопрос архитектуры процесса: кто отвечает за смысл кода, если объяснение генерируется автоматически.

Если не уверены, что документация в вашем проекте отражает реальную логику, а не просто выглядит правдоподобно — это повод для диагностики.