Byndyusoft

Во время ИИ-трансформации главное не заменить самого себя. Доброе утро, коллеги 😊

«Белковые» паттерны больше не нужны Интересно, что почти вся история разработки программного обеспечения — это попытка справиться с его главным свойством: софт слишком легко менять. Построенный девятиэтажный дом никто не предложит раздвинуть посередине, чтобы вставить туда аквариум. А в программном продукте подобные просьбы возникают постоянно и часто звучат вполне разумно. Именно поэтому появились архитектура, всякие SOLID, тесты и TDD, типизация, микросервисы, контроль версий, CI/CD, Agile и множество других практик. Весь этот сложный огород нужен потому, что каждое новое изменение должно сохранить всё, что уже работало ранее, и вносить новое с сохранением возможности новых изменений. С приходом ИИ фундаментальная проблема никуда не исчезает. Софт остаётся аморфным, требования продолжают меняться, а прежнее поведение по-прежнему нужно воспроизводить в коде и дизайне со стопроцентной точностью. Только теперь изменения вносит ИИ-станок, у которого нет человеческой памяти о проекте, устойчивого фокуса и неявного понимания того, «почему здесь всё устроено именно так». Поэтому, возможно, мы стоим не просто перед очередной сменой инструментов разработки. Нам предстоит заново изобрести сами паттерны работы с изменениями. Прежние паттерны во многом были рассчитаны на «белкового» разработчика: на его ограничения, способы мышления, потерю контекста и необходимость координации с другими людьми. Новые паттерны должны описывать уже не поведение программиста, а поведение всей системы.

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

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

ИИ для руководителя: как превратить бизнес-цель в работающую стратегию Стратегия редко разваливается из-за недостатка идей. Чаще причина в другом: цель сформулирована неточно, предположения выданы за факты, между решениями и результатом нет ясной связи, а интересы ключевых людей не учтены. В этой записи Олег Корнев на живом примере показывает, как использовать ИИ для разработки стратегии — не передавая ему мышление и ответственность за решения. За время мастер-класса мы с нуля разбираем стратегию B2B-компании, работающей с промышленным оборудованием: — уточняем бизнес-цель и связываем рост выручки с прибылью; — определяем метрики, по которым можно понять, работает ли стратегия; — находим людей и организации, от поведения которых зависит результат; — разбираем их боли, интересы и мотивацию; — формулируем три проверяемые гипотезы для заказчиков, поставщиков и управленческой команды; — превращаем гипотезы в конкретные задачи; — проводим финальный аудит и находим ошибки, способные разрушить всю логику стратегии. Вся работа происходит прямо в Социотехе. ИИ подключается к проекту, анализирует карту, помогает увидеть слабые связи и задаёт неудобные вопросы. Но окончательное решение всегда остаётся за руководителем. Главная мысль мастер-класса: ИИ не должен думать вместо вас. Его сила в том, чтобы удерживать логику, замечать противоречия и помогать превращать управленческие идеи в систему, которую можно проверить действием.

Мастер-класс ведёт Олег Корнев — коммерческий директор с опытом более 10 лет в управлении производственно-торговыми направлениями B2B и B2C.

Смотрите запись и попробуйте после просмотра разобрать таким же способом одну реальную цель своего бизнеса. MCP Социотеха: https://sociotech.center/mcp Готовые скиллы для ИИ: https://github.com/Byndyusoft/sociotech-ai-skills

ИИ для руководителя: как превратить бизнес-цель в работающую стратегию

Почему даже хорошие планы иногда не приводят к результату? Часто мы путаем цель с перечнем действий, принимаем предположения за факты и не учитываем, почему клиенты, партнёры или сотрудники должны поступить именно так, как мы ожидаем.

