Byndyusoft

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 мы строим так, чтобы архитектурный контекст не терялся при масштабировании. Потому что быстро запустить — это одно, а удержать контроль над тем, что растёт — другое. Есть задача запустить решение и не потерять над ним контроль? Напишите — разберём.

Друзья, не теряйте важные навыки 💪

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

Шахматы и ИИ: вечер интеллектуальных экспериментов Первый вечер августа мы посвящаем искусственному интеллекту - технологии, которая меняет правила игры во всех сферах, включая шахматы. В программе - лекция топ-спикера, турнир с уникальным ценным призом🎁 и возможность сразиться с роботом. Главный гость вечера - Руслан Сафин, соучредитель компании «Бындюсофт», преподаватель магистратуры по ИИ в ИТМО и IT-архитектор. В своём выступлении на тему «Шахматы как бизнес-задача: SWOT-анализ дебюта с помощью ИИ в Социотехе» Руслан впервые представит новый инструмент для аналитики дебютов, созданный для анализа бизнеса, но адаптированный и для анализа дебюта. Что вас ждёт: 🎁 Турнир с главным призом - шахматной доской со встроенным искусственным интеллектом. И другие подарки для призеров 🤖 Игра с роботом - испытайте свою силу игры против машинного алгоритма. 🍰Эксклюзивный десерт и авторский коктейль для резидентов клуба. 📍4 августа 🕡 Сбор гостей - 18:30 Большой проспект П.С., 37. Терраса. При изменении погодных условий - внутри ресторана Введенский. 🎫Количество мест строго ограничено. Билеты - у ведущей @pershinanadya. Стоимость: 4500 ₽.

А вот и запись вебинара по Карте Реализации Историй (КРИ) с Андреем Шапиро (автором подхода). Дополнительная информация по Карте Реализации Историй Инструмент, в котором мы рисовали карту А вот ссылки на видео: RUTube VKVideo

Большое обновление моделей в «Социотех»: качество выше, цена та же Мы завершили масштабное обновление моделей, доступных для ИИ-операций. Что изменилось: — в линейку добавлены GLM-5.2 от Z.ai и Kimi K3 от Moonshot AI; — дополнение и валидация карт теперь выполняются на Claude Sonnet 5; — все операции на моделях OpenAI переведены на семейство GPT-5.6; — для наиболее сложных задач используется флагманская GPT-5.6 Sol, для остальных — Terra и Luna; — Qwen обновлён до версии 3.7-Max. ‼️ Обратите внимание на GLM: на задачах Социотеха эта ИИшка работает с качеством лучше и с той же скоростью, что и ChatGPT, но по цене сильно дешевле. Например, генерация Карты гипотез с ChatGPT стоит 25 токенов, а с GLM всего 5 токенов! Для большинства моделей мы также отдельно настроили глубину рассуждений: — средний уровень — для Claude Sonnet и DeepSeek; — повышенный — для GPT; — максимальный — для Kimi и GLM. Параметры подбирались индивидуально для каждого семейства моделей с учётом баланса качества, скорости ответа и стоимости. Результат: более качественные ответы ИИ при сопоставимой стоимости для пользователей «Социотеха». Переходите в Социотех https://sociotech.center и попробуйте обновлённые модели на своих проектах.

