Byndyusoft

Zed научил своего агента новым трюкам — и Linux-разработчики заметят первыми Zed получил поддержку Skills для встроенного AI-агента. Теперь разработчики могут складывать конкретные навыки прямо в агента — и управлять тем, что он умеет, не выходя из редактора. Это меняет разговор о встроенных агентах. Раньше выбор был простой: либо внешний агент с гибкостью, либо встроенный с удобством. Zed начинает стирать эту границу — внутренний агент получает расширяемость, которую раньше давали только внешние инструменты. Отдельный момент для Linux-разработчиков. GUI-версии Codex под Linux нет. Zed есть. И теперь с агентом, который умеет в Skills, — это уже не «альтернатива на крайний случай», а рабочий выбор. Такие обновления хорошо показывают, куда движется инструментарий: AI всё глубже встраивается в среду разработки, а не висит рядом отдельным окном. Команды, которые это учитывают сейчас, не будут догонять через год. Если вы думаете, как встроить AI-агентов в рабочие процессы своей команды — мы поможем разобраться, что реально даст результат. Напишите в личку или оставьте заявку на сайте.

ИИ читает pull request и говорит QA, что проверять Регрессионное тестирование часто превращается в «проверь всё и молись». QA-инженер смотрит на релиз и пытается угадать, что могло поломаться. Мы проверяем идею: ИИ анализирует pull request и определяет, какие части системы затронуты изменениями. На выходе — конкретный список того, что стоит перепроверить. Не весь продукт, а именно те зоны, которые задела правка. Это не замена QA и не автотесты. Это подсказка: «смотри сюда». Инженер всё равно принимает решение — но уже не с чистого листа. Идея пока на стадии проработки. Если вы сталкивались с похожей задачей или уже пробовали что-то подобное — расскажите, как решали.

Бенчмарки врут. Вот что говорит реальный код Наши инженеры сравнили Claude Sonnet 4.6, GPT 5.4/5.5 и GLM 5.1 в реальных задачах агентного кодинга. Не на синтетических тестах — на живом коде. Главный вывод: публичные бенчмарки почти бесполезны при выборе модели под конкретный тип задач. Они показывают среднюю температуру по больнице, а не то, что происходит, когда агент обходит десять файлов и пишет миграцию. Mode thinking — Medium или High — меняет не только качество, но и расход токенов. High даёт заметно лучший результат на сложных задачах, но цена вырастает ощутимо. На простых задачах эта разница практически не видна, и платить за неё нет смысла. Claude Sonnet 4.6 в агентных сценариях ведёт себя стабильнее при многошаговых цепочках. GPT 5.5 выигрывает там, где важна широта контекста. GLM 5.1 — неожиданно конкурентный вариант там, где бюджет ограничен. Если вы строите агентную систему и выбираете модель «по рейтингу» — скорее всего, переплачиваете или получаете не то. Выбор модели — это часть архитектуры, а не настройка. Мы занимаемся именно этим: проектируем и внедряем ИИ-агентов под реальные процессы. Если хотите разобраться, какая связка подойдёт вашей задаче — напишите нам.

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

Это сильно повышает качество стратегической работы. Потому что хорошая гипотеза отвечает не только на вопрос «что мы сделаем?», но и на вопрос: почему субъект после этого начнёт вести себя иначе?

— ЭКГ по красному пути Особенно полезны эти функции для построения ЭКГ по красному пути. ЭКГ — это Экспресс Карта гипотез, быстрый способ собрать стратегический скелет не всей карты целиком, а только самого важного пути:

цель → ключевая метрика → ключевой субъект → его главная боль или желание → гипотеза → задачи

Красный путь нужен, чтобы не утонуть в десятках веток, а быстро понять: за счёт чего мы реально собираемся достичь цели. Это удобно на первых встречах, стратегических сессиях, продуктовых обсуждениях и разборе новых инициатив. За короткое время команда видит не абстрактную стратегию, а конкретную логику действия: какую метрику двигаем, через какого субъекта, за счёт какой мотивации и какими гипотезами. — Кому это может быть полезно? Фасилитаторам стратсессий, стратегическим консультантам, трекерам, продуктовым командам, маркетингу, продажам, HR и руководителям — всем, кто использует Карту гипотез не как красивую схему, а как инструмент принятия решений. Новые функции уже доступны в Социотехе. Попробуйте вынести метрики и мотивацию субъекта на вашей карте или пройти с командой по красному пути от цели до конкретных задач.

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

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

