[2/2] Virtual Agent Economies (Рубрика #AI)

Продолжая рассказ про этот whitepaper, расскажу про методологию авторов, где они выполняли концептуальное моделирование виртуальных экономик агентов ИИ, опираясь на метафору «песочницы». Sandbox экономика определяется как набор связанных цифровых рынков, где агенты ИИ обмениваются между собой услугами и ресурсами. Такой «песочнице» можно придать разные свойства, варьируя два основных параметра:
1. Происхождение системы – стихийное развитие vs. намеренно спроектированная среда. В первом случае экономика агентов возникает как побочный продукт широкого внедрения ИИ без единого плана, во втором – люди сознательно создают ограниченную среду для экспериментов и отработки правил
2. Проницаемость границ – проницаемая экономика агентов, плотно интегрированная с человеческой (агенты свободно взаимодействуют с внешними рынками), vs. непроницаемая (закрытая от прямого влияния на внешнюю экономику, чтобы локализовать риски)

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

1. Научные исследовательские агенты: Группа агентов могла бы совместно ускорять научный прогресс – одни генерируют гипотезы, другие проводят эксперименты, обмениваясь ресурсами. Поскольку исследования требуют доступа к оборудованию, данным и участию разных организаций, агенты должны договариваться о доступе к ресурсам и взаимно компенсировать затраты. По сути, возникает рынок, где агент лаборатории может “нанять” другого агент-аналитика или купить данные, а расчеты и учет вкладов осуществляются через блокчейн для надежного распределения кредитов за результаты исследований
2. Роботы-агенты: В сценарии из области робототехники предполагается, что физически воплощенные ИИ (роботы) будут обмениваться задачами для оптимизации усилий. А все транзакции будут фиксироваться на распределенном реестре (блокчейне), создавая доверенную запись о том, каково участие каждого агента.
3. Персональные ассистенты: Взаимодействие личных AI-ассистентов пользователей, где два ИИ-агента, представляющие интересы разных пользователей, вынуждены вести переговоры из-за конфликта предпочтений. В этом микромире агенты выступают как прокси для людей, автоматически достигая компромиссов – по сути, реализуя рыночный механизм спроса и предложения для персональных услуг.

Новизна подхода авторов состоит в том, что они попытались соединить современные возможности многокомпонентных систем ИИ с экономическими механизмами и принципами справедливости (аукционы), а также принести идею «миссионных экономик», то есть целевых рынков агентов, нацеленных на решение крупных общественных задач (напр., изменение климата, глобальные риски). Авторы предполагают, что можно спроектировать такие экономики, где ценовые сигналы и вознаграждения привязаны к достижению коллективных целей, стимулируя агентов координироваться во благо определенной миссии.

Для работы такой агентской экономики потребуется соответствущая инфраструктура: системы удостоверений и репутации для доверия, стандартизованные протоколы общения вроде Agent2Agent (A2A) и Model Context Protocol (MCP) для совместимости агентов, инструменты мониторинга и регулирования поведения агентов во времени, основанные на неизменяемых журнализационных записях (ledger) и многоуровневом надзоре (автоматизированные фильтры + человеческий контроль сложных случаев).

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

#AI #Engineering #Architecture #ML #Software #Economics

[2/4] Панельная дискуссия про влияние AI на разработку софта (Рубрика #AI)

Продолжая рассказ про вопросы панельной дискуссии поделюсь мыслями про первые два вопроса
1. Что изменилось в разработке из-за AI?
2. Как повышать adoption AI? Сверху или снизу?

1. Реальные изменения в разработке под влиянием ИИ
Я рассказывал примерно про это в своем докладе "Интегрируем AI в процессы разработки в большой компании" на CTO Conf. Но если говорить кратко, то ещё пару лет назад ИИ-инструменты в программировании казались диковинкой, а сегодня ими пользуется подавляющее большинство разработчиков. Согласно отчёту DORA 2025, 90% технологических специалистов теперь ежедневно применяют ИИ при разработке – от программистов до продакт-менеджеров. Что же изменилось на практике? Разработчики ощутили ускорение рутинных задач. Генерация типового кода, шаблонов, тестов и документации теперь зачастую делегируется ИИ. По данным DORA, одни из самх распространённых кейсов
- Написание нового кода
- Модификация существующего (аля миграции кода)
- Генерация тестов
- Написание документации с помощью ИИ

Вместе с тем реальный эффект пока далёк от утопического кратного ускорения - улучшения есть, но пока не революционные. Если в прошлом году в отчете DORA наблюдалось даже замедление из-за внедрения ИИ (команды не успевали адаптироваться), то теперь ситуация выправилась: DORA-2025 впервые зафиксировал рост скорости выпуска софта при увеличении использования ИИ. При этом качество и стабильность выпуска остаются вызовом. DORA отмечает, что хотя throughput вырос, нестабильность и число сбоев по-прежнему повышены. Это ожидаемо: сначала все гнались за скоростью, теперь надо подтянуть качество.

2. Внедрение ИИ: стихийно «снизу» или управляемо «сверху»?
Практика показывает, что инициатива внедрения ИИ часто идёт “снизу” – от самих разработчиков. После появления массовых инструментов типа ChatGPT, Copilot и пр., инженеры начали экспериментировать с ними задолго до официальных указаний. Например, исследование Microsoft показало: 3 из 4 сотрудников уже используют ИИ в работе, причём ~80% делают это через личные, “принесённые из дома” инструменты (BYOAI). И в крупных корпорациях доля тех, кто самовольно внедряет ИИ, достигает 78%. То есть повсеместно возник феномен «Bring Your Own AI»: люди подключают в рабочие процессы сторонние ИИ-сервисы, зачастую без ведома ИТ-отдела и руководства. Так было с личными гаджетами (BYOD) в прошлое десятилетие, теперь то же самое – с ИИ-инструментами. Про это было исследование "The GenAI Divide: State of AI in Business 2025" от MIT, что я уже разбирал.

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

Мне кажется, что лидерам нужно курировать, а не подавлять энтузиазм инженеров. Нужен открытый диалог о целях ИИ, обучение, внутренние «песочницы» для проб и централизованные меры безопасности позволяют превратить разрозненные инициативы в управляемую трансформацию. В конечном счёте, оптимальный подход – гибридный: воспользоваться импульсом “bottom-up”, подкрепив его стратегией и контролем “top-down”. Тогда ИИ внедряется не хаотично, а в русле общих целей, и компания извлекает максимум пользы без лишних сюрпризов. Это похоже на подход предложенный для развития экономики агентов в whitepaper "Virtual Agent Economies" от Google, который я уже разбирал. Там предложено проактивный дизайн правил и инфраструктуры для агентных рынков. Если это переносить на SDLC, то нам нужны понятные правила и дизайн использования внутренних AI инструментов vs внешних моделей/инструментов. Это нужно для пилотирования новых возможностей и понятных правил перехода в продакшен этих наработок

#AI #Engineering #Architecture #ML #Software #Economics #Software

[3/4] Панельная дискуссия про влияние AI на разработку софта (Рубрика #AI)

Продолжая рассказ (1 и 2) про панельную дискуссию поделюсь оставшимися темами и начну с рисков.

3. Возможности vs риски: как балансировать ускорение и угрозы
Преимущества ИИ в разработке очевидны и заманчивы. Главные драйверы, которые называют компании: повышение производительности, ускорение релизов и сокращение издержек. Но это тянет за собой шлейф рисков
- Риски качества и ошибок. ИИ склонен “галлюцинировать” – давать уверенные, но некорректные ответы. Разработчики жалуются, что много времени уходит на отладку кода, который почти рабочий. Здесь стратегией может быть создание дополнительных проверок. Автотесты, статический анализ, линтеры – обязательны даже для сгенерированного кода (особенно для него!). Некоторые компании идут дальше: обязывают помечать или ревьюить весь код, внесённый с помощью ИИ
- Риски для организации и процессов. Без грамотного подхода ИИ может усилить узкие места. Например, DORA предупреждает: если компания страдает от устаревших процессов, технического долга, недостатка автоматизации, то ускорение разработки через ИИ приведёт к лавинообразному росту проблем – больше сырого кода вольётся в те же кривые пайплайны. В итоге, в таком случае помимо внедрения AI-инструментов надо заниматься развитием платформы разработки и инженерных процессов.
- Конфиденциальность и безопасность данных. ИИ-инструменты часто требуют отправки исходного кода или данных на внешние сервисы. Для финансовых компаний это красный флаг. Такие компании разворачивают AI решения локально и дорабатывают их под свои сценарии. Если у вас есть договорные отношения с провайдерами LLM моделей, то вы можете попробовать решить эту проблему на уровне договоров.
- Vendor lock-in. Сейчас рынок ИИ-платформ в основном контролируется несколькими игроками – OpenAI (Microsoft), Google, Anthropic и т.д. Если команда плотно подсаживается, скажем, на GitHub Copilot, возникает зависимость, поэтому крупные фирмы стараются диверсифицировать и держать контроль. Практика больших компаний – развивать внутреннюю экспертизу и/или использовать сервисы разных провайдеров (что умножает косты)
- Компетенции команды и “атрофия навыков”. Ирония: мы хотим, чтобы команда работала быстрее с помощью ИИ, но боимся, что от этого люди перестанут расти как профессионалы. Здесь все завязано на обучение сотрудников и мотивацию их не просто копировать ответы модели, а разбираться с ними и понимать как и почему это работает.

4. Как меняются процессы разработки и состав команд?
Широкое внедрение ИИ уже начинает менять структуру и роли в командах разработки. Есть прогноз, что в ближайшие годы потребность в тестировщиках и аналитиках снизится, а число инженеров-разработчиков в штате вырастет.
- Почему меньше тестировщиков? Традиционное ручное тестирование – один из процессов, наиболее поддающихся автоматизации ИИ. Современные инструменты способны сами генерировать тестовые сценарии, подбирать edge-cases и даже поддерживать тесты актуальными при изменении кода.
- Почему меньше аналитиков? Под словом аналитики здесь можно понимать бизнес-аналитиков, системных аналитиков – тех, кто переводит бизнес-требования в ТЗ, прорабатывает спецификации. ИИ начал постепенно отъедать и эту часть работы.

Уже сегодня влияние ИИ ощущается на командных ролях: разработчики становятся центром процесса, опираясь на ИИ, они берут на себя часть задач тестирования и аналитики; тестировщики и аналитики трансформируются в более технические и совмещённые роли, а еще возникают новые позиции. Для бигтеха и финтеха это шанс оптимизировать структуры команд и повысить эффективность, но успех зависит от переподготовки людей. Роль человека будет смещаться к тому, чтобы решать нестандартные проблемы, принимать продуктовые решения и направлять ИИ, в то время как ИИ возьмёт на себя больше рутины. Команды станут более “умными” и кросс-функциональными, а люди – более универсальными.

Окончание будет в финальном посте.

#AI #Engineering #Architecture #ML #Software #Economics #Software

[4/4] Панельная дискуссия про влияние AI на разработку софта (Рубрика #AI)

Заканчивая рассказ (1, 2 и 3) про панельную дискуссию расскажу про последние две темы

5. Есть ли доверие к возможностям AI или это просто хайп?
Несмотря на все успехи, в индустрии ощущается неоднозначное отношение к ИИ-инструментам. С одной стороны, все публично говорят о стратегиях AI-first и как нейросети влияют на эффективность. С другой – в кулуарах многие инженеры и менеджеры признают, что не до конца доверяют этим решениям и иногда «делают вид, что поддерживают тренд», подстраиваясь под моду. Где же граница между реальной верой в технологию и имитацией энтузиазма?
Объективно уровень доверия снизился по сравнению с ажиотажем первых лет. По данным опросов, доля разработчиков с явным позитивным отношением к AI-инструментам в 2025 снизилась до ~60%, тогда как в 2023 была > 70%. То есть первоначальный восторг поостыл, пришло понимание ограничений. Отчёт DORA говорит о «парадоксе доверия»: хотя 90% используют ИИ, только 4% полностью ему доверяют и лишь 20% доверяют «значительно». Около 30% вообще признают, что доверия мало либо нет. Другими словами, почти все считают ИИ полезным, но почти никто не считает его безошибочным. В итоге, сейчас многие следют поговорке "доверяй, но проверяй" - для высокорисковых операций все еще нужен human in the loop, а вот менее рисковые операции пытаются поручить условным AI-агентам с возможным пост-контролем (на дизайн ревью, на код ревью, на этапе тестирования). В общем, люди все еще неотъемлемая часть процесса

6. Что ждет разработку на горизонте 3х лет? Сингулярность наступит или хайп схлопнется?
Заглядывая на 3 года вперёд, можно с уверенностью сказать: ИИ всё глубже проникнет во все фазы жизненного цикла разработки ПО, хотя степень этой интеграции будет зависеть от зрелости самих организаций. Текущие тренды указывают, что ИИ из разрозненной “полезной приблуды” превращается в неотъемлемую часть инструментов разработчика – подобно тому, как когда-то системы контроля версий или CI/CD стали стандартом.

Уже сейчас ИИ задействован на многих стадиях: планирование и дизайн (ИИ-генерация требований, создание дизайна, наброски архитектуры), кодирование (автодополнение, генерация кода по текстовому описанию(аля агенсткий режим)), тестирование (автогенерация тестов, поиск багов), деплоймент и сопровождение (AIOps – прогнозирование инцидентов, автоскейлинг, анализ логов). Пока эти применения часто точечные – каждая команда сама прикручивает отдельные сервисы. Но в будущем можно ожидать более плотного сквозного встраивания ИИ во все процессы SDLC. DORA прогнозирует, что ИИ трансформирует каждый этап жизненного цикла, от дизайна до поддержки. Это значит, появятся интегрированные решения: скажем, ваш таск-трекер сразу подсказывает с помощью ИИ уточнения к требованию; среда разработки автоматически генерирует не только код, но и тесты (а может еще и тестовый стенд поднимает); AI SRE инженер мониторит системы и сам фиксит инцидент на проде, а потом пишет постмортем с анализом причин аварии.

Важный фактор – развитие самих моделей ИИ. Если за 2023–2025 мы видели скачок от “слегка помогающих” моделей к решениям, которые уже могут решить ~70% стандартных задач по кодированию, то к 2028–2030 можем увидеть еще более умных помощников. Скорее всего возникнет множество специализированных моделей: отдельные для генерации UI, отдельные для оптимизации баз данных, для миграции легаси-кода и т.п. Такие узко заточенные ИИ, работающие в составе единой экосистемы, сделают присутствие AI незаметным, но постоянным на всех стадиях.

А как же стартапы? У молодых компаний своя динамика: они чаще сходу “AI-native” – используют ИИ на всех участках, где можно, чтобы компенсировать малый штат. Им проще интегрировать новейшие технологии без бюрократии. Уже есть примеры стартапов, где значительная часть кода генерится ИИ, тестирование полностью автоматизировано AI-платформами, а люди фокусируются на уникальной логике.

#AI #Engineering #Architecture #ML #Software #Economics #Software

[1/2] AI в SDLC: путь от ассистентов к агентам (Рубрика #AI)

Сегодня с таким докладом я выступал на конференции AI Boost от Surf. В этом посте я тезисно расскажу о самой сути выступления, а также поделюсь всеми материалами для дополнительного изучения. И начать нужно с того, что это выступление продолжает мое предыдущее "Интегрируем AI в процессы разработки в большой компании", которое задавало рамку и неплохо показывало как и куда стоить идти при внедрении AI. Но в этот раз я сделал фокус на агентах. И начал я с того, что вспомнил про GitHub Copilot и Cursor, которые скорее известны как ассистенты инженеров. И принятие этих инструментов уже произошло, но потом появились Claude Code и OpenAI Codex, которые заявили о себе как об агентских системах для инженеров (сам я экспериментировал с OpenAI Codex и мне понравилось). И кажется, что это gamechanger, так как если агентские системы заработают успешно, то им можно будет делегировать часть jobs to be done сценариев, которые раньше делали люди (пока эти системы зачастую работают не достаточно хорошо). Для улучшения работы этих систем Anthropic и Google придумали соотственственно протоколы MCP и A2A, про которые я уже рассказывал, то есть инфраструктура постепенно собирается.

Есть и экономическое предпосылки перехода к агентами
- Инвестиции в AI: с 2023 года в инструменты ИИ-программирования вложены миллиарды долларов, а компании ожидают отдачи
- Давление на эффективность: Компании ищут пути ускорить разработку и снизить издержки
- Провайдеры AI технологий обещают манну небесную: топ-менеджеры в компаниях-потребителях ждут отдачи инвестиций

И даже есть компании, где такие системы выдают топ-левел результаты - это я про Google с их агентской системой AlphaEvolve (см. мой разбор), где были получены ощутимые результаты
- Повышение эффективности дата-центров: AlphaEvolve разработал эвристику для оркестратора Borg, которая непрерывно восстанавливает в среднем 0,7% мировых вычислительных ресурсов Google.
- Оптимизация чипов: система предложила переписать код Verilog для удаления избыточных битов в арифметической схеме умножения матриц, что было интегрировано в новую версию TPU.
- Ускорение обучения LLM моделей: AlphaEvolve ускорил ключевой компонент архитектуры Gemini на 23%, что привело к сокращению времени обучения Gemini на 1%

На фоне этого уважаемые ученые рассматривают вопросы будущего, например
- "Future of Work with AI Agents" от Stanford, где ребята задались вопросом а что можно уже агентизировать, а также что люди хотят передать машинам, а также как поменяется рынок труда в результате (см мой разбор)
- "Virtual Agent Economies" от Google, где ребята размышляли про экономику, где агенты могут выполнять и координировать работу автономно. Ученых интересовала как это повлияет на нашу привычную экономику и как сделать так, чтобы мы могли управлять этими изменениями (см мой разбор)
- "Towards AI-Native Software Engineering (SE 3.0)", где авторы размышляют про изменение индустрии разработки до третьей версии, где первой было стандартное написание кода, второй - написание кода с ассистентами, а третье - это уже агенты во всей красе с intent-first разработкой. Разбор этой статьи у меня на подходе, но пока вы можете почитать оригинал

Как может выглядеть агентский режим в реальности (у нас в Т-Банке) стоит посмотреть на демках, которые есть и в моем докладе и в уже опубликованном докладе Стаса Моисеева, моего коллеги, который рассказывал об этом и не только на Big Tech Night (см мой разбор). Но для получения эффекта от AI просто агентского режима не хватит - надо работать фокусно по jobs to be done сценариям, что выполняют инженеры в рамках своей работы. Подробнее про это, а также про измерение эффекта будет в продолжении.

#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy

[2/2] AI в SDLC: путь от ассистентов к агентам (Рубрика #AI)

Продолжая рассказ о своем докладе, поделюсь своими мыслями о том, как подходить к AI-фикации разработки, которые основаны на whitepaper Measuring Developer Goals. В этой статье авторы рассказывали о том, что понимание и эффективное измерение целей критически важно для улучшения опыта разработчиков и повышения их эффективности. Для ответа на вопросы о продуктивности удобнее привязывать измерения не к конкретным инструментам, а к тем целям, которые разработчики ставят перед собой при использовании инструментов. Это позволяет отвечать на вопросы, похожие на те, что приведены выше, сохраняя метрики ориентированными на пользователя, а не инструмент. Подробный разбор в блоге, а также есть восьмая серия подкаста Research Insights Made Simple, где мы разбирали эту статью с Сашей Кусургашевым, моим коллегой, что руководит разработкой Spirit (наша внутренняя платформа разработки). Вообще, может быть полезна вся серия статей про "Developer Productivity for Humans", которуя я разбирал в двух постах (1 и 2).
Если привязывать эти идеи к внедрению AI в разработку, то ясно, что надо фокусироваться на главных jobs to be done сценариях, которые массовые/проблемные - помогая с ними можно получить максимальный эффект. Причем начинать стоит с AI-assisted вещей, а по мере улучшения ассистирования двигаться в сторону делегирования всего сценария агенту (правда, тут придется поработать с подготовкой контекста, настройкой evaluation, изменениями в процессах работы людей). И по мере изменений надо уметь измерять эффекты от этих улучшений так, чтобы показывать результаты топ-менеджерам (а они любят цифры).

Про измерения продуктивности (как и зачем) я уже рассказывал раньше, но там были классические DORA, SPACE, DevEx. А в последнее время я пристально наблюдаю за платформой для измерения продуктивности DX, которая была основана теми, кто развивал предыдущие подходы. Эти ребята сделали систему с опросами и интеграцией с системами типа Jira, Wiki, git, CI/CD, ... В общем, ребята придумали свой фреймворк DX Core 4 для измерения инженерной продуктивности (см мой текстовый разбор + разбор в моем подкасте с Женей Сергеевым из Flo), а в этом году они же расширили его веткой для измерения эффективности AI ассистентов и агентов (см мой текстовый разбор + разбор в моем подкасте с Женей).
По-факту, эффективность AI ассистентов и агентов можно измерять с точки зрения трех направлений
1) Utilization - отслеживание внедрения и использования AI-инструментов (DAU, MAU, % сгенерированного кода, % PR с AI ассистированием, ...). Обычно с этого начинаются измерения, так как эти показатели измерить проще, чем те, что в следующих пунктах (Impact, Cost)
2) Impact - измерение реального эффекта на производительность (экономия времени разработчиков, PR throughput, percieved rate of delivery, ...)
3) Cost - отслеживание затрат и чистой прибыли
У ребят из DX есть бенчмарки по этим метрикам, которые они предоставляют клиентам DX платформы.

Если говорить про наш подход в Т-Банке, то мы умеем мерить первый уровень Utilization, а также у нас внедрен фреймворк SPACE для оценки developer productivity. Это позволдяет нам двигаться в сторону оценки Impact. Кстати, про наш фреймворк SPACE ребята рассказывали на IT Пикнике и вот разбор этого выступления. Но если у вас не внедрены инструменты для измерения developer productivity в компании, то не стоит грустить. Уровень утилизации можно измерить относительно просто, а большего вам может быть и не надо - сейчас разработка революционно меняется за счет использования AI-ассистентов и AI-агентов, а значит можно не вкладывать кучу сил в измерения старого подхода к делу, а экспериментировать с новым. Условно, не стоит обмерять деревянное колесо диллижанса, если у нас уже его вытесняет металлическое колесо машины:)
Ну а если хочется бенчмарков, то можно поучаствовать в нашем Большом исследовании AI в инженерной культуре России.

#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy

Podlodka Techlead Crew про архитектурные антипаттерны (Рубрика #Architecture)

Когда рассказывают про архитектуру, то теоретики часто фокусируются на том, а как строить качественную архитектуру. Но на практике инженеры часто сталкиваются с неидеально спроектированными системами, которые доставляют много проблем. Поэтому часто бывает полезно знать симптомы того, что ваша архитектура требует доработок. Ну а вообще лучше изначально разобраться с типовыми ошибками проектирования, которые бывают и у опытных инженеров. Именно этой теме посвящен новый сезон онлайн-конференции Podlodka Techlead Crew.

В программе конференции будут следующие выступления
- От спагетти кода к доменной модели: критерии выбора между Transaction Script, Active Record, DDD и Clean Architecture, практический взгляд Кирилла Ветчинкина (Авито).
- AI для архитектора: валидация требований, поиск зависимостей, возможность ускорения архитектурного ревью с AI в интервью с Тимуром Баюровым (Т-Банк). Кстати, Тимур многое делает для проникновения AI в архитектурные процессы Т-Банка.
- Архитектура хранилища данных для вашего проекта: советы от Евгения Ненахова (МТС Web Services).
- Еда, EDA и C4 — выбери 3 из 3: практический воркшоп по Event-Driven Architecture и отказоустойчивости с разметкой в C4 проведёт Владимир Невзоров (автор канала System Design World).

Конференция пройдет на неделе с 13-17 октября и может принести вам много пользы, если вы связаны с проектированием и разработкой софта. Подробности здесь.

P.S.
Спасибо ребятам за то, что пошарили информацию о нашем исследовании AI в инженерной культуре России.

#Architecture #DistributedSystems #Software #Engineering #Processes #AI