Книжный куб

У наших аналитиков в Т есть подкаст InSAйт, куда они зовут гостей обсуждать интересные темы. Второй сезон заканчивался темой "У системных аналитиков нет комьюнити: миф или реальность", куда ребята позвали гостем Анастасию Кабищеву, Head of project management office компании Ekleft, консультанта по психологической безопасности команд, а также мою жену. В итоге, я не мог ни рассказать об этом подкасте - рекомендую его к прослушиванию всем, кто занимался темой построения коммьюнити.

The Software Engineer's Guidebook (Разработчик ПО: Путеводитель по карьерной лестнице для будущих сеньоров, техлидов и стаффов) (Рубрика #Engineering) Недавно дочитал книгу Гергели Ороша, автора рассылки "The Pragmatic Engineer", бывшего engineering менеджера в Uber и разработчика в Skype/Microsoft и Skyscanner. Я уже рассказывал про эту книгу раньше, когда я только начинал ее читать. Теперь, после прочтения, я могу поделиться кратким саммари. Книга хорошо подходит для инженеров, которые хотят пройти по всем ступенькам от джуна до стафф+ инженера - часть материалов адресована всем уровням, а дальше блоки для middle → senior → tech lead → staff идут по нарастающей. Автор отдельно замечает, что книга полезна и менеджерам, особенно тем, кто старается оставаться «hands‑on». Книга разбита на отдельные темы + есть бонусные онлайн-главы - Базовые принципы карьеры - пути развития, «владение» своей карьерой, performance‑review, промо, как работать в разных средах (стартап/BigTech), смена работы. - Компетентный разработчик - как доводить задачи до результата, написание кода, процесс разработки, инструменты продуктивного инженера. - Senior инженер - взаимодействие и командная работа, инженерные практики, тестирование, архитектура. - Техлид (не важно должность это или роль) - проектное управление, выпуск в прод, управление стейкхолдерами, структура и динамика команды. - Staff/Principal - понимание бизнеса, влияние без полномочий, надёжность и архитектура. - Заключение + онлайн‑«бонус‑главы» к предыдущим частям Книгу можно использовать как настольный справочник и читать точечно, в нужном месте. Мне показались интересным советы о карьере, которые повышают осознанность и успешность движения по карьерной лестнице - "Владейте своей карьерой" - ведите журнал выполненных задач, регулярно просите обратную связь и делайте менеджера союзником — это прямая инвестиция в промо. - Готовьтесь к performance‑review готовятся заранее - начинайте собирать контекст и артефакты за месяцы до ревью, помогая менеджеру и калибровке. - Промо ≠ просто "побольше сделать" - эффект конечно важен, но также нужно демонстрировать компетенции следующего уровня и координировать сложные инициативы. - Среда имеет значение: BigTech и стартапы требуют разных стратегий; выбирайте то, что лучше под ваши цели и этап В принципе, есть и другие похожие книги для IC и engineering managers, о которых я уже рассказывал - Will Larson "Staff Engineer: Leadership Beyond the Management Track" - про то, как расти и работать на staff‑ветке без ухода в менеджмент (см. мой обзор) - Tanya Reilly "The Staff Engineer’s Path" - подробное руководство по роли staff‑инженера: стратегия, влияние, стандарты качества (см. мой обзор) - Camille Fournier "The Manager’s Path" - путь инженера в engineering менеджеры (см. мой обзор) - Will Larson "An Elegant Puzzle" - системный взгляд на инженерный менеджмент и организационные решения (см. мой обзор) Итого, эта книга мне показалсь довольно практичной и полезной для инженеров, которые хотят осознанно развивать свою карьеру не просто прыгая по уровням, а строя правильный инженерный фундамент и фокусируясь на важных вопросах на каждом этапе от джуна до staff инженера. #Engineering #Management #Leadership #Processes #Software #Career #Staff #Career #Architecture