Рабство привычки сегодня стоит дорого Человек делает что-то каждый день. То, как он что-то делает, оставляет на нём неизгладимый след, вгрызается в него и закрепляется на нём. То, что философы называли modus operandi, или способ действия, буквально прописывается на человеке и становится его привычкой. Когда мы ходим одним и тем же маршрутом или завариваем любимый напиток одним-двумя излюбленными способами, всё это способы действия, которыми мы «пропитались». Человеку обычно очень трудно целенаправленно сменить привычный приём. Для этого нужно как будто проснуться и увидеть возможность такой смены. В практике жизни я вижу, что большинству начхать на это, им просто хочется продолжать жить как они жили, ничего не меняя. Близкие мне люди, когда я вижу, как они справляются с каким-то действием, и предлагаю альтернативу, почти всегда отказываются от непрошеных идей. С одной стороны, это очень понятно: нужно как-то потакать своему эго. Вот я и отправляюсь с «совет свой себе посоветуй». С другой стороны, я не понимаю, как можно отказываться от новых стратегий выживания. Чтобы проиллюстрировать, насколько глубоко в нас сидят автоматические процедуры, поделюсь самонаблюдением. На участке между домом и офисом есть магазин музыкальной техники. Время от времени я заказываю туда что-то и чаще всего забираю заказы на пути из офиса домой. Дорог туда и обратно множество, и когда я планировал забрать оттуда заказ, я мысленно представлял, как пойду после рабочего дня. Но это всегда было только на обратном пути. Одним утром я увидел в списке дел «зайти за заказом», решил по привычке, что сделаю это вечером на обратном пути, и двинулся в офис. Ураганный ветер сильно скорректировал мой обычный маршрут и я чуть сдвинулся. Каково же было моё удивление, когда я вдруг оказался рядом с тем магазином и сопоставил одно с другим: моё местонахождение и задачу в списке. Удивление моё было вызвано тем, насколько зашоренно я думал с утра. Почему я сразу не увидел альтернативной возможности и не рассмотрел её? А сколько ещё таких вариантов я упускаю? Почему я настолько ведом тем, что прописалось во мне, также как феромоновая дорожка действует на муравья? Не стоит и говорить о том, как глубоко прописалась в моих коллегах привычка «нанимать» привычные средства для решения задач в разработке. Недавно сидел вместе с коллегой, он технологический лидер в компании, очень способный малый. Мы вместе решали задачу новым способом. По окончанию он был ошеломлён разницей в трудозатратах. Новый способ решал задачу за час против двух дней старым способом. На следующий день я услышал на летучке, что он собирается вновь применить старый способ для другой задачи. Я удивился и подошёл к нему побеседовать. Чтобы не удлинять рассказ, скажу итог. Человеку нужно несколько раз самому убедиться в том, что новый способ лучше, а для этого нужно к нему несколько раз вернуться, чему мешает старая привычка. Здесь я передаю привет всем агентам изменений в ИИ-трансформации. ИИ-трансформация почти никогда не упирается только в качество новых инструментов. Она упирается в старые способы действия, которые прочно «гнездятся» на людях и командах. Можно один раз показать, что новый ход быстрее, дешевле и умнее, и всё равно на следующий день люди вернутся к старому.

Так что задача «внедрить ИИ» это только команда «фас». Настоящее дело будет за тем, как помочь команде несколько раз пройти новым путём, пока он не перестанет быть чужим.

Если вы видите, что команда уже попробовала новые ИИ-средства, но продолжает жить по-старому, значит проблема не в инструменте. Значит, нужно менять способ действия.

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

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

Язык — это инструмент мышления. Деградирует инструмент — деградирует мышление.

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

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

AI-агент читает весь git log — и сжигает токены впустую Когда AI-агент работает с терминалом, он читает всё подряд: полный git log, длинный ls, весь вывод тестов. Каждая лишняя строка — это токены. И деньги. Инструмент rtk-ai/rtk позволяет фильтровать этот вывод до того, как он попадёт в контекст модели. Большие логи, избыточные листинги, многословные отчёты тестов — всё это можно обрезать или сжать по правилам. Агент получает только нужное. Контекст не засоряется, токены не тратятся впустую. Если у вас есть агенты, которые активно работают с терминалом — стоит посмотреть на rtk-ai/rtk. Ссылка в комментариях.

