[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 стал стандартом для подключения к данным.

Следующий пост будет про устройство протокола MCP.

#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

[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/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