🎙 На канале @another_sa вышел подкаст с моим участием [спасибо Андрей @and_burakov, что позвал. Зови ещё!] Говорили про то, что я люблю больше всего: куда едут код-агенты, что будет с индустрией, как поедут наши роли и чему придётся доучиваться. Вышло и правда философски — местами улетали лет на десять вперёд. С этого и начали. Прошлой осенью я впервые на конференции про свой взгляд на будущее (позже написал статью), где сдвиг в методологиях проектирования архитектуры я закладывал на «лет через пять-десять». А в этом месяце сел за ретроспективу своих прогнозов — и обнаружил, что этот сдвиг уже случился, за какие-то полгода. Настолько всё ускорилось. 💨 Несколько мыслей, которые я в подкасте накидываю на вентилятор 🤖 Код-агенты за полгода прыгнули так, что я сам не сразу поверил Прошлым летом я по ночам пилил движок для своих шахмат с кубиками и упирался в тяжёлые расчёты на процессоре — мы с агентом неделями вылизывали профайлером каждый процент, и я его в итоге забросил. Вернулся весной, уже на новых моделях, — и агент даже не стал запускать код: подумал минут десять, прочитал кодовую базу, нашёл хвост рекурсии и применил математический алгоритм, которого я, честно, даже не знал (потом загуглил — действительно есть такой). Час работы — ускорение в 20 раз, и все тесты зелёные. А ещё мы по согласованию с заказчиком сделали коммерческий проект целиком на агентах: ни строчки кода руками, два месяца — сдали и получили оплату. Классической командой людей было бы раза в два больше, а провозились бы минимум в полтора раза дольше. 🌱 От проектирования систем — к выращиванию среды. Это моя главная ставка на будущее. Система — когда ты знаешь все компоненты и связи и держишь их в голове. Среда — когда их столько, что учитывать каждую связь бессмысленно, и ты работаешь на уровне законов: как гладь воды, где форму волны считаешь формулой, не отслеживая каждую молекулу. Архитектор здесь становится садовником — ставит свет, подвязывает, обрезает, а растение тянется само. И это не на самом деле уже сейчас не фантастика: k8s, автоскейлинг, FinOps — всё это отчасти уже имеет в себе элементы средового подхода (а не системного). А SDD и harness для ИИ-агента — это вообще один в один оно и есть: ты не диктуешь строчки кода, а задаёшь законы, стимулы и фитнес-функции, по которым код вырастает сам. Как раз про это моя свежая статья, её в выпуске и разбираем: https://habr.com/ru/articles/1051722/ 🧭 Языки программирования — временный костыль. [Я это уже несколько лет говорю, а на этой неделе и Илон Маск сказал то же самое )) тут должен быть мем: я же говорил] Python, Java, C# придумывали, чтобы код читал и писал человек. Уходит человек из цикла — костыль становится не нужен. Тут я всегда вспоминаю шахматный движок AlphaZero: он разгромил собственную прошлую версию именно потому, что его не кормили человеческими партиями — не досталось наших стереотипов «в дебюте ходи так». Следующий шаг — освободить и ИИ-агентов от наших языков и паттернов, пусть пишут на языке математики. Отсюда мой любимый тезис про джунов: джуны на Python/Java не нужны, а вот просто способные джуны — очень нужны. Только сажать их сразу в кабину экскаватора, а не учить сперва копать лопатой. И одно наблюдение уже про нас самих: ИИ обещал разгрузить, а когнитивная нагрузка выросла. Раньше ты сильно думал, а потом отдыхал мозгом на механике — рисовал схемы, печатал код. Теперь всю механику забирает агент, и держать максимальную концентрацию приходится постоянно. К такому режиму пока не готов ни один из нас — впору вспоминать про медитацию 🧘‍♀️ Послушайте подкаст целиком (там ещё про отбор, ниши, схлопывание ролей, живые возражения ведущего и почему в код лучше не лезть руками): https://youtu.be/Wx1L69NihbM Копаем дальше 🏗