Как научить агента проектировать систему, а не просто выполнять задачи У нас прошла открытая онлайн-встреча по ИИ-агентам. Один из докладов зацепил сильнее других — про «зазор творчества». Идея такая: когда агент проектирует или выращивает ИТ-систему, ему нужна мета-система сверху. Она не выполняет задачи — она управляет тем, как агент принимает решения об архитектуре и развитии системы. Без такой мета-системы агент либо действует хаотично, либо слишком жёстко ограничен. «Зазор творчества» — это пространство между полным контролем и полной свободой, где агент может работать осмысленно. Разобрали, как этот зазор выстроить и почему это не абстракция, а реальная инженерная задача. Если тема интересна — пишите в комментарии, поделимся материалами встречи.

Социотех теперь умеет сам строить Карты гипотез В феврале я показывал как размышлять о ситуации с помощью Связанного SWOT-анализа. И ключевым в этой истории было то, что ИИ теперь может здорово помогать стартовать в размышления с нуля или достраивать их. Сегодня я рад поделиться тем, что мы добавили генерацию в Карту гипотез с Социотехе. Показываю на примере идей по популяризации технологии КРИ Попробуйте и сами — https://sociotech.center/

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

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

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

— Как это работает? Два сценария 1. Если карта уже есть — но «недожата» Набросали цель, метрики, ключевых субъектов — но чувствуете, что чего-то не хватает? → Жмёте «Дополнить с ИИ» → выбираете модель (Gemini, ChatGPT, Claude, Гигачат, DeepSeek, Qwen) → получаете 10–20 связанных элементов: метрики, мотивация, гипотезы, задачи.

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

Что это даёт: вместо «вроде всё учли» — вы видите, где пробелы. Например, как боль пользователя в мобильном приложении тянет за собой задачу по интерфейсу и метрику удержания. 2. Если начинаете с нуля Нет даже черновика? Загружаете документ — ТЗ, бриф с клиентом, презентацию компании или своё резюме, если делаете личную стратегию. → ИИ анализирует текст → собирает черновик прогноза, анализа и Карты гипотез: цели, субъекты, метрики, гипотезы, задачи.

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

Что это даёт: старт без «муки первого листа». Не идеально, но уже есть за что зацепиться. — Зачем это вам? Не про «удобно», а про результат ♦️ Вы экономите не время — энергию. Ручное связывание фактов выматывает. ИИ берёт рутину на себя, вы оставляете себе право решать. ♦️ Вы видите то, что иначе упустили бы. Например, как гипотеза про «удобство оплаты» влияет на средний чек, а та — на задачу по интеграции платёжки. ♦️ Вы говорите с командой на одном языке. Каждая гипотеза — в формате «Если… То… Потому что… Тогда...». Меньше недопонимания, больше фокуса на проверке. ♦️ Вы остаётесь в контроле. ИИ предлагает — вы выбираете. Принять, отклонить, отредактировать: финальное решение всегда за вами. — Когда это действительно нужно 📌 На старте проекта — чтобы быстро собрать черновик стратегии из разрозненных данных. 📌 Когда карта «застоялась» — и требует свежих гипотез или детализации. 📌 Когда в команде разные взгляды — и нужно визуализировать общую картину. 📌 Когда дедлайн близко, а стратегия ещё в голове.

ИИ не заменяет ваше мышление. Он не знает контекст так, как знаете вы. Он не чувствует нюансы, которые очевидны вам после трёх встреч с клиентом. Но он помогает не утонуть в деталях. Как черновик, который можно взять за основу. Как второй взгляд, который подсказывает: «А что если посмотреть сюда?»

Если хотите проверить, как это работает в вашей задаче: Социотех → Карта гипотез → «Дополнить с ИИ» или «Создать с ИИ» → выбрать модель. 🔗 https://sociotech.center

Руслан, технический директор нашей компании, выпустил статью на Хабре. Это текст по мотивам его доклада о будущем ИТ. В этот раз Руслан отошёл от привычных прикладных тем вроде микросервисов, отказоустойчивости и тестирования архитектуры. И попробовал посмотреть шире. В статье он пишет о том, что меняется в ИТ из-за ИИ. Почему архитектура никуда не исчезает. И почему роль разработчика постепенно смещается от простого написания кода к работе со сложностью: постановке задач, проектированию, выбору ограничений и проверке результата. Главная мысль простая: инженерия не становится менее важной. Она просто меняется. Текст местами спорный, и в этом его смысл. Там есть и про то, что языки программирования могут стать промежуточным слоем, и про архитектуру как способ держать сложность под контролем, и про разработчика будущего — где-то между архитектором, аналитиком и тимлидом ИИ-агентов. Читайте статью на Хабре: https://habr.com/ru/articles/1027144/ И, как пишет сам Руслан, ставьте огонёчки, плюсики в карму и всё, что там принято на Хабре.