Эволюция метрик и практика применения SPACE (Рубрика #DevEx) Мои коллеги Саша Кусургашев и Дима Гаевский на IT Пикнике летом рассказывали про то, как мы используем фреймворк SPACE для оценки продуктивности инженеров. Недавно появилась запись выступления Саши (который отдувался за двоих) и я решил поделится кратким саммари этого рассказа. Если уложить это саммари в одну мысль, то она примерно такая "инженеров нельзя адекватно оценить одной цифрой или простым количественным показателем" - хотя часто это пытались сделать (например, число коммитов, строк кода, выполненных задач), но каждая такая метрика отражает лишь одну сторону дела и сильно зависит от контекста. Например, большое число изменений в коде может свидетельствовать как о высоком темпе команды, так и о переработках или неэффективном процессе – без контекста такие цифры вводят в заблуждение. Ребята привели в докладе кучу примеров того, как приходится учитывать множество граней эффективности: скорость работы, качество результата, командное взаимодействие, удовлетворённость сотрудников и другие факторы. Собственно, первая половина доклада была про сам фреймворк "SPACE", где рассказ строился на статье "The SPACE of Developer Productivity", о которой я уже рассказывал раньше. Сам акроним SPACE расшифровывается как - Satisfaction & Well being (удовлетворённость) - Performance (результативность) - Activity (активность) - Communication & Collaboration (коммуникация) - Efficiency (эффективность) Каждое из этих измерений дополняет остальные, создавая целостную картину. В выступлении отмечалось, что такой многомерный подход родился как реакция на злоупотребления однобокими метриками и нацелена на то, чтобы сделать оценку работы инженеров более справедливой и осмысленной. Вторая часть доклада была посвящена опыту внедрения SPACE и мне она кажется самой полезной частью выступления. Саша рассказал с чего начать сбор метрик и как интерпретировать.Внедрение многомерной системы измерений оказалось непростой задачей – потребовалось агрегировать данные из разных источников (систем контроля версий, трекеров задач, CI/CD, опросов сотрудников и пр.) и привести их к единой основе для сравнения. Авторы подчеркнули важность нормализации данных и правильных «разрезов» – нужно решать, по каким сечениям анализировать метрики (по командам, по проектам, по временным периодам), чтобы выявлять закономерности и проблемные зоны. Это оказалось нетривиально: разные сегменты показывали разную картину, и неправильный выбор среза мог скрыть проблему или создать иллюзию успеха. Например, сравнение по командам требует учёта специфики проектов; сравнение по времени – учёта сезонности и изменений обстоятельств. Круто, что ребята честно поделились ошибками первого подхода к SPACE. Поначалу они старались измерить «всё и сразу» и получить мгновенный интегральный показатель. Это привело к избытку данных и трудностям в их понимании. Как итог - не стоит пытаться охватить сразу все метрики без приоритизации. Вместо этого лучше выбрать несколько метрик по ключевым измерениям, которые наиболее актуальны для текущих проблем команды, и начать с них. Важно «не перегнуть палку и не утонуть в данных», а подбирать метрики под свой контекст. Постепенно, когда культура работы с метриками начала формироваться, они расширяли охват SPACE-факторов, но уже осознанно и с учётом полученных инсайтов. Из выступления можно забрать такие мысли 1) Комбинируйте объективные метрики с обратной связью от людей 2) Используйте метрики как инструмент для улучшения, а не для наказания. Стоит выявлять узкие места и точки роста, а не устраивать «соревнование разработчиков» или повышать бюрократию 3) Вводите метрики постепенно и осмысленно. Начать с пилотной команды или направления, выбрать небольшое подмножество SPACE-метрик, относящихся к наиболее болезненной проблеме, и опробовать их в деле 4) Важна роль культуры и поддержки руководства. Внедрение SPACE – это не разовая акция, а изменение подхода к управлению #Processes #Management #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SRE

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

[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

ЦСКА - Спартак Добрались с сыном на дерби со Спартаком. Первые двадцать минут выглядели как сказка - 3:0. Но потом сказка превратилась в триллер - Спартак сделал счет 3:1, а четвертый гол ЦСКА отменили. А второй тайм принес второй гол Спартака 3:2, травму Акинфеева и дальше футбол превратился в "бей-беги". Но матч так закончился со счетом 3:2, но концовка была валидольной. В общем, нам все понравилось:)

[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

[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

[2/3] Панельная дискуссия про влияние 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

[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

[1/4] Панельная дискуссия про влияние AI на разработку софта (Рубрика #AI) Вчера вечером я был на закрытом мероприятии в SVOY Hamovniki, где прошла презентация большого исследования IT One и Сколково про ИИ в разработкe, а также поучаствовал в дискуссионной панеле «Будущее применение AI в разработке и создании продуктов». В ней участвовали следующие джентельмены - Сергей Щербинин - CEO Faust Consulting - Андрей Плужников - СЕО Hoff Tech - Алексей Ульенков - Первый вице-президент Газпромбанка - Женя Бобков - главный по цифровым витринам в Мегафон (тут я прям ошибаюсь, но ты меня поправь) - Дима Немов - директор по развитию продукта IT One - и ваш покорный слуга Мы обсудили вопросы ниже, а я решил не останавливаться на разговорной части и поделиться своими мыслями с читателями канала 1. Что изменилось в разработке из-за AI? 2. Как повышать adoption AI? Сверху или снизу? 3. Как выглядит баланс плюсов и минусов: скорость разработки vs баги, утечки данных, vendor lock, снижение квалификации инженеров 4. Как меняются процессы разработки и состав команд? 5. Есть ли доверие к возможностям AI или это просто хайп? 6. Что ждет разработку на горизонте 3х лет? Сингулярность наступит или хайп схлопнется? Дальше будет три поста с разбором этих вопросов + я отдельно разберу итоги исследования #AI #Engineering #Architecture #ML #Software #Economics #Software

Avito Tech Conf (Рубрика #Conference) Сегодня приехало приглашение от Авито на их конференцию для менеджеров или как описывают организаторы это Конференция для тех, кто управляет процессами, продуктами и людьми Мне понравился креатив организаторов, которые подошли к делу творчески и в небольшой коробочке отгрузили - Игру с вопросами для one2ones - Специальное растворимое кофе, чтобы менеджеру было проще просыпаться по утрам - Специальную свечку с пожеланием того, чтобы горела она, а не календарь - Прозрачный кубик с чем-то зеленым внутри Но не только приглашение выглядит интересно, но и темы: - Про лидерство - куда развиваться лидеру, как управлять ограниченными ресурсами и как стать CTO - Про AI - LLM в разработке и как проявлять лидерство в эпоху таких больших изменений - Про процессы - как адаптироваться к изменениям и реорганизовывать все вокруг - Про людей - про performance review и решение конфликтов в команде В общем, приходите очно или смотрите трансляцию, а я постараюсь выделить 17 октября под этот event и прийти в оффлайн:) #Conference #Software #Engineering #Management #Leadership

[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

[1/2] Virtual Agent Economies (Рубрика #AI) Изучил очередной интересный whitepaper от ребят из Google на этот раз на тему агентской экономики. В этой работе они изучают зарождение нового слоя экономики, управляемого автономными агентами искусственного интеллекта. Они задались целью осмыслить, как массовое внедрение таких агентов повлияет на экономику и приведет к отдельной виртуальной агентной экономике, где цифровые агенты взаимодействуют, совершают сделки и координируются с масштабом и скоростью, недоступными для непосредственного контроля человека. Для описания этого явления авторы вводят понятие sandbox economy и предлагают характеризовать ее по двум осям 1. Происхождению: стихийно-эмерджентная vs. преднамеренно спроектированная 2. Степени отделенности от существующей человеческой экономики: проницаемая vs. непроницаемая Основной вывод работы: без целенаправленного вмешательства велика вероятность стихийного формирования обширной агентной экономики с высокой степенью проницаемости границ, т.е. тесно связанной с реальным рынком. Тут есть плюсы и минусы (+)Такая система сулит беспрецедентные возможности для координации и автоматизации – агенты способны самостоятельно создавать экономическую ценность, взаимодействуя друг с другом вне прямого участия человека (-) У такой системы значительные риски: возможны новые формы системного экономического риска (например, мгновенные «флэш-кризисы» из-за сверхбыстрых сделок ИИ) и усиление неравенства, если продвинутые агенты получат преимущество перед более слабыми В итоге, авторы делают вывод о необходимости проактивного дизайна правил и инфраструктуры для этих агентных рынков. Они предлагают ряд мер и механизмов – от аукционов для справедливого распределения ресурсов до создания «миссионных» экономик под цели всеобщего блага – которые позволили бы направлять эволюцию агентной экономики в безопасное русло. Ключевой рекомендацией является преднамеренная архитектура виртуальных рынков с встраиванием принципов доверия, прозрачности и подотчетности, чтобы грядущие изменения в экономике служили долгосрочному процветанию человечества. В прододжении чуток расскажу про методологию анализа авторов. #AI #Engineering #Architecture #DistributedSystems #ML #Software #Economics

[3/x] Model Context Protocol (MCP) и Agent-to-Agent (A2A) - Архитектура A2A (Рубрика #AI) Продолжая рассказ про протоколы (1 и 2), расскажу про то, как устроен A2A протокол от Google. Архитектура A2A также следует модели клиент-сервер, но на уровне агентов. Здесь A2A-клиентом выступает один агент, инициирующий задачу, а A2A-сервером – другой агент, способный эту задачу выполнить. В отличие от MCP, где сервер – просто коннектор к данным, в A2A оба конца коммуникации – интеллектуальные агенты с потенциалом автономного поведения. Протокол A2A определяет стандарт, как один агент может обнаружить другого, узнать, что тот “умеет”, и далее передать ему задачу на выполнение с последующим получением результата. Технически A2A основан на HTTP и JSON-RPC, дополняемых протоколом событий SSE для асинхронного обмена сообщениями и потоковых обновлений состояния. Каждый агент, работающий по A2A, экспонирует HTTP-эндпойнт (например, небольшой веб-сервер) со стандартным API A2A. Чтобы агенты могли находить друг друга и правильно обращаться, A2A вводит понятие Agent Card – своего рода паспорт агента. Agent Card – это JSON-документ, публикуемый агентом, где указаны его имя, адрес (URL для подключения), версия, а главное – перечень его навыков/умений (Agent Skills) с описаниями того, какие задачи он способен выполнять. Другие агенты могут получить этот «карт-бланш» и понять, к какому агенту за чем обращаться. Обмен задачами в A2A происходит через Task – стандартизованное описание задания, которое клиент-агент формирует для удалённого агента. Задача включает контекст (например, запрос пользователя), требуемое действие и формат ожидаемого ответа. Агенты обмениваются сообщениями (Messages) в процессе решения задачи – это могут быть шаги выполнения, уточняющие вопросы, промежуточные результаты. В итоговом ответе могут передаваться так называемые Artifacts – артефакты, например файлы, изображения или другие результаты работы агента. Протокол поддерживает потоковое взаимодействие: если задача длительная, удалённый агент может слать промежуточные обновления (статус выполнения, частичные результаты) через SSE-поток, пока задача не будет завершена. Ключевые технические принципы A2A, заявленные Google и партнёрами: 1. Опора на существующие стандарты: не изобретать новый транспорт, а использовать HTTP для совместимости с любыми веб-технологиями, JSON-RPC для структурированных вызовов, SSE для стриминга. Это облегчает интеграцию A2A в существующую ИТ-инфраструктуру предприятий. 2. Безопасность по умолчанию: протокол изначально разработан с учётом корпоративных требований безопасности – поддерживает аутентификацию и авторизацию агентов по аналогии со схемами безопасности OpenAPI. Каждый агент может требовать проверку ключа или токена перед приёмом задач, устанавливать разрешения на выполняемые действия и т.п., чтобы предотвратить несанкционированный доступ. 3. Поддержка длительных задач: архитектура учитывает, что агентские взаимодействия могут занимать значительное время (часы или дни, если в цикле есть человек). Благодаря событийной модели, A2A позволяет агентам поддерживать диалог о ходе задачи, уведомлять о промежуточном прогрессе, ожидать внешних действий и затем продолжать работу. 4. Мультимодальность: A2A не ограничивается текстом – предусмотрена передача аудио- и видеопотоков, если агенты работают с этими типами данных. Это важно, например, для агентов, обрабатывающих голосовые запросы или видеоданные (они тоже могут сотрудничать через единый протокол). Архитектурно A2A создает надстройку над отдельными агентами, превращая их в единый оркестр. Например, если пользовательскому ассистенту (агенту) поступает сложный запрос – спланировать деловую поездку – он может через A2A делегировать подзадачи специализированным агентам: один агент бронирует билеты и отели, другой – обрабатывает оплату, третий – проверяет соответствие поездки корпоративной политике #AI #Engineering #Architecture #DistributedSystems #ML #Software

[2/x] Model Context Protocol (MCP) и Agent-to-Agent (A2A) - Архитектура MCP (Рубрика #AI) Прололжая рассказ про эти протоколы, надо рассказать про то, как они технически устроены. Архитектура MCP основывается на классической модели «клиент-сервер». MCP-клиентом выступает ИИ-приложение (ассистент, агент), которому требуется доступ к внешним данным или функциям, а MCP-сервером – модуль-коннектор, умеющий взаимодействовать с конкретным внешним сервисом или репозиторием данных. MCP формально специфицирует, как серверы объявляют свои возможности (для их обнаружения клиентами) и как клиенты запрашивают выполнение определённых действий у серверов с получением результатов. В основе коммуникации лежит протокол JSON-RPC 2.0, а обмен сообщениями может происходить по различным транспортам: - STDIO - взаимодействие через стандартный ввод/вывод, удобно для локальных интеграций - HTTP - REST API с поддержкой Server-Sent Events для потоковых ответов Такая архитектура обеспечивает гибкость: один и тот же MCP-клиент (например, чат-бот) может подключаться к разным MCP-серверам (инструментам) по единому протоколу, будь то локально или через сеть. На практике это выглядит так: разработчик поднимает MCP-сервер для некоторого ресурса – например, MCP-коннектор к базе данных или файловому хранилищу. Сервер описывает, какие функции доступны (например, readFile, queryDatabase) и в каком формате запросы/ответы принимаются. ИИ-модель (клиент) через MCP может динамически обнаруживать доступные инструменты и вызывать их, не имея жёстко закодированных инструкций под каждую интеграцию. Протокол поддерживает двусторонний обмен: сервер может возвращать не только данные, но и метаданные (описание контекста, теги) и даже генерировать последовательность сообщений для управления сложными задачами. Для упрощения разработки Anthropic выпустила SDK MCP и открыла репозиторий с примерами серверов. Это означает, что разработчики могут быстро создавать собственные MCP-коннекторы для любых систем. Таким образом, технически MCP стандартизует три ключевых аспекта: 1. Discovery: клиенты могут запрашивать у сервера список его возможностей и схемы данных, получая единообразное описание инструментов 2. Invocation: формат запроса для выполнения действия и формат ответа (или ошибки) строго определены JSON-RPC, что устраняет двусмысленность в коммуникации 3. Context handling: MCP позволяет обмениваться контекстной информацией и подгружать данные в подсказки модели. Например, MCP-сервер может не только вернуть сырые данные, но и предоставить модель встроенной подсказкой о том, как эти данные интерпретировать. Следует отметить, что MCP не привязан к конкретному ИИ-модулю – это уровень интеграции. Любая модель (Claude, GPT-4, Gemini и др.), чей контейнер поддерживает MCP-клиент, сможет обращаться к MCP-серверам. Именно благодаря этому MCP быстро подхватили разные вендоры: стандарт изначально задуман как открытый и совместимый со всеми экосистемами. В общем, подробнее про MCP можно почитать на сайте Anthropic, а следующий пост будет посвящен рассказу про архитетуру A2A протокола. #AI #Engineering #Architecture #DistributedSystems #ML #Software

[1/x] Model Context Protocol (MCP) и Agent-to-Agent (A2A) (Рубрика #AI) В рамках подготовки к докладу про переход от ассистентов к агентам я решил изучить как мы пришли к двум самым популярным протоколам для LLM. И я говорю про MCP от Anthropic и A2A протокол от Google. Сейчас кажется, что мы движемся в сторону будущего, где AI-ассистенты разных видов свободно подключаются к нужным им данным (через MCP) и объединяются друг с другом для решения наших задач (через A2A). Но так было не всегда, давайте вернемся на шаг назад и посмотрим как появлялись эти протоколы. Model Context Protocol (MCP) – это открытый стандарт, разработанный компанией Anthropic и представленный 25 ноября 2024 года. Anthropic анонсировала MCP как решение для подключения ИИ-ассистентов к внешним системам и данным, с целью преодолеть разрозненность интеграций, так как до этого приходилось писать кастомные интеграции с каждым источником данных. Запуск MCP привлёк внимание отрасли: - Уже на старте Anthropic открыла исходный код спецификации и SDK протокола, а также предоставила готовые серверные коннекторы для популярных систем (Google Drive, Slack, GitHub, базы данных и пр.) - В марте 2025 года OpenAI официально объявила о внедрении MCP во все свои продукты. - Вскоре о поддержке MCP объявила и Google DeepMind: в апреле 2025 года Демис Хассабис подтвердил, что грядущие модели семейства Gemini будут совместимы с MCP для подключения к внешним данным. В итоге, к середине 2025 года MCP превратился в де-факто индустриальный стандарт интеграции данных для LLM-ассистентов: его поддержка заявлена в продуктах OpenAI (включая ChatGPT), Anthropic Claude, платформах Microsoft (Semantic Kernel, Azure OpenAI) и других. СМИ окрестили MCP своего рода «USB-C для ИИ» – единым разъёмом, который объединяет конкурентов ради совместимости. Agent-to-Agent (A2A) – это открытый протокол обмена сообщениями между ИИ-агентами, который был представлен Google 9 апреля 2025 года на платформе Google Cloud совместно с более чем 50 партнёрами. Инициатива A2A возникла из потребности обеспечить взаимодействие множества автономных агентов в корпоративных сценариях. В своем официальном анонсе Google отметила, что предприятия всё активнее внедряют агентные решения для автоматизации рабочих процессов и такие агенты должны уметь сотрудничать друг с другом, даже если они созданы разными вендорами или на разных платформах. Протокол A2A был задуман как универсальный язык для таких агентов, позволяющий им обнаруживать друг друга, обмениваться информацией и координировать действия в рамках распределённой экосистемы. Запуск A2A сразу получил широкую поддержку в отрасли: - В работе над стандартом помимо Google участвовали компании Atlassian, Box, Cohere, Intuit, LangChain, MongoDB, PayPal, Salesforce, SAP, Accenture, Deloitte, IBM и др. - В июне 2025 года Google передала A2A под эгиду Linux Foundation для нейтрального развития сообщества (это чем-то напоминает как Google передала Kubernetes в Cloud Native Computing Foundation, что входит в Linux Foundation) - Одновременно было объявлено об участии в проекте A2A таких гигантов, как AWS, Cisco, Microsoft, Salesforce, SAP, ... К середине 2025 года A2A закрепился как открытый межплатформенный стандарт, поддерживаемый множеством крупных игроков, аналогично тому, как MCP стал стандартом для подключения к данным. Следующий пост будет про устройство протоколов. #AI #Engineering #Architecture #DistributedSystems #ML #Software

Журнал "Майнкрафт" (Рубрика #Kids) Вчера были в большом торговом центре семьей и купили детишкам журналы в разделе пресса. Младший сын, которому скоро будет пять, выбрал себе журнал про майнкрафт, которым он увлечен последний год:) Сегодня мы с ним рассматривали картинки и зачитывали избранные отрывки, а я вспоминал времена своего детства. В те времена я покупал журналы про игры на денди, сега, а потом и про компьютерные игры. Время идет, игры меняются, а игровые журналы все равно собирают аудиторию (хотя с текущим засильем интернета часть изданий теперь обходится без бумаги). #Kids #Games

How are developers using AI? Inside our 2025 DORA report (Рубрика #AI) Эту статью от 23 сентября мне подкинул Pulse от ChatGPT, который делает подборки по моим интересам. А я действительно много общался с ChatGPT про исследования DORA и про влияние AI на разработку софта - мы в Т-Банке даже запустили большое исследование AI в инженерной культуре России. Но если возвращаться к отчету DORA за 2025 год, то он уже доступен, а также доступно executive summary в этой статье в блоге Google. Если говорить кратко, то вот как AI влияет на разработку софта по измерениям авторов опроса 1. Использование ИИ стало почти повсеместным - Около 90% разработчиков применяют AI-инструменты - Более 80% считают, что это повышает их продуктивность - Около 59% считают что улучшает качество кода. 2. Значительное большинство (65%) опрошенных в значительной степени полагаются на ИИ при разработке программного обеспечения: 37% сообщают об «умеренной степени» зависимости, 20% - о «большой» и 8% - о «значительной». 2. Парадокс доверия и продуктивности Несмотря на такое проникновение, доверия к AI не настолько велико - 24% респондентов сообщают о «очень большом» (4%) или «большом» (20%) доверии к ИИ - 30% доверяют ему «немного» (23%) Оказывается, что респонденты могут считать работу AI полезной, даже если не полностью доверяют ей. Возможно, они так выстроили процессы, что AI работает скорее как ассистент, но работа полностью не делегируется ему. 3. Архетипы команд Исследование в этом году также показало, что ИИ может действовать как «зеркало и умножитель». В сплоченных организациях ИИ повышает эффективность. В раздробленных - выявляет слабые места. Для того, чтобы копнуть в это глубже авторы раскрыли семь различных архетипов команд от "гармоничных и успешных" до команд, столкнувшихся с "legacy узкими местами". 4. A blueprint for guiding AI in organizations В отчете по итогам опроса авторы предлагают "DORA AI Capabilities Model", которая выделяет семь базовых практик, открывающих путь к эффективному применению AI. #AI #Software #Engineering #Management