10892
Рекомендации интересных книг, статей и выступлений от Александра Поломодова (@apolomodov), технического директора в T Tech
[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
[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
[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
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
[1/2] The Technological Republic: Hard Power, Soft Belief, and the Future of the West (Технологическая республика. Жесткая сила, мягкая вера и будущее Запада) (Рубрика #Economics)
Прочитал интересную книгу Александра Карпа и Николаса Замиски из компании Palantir о будущем Запада. Чтобы понять контекст книги, необходимо знать о Palantir Technologies - компании, которую Александр Карп (со-автор книги) основал в 2003 году совместно с Питером Тилем и несколькими выпускниками Стэнфорда. Название Palantir заимствовано из Толкеина: палантиры - это “видящие камни”, позволяющие наблюдать на расстоянии (компания специализируется на анализе больших данных и разведывательной аналитике для спецслужб). Palantir с самого начала создавалась при активном участии ЦРУ и других разведывательных ведомств США, которые стали ее первыми клиентами. Сейчас капитализация компании составляет 420+ миллиардов долларов.
В политическом плане Карп сам определял себя как прогрессивного социалиста, который всю жизнь голосовал за демократов и жертвовал крупные суммы в их поддержку. При этом он стал сооснователем компании, тесно связанной с военными и спецслужбами США, и убежденным сторонником укрепления обороноспособности Запада. Это своеобразное сочетание убеждений - делает Карпа фигурой нетипичной для Кремниевой долины. Карп открыто заявляет, что деятельность Palantir - это проект в защиту демократии, а усиление военного потенциала США и союзников он видит средством обеспечения свободы.
Если говорить про основные идеи книги, то их можно суммировать до следующих
1. Кремниевая долина потеряла ориентир общественного блага
2. Урок истории: союз технологий и государства творил великие дела (Манхэттенский проект и проект Apollo)
3. “Мягкая вера” Запада: утрата общих убеждений и целей
4. Необходим пересмотр либерального консенсуса: веры в автоматическое торжество свободного рынка, глобализации и толерантности
5. Технологическая республика: как технологии могут спасти, а не убить демократию
Продолжение здесь.
#History #Economics #Future
[2/3] Future of Work with AI Agents: Auditing Automation and Augmentation Potential across the U.S. Workforce (Рубрика #AI)
Продолжая рассказ про исследование, поделюсь найденными результатами.
Положительное отношение к автоматизации рутины
Вопреки распространенным страхам, значительная доля работников хочет передать ИИ рутинные и низкоценные задачи. По опросу, для 46,1% всех рассматриваемых задач респонденты дали позитивную оценку возможности автоматизации (выше нейтральной на 5-балльной шкале). Причем перед ответом людей просили задуматься о риске потери работы и о том, нравится ли им выполняемая задача - но даже с учетом этого почти половина задач желанна для автоматизации по следующим причинам
- Освободить время для более важной работы" (отметили ~69% сторонников автоматизации)
- Избавиться от рутины (~47%)
- Улучшить качества результата с помощью ИИ (~46%)
- Избежать стресса (~25%)
Опасения и зоны неприятия
Вместе с тем, опрос подтвердил наличие серьезных опасений работников относительно ИИ. Наиболее распространены
- Недоверие к качеству решений AI (упомянули ~45% – сомнения в точности, надежности алгоритмов)
- Страх потери работы (23%)
- Отсутствие человеческого подхода (16%)
Эти страхи особенно сильны в творческих и гуманитарных сферах: например, в секторе «Искусство, дизайн, медиа» лишь 17% задач получили позитивную оценку автоматизации
Четыре зоны соответствия желаний и возможностей
Сопоставив желание работников с оценками экспертов, авторы разделили все задачи на 4 категории
1. "Зеленый свет" - задачи, которые люди готовы отдать ИИ и для которых уже есть технические возможности. Такие задачи - первые кандидаты на внедрение AI, обещающие наибольший выигрыш в продуктивности.
2. "Красный свет" - задачи, которые ИИ умеет выполнять, но люди не хотят автоматизировать. Здесь потенциальное внедрение ИИ может встретить сопротивление или иметь негативные соц. последствия, поэтому требуется осторожность
3. Зона R&D - задачи, которые работники очень хотели бы автоматизировать, но нынешние AI-модели с ними не справляются. Эти направления – перспективные цели для дальнейших разработок ИИ, чтобы удовлетворить явный запрос пользователей
4. "Низкий приоритет" - задачи с низким желанием автоматизации и низкой реализуемостью ИИ; ими можно пренебречь в ближайшей перспективе.
Анализ показал значительные несоответствия: порядка 41% задач попали либо в «красную» зону, либо в «низкий приоритет», то есть значительная часть текущих усилий по внедрению AI либо направлена не туда, где этого хотят люди, либо пытается автоматизировать то, что пока не по силам технологиям. Например, оказалось, что стартапы из акселератора Y Combinator часто нацелены на задачи из «красной» или малоприоритетной зон, тогда как многие желанные для людей области (зелёная зона и R&D) остаются недоинвестированными. Этот вывод подчеркивает разрыв между интересами разработчиков/инвесторов и потребностями работников, а также указывает, куда стоит перенаправить усилия - на задачи зоны “Green Light” и R&D, где запрос высок, а технологий пока не хватает.
Предпочтение сотрудничества, а не полной замены
Большинство работников предпочитают не полную автоматизацию, а партнерство с ИИ. По введенной шкале участия человека (HAS) наиболее распространенный идеал - уровень H3 (равноправное партнерство): в среднем 45,2% опрошенных хотели бы работать в тандеме с AI-агентом как с равным “напарником”. Еще ~35,6% предпочитают модель H4 – то есть ИИ как ассистент под контролем человека (человек принимает ключевые решения). Таким образом, совокупно ~80% респондентов выступают за сохранение существенной роли человека при внедрении ИИ. Лишь малая доля работников (около 19%) готовы к почти полной автономии AI (уровни H1–H2) либо, наоборот, к совсем минимальному его использованию (H5). Это свидетельствует о ясном нежелании полностью передавать работу машинам: люди хотят, чтобы контроль и критические решения оставались за ними.
Окончание в следующем посте.
#AI #Economics #ML #Work
Yandex Neuro Scale (Рубрика #AI)
Дошел сегодня на конференцию Yandex Cloud, где на keynote докладе анонсировали много нового: новую зону доступности, новые AI инструменты внутри Яндекс Облака, новую AI студию для создания агентов и т.д. А сейчас я зашел послушать про работу AI агентов в разработке софта от Жени Колесникова (через недельку просто я сам буду выступать на похожую тему). Думаю, что потом напишу пост про выступления, что мне понравились на этой конфе.
#AI #Cloud #Engineering #Software
[1/2] How tech companies measure the impact of AI on software development (Рубрика #AI)
Интересный пост от Гергели Ороша, автора подписки "The Pragmatic Engineer", и Лаура Тахо, CTO платформы DX, которая занимается измерением эффективности продуктивности. Они вместе были в подкасте "Measuring the impact of AI on software engineering", который я уже разбирал. У DX есть свой фреймворк для измерения продуктивности и недавно появился фреймвор для измерения влияния AI. В подкасте Research Insights мы их разбирали с Женей Сергеевым, engineering director из Flo Health
- "DX Core 4"
- "Measuring AI Code Assistants and Agents"
Если возвращаться к этой статье, то интересны примеры конкретных метрик из 18 компаний, которые Лаура привела в качестве примеров. Из них видно, что ИИ-инструменты уже широко распространились: ими пользуются ~85% разработчиков. Но измерить их эффект непросто - 60% техлидов признаются, что у них нет понятных метрик пользы ИИ. В новостях упрощают: звучат заявления вроде «ИИ пишет N% кода». Однако строки кода - плохая метрика продуктивности: исходный код - скорее бремя, а не ценность.
В итоге, Лаура предлагает ориетироваться на базовые метрики продуктивности: качество, надёжность, скорость, удовлетворённость инженеров. Многие компании продолжают измерять те же показатели, что и до ИИ (частота сбоев, скорость выпуска, время цикла, DevEx), а также оценивают насколько AI помогает их улучшать. Если эти базовые метрики не определены и нет консенсуса, а что считать продуктивностью, то оценка ИИ сведётся к пустым метрикам типа «количество кода» или процент принятых подсказок.
Кромое стандартных показателей появляются и специфичные для AI метрики и они разбиваются на три категории (подробности в статье "Measuring AI Code Assistants and Agents"):
1. Уровень использования (usage)
2. Влияние на работу (сэкономленные часы)
3. Экономическое влияние (cost & benefits)
Продолжение в следующем посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
AI agents in 2025: Expectations vs. reality (Рубрика #AI)
Когда изучал информацию про успехи AI Agents наткнулся на статью полугодовой давности от IBM. В марте 2024 года IBM собрали четверых экспертов, чтобы обсудить с ними насколько реальна революция AI агентов. Среди экспертов были
- Maryam Ashoori, PhD: Director of Product Management, IBM® watsonx.ai™
- Marina Danilevsky: Senior Research Scientist, Language Technologies
- Vyoma Gajjar: AI Technical Solutions Architect
- Chris Hay: Distinguished Engineer
Их позиции в этой статье выглядели примерно так
1. Ашоори: Сегодняшние «агенты» - это LLM с базовым планированием и function calling. Настоящий агент должен автономно рассуждать и планировать.
2. Данилевски (самая скептичная): «Я до сих пор не понимаю, чем это отличается от обычной оркестрации. Вы просто переименовали оркестрацию в агенты, потому что это модное слово». Данилевски опирается на опыт программирования - оркестрация существует давно. Ашоори разделяет текущие возможности и теоретический потенциал.
3. Хэй (самый оптимистичный): Технологический фундамент уже готов:
-- Лучшие, быстрые, компактные модели
-- Chain-of-thought training
-- Расширенные контекстные окна
-- Function calling
На чем основано: Хэй анализирует техническое развитие моделей за 12-18 месяцев и видит качественный скачок в возможностях.
4. Гаджар: «Мы видим ранние проблески, но для сложных решений нужны прорывы в контекстном мышлении и edge cases».
Среди экспертов разгорелись споры по следующим темам
1. Оркестрация vs единый агент
Хэй: Будет маятниковое движение - сначала multi-agent системы с оркестратором, потом переход к «богоподобным» единым агентам, затем снова к коллаборации.
- Ашоори: Это архитектурное решение, зависит от use case. Не всегда нужен мета-оркестратор.
2. Enterprise readiness
- Хэй: «Большинство организаций не готовы к агентам. Интересная работа будет в экспозиции API ваших enterprise-систем». На чем основано: Понимание текущего состояния enterprise-архитектур и требований интеграции.
3. Проблемы безопасности
- Ашоори: «Что, если агент подключится к датасету и удалит кучу чувствительных записей?»
- Данилевски: «Технология не думает. Она не может быть ответственной. Масштаб риска выше - технология может сделать больше за меньшее время незаметно».
- Гаджар предлагает в качестве решений: строгое тестирование в sandbox, механизмы rollback, audit logs.
4. Human-in-the-loop vs замещение
- Данилевски: Агенты будут аугментировать людей - «человек должен постоянно присутствовать и принимать финальные решения».
- Хэй: «Есть реальный риск, что при неправильной реализации люди будут дополнять AI, а не наоборот».
На чем основаны прогнозы экспертов
- Технический анализ: Хэй смотрит на прогресс в модельных capabilities
- Практический опыт: Данилевски основывается на опыте с текущими системами
- Enterprise research: Ашоори опирается на исследования поведения разработчиков
- Архитектурное понимание: Гаджар анализирует требования к production-системам
Выводы для инженеров
- Текущие «агенты» - это upgraded LLM с function calling. До настоящей автономии еще далеко, но базовые кейсы уже работают.
- Ценность будет у тех, кто организует свои данные для агентных workflow. Проблема не в моделях, а в enterprise-readiness.
- Transparency, traceability, rollback mechanisms - это не опция, а must-have. Один неконтролируемый агент может удалить критические данные.
- «Не становитесь молотком в поисках гвоздей» - сначала определите ROI, потом внедряйте агенты.
Главное предсказание авторов в том, что 2025 действительно станет годом экспериментов с агентами, но революцию стоит ожидать позже. Готовьте почву сейчас, но держите ожидания реалистичными. Пока кажется, что он сбывается:)
#AI #Software #Architecture #Agents #Leadership #ML #SystemDesign
Спектакль «Учёная семейка и роботы» (Рубрика #Kids)
Ученая семейка рассказывала про роботов. Нащшим малышам выдали дипломы повышения квалификации по итогам часового представления:)
А если серьезно, то были опыты с жидким азотом, рассказ о том, как работают гидроэлектростанции, конвейер и роботы. Теоретическая часть была хорошо сдобрена юмором - детишки смеялись и с большим интересом генерировали ответы на вопросы актеров.
#ForKids #ForParents
Большая энергетика. Что почем и как с этим жить (Рубрика #Economics)
Прочитал уже вторую книгу Андрея Косько, популяризатора науки, который в своей первой книге "Да будет свет... и тепло! Сколько стоит энергия" уже обращался к теме энергетики. Я про нее уже рассказывал, но если кратко, то там он на пальцах объяснял, что такое энергия и откуда она берется, отвечал на вопросы вроде «Когда закончится нефть?» и «Пересядем ли мы на автомобили с солнечными панелями?» - опираясь на основы физики, экономики и политики. Во второй книге "Большая энергетика" 2022 года Андрей продолжает эту тему на более глобальном уровне, но как и первое издание, она написана для широкой аудитории и не требует специальных знаний выше школьного курса. Правда, теперь автор смещает фокус с бытовых аспектов к "большой энергетике" - мировой энергетической системе, рынкам и геополитике. Это логичное развитие: получив в первой книге базовое понимание об энергии, читатель во второй погружается в сложные вопросы международной энергетики и получает ответы на вопросы вида
- Что нас ждет с изменением климата?
- Почему во всем мире так активно внедряется электротранспорт?
- Что вызывает ценовые шоки на нефтяных и газовых рынках и управляет динамикой поставок углеводородов?
Андрей подкрепляет выводы официальными документами, статистикой и реальными примерами. Книга охватывает технические, экономические, торговые и политические аспекты производства, транспортировки и потребления энергоносителей. Благодаря такому комплексному подходу читатель получает целостное представление о том, как устроена большая энергетика - от скважины и электростанции до розетки в доме, и какие силы движут этой системой. Эта тема особо важна сегодня: мир переживает сложный этап в энергетике, когда традиционный рынок углеводородов становится все более непредсказуемым из-за геополитических и экономических потрясений, а параллельно набирают вес новые факторы, такие как глобальная электрификация и стремительный рост спроса на электроэнергию со стороны IT и искусственного интеллекта.
Структура книги
Книга логично поделена на четыре части, каждая из которых отвечает на конкретный блок вопросов
Часть I: «Статистика. Что и сколько?» - здесь собраны данные о ключевых энергетических ресурсах: нефть, природный газ (включая сжиженный - СПГ), уголь, электроэнергию и их роль в мировом энергобалансе.
Часть II: «Торговля. Кто и кому?» - посвящена глобальному энергетическому рынку. Обсуждается, что такое рынок энергоносителей и как энергоресурсы превращаются в товар.
Часть III: «Экология. Что делать?» - сфокусирована на климате и экологии. Здесь автор разбирает проблему глобального потепления, парникового эффекта и их прямую связь с энергетикой.
Часть IV: «Политика. Как с этим жить?» - заключительная часть об энергетической политике и безопасности. Косько описывает понятие энергетической безопасности и вспоминает энергетические кризисы прошлого, чтобы показать их уроки. Даётся обзор деятельности международных энергетических организаций и анализируются региональные стратегии.
Хотя книга вышла в 2022 году, её содержание остается весьма актуальным на конец 2025 года. За последние годы энергетический ландшафт претерпел резкие изменения, но описанные Косько тренды только усилились. Рынок углеводородов по-прежнему лихорадит: после волатильности 2022–2023 гг. цены на нефть и газ то взлетают, то падают, реагируя на геополитику, санкции и решения ОПЕК. Электротранспорт продолжает набирать популярность по всему миру, выполняя прогнозы книги. Одновременно искусственный интеллект и цифровая экономика предъявляют новый запрос на электроэнергию: мощности дата-центров и суперкомпьютеров для ИИ растут экспоненциально. По оценкам, уже сейчас 5–15% потребления энергии дата-центров приходится на задачи ИИ, а к 2030 году эта доля может возрасти до 35–50%. Вопросы экологии тоже никуда не делись: 2023–2025 годы принесли рекордные природные аномалии, подчёркивая срочность борьбы с изменением климата – тем самым поддерживая важность обсуждения климатической повестки, рассмотренной в книге.
#Engineering #History
🧠 Как устроен наш ИИ-агент для разработчиков
Мы в Т запустили агентский режим для разработки. Теперь агент не просто подсказывает части кода, а выполняет последовательность действий по заданию инженеров и помогает им сфокусироваться на сложных и креативных задачах.
🔥 Скоро откроем предзапись, чтобы любой желающий мог попробовать ИИ-агента в деле. Подробнее — на сайте.
#AI4SDLC
AI в SDLC: от ассистентов к агентам
3 октября на конференции AI Boost я буду выступать с таким докладом. Саму конференцию про реальное ускорение разработки с помощью AI организовали ребята из Surf и где-то месяц назад они предложили мне выступить с продолжением моего доклада "Интегрируем AI в процессы разработки в большой компании", который я рассказывал летом на CTO Conf.
В новом докладе я планирую поговорить про переход от режима AI-«ассистентов» (GitHub Copilot, Cursor и др.) к агентному подходу - когда автономные ИИ-агенты становятся полноценными участниками SDLC и взаимодействуют между собой. Будут затронуты следующе темы
1. Почему про это так много говорят - экономические предпосылки и эффект на workforce
2. Почему для эффективности AI-агентов критически важны чёткая постановка задач и знание контекста проекта
3. Как роль инженера смещается в сторону тимлида команды AI-агентов и какие для этого требуются навыки и образ мышления
4. Как мы дошли до жизни такой и какие агентские инструменты появились или засияли в 2025 году (Claude Code, OpenAI Codex, ...)
5. Как мы создали свой агентский режим для разработки и как он себя показывает на наших сценариях
6. Как это связано с модным "вайб-кодингом", где новым многообещающим языком программирования видят ... английский
Если вам нравится эта тема, то покупайте билеты на конференцию и приходите слушать и задавать вопросы. А если вам интересно общее состояние дел о том, как AI влияет на инженерную культуру, то предлагаю пройти опрос от Т-Банка на эту тему. О чем этот опрос и почему его результаты будут интересными я уже рассказывал раньше.
#AI #Engineering #Software #Management #ML #DevEx
Как измерять продуктивность инженеров на разных уровнях (Рубрика #DevEx)
Появилась запись выступления Станислава Моисеева, директора R&D‑центра Т‑Банка с Big Tech Night. В этом докладе Стас делает обзор лучших практик последних лет и связывает их с волной GenAI‑инструментов. За 5 лет ландшафт сильно изменился: ковид → удалёнка → внедрение AI. Компании инвестируют в ИИ‑инструменты для разработки, но без измерений сложно доказать ROI. Доклад показывает, какие метрики и на каком уровне отвечают на вопрос «что реально ускоряет поставку ценности», и упоминает методологию индустриального опроса 2025 для оценки влияния GenAI на разработку.
Если говорить про уровни, то они такие IC (индивидуальные контрибьюторы) -> команды -> компании -> индустрия целиком. И работает это так
- IC (индивидуальный инженер): следить стоит не за «строками кода», а за временем потока (сколько часов без переключений), cycle time своего PR, долей переделок/rollback’ов, качеством ревью. Это помогает видеть, как инструменты (IDE‑плагины, ассистенты, автотесты) влияют на вашу личную скорость и аккуратность. Осмысленный набор метрик хорошо описывается рамкой SPACE (удовлетворённость, performance, activity, communication, efficiency).
- Команда: классический набор DORA (частота деплоев, lead time for changes, доля неудачных изменений, MTTR) + операционные метрики потока: WIP, размер PR, доля «ожидания» vs «работы», стабильность спринтов. Эти показатели коррелируют с предсказуемостью поставки и качеством.
- Компания: здесь важны сквозные метрики: cost‑per‑change, time‑to‑value, скорость онбординга, покрытие автотестами критичных путей, утилизация платных AI‑мощностей на разработку vs «игрушки», экономия инженерных часов от ассистентов. Цель - связать инженерные метрики с P&L: сколько стоил прирост скорости и как он отразился на бизнесе.
- Индустрия: бенчмарки и сравнительные опросы. В докладе заявлен подход к индустриальному исследованию 2025 года по влиянию GenAI — чтобы компании могли соотнести свои практики с «средней температурой по цеху» и отделить хайп от эффекта (я уже рассказывал про это исследование раньше)
Если говорить про то, на что обратить внимание при использовании метрик, то
- Не стоит использовать анти‑метрики: «строки кода», «количество задач», «скорость закрытия багов» без контекста. Они легко геймитсятся и толкают к плохим решениям.
- Не используйте метрики без обратной связи: любой график должен вести к конкретному решению процесса или инструмента.
- Не мерьте температуру «среднюю по больнице»: сравнивайте себя со своей историей (тренды), а не с соседним отделом с другим контекстом или на другой архитектуре.
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership
Запустили T-Pay на iPhone и вернули бесконтактную оплату на смартфоны Apple ⚡
Сервис работает на технологии Bluetooth Low Energy и совместим с технологией оплаты iPhone от Сбера. Для покупки достаточно поднести смартфон к терминалу. Кэшбэк и мили начислим так же, как при оплате картой.
Рассказываем, как подготовить iPhone к оплате с T-Pay:
1️⃣ Скачайте и установите актуальную версию нашего приложения. Его могут удалить из App Store в любой момент, поэтому лучше обновиться прямо сейчас. У приложения могут быть разные названия, так и задумано. Главное — скачивать по официальной ссылке.
2️⃣ Убедитесь, что ваш смартфон подключен к интернету и работает на iOS 16 или новее, а версия приложения Т-Банка — 7.19 и выше.
3️⃣ Проверьте, что у вас подключен Bluetooth, затем настройте его. Для этого зайдите в настройки iPhone: «Конфиденциальность и безопасность» → Bluetooth → разрешите доступ приложению Т-Банка.
4️⃣ Если при оплате автоматически открывается Apple Pay, рекомендуем увеличить расстояние между смартфоном и терминалом либо удалить карты из Wallet, чтобы использовать именно T-Pay.
➡️ Скачать приложение: https://t.tb.ru/ble_smm
❤️ — если скучали по бесконтактным покупкам
[1/2] Virtual Agent Economies (Рубрика #AI)
Изучил очередной интересный whitepaper от ребят из Google на этот раз на тему агентской экономики. В этой работе они изучают зарождение нового слоя экономики, управляемого автономными агентами искусственного интеллекта. Они задались целью осмыслить, как массовое внедрение таких агентов повлияет на экономику и приведет к отдельной виртуальной агентной экономике, где цифровые агенты взаимодействуют, совершают сделки и координируются с масштабом и скоростью, недоступными для непосредственного контроля человека. Для описания этого явления авторы вводят понятие sandbox economy и предлагают характеризовать ее по двум осям
1. Происхождению: стихийно-эмерджентная vs. преднамеренно спроектированная
2. Степени отделенности от существующей человеческой экономики: проницаемая vs. непроницаемая
Основной вывод работы: без целенаправленного вмешательства велика вероятность стихийного формирования обширной агентной экономики с высокой степенью проницаемости границ, т.е. тесно связанной с реальным рынком. Тут есть плюсы и минусы
(+)Такая система сулит беспрецедентные возможности для координации и автоматизации – агенты способны самостоятельно создавать экономическую ценность, взаимодействуя друг с другом вне прямого участия человека
(-) У такой системы значительные риски: возможны новые формы системного экономического риска (например, мгновенные «флэш-кризисы» из-за сверхбыстрых сделок ИИ) и усиление неравенства, если продвинутые агенты получат преимущество перед более слабыми
В итоге, авторы делают вывод о необходимости проактивного дизайна правил и инфраструктуры для этих агентных рынков. Они предлагают ряд мер и механизмов – от аукционов для справедливого распределения ресурсов до создания «миссионных» экономик под цели всеобщего блага – которые позволили бы направлять эволюцию агентной экономики в безопасное русло. Ключевой рекомендацией является преднамеренная архитектура виртуальных рынков с встраиванием принципов доверия, прозрачности и подотчетности, чтобы грядущие изменения в экономике служили долгосрочному процветанию человечества.
В прододжении чуток расскажу про методологию анализа авторов.
#AI #Engineering #Architecture #DistributedSystems #ML #Software #Economics
[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
Журнал "Майнкрафт" (Рубрика #Kids)
Вчера были в большом торговом центре семьей и купили детишкам журналы в разделе пресса. Младший сын, которому скоро будет пять, выбрал себе журнал про майнкрафт, которым он увлечен последний год:) Сегодня мы с ним рассматривали картинки и зачитывали избранные отрывки, а я вспоминал времена своего детства. В те времена я покупал журналы про игры на денди, сега, а потом и про компьютерные игры. Время идет, игры меняются, а игровые журналы все равно собирают аудиторию (хотя с текущим засильем интернета часть изданий теперь обходится без бумаги).
#Kids #Games
[2/2] The Technological Republic: Hard Power, Soft Belief, and the Future of the West (Технологическая республика. Жесткая сила, мягкая вера и будущее Запада) (Рубрика #Economics)
Продолжая рассказ про книгу, расскажу про основные идеи подробнее
1. Кремниевая долина потеряла ориентир общественного блага. Авторы начинают с резкой критики современной Силиконовой долины, утверждая, что за последние десятилетия технократическая элита изменила своим бывшим идеалам. Вместо решения больших задач человечества или укрепления национального процветания, лучшие инженерные умы занялись обслуживанием тривиальных потребностей рынка. Авторы говорят, что IT-гиганты ныне тратят колоссальные ресурсы не на прорывные инновации ради общего блага, а на приложения для комфорта избалованных потребителей. Забавно, что не требуется даже думать, чтобы можно было назвать конкретные компании, которые критикуют авторы.
2. Урок истории: союз технологий и государства творил великие дела. В противопоставление нынешней ситуации авторы приводят золотой век техно-прорывов XX века, когда наука, бизнес и государство в США действовали заодно (Манхэттенский проект, проект Apollo с высадкой человека на Луну). Эти программы объединили тысячи лучших учёных и инженеров, были щедро профинансированы государством и привели к колоссальным достижениям, изменившим ход истории. Авторы подчёркивают, что ранние инновации Кремниевой долины рождались похожим образом. Контраст с сегодняшним днем разителен: вместо “больших замыслов” - культура стартапов, устремленных к быстрому IPO; вместо сотрудничества с государством - гордое противопоставление ему или бегство от регулирования. Кстати, современный проект "Stargate" в этом плане выделяется (см. документалку, о которой я уже рассказывал)
3. “Мягкая вера” Запада: утрата общих убеждений и целей. Важнейшее понятие, которое вводят Карп и Замиска, - это кризис веры и идейной воли на Западе, то, что они называют "soft belief". С их точки зрения, у западных элит (политиков, академиков, гендиректоров) притупилась способность формулировать настоящие убеждения и отстаивать их публично. В публичной сфере царит дух самосохранения и страха кого-либо обидеть, из-за чего лидеры предпочитают говорить ни о чем, прятаться за корпоративными лозунгами, лишь бы избежать шквала критики в соцсетях. Этот интеллектуальный релятивизм ведет к тому, что компании, реально определяющие будущее (бигтехи), хранят многозначительное молчание о том, куда движется мир. Авторы доходят до идеи о “распаде национальной идентичности”, которая когда-то сплачивала изобретателей и инженеров вокруг общей цели, а теперь растворилась в космополитичном мире потребительства
4. Необходим пересмотр либерального консенсуса. Вследствие вышеописанного авторы считают, что сложившийся после Холодной войны либеральный консенсус – вера в автоматическое торжество свободного рынка, глобализации и толерантности - нуждается в переосмыслении. Карп и Замиска вовсе не призывают отказаться от демократических свобод, но считают, что Западу пора избавиться от наивности и вернуть стратегическое мышление времен противостояния с тоталитаризмом. Видно, что авторы противопоставляют себя Китаю и другим автократиям.
5. Технологическая республика: как технологии могут спасти, а не убить демократию. Центральный образ книги - “технологическая республика” и аллюзия на платоновскую «Республику» (не случайна). Речь о политическом порядке, крайне необходимом сегодня Америке и всему Западу, понимаемому как сообщество технологически и морально развитых демократий под лидерством США. По замыслу авторов, такая республика смогла бы противостоять вызовам XXI века, опираясь одновременно на “жесткую силу” (военную и технологическую мощь) и “мягкую веру” (убежденность, ценности и интеллектуальную смелость). По сути, “технологическая республика” - это призыв к возрождению просвещенного патриотизма среди технарей, ученых, предпринимателей. Их книга - это манифест уверенности в том, что Запад еще способен обновиться и победить, если обретет волю и смысл.
#History #Economics #Future
[3/3] Future of Work with AI Agents: Auditing Automation and Augmentation Potential across the U.S. Workforce (Рубрика #AI)
Заканчивая рассказ (1 и 2) про исследование, поделюсь финальными мыслями.
Исследование также выявило важную тенденцию: по мере внедрения AI-агентов меняется набор ключевых навыков, востребованных у человека. Человеку будущего потребуется меньше узкоаналитических умений, но больше социальных и управленческих компетенций. Ведь аналитическую работу заберет на себя ИИ.
Отдельно авторы обсудили ограничения своего исследования:
- Авторы подчеркивают, что их результаты - это “срез” начала 2025 года, и прямолинейно проецировать их на далекое будущее нельзя без учета развития технологий. В частности, база WORKBank охватывает существующие задачи из O*NET; но в будущем появятся новые виды задач и профессий по мере интеграции AI, которые сейчас просто не учтены
- Респонденты могли не до конца представлять возможности новейших AI-систем (авторы отмечают, что многие люди пока мало знают о границах и потенциале ИИ), что могло повлиять на их ответы
- Опрос охватил 104 компьютеризированные профессии - это широкий спектр, но не все профессии экономики; исключены, например, рабочие специальности, где ИИ-агенты пока не применяются.
Авторы прогнозируют, что ландшафт предпочтений и возможностей будет смещаться: по их словам, «AI Agent WORKBank отражает текущее состояние генеративного ИИ в начале 2025 года, и по мере эволюции технологий картина выполнимых и желанных для агентов задач будет меняться. Будущие итерации этого аудита необходимы для отслеживания долгосрочных трендов».
Также исследователи дают несколько предсказаний и рекомендаций
1. Они ожидают снижения спроса на чисто аналитические, монотонно-информационные навыки (там, где ИИ уже доказал эффективность) и увеличения роли навыков, требующих взаимодействия между людьми. Этот прогноз подкрепляется их находкой о смещении высокооплачиваемых навыков и фактически рисует образ рынка труда, где в цене будут социальный интеллект, умение управлять и обучать, а не только умение работать с информацией
2. Авторы призывают к активным мерам по переподготовке работников. Поскольку AI-агенты способны изменить структуру спроса на навыки, важно уже сейчас разрабатывать программы рескиллинга и апскиллинга - переобучения сотрудников под новые компетенции
3. Исследование указывает на необходимость более человеко-ориентированной стратегии внедрения ИИ. Организациям и разработчикам рекомендуется учитывать желания работников при решении, что автоматизировать - то есть AI-системы будущего должны разрабатываться в тандеме с пользователями, чтобы они вызывали доверие, принимались сотрудниками и повышали эффективность без негативных социальных последствий
4. Бриньолфссон подчеркивает, что особое внимание следует уделить зонам “R&D Opportunity” - тем задачам, которые люди хотят автоматизировать, но техника пока не умеет. Повышение интенсивности исследований именно в этих областях позволит создать AI-инструменты, приносящие максимальную пользу и востребованные на рабочих местах, тем самым лучше подготовив экономику к будущему
В целом, авторы видят будущее труда не как полную роботизацию, а как эволюцию ролей, где человек и умные агенты работают совместно, и призывают управлять этой эволюцией ответственно, исходя из потребностей людей.
P.S.
Выводы авторов про совместную работу напоминают идеи из whitepaper "Rethinking Software Engineering in the Foundation Model Era: From Task-Driven AI Copilots to Goal-Driven AI Pair Programmers", про который я рассказывал раньше.
#AI #Economics #ML #Work
[1/3] Future of Work with AI Agents: Auditing Automation and Augmentation Potential across the U.S. Workforce (Рубрика #AI)
Прочитал свежее и интересное исследование про будущее работы с учетом появления AI агентов (июнь 2025 года). Данное исследование проведено группой ученых Стэнфордского университета - в частности, исследователями из Института человеко-ориентированного ИИ (HAI) и Лаборатории цифровой экономики Стэнфорда. В состав авторов входят молодые исследователи (Йидзя Шао, Хумишка Зоуп, Ючэн Цзян, Цзясин Пэй, Дэвид Нгуен) под руководством признанных экспертов: профессор компьютерных наук Дии Йэн (Diyi Yang) и экономист Эрик Бриньолфссон (Erik Brynjolfsson). У Эрика есть научно-популярная книга “Machine, Platform, Crowd” 2017 года, о которой я уже рассказывал. Также я недавно разбирал похожую статью от Erik Brynjolfsson, Bharat Chandar и Ruyu Chen про трудоустройство "Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence".
И теперь, когда ясно, что исследование от уважаемых людей, стоит рассказать в чем основная мысль авторов. Они хотели понять, а чего именно хотят сами работники от внедрения ИИ на рабочих местах, и насколько современные возможности AI-агентов соответствуют этим желаниям. Это желание напомнило мне whitepaper "What Do Developers Want From AI?" от ребят из Google, который я разбирал раньше. Но в этом исследовании вопрос поставлен примерно так: какие задачи своей работы люди хотели бы автоматизировать с помощью AI-агентов или, наоборот, предпочли бы оставить под человеческим контролем, и совпадает ли это с тем, что текущие технологии вообще способны автоматизировать. Плюс исследователей интересовало то, как интеграция AI-агентов может повлиять на структуру навыков и ролей в будущем.
Для ответа на этот вопрос авторы разработали отдельную методологию, завязанную на опросы работников и экспертов. Они опросили 1 500 сотрудников из 104 различных профессий по всей США. Вопросы касались конкретных рабочих задач (взятых из официальной базы задач O*NET Министерства труда США), которые каждый респондент реально выполняет на своей работе. Работников просили указать, хотят ли они, чтобы AI-агент полностью автоматизировал выполнение каждой такой задачи, лишь помогал (дополнял человека) или же предпочли бы не использовать ИИ для данной задачи вовсе. Для более глубоких ответов использовались аудио-интервью (голосовые комментарии) и 5-балльная шкала Human Agency Scale (HAS), отражающая уровень участия человека - от H1 (полностью автономный ИИ, без участия человека) до H5 (полностью ручное выполнение, ИИ только как инструмент). Этот новый показатель HAS позволил количественно оценить предпочтительную степень участия человека в разных заданиях, а не только бинарно "автоматизировать или нет".
Отдельно авторы опросили 52 экспертов по ИИ (разработчиков AI-агентов) для оценки текущей технической реализуемости автоматизации тех же задач. Эксперты оценивали, насколько современные системы ИИ (на начало 2025 г.) способны выполнять каждую из 844 рассмотренных рабочих задач. Такой двойной сбор данных - от работников и от экспертов - лег в основу базы WORKBank (AI Agent Worker Outlook & Readiness Knowledge Bank). WORKBank объединил предпочтения работников и оценки возможностей ИИ по широкому спектру задач (844 задачи, 104 профессий).
Используя собранные данные, исследователи построили "ландшафт желаний vs. возможностей", распределив задачи по четырем зонам в зависимости от того, хотят ли люди их автоматизации и может ли ИИ их выполнить (вспоминается тост "Так выпьем же за то, чтобы наши желания совпадали с нашими возможностями"). Также была проанализирована текстовая расшифровка аудиоответов работников (тематика опасений и надежд) с помощью тематического моделирования, и выполнено сопоставление задач с требуемыми навыками и уровнем заработной платы, чтобы выявить смещение значимости навыков в связи с ИИ.
Продолжение с разбором результатов исследования в следующем посте.
#AI #Economics #ML #Work
[2/2] How tech companies measure the impact of AI on software development (Рубрика #AI)
Продолжая пост про измерение влияние AI на разработку хочется поделиться примером из Dropbox, где ~90% инженеров регулярно пользуются AI-помощниками (по индустрии ~50%). Там измеряют активных пользователей, CSAT, экономию времени и расходы на ИИ, а затем накладывают эти данные на core-метрики: change fail percentage (CFR), throughput и др. (заметим, что CFR и throughput - это контр-балансирующие метрики). В итоге AI-пользователи доставляют на ~20% больше кода в неделю, при этом качество не падает (сбоев даже меньше). Это признак того, что массовое внедрение ИИ реально повышает эффективность, а не просто активность.
Компании также сравнивают показатели у тех, кто пользуется ИИ, и тех, кто нет, и наблюдают изменения со временем. Такой анализ возможен только при наличии базовых данных до внедрения ИИ, но он ценен: так можно проверять гипотезы о влиянии ИИ на реальных цифрах. Важно не упирать только на скорость, забивая на качество - важно, чтобы рост частоты релизов/PR не сопровождался увеличением багов или откатов. Для выявления скрытого негативного эффекта (ухудшение maintainability, недовольство команды) проводите регулярные опросы Developer Experience.
Из размышлений авторов вытекают практические рекомендации:
1.Сформулируйте ключевые метрики продуктивности (качество и скорость) и зафиксируйте базовый уровень до внедрения ИИ. Без этого непонятно, улучшает ли ИИ то, что нужно.
2. Отслеживайте использование ИИ, но не путайте активность с результатом. Важно не количество сгенерированного кода, а влияние на качество, скорость и комфорт работы
3. Балансируйте скорость и надёжность. Ускорение работы не должно приводить к росту брака - следите сразу за метриками скорости и качества
4. Учитывайте опыт команды. Наряду с логами и другими системными метриками регулярно собирайте обратную связь разработчиков (опросы DevEx, CSAT) - так вы не пропустите проблемы, незаметные в одних только цифрах.
5. Не карайте метриками. Донесите, что показатели ИИ нужны для улучшения процессов, а не для оценки персонала. Иначе подорвёте доверие и получите искажённые данные.
6. Культивируйте эксперименты. Пробуйте разные инструменты на небольших проектах, сравнивайте, где эффект максимален. Поощряйте обмен знаниями – обсуждайте удачные и провальные кейсы, делитесь находками и предупреждайте об ограничениях инструментов
7. Держите в фокусе ROI и риски. Отслеживайте, где ИИ даёт наибольший эффект и оправдывает вложения. Ограничьте применение ИИ в критичных зонах (данные пользователей, безопасность) до появления уверенности и нужных контролей
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Unpacking нового роутера (Рубрика #Hardware)
Недавно решил сменить роутер дома, так как прошлый не дотягивал до дальней комнаты. Решил прикупить роутер с 4 ядрами, достаточным количеством оперативы, а также слотом под флешку, чтобы расширять их. После раздумий я купил TP-Link AX80v1, особенно когда под него появилась прошивка под openwrt. А потом я его начал распаковывать и настраивать, что привело к распаковке до уровня платы и подключению через uart для накатки новой прошивки. Внутри роутер выглядит тоже отлично, примерно как и снаружи. Зато теперь у меня есть неплохой роутер со всеми нужными для меня возможностями (правда я узнал, что под перепрошивку можно купить роутер помощнее и даже подешевле).
#Hardware #Software
Rethinking Software Engineering in the Foundation Model Era: From Task-Driven AI Copilots to Goal-Driven AI Pair Programmers (Рубрика #AI)
Прочитал интересный и короткий whitepaper про изменения в разработке софта, готовясь к выступлению "AI в SDLC: от ассистентов к агентам". Если кратко, то это статья далекого 2024 года (а для AI прошлогодняя статья - это реально далеко), в которой авторы A. E. Hassan, G.A. Oliva, D. Lin, B. Chen, Z. M. Jiang предлагают уйти от task‑driven copilot‑инструментов к goal‑driven AI‑напарнику, который понимает цели разработки, помогает с архитектурой, кодом и проверкой результата.
Если присмотреться, то ключевые моменты такие
- Goal‑driven AI pair programmer, где ИИ не автодополнение, а партнёр по достижению цели (фичи, баг-фикса, миграции)
- Инженерный процесс EDD (evaluation‑driven delivery), который аналогичен TDD (test-driven development), но фокус на постоянной проверке прогресса к цели на основе evals
- В основе мультиагентная схема из четырех агентов:
-- Агент целей - помогает выяснить цели инженера, общаясь с ним и собирая информацию (работает как аналитик)
-- Агент архитектуры - умеет дизайнить под выясненные требования, знает архитектурные паттерны и может использовать ATAM (architecture tradeoff analysis method) или его аналоги
-- Агент кода - рабочая лошадка, что умеет писать хороший код (и не только добавлять, но и рефакторить и удалять мертвый код)
-- Goal delivery агент - агент, что отвечает за интеграцию работы всех остальных агентов для доведения проекта до успешного завершения. Он отслеживает выполнение конечных требований: превращение требований в тесты, актуальность тестов при изменении требований, и финальное прохождение всех тестов. Этот агент, помимо прочего, накопливает историю выполненных целей и прогресса, что затем может использоваться для наставничества: по мере работы он отмечает, какие навыки приобретает человек, где делает ошибки (связано с задачей обучения разработчика, см. Challenge 4). (Проще говоря, агент контролирует, чтобы всё задуманное действительно реализовано и проверено тестами, и фиксирует уроки для будущего).
Для успешной работы такой системы есть следующие вызовы
-Выравнивание целей человека и ИИ (минимум уточняющих вопросов, максимум понимания контекста) - тут мы видим пресловутый вопрос alignment
- Общение на естественном языке вместо “промпт‑инжиниринга” (лучшие промпты машины пишут сами себе)
- Доступные и умные code‑LLM (качество понимания проекта при умеренных ресурсах)
- Роль ИИ‑наставника: адаптивное обучение разработчика “в паре” (AI не только исполнитель, но и ментор для инженера)
В своем исследовании авторы опираются на следующие факты
- Накопленный опыт использования GitHub Copilot и аналогов в индустрии, включая выявленные проблемы взаимодействия человека с AI
- Предыдущие попытки автоматизировать разработку с помощью мультиагентных систем (ChatDev, MetaGPT, Devin и др.)
- Проверенные временем методологии разработки (TDD, парное программирование)
- Фундаментальные теории из образования (эффект наставничества по Блуму) и психологии (Theory of Mind) для обоснования социально-обучающего аспекта ИИ
Статья была опубликована как препринт на arXiv в апреле 2024 года и сразу привлекла внимание в сообществе. Google Scholar индексирует эту работу; уже в 2024–2025 годах появились ссылки на нее в ряде новых исследований. Стоит отметить, что сами авторы продолжили развивать эту тему: в октябре 2024 они выпустили расширенный препринт “Towards AI-Native Software Engineering (SE 3.0): A Vision and a Challenge Roadmap”, фактически развивающий идеи этой статьи. В нем они ввели терминологию “Software Engineering 3.0” и более подробно описали план исследований на ближайшие годы.
Если вам нравится эта тема и интересно общее состояние дел о том, как AI влияет на инженерную культуру, то предлагаю пройти опрос от Т-Банка на эту тему. О чем этот опрос и почему его результаты будут интересными я уже рассказывал раньше.
#AI #Software #Architecture #Agents #Leadership #ML #SystemDesign
Обложка книги "Большая энергетика. Что почем и как с этим жить" и несколько иллюстраций
Читать полностью…
Angular: The Documentary | An origin story (Рубрика #Engineering)
Посмотрел интересный документальный фильм про создание и развитие фронтового фреймворка Angular. Этот фильм интересно посмотреть даже если вам не интересна история фронтовых фреймворков (кстати, про react тоже есть документалка и я уже про нее рассказывал). Фильм рассказывает как Angular родился как внутренний эксперимент в Google, который поначалу отмахнули большие команды (Gmail и Maps), а затем стал массовым фреймворком и прошёл через болезненную «вторую жизнь» (Angular 2+). А теперь чуть
1. Как Angular появился внутри Google (локальная инициатива)
Старт проекту дала команда, работавшая над Google Feedback. Она утонула в 17 000 строк фронтенда и низкой тестопригодности. Тогда Ми́шко Хевери предложил дерзкий ход: переписать всё за две недели своим хобби‑проектом (GetAngular/AngularJS). Вышло за три, но код сжался до ~1 500 строк, и это стало моментом истины — менеджмент увидел в подходе ценность и дал зелёный свет на развитие. В общем, видно, что Angular родился не как глобальная инциатива "сверху-вниз", а скорее как локальная инженерная идея, доказавшаяся прототипом лечение реальной боли команды.
2. Борьба за ресурсы и «нет» по дороге
На старте AngularJS не получал аппрув от флагманов внутри Google - многие говорили что-то в стиле "хорошая игрушка, удачи". Поддержка пришла после демонстрации драматической экономии сложности/кода и скорости разработки. Сначала - маленькая команда, много скепсиса, мало ресурсов; дальше - органический рост вокруг первых успешных внедрений. Итого, в большой компании лучше один раз радикально показать ценность на рабочем кейсе, чем долго убеждать словами.
3. Как в Angular появился Dart и почему далее произошёл «раскол» AngularJS и Angular
Следующей развилкой стала производительность, статанализ и tree‑shaking. Внутри Google к этому моменту крепки были позиции Dart (с его dart2js и агрессивным tree‑shaking), а команда Angular экспериментировала между JS, AtScript и Dart. В итоге Google и Microsoft сошлись на TypeScript: ключевые идеи AtScript попали в TS 1.5, а Angular 2 строили уже на TypeScript, параллельно поддерживая AngularDart для крупных внутренних продуктов (Ads/AdSense). Это и закрепило исторический «раскол»: AngularJS (1.x) и Angular (2+) — два разных мира. В итоге, видно, что Dart повлиял на выделение дополнительных ресурсов, архитектуру фреймворка и компиляцию (статичность, AOT, tree‑shaking), но "языковая ставка" в открытой экосистеме ушла в сторону TypeScript.
4. Большие миграции
У Angular было две ключевые миграции:
- Архитектурный разрыв AngularJS → Angular (2+) - без обратной совместимости. Перепроектирование ради мобильности, модульности, типизации и будущей компиляции. Это самая болезненная точка истории.
- Смена движка рендера на Ivy (Angular 9) - уже внутренняя замена View Engine на новый компилятор/рендерер, специально спроектированный под мелкогранулярный tree‑shaking и меньшие бандлы. Переход стал дефолтом в v9 и принёс ощутимую экономию размера без переписывания приложений с нуля.
Обе миграции были болезненны, но кажется, что необходимы.
5. Как Angular чувствует себя сейчас и планы
Angular снова на подъёме: зрелая реактивность (Signals), сильный SSR/гидрация, фокус на DX и производительности, аккуратные мажоры без «лома мира». А Google планирует переносить фичи Wiz (внутреннего фреймворка внутри Google) в публичный Angular. Акутальная дорожная карта есть на angular.dev/roadmap.
В общем, документалка показалась мне интересной как техническому руководителю и инженеру - из этой истории можно извлечь много полезных уроков о том, как создавать и развивать крупные проекты.
#Software #SoftwareDevelopment #Architecture #Engineering #Management #OpenSource
Мы рассказали чуть подробнее о том, как работает наш агентский режим для разработчиков
Читать полностью…
Библиотеки
Прикольно, что в парке на Ходынке сделали библиотеку. Забавно, что в нее я хожу со своими книгами:) Но сама идея - топ. Правда, я все равно предпочитаю читать книги, гуляя по парку, а не сидя в библиотеке. Вот дочитываю книгу Гергели Ороша, про котрую писал уже раньше
Code of Leadership #55 Interview with Alexey Kashin about management, architecture & reliability (Рубрика #Leadership)
Интервью с Алексеем Кашиным, моим коллегой, который в Т-Банке руководит направлением разработки сервисов неклиентских профилей в нашей платформе профилей. Интересно, что параллельно этому Леша выполняет роль chief reliability officer, главного за надежность в той же profiles platform. За полтора часа мы обсудили множество тем
- Вступление и текущая роль (платформа профайлов)
- Ранние годы и первые шаги в программировании
- Вуз: поступление, SQL/БД, диплом
- Старт карьеры: финуправление и администрирование
- Внедрение документооборота: процессы, обучение, модель работы
- Переход к руководству и запуск BPM-направления (стоимость, импортозамещение, Java)
- Первый продукт на новой платформе; смена стека и переход в другую компанию
- Формат работы и инфраструктура; проблемы многопоточности и зависаний
- Рост команды и обучение; «единая кредитная заявка» и финмаркетплейс
- Платформа и технические улучшения; переход в Тинькофф и реинжиниринг CRM
- Архитектура домена компаний и бесшовная миграция (репликация, Kafka, сверка данных)
- Инструменты и надёжность: инциденты, метрики, шардирование/кастом БД, миграции
- Инженер vs менеджер, распределёнка и роль офисов
- Work/liffe баланс и советы слушателям
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#Software #Engineering #Management #Career #Leadership #Architecture #Reliability
Релиз мобильного Т-Банка на iOS с оплатой по bluetooth:)
Читать полностью…