☕️ Дизайн-завтрак №43: Разбираем менторство Менторство — это модный тренд или эффективный инструмент развития? Если мысль о менторстве у вас уже возникала, но каждый раз что-то останавливало — самое время встретиться и обсудить эту тему вживую. Разберемся, кому и для чего оно нужно на самом деле. Обсудим: • Что ожидать от ментора и менти? • Как получить максимум пользы от такого взаимодействия? • Какие мифы мешают менти и с какими проблемами сталкиваются сами менторы? Приглашаем на живое обсуждение дизайнеров, продактов, разработчиков и всех, кто хочет разобраться в теме или поделиться личным опытом. 📅 26 мая, вторник, в 19:00 📍 Failover Bar, ул. 2-я Советская, 18, СПб ☕️ Вход свободный. Еда и напитки — за свой счёт. 💬 Чтобы не пропустить новые встречи и детали, добавляйтесь к нам в чат: https://t.me/+Sfytv_pNjxE0MGFi ТГ-канал Failover Bar: https://t.me/failoverbar ❗ Для участия зарегистрируйтесь: https://byndyusoft-event.timepad.ru/event/3986921/

Уже завтра (в субботу!) встречаемся на конференции UWDC — и продолжаем вечер на афтепати! На конференции мы подготовили подарки для авторов лучших вопросов на докладах наших секций. Любим живые обсуждения, неожиданные вопросы и настоящий интерес к теме — поэтому хотим отметить самых активных участников 🎁 А вечером встретимся уже в более неформальной атмосфере: Бындюсофт выступает спонсором афтепати. Там тоже будут подарки — разыграем их среди участников, которые будут активно общаться, знакомиться и заряжать вечер энергией 😉 Вечер в баре — это отличная возможность поговорить со спикерами и участниками без формальностей: обсудить доклады, обменяться историями и почувствовать атмосферу настоящего комьюнити. Так что задавайте смелые вопросы на конференции, включайтесь в обсуждения вечером — и приходите за новыми знаниями, знакомствами и подарками. Увидимся на UWDC!

AACT 2.0: Architecture as Code становится ближе к ежедневной разработке 🚀 У нашего Open Source-репозитория AACT — большое обновление. Контрибутор Сергей @chs237 проделал огромную работу: теперь AACT можно использовать не только как набор примеров и идей, но и как полноценный инструмент — консольную утилиту и npm-пакет. AACT — это инструменты для работы с архитектурой в формате as Code: тестирование архитектурных договорённостей, анализ зависимостей, автогенерация и проверка принципов проектирования. Что поддерживает командная строка: — CLI-команды для старта, проверки, анализа и генерации архитектуры: npx aact init npx aact check npx aact check —fix npx aact analyze npx aact generate — поддержка PlantUML и Structurizr; — проверки архитектурных принципов и паттернов: ACL, acyclic dependencies, API Gateway, CRUD-сервисы, database per service, cohesion > coupling, stable dependencies, common reuse principle; — анализатор архитектурных метрик, включая проверку принципа каскадного снижения связанности; — auto-fix для части нарушений: AACT не просто находит проблему, а может аккуратно поправить её в PlantUML или Structurizr DSL с учётом границ контекстов и naming convention. Масштаб обновления впечатляет: 77 коммитов, 139 файлов и 267 тестов. Для нас это важный шаг к идее, в которую мы верим: архитектурные договорённости должны жить не только в головах, презентациях и Confluence, а проверяться автоматически — так же естественно, как тесты и линтеры проверяют код. Спасибо Сергею за вклад в развитие AACT и Open Source 🙌 Репозиторий: https://github.com/Byndyusoft/aact PR: https://github.com/Byndyusoft/aact/pull/17 Видео с примером использования CLI в канале Руслана: https://t.me/rsa_enc/406 Будем рады звёздам на GitHub, вопросам, Issues, Pull Request’ам и идеям: каких возможностей вам не хватает в инструментах для Architecture as Code?

UWDC послезавтра — и мы там со всем, чем можем 16 мая в Челябинске пройдёт UWDC — и в этом году Byndyusoft там очень плотно. Мы собрали четыре секции: бэкенд, фронтенд, дизайн и QA. Большую часть программы сформировали наши программные комитеты. От нас выступят три спикера. Андрей Шапиро расскажет про техники структурирования беседы — с заказчиком, командой и собой. Никита Моргунов объяснит, почему любит Икею и при чём тут SignalR. Руслан Сафин поговорит о будущем ИТ-архитектуры и роли архитекторов. Регистрация бесплатная. Полная программа — на uwdc.ru/events/uwdc2026/timetable До субботы два дня. Успевай.