Всем привет! Сегодня у меня день рождения, и я сделал себе к нему подарок — закончил работать над черновиком своей книги "Доказательная архитектура" 😊 🎞️🎞️🎞️🎞️🎞️🎞️🎞️ «Ну ты же архитектор, тебе виднее». Эту фразу слышал, кажется, каждый в профессии, и говорят её обычно с уважением. Только вот с чего виднее? За решением стоит опыт — сколько-то похожих систем, сколько-то прочитанных книг, сколько-то шишек. У коллеги, который предлагает сделать наоборот, найдётся не менее убедительная история. Оба опираются на опыт и оба звучат уверенно, а выбрать в итоге нужно какой-то один вариант. Я много лет собирал ответ на этот вопрос по кускам: в докладах, статьях, спорах, чужих постмортемах и собственных ошибках. Теперь куски собрались в книгу — «Доказательная архитектура». Главный тезис такой: у архитектурного решения должно быть не только описание того, как будет устроена система. Оно должно объяснять, почему мы рассчитываем, что выбранный вариант сработает в нашем контексте, как мы это проверим и какие сигналы заставят нас его пересмотреть. Что внутри, если коротко: ➡️ лестница силы аргументов — от интуиции до эксплуатационных наблюдений: чтобы прямо на архсовете понимать, сколько весит прозвучавший аргумент; ➡️ архитектурная гипотеза: как превратить мнение архитектора в проверяемую запись с механизмом эффекта, метриками и условиями пересмотра, зафиксированными до внедрения; ➡️ принцип каскадного снижения связанности, доведённый до проверяемого неравенства; ➡️ Architecture as Code с тестами: как ловить расхождение схемы и реальности на CI, а не на инциденте; ➡️ метрики архитектуры и способы не обмануть себя ими же; ➡️ как проверять отказоустойчивость, когда начинать архитектурный рефакторинг и что изменится, если приложить тот же аппарат к платформам, процессам и оргструктурам; ➡️ и отдельная глава про то, что со всем этим делает ИИ. В итоге получилось пятнадцать глав со сквозным примером, тянущемся через всю книгу, в конце каждой главы — чек-лист. Сейчас это черновик. Сейчас хочу собрать небольшую группу коллег по цеху желающих прочесть черновик для проверки. Если чувствуете в себе силы осилить и дать фидбэк — пишите в личку @razonrus 😎 В качестве обратной связи по черновику мне нужны минимум две вещи: 1. Общие замечания по содержанию. Где я ошибся, где излишне упростил, где пропустил что-то, где не учёл важный контекст. Это хочется обнаружить до публикации. 2. Точечные комментарии прямо по тексту: неточность, спорный переход, недостающее уточнение. На верстку, стиль картинок, мелкие опечатки и пунктуацию пока можно не обращать внимания. Мне важно именно содержание. Если формулировка мешает понять мысль, конечно, отмечайте: это уже содержательная проблема. Планирую собрать обратную связь за месяца полтора. Спасибо 🙏

Жесткая правда от ИИ. Всем хорошей рабочей недели! 😊

10 минут вместо дня: ИИ пишет хаос-тест сам Один из наших разработчиков писал нагрузочный тест с хаотическим падением сообщений через блокировки в БД. Задача нетривиальная: нужно не просто «иногда падать», а делать это с точными вероятностями и проверять, что retry отрабатывает корректно. Он отдал задачу ИИ. Тот сам реализовал вероятностное распределение ошибок — 10% для одного типа, 4% для другого. Добавил проверку: если retry есть, количество фактических падений должно совпадать с расчётным. Всё это без подсказок по реализации. Вручную такой тест занял бы значительную часть дня. Вышло за ~10 минут. Интересно не то, что ИИ «быстро написал код». Интересно, что он удержал логику задачи целиком — вероятности, механизм retry, граничные условия. Обычно именно это отнимает время: не сам код, а продумывание сценариев. Мы используем ИИ не чтобы заменить разработчиков, а чтобы убрать рутину из сложных задач. Там, где раньше тратили день на тест — теперь тратят час на что-то важнее. Если хотите разобраться, где в вашей разработке ИИ реально сокращает время — напишите нам. Покажем на конкретных сценариях.

Анонс мини-курса по Карте реализации историй Сколько раз вы видели, как команда усердно работает над фичей, но потом выясняется: в ней нет ничего важного для потребителя? В бэклоге всё аккуратно, в макете всё красиво, разработка идёт — и всё же приходится выкидывать или переделывать, потому что смысл задачи потерялся где-то между первым разговором и итоговым интерфейсом. Если вы аналитик, продакт, дизайнер или разработчик и вам приходится объяснять, зачем вообще нужна функция, а не только что в ней должно быть, этот разрыв вам знаком. Карта реализации историй даёт недостающий мост. Она удерживает в одном ёмком описании действия его носителя, ситуацию, способ работы, объекты оперирования и цель. Поэтому требования можно провести от шага в процессе до структуры интерфейса и показать, откуда взялся каждый блок, вместо того чтобы прикрываться догадками и домыслами. Я собрал мини-курс, чтобы этот подход, отточенный до уровня технологии, вы освоили на своей ситуации и принесли в команду. Восемь занятий через день, онлайн; останутся видео, шаблон, практические задания и разборы. —— Мини-курс по Карте реализации историй