На онлайн-мастер-классе разберём, как использовать ИИ, чтобы принимать более продуманные управленческие решения — не отдавая ему ответственность и не подменяя собственное мышление. На живом примере мы с нуля разработаем стратегию в Социотехе: – определим, какого бизнес-результата хотим достичь; – разберёмся, от кого и от чего он зависит; найдём слабые места и непроверенные предположения; – превратим общие идеи в понятные решения и следующие шаги; – покажем, где ИИ действительно помогает руководителю, а где последнее слово должно оставаться за человеком. Мастер-класс проведёт Олег Корнев — коммерческий директор с опытом более 10 лет в управлении производственно-торговыми направлениями B2B и B2C. 📅 Встречаемся в среду в 15:00 мск. Регистрируйтесь и приходите — за один мастер-класс разберём весь путь от бизнес-цели до связной и реалистичной стратегии. 👉 https://byndyusoft-event.timepad.ru/event/4160048/

Скоро вы не поймёте, где работает SDD, а где сама модель Разработчик поправил верстку прямо в Codex без OpenSpec, а спеки написал уже потом. Мелочь, но она показывает, куда всё движется. Spec-driven development сейчас — это обвес вокруг модели. Мы пишем спеки, гоняем их через харнесс, страхуемся от галлюцинаций и потери контекста. Но чем сильнее становятся модели и код-агенты, тем меньше видно, где реально помог обвес, а где модель справилась сама. Скоро мы перестанем отличать одно от другого. Спеки будут появляться не «до», как ограничитель, а «после», как документация того, что уже сработало. Граница исчезает не потому, что SDD стал не нужен, а потому что он растворяется в самом инструменте. Когда непонятно, что держит качество — процесс или модель — легко решить, что процесс лишний. А потом на масштабе выясняется, что без внятной архитектуры и проверяемых спеков система разваливается ровно там, где модель молча ошиблась, а поймать это было нечем. Поэтому вопрос смещается с «как заставить агента написать код» на «кто отвечает за то, что этот код выдержит рост нагрузки и требований». Это уже не про промпты, а про инженерную дисциплину. Мы в Byndyusoft разрабатываем с ИИ MVP, который не упирается в потолок на первой же тысяче пользователей, а спроектирован под масштабирование. Модель ускоряет, экспертная команда отвечает за то, что решение переживёт этот рост. А у вас спеки чаще пишутся до кода или уже после?

Наверное это тот выпуск, которым я особенно горжусь. Злободневно, вечно и можно разбирать на цитаты. 💡Почему после стратсессии ничего не меняется? Почему после большинства стратсессий стратегия так и не появляется, а остаются "амбициозные" цели на доске, сотни задач и ощущение, что команда очень занята и всем некогда пописать. В этом выпуске разбираемся, как связать стратегию с операционкой, почему ресурсы должны получать только обоснованные задачи и как AI помогает увидеть, куда на самом деле уехала команда. В гостях — Александр Бындю @alexanderbyndyu, методолог, предприниматель, автор технологии «Карта гипотез» и книги «Антихрупкость в IT». Было остренько, но все жизнь. 🎬YouTube| 🎬ВК видео Я вангую, если вы строите бизнес как собственник или часть команды – вы получите удовольствие от просмотра. Enjoy.

Сегодня наглядно покажу, как ответить на два вечных вопроса руководителя: 1. Куда вложить ограниченные ресурсы, чтобы прийти к результату? 2. Как понять, что операционка не разошлась с выбранной стратегией? Это не доклад, а практика. Я продемонстрирую, как с помощью ИИ-агента связать стратегию в Социотехе с любым источником операционных задач: Битрикс24, amoCRM, 1С, Kaiten, Jira,... или обычным файлом. Если вы руководитель, бюджеты у вас не бесконечные, а целей достигать нужно — приходите посмотреть, обсудить и попробовать. Регистрация: https://byndyusoft-event.timepad.ru/event/4140094/

Кто виноват, когда ИИ-агент сломал вашё приложение 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 в мультирепо-проектах?

Вот это подарок! 20 августа в 15:00 МСК ждём руководителей на эфире «Как с помощью стратегии увеличить показатели за месяц».

Всё чаще возникает странное ощущение: инструменты для нормального стратегического управления уже доступны почти каждому, а многие компании до сих пор управляются примерно так: «кажется, надо усилить продажи», «давайте наймём ещё людей», «маркетинг что-то просел», «конкуренты опять что-то придумали» и вечное «срочно тушим вот это».

При этом у руководителей сейчас хватает задач и без управленческого шаманства: •показатели стоят или растут не туда, команда загружена, а результат не пропорционален усилиям; •идей много, понять, какую проверять первой, сложно; •отделы оптимизируют свои KPI и иногда бодро портят общий результат; •планы меняются быстрее, чем успевает закончиться совещание; •ИИ ускоряет рынок так, что вчерашнее конкурентное преимущество сегодня уже просто функция в подписке за $20. И вот здесь уже правда немного странно жить без стратегии. В 2026 году управлять бизнесом только опытом и интуицией примерно как ехать в незнакомый город без навигатора, когда телефон лежит у вас в кармане. Конечно, можно. Возможно, даже доедете. Но зачем так усложнять себе жизнь? Ещё пару месяцев назад разговор о системном стратегическом мышлении можно было воспринимать как разговор о будущем. Сейчас это уже настоящее. И довольно скоро к огромному количеству профессий придётся мысленно добавлять слово «стратег»: руководитель-стратег, маркетолог-стратег, операционный директор-стратег. Потому что сегодня недостаточно просто генерировать идеи. Нужно понимать, какая из них способна сдвинуть показатель, как её проверить, сколько на это потратить и что при этом нельзя случайно испортить в соседнем углу бизнеса.

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

Приходите со своими задачами. Готовьте вопросы, цифры, тупики, спорные решения и всё, на что хочется сказать: «Мы уже всё попробовали». Очень любим начинать именно с этого места🙂 20 августа, 15:00 МСК. Эфир для руководителей. Регистрируемся!

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

Надиктовка историй в паре с агентом Вот так, голосом, через MCP Социотеха я правлю и добавляю новые рабочие истории в Карту реализации историй. Досмотрите до конца, это даст интуицию для других применений. Особенно полезно, когда предстоит множество преобразований, массовые импорты/экспорты или рефакторинги досок. Кстати, ближайший мини-курс по КРИ будет именно в Социотех. С ним не нужно тратить время на вёрстку карты и, так как все карты связаны единой моделю данных, работать с код-агентами с ними милое дело.

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

⚽️ Футбол, в котором можно буквально влететь в игру! Питерский офис Byndyusoft проверил на себе необычный формат — футбол в огромных надувных шарах. Было много смеха, столкновений и непередаваемых ощущений 😄 Кто-то поймал азарт, а кто-то понял: наблюдать за таким футболом всё-таки приятнее, чем участвовать 😅 Завершили вечер в уютном ресторане: вкусно поели, вдоволь наговорились и восстановили силы после этого спортивного эксперимента. А вы бы решились выйти на поле в таком шаре? 👇

Доброе утро, коллеги ☀️

Тестировать код без документации — это как чинить машину с закрытыми глазами 29 июля QA Meetup прошёл сразу в двух городах — Санкт-Петербурге и Челябинске. Собрались, чтобы обсудить конкретную боль: как тестировать функциональность, написанную в режиме вайб-кодинга. Без требований, без документации, без понятной истории решений. Разговор быстро вышел за рамки одной темы. Заговорили про агентскую разработку в целом: как работать с AI-инструментами, как контролировать результат, какие риски это несёт и как быстро копится технический долг. Эта тема не случайна. Когда код пишет AI-агент, а не человек по спецификации, у команды часто нет ответа на простой вопрос: почему система работает именно так. Решения принимались на лету, логика зашита в код, а не в документы. Тестировать такое сложно — риски скрыты, а не очевидны. Именно с этим мы разбираемся в услуге «Аудит и диагностика процессов и цифровых систем»: смотрим, что реально происходит внутри системы, где скрыт технический долг и какие решения принимались без фиксации логики. Это особенно актуально для продуктов, где часть кода писал AI. Спасибо всем, кто пришёл и делился опытом. До встречи на следующих митапах. Telegram: https://t.me/qa_meetups Max: https://max.ru/join/osPeH61resYegoyIbcKPLotu52BWttaeThkDu9FqS0M

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

🚀 Подключи своего ИИ-агента к Социотеху! Подключиться можно здесь: https://sociotech.center/mcp Самое интересное — можно давать ему комплексные поручения, которые руками в интерфейсе делать долго и сложно. Например: 🔎 Исследовать рынок и сразу дополнить проект Посмотри мой проект про кафе. Зайди на сайт франшизы, собери оттуда данные о бизнес-модели, инвестициях, окупаемости и требованиях к помещению, а затем добавь важные выводы в SWOT-анализ. 📊 Найти недостающие бизнес-метрики Посмотри, какие метрики уже есть в моём проекте. Добавь метрики, которые обычно используются в похожем бизнесе, чтобы я ничего не забыл. Для каждой метрики создай связанные цепочки из субъектов, гипотез и задач. 🕵️ Провести конкурентный анализ Найди пять основных конкурентов, изучи их сайты, продукты, цены и позиционирование. Сравни их с моим проектом, обнови SWOT и добавь гипотезы, как мы можем от них отстроиться. 🧩 Найти дыры в проекте Проверь весь проект на логические разрывы: цели без метрик, метрики без задач, гипотезы без способов проверки и задачи, которые ни на что не влияют. Предложи исправления и добавь недостающие связи. 🗣️ Разобрать интервью с клиентами Изучи записи интервью в папке проекта. Выдели боли, потребности, возражения и повторяющиеся паттерны. Создай на их основе субъектов и гипотезы, а для самых сильных гипотез добавь задачи для проверки. 🗺️ Перенести карту из Miro в Социотех Я скачал карту гипотез, которую рисовал в Miro. Прикрепляю файл. Распознай структуру карты, создай новый проект в Социотехе, перенеси в него все данные и восстанови связи между субъектами, гипотезами, метриками и задачами. 🧨 Устроить стратегии стресс-тест Представь, что ты инвестор, конкурент и недовольный клиент. С трёх точек зрения раскритикуй мой проект, найди самые рискованные предположения и добавь гипотезы и задачи, которые помогут проверить их как можно раньше. 🧹 Навести порядок во всём проекте Найди дублирующиеся сущности, противоречащие друг другу гипотезы и слишком общие задачи. Объедини дубли, уточни формулировки и сохрани все важные связи. Пробуйте придумывать собственные сценарии — чем сложнее и «хитрее» поручение, тем заметнее польза MCP https://sociotech.center/mcp. Вопросы, идеи и обратную связь оставляйте в комментариях 👇

Код не врёт. Но вы можете его не слышать Когда разработчик смотрит в код и понимает, что «здесь что-то не так» — это не интуиция. Это ментальная модель системы, которая живёт у него в голове. Ментальная модель — это представление о том, как части системы связаны между собой, где проходят границы ответственности, что должно происходить при том или ином изменении. Без неё ревью превращается в чтение строк, а не в понимание смысла. С AI-агентами это становится острее. Агент генерирует код быстро и уверенно. Он не знает контекста вашей архитектуры, не держит в голове неочевидных зависимостей, не помнит, почему три месяца назад приняли именно это решение. Заметить расхождение между тем, что агент сделал, и тем, что система ожидает — может только человек с моделью в голове. Если такого человека нет или модель устарела — ошибки не отловить на ревью. Их найдут позже. В проде. MVP с AI мы строим так, чтобы архитектурный контекст не терялся при масштабировании. Потому что быстро запустить — это одно, а удержать контроль над тем, что растёт — другое. Есть задача запустить решение и не потерять над ним контроль? Напишите — разберём.