10к подписчиков на канале

Вчера нас в этом канале стало 10 тысяч, что, как я считаю, очень круто. Спасибо всем, кто подписан на канал, я надеюсь, что вы находите для себя здесь иногда интересную информацию. Думаю, что по поводу юбилея надо устроить еще одну AMA (ask me anything) серию, как была в прошлом августе. В общем, если есть что спросить, то не держите в себе, а пишите комменты в тред под этим постом.

MCP vs ACP vs A2A: Comparing Agent Protocols - Laurie Voss (Рубрика #AI)

Ироничное выступление Laurie Voss, VP Developer Relations в LlamaIndex, где он за 15 минут рассказал про основные протоколы межагентского взаимодействия. Изначально он хотел рассказать про 3 основных протокола, но в ходе подготовки обнаружил ещё 11:) А в ходе выступления пошутил, что добавил бы еще в список протоколов WTF и LOL просто так... хотя наверняка уже есть протоколы с такими названиями.

Основные идеи представлены ниже

1. Создавать протоколы сейчас модно
За месяц исследований при подготовке scope доклада вырос с 3 до 14 протоколов, создалось даже впечатление, что почти все сейчас работают над агентскими протоколами
2. Два типа протоколов
- Context-oriented: предоставляют контекст LLM (MCP, agents.json)
- Inter-agent: обеспечивают взаимодействие между агентами (все остальные)
3. MCP - де-факто стандарт
Model Context Protocol от Anthropic доминирует благодаря раннему фокусу на конкретной проблеме.
4. A2A от Google
Agent2Agent Protocol от Google фокусируется на асинхронном взаимодействии и долгосрочных задачах.
5. Два ACP протокола
- ACP Connect от Agntcy, куда входят Cisco, LangChain, LlamaIndex, Galileo and Glean - с интегрированным реестром агентов
- ACP Communication от IBM - форк MCP, развивающийся в сторону A2A
6. Agora - самообновляющийся протокол
Agora - это интересный подход, где все начинается с естественного языка и дальше он позволяет участникам обновлять протокол во время взаимодействия.
7. Протокол от блокчейн ребят
AITP от NEAR Protocol слишком фокусируется на стоимости взаимодействий. Забавно, что спикер пошутил в духе, что "блокчейн пока не решил ни одной проблемы, так что не думаю, что решит и эту"
8. LMOS почти от IBM
Eclipse Foundation создаёт LMOS, параллельно с собственным ACP. Здесь была шутка о том, что Eclipse Foundation - это замаскированная IBM, создающее то же самое, что создаёт IBM. И если это кажется вам странным, значит вы мало общались с IBM:)
9. Отсутствие ключевых компонентов
Всем протоколам не хватает по мнению автора: централизованного реестра, системы авторизации и системы репутации.
10. MCP как основа будущего
Итоговый вывод в том, что MCP завоевал внимание и может расшириться для решения межагентских задач без добавления новых протоколов.

P.S.
Эта тема с агентами хорошо дополняет историю с вчерашнего доклада про внедрение AI в SDLC, которую я рассказывал на CTO Conf X.

#AI #Agents #Engineering #DistributedSystems

Генетическая селекция эмбрионов: От научной фантастики к коммерческой реальности (Рубрика #Science)

Наткнулся вчера на пост про стартап Nucleus Genomic, что презентовал революционную платформу Nucleus Embryo, которая позволяет родителям анализировать генетические профили эмбрионов при ЭКО и выбирать наиболее подходящие для имплантации. Это мне напомнили дистопический мир, изображенный в культовом фильме "Гаттака" 1997 года. Но давайте сначала поговорим про продукт, а дальше вспомним Гаттаку

Nucleus Embryo — это софт для генетической оптимизации, который позволяет родителям проанализировать до 20 эмбрионов по более чем 900 наследственным заболеваниям, а также по 40 дополнительным параметрам, включающим риски развития рака, хронических заболеваний, физические характеристики, когнитивные способности и даже цвет глаз. Это решение основано на полногеномном секвенировании (WGS) с глубиной покрытия 30x, что обеспечивает анализ 100% ДНК по сравнению с менее чем 0,1% у конкурентов вроде 23andMe. Компания утверждает, что секвенирует в 1000 раз больше ДНК, чем традиционные потребительские тесты, обеспечивая беспрецедентную точность генетического анализа. Если говорить про сам подход, то это полигенный скриннинг эмбрионов (PES), что основан на вычислении полигенных оценок риска (PRS) для каждого эмбриона. Оценки рассчитываются путем суммирования эффектов сотен, тысяч или даже миллионов вариантов ДНК, которые различаются между индивидуумами. Современные исследования показывают, что эффективность такой селекции ограничена, т.к. большинство выборов происходит между эмбрионами одних и тех же родителей, что существенно ограничивает как генетическую, так и средовую вариабельность.

А теперь проведем параллели с фильмом "Гаттака", в котором показано как может выглядеть социальная стратификация на основе генетики. В этом мире общество было разделено на "валидных" (генетически усовершенствованных) и "инвалидных" (естественно рожденных), при этом последние ограничены в доступе к образованию, работе и даже браку. Главынй герой фильма, Винсент Фримен, как раз человек второго сорта. Он близорук, имеет врождённый порок сердца, а генетический тест сулит ему примерно 30 лет жизни. Но у Винсента есть мечта — полететь в космос. И мы весь фильм наблюдаем как он идет к своей мечте, преодолевая ограничения окружающего мира за счет своей воли и работы над собой.

Если экстраполировать современные технологии (аля Nucleus Embryo), то видно, что они создают предпосылки для аналогичной стратификации. Хотя генетическая дискриминация формально запрещена, экономические барьеры доступа к генетической помощи могут привести к тому, что привилегированные слои общества смогут передавать свои преимущества детям через биологические механизмы. Как отмечают исследователи, это может привести к натурализации привилегий, оправданных научными предсказаниями. Интересно, что услуги полигенной селекции эмбрионов уже предлагаются потребителям как минимум четырьмя компаниями, а 5 лет назад родлился первый ребенок, прошедший через PES. Правда, существующие технологии имеют значительные ограничения. Исследования показывают, что полигенная селекция в целом не очень полезна при нацеливании на сложные характеристики здоровья — возникает проблема с оптимизацией по множеству критериев (генетические риски роста, IQ, цвета глаз и различных заболеваний), а значит принятие решения становится сложным. Думаю, что мы придем к созданию аля профилей вида: "спортсмен", "ученый", "поэт", "долгожитель", в которых будут зашиты комбинации критериев, а также будет отдельно возможность поиграться с фильтрами:))

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

#Science #PopularScience #Engineering

GitHub CEO predicts the future of programming (AI)

Посмотрел на выходных интервью Thomas Dohmk, CEO GitHub, которое у него брал Matthew Berman, известный AI-блогер. Само общение состоялось уже после MS Build, где GitHub анонсировал open source для своего чата внутри VSCode "GitHub Copilot Chat". Основные мысли интервью ниже

1. Влияние GPT и начало Copilot
Генеральный директор GitHub признаёт, что изначально сомневался в работоспособности GPT, но был впечатлён результатами: GPT изменил подход к разработке ПО навсегда. Copilot стал первым массовым инструментом, который завершает код за пользователя, и это оказалось крайне востребованным
2. Статистика и пользовательский опыт
Copilot пишет 25% кода в файлах, где он включён, а уровень удовлетворённости пользователей очень высок (NPS — 72). Интеграция с редакторами (VS Code) и code completion стали точкой входа AI в ежедневную работу разработчика
3. Образование и значимость программирования
Программирование остаётся важным навыком для понимания современного мира, его нужно преподавать детям и взрослым. Основы информатики и умение читать код — это универсальная грамотность будущего.
4. Роль и ответственность разработчика
Даже с появлением copilot агентов инженер должен проверять и подтверждать изменения, чтобы избежать ошибок и проблем с безопасностью. Важно понимать, что делает ИИ-агент, и не терять контроль над кодом
5. Эволюция индустрии и открытый исходный код
Открытый исходный код стал стандартом индустрии, а Copilot теперь доступен как open source для интеграции и доработки сообществом (речь идет про расширение для чата). GitHub и Microsoft делают ставку на использование нескольких моделей ИИ для разных задач, а не на одну универсальную (одну для code completion из-за требований к latency, другую для агентских workflow, где latency не так важно и можно использовать модель поумнее и помедленнее)
6. Будущее разработки: агенты и микро-приложения
Интересная идея о том, что в будущем персональные агенты могут создавать мини-приложения "на лету" для конкретных задач, а операционная система будет скрыта за ИИ-интерфейсом. Пример: автоматизация семейных задач (управление карманными деньгами детей) с помощью Copilot и персонализированных приложений
7. Vibe Coding и ограничения ИИ
Vibe Coding — подход, при котором ИИ помогает быстро воплощать идеи в прототипы, но для серьёзных задач нужны ревью, безопасность и стандарты. ИИ-агенты пока ограничены по объёму обрабатываемого кода, но в будущем смогут работать с большими проектами и тогда вайбкодить станет еще проще.
8. Интеграция и экосистема ИИ-агентов
Ожидается появление экосистемы персональных ИИ-агентов, интегрированных с работой и личной жизнью пользователя. Знания, связанные с работой, будут принадлежать компании, а личные — останутся у пользователя. Чем-то этот концепт напоминает сериал "Разделение", который я не смотрел, но про который слышал.
9. Влияние на рынок труда и новые профессии
ИИ автоматизирует рутинные задачи, но открывает новые профессии и возможности, даже для тех, кто не владеет английским языком. Как и в прошлые технологические революции, часть профессий исчезнет, но появятся новые роли и специализации.
10. Оптимизм в отношении ИИ
Томас выражает оптимизм: ИИ не заменит людей, а поможет решать больше задач, повысит продуктивность и создаст новые возможности для разработчиков

В общем, интервью неплохо показывает как быстро развивается сфера AI-assisted programming и какую роль в этом играет GitHub как лидер индустрии. Основной посыл: AI не заменяет программистов, а делает их более продуктивными, позволяя сосредоточиться на креативных и стратегических аспектах разработки.

#AI #Software #Engineering #Architecture #Agents #Math #Software #ML #Leadership

Measuring Productivity: All Models are Wrong But Some are Useful (Рубрика #Management)

Этот whitepaper от исследователей Google Сьеры Джаспан и Коллина Грина, представляет собой текстовую версию их выступления на DPE Summit (Developer Productivity Engineering). В заглавие статьи они вынесли знаменитую цитату Джорджа Бокса "В сущности, все модели неправильны, но некоторые полезны", которая отлично применима и к вопросам измерения продуктивности инженеров тут к месту. Они рассказывают про принципы и методики, что выработали в Google для преодоления ограничений моделей и получения ценных инсайтов. Эта статья продолжает серию "Developer Productivity for Humans" в журнале IEEE, все статьи из которой рассмотрены в отдельном посте, а дальше поговорим про этот whitepaper.

1. Измерение продуктивности разработчиков — это построение моделей, где необходимо принять, что ни один подход к измерению не способен идеально охватить всю сложность разработки софта. Авторы утверждают, что модели продуктивности часто «опасно избирательны», поскольку опускают важные аспекты работы разработчиков, что приводит к неполным или искажающим оценкам. Важно понимать, что эффективное измерение продуктивности требует комплексного подхода, который охватывает несколько аспектов работы, а не опирается на примитивные метрики вроде количества строк кода или частоты коммитов.
2. Часто такой комплексный подход связан с компромиссами между разными сторонами разработки софта, например, легко ускорить velocity, если выкинуть этап код ревью и тестирования. Для нас это означает, что продуктивность следует рассматривать как баланс между несколькими факторами, в первую очередь скоростью, удобством и качеством, а не как единичный измеряемый результат. Интересно, что в Google этот компромисс представляется в виде треугольника: speed, ease, quality.
3. Исследователи в Google также смотрят и на социологические аспекты, учитывая их совместно с технологическими. Именно этот подход дал название всей серии статей, где измерение продуктивности должно учитывать сложную, творческую природу работы разработчика, а не рассматривать её как чисто механический процесс.
4. В этом исследовании лежит структурированная модель построения систем измерения продуктивности, которая избегает распространённых ошибок. Кажется, авторы используют подход Goals/Signals/Metrics (GSM), про который я уже писал, когда разбирал книгу "Software Engineering at Google", но они прямо об этом не говорят:)
5. Авторы учитывают два противоположных фактора: стремление к простоте (parsymony) и избегание опасной избирательности (worrying selectivity). Парсимония подталкивает к включению меньшего числа компонентов ради простоты, а worrying selectivity требует включения большего числа аспектов для охвата всех важных сторон продуктивности. Исследование советует склоняться к более полному охвату, а не к чрезмерной простоте.
6. Авторы комбинируют в своей методологии качественные и количественные методы, используя данные из инструментальных логов и опросов. Такой смешанный подход отражает их понимание того, что продуктивность разработчиков нельзя полностью охватить только количественными метриками или исключительно субъективными оценками. Вместо этого они предлагают комбинировать разные типы данных для более полного понимания картины. Интересно, что структура их модели учитывает влияние самих измерений на поведение: то, что измеряется, зачастую начинает влиять на поведение сотрудников, иногда вопреки изначальным целям.

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

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

The 4 Patterns of AI Native Development — Patrick Debois (Рубрика #AI)

Вчера посмотрел короткое, но интересное выступление от Патрика Дюбуа, эксперта по DevOps, соавтора "DevOps Handbook", эксперта по интеграции AI в разработку. Это выступление состоялось 4 июня 2025 года на AI Engineer World's Fair 2025 в Сан-Франциско — крупнейшем отраслевом событии, посвященном практическому применению AI в инженерии. Конференция собрала около 1000 основателей, вице-президентов и ведущих инженеров со всего мира (я с большим интересом следил за этой конференцией в прямом эфире, что был доступен на Youtuve).

Ключевые идеи Патрика о том, что мы сейчас в состоянии перехода от обычной разработки к AI Native. По его мнению это похоже на то, как мы все двигались в сторону cloud native, но теперь у нас новая волна изменений. А это приводит к тому, что инженеры меняются в 4 направлениях

1. От производителя к менеджеру.
Разработчики все меньше пишут код сами, вместо этого управляют AI-агентами, которые генерируют код. Время написания кода сокращается, но время на ревью увеличивается — когнитивная нагрузка растет.
2. От реализации к намерениям
Фокус смещается с "как делать" на "что делать". Мы описываем цель и требования, позволяя AI самостоятельно найти решение. Появляются specification-центричные инструменты.
3. От delivery к discovery
Стоимость экспериментов резко снизилась. Теперь можно быстро создавать прототипы, тестировать множественные варианты и исследовать новые идеи, прежде чем принимать решения.
4. От контента к знаниям
AI дает мотивацию систематизировать и сохранять знания команды. Накопленная экспертиза становится конкурентным преимуществом компании, поскольку создание продуктов становится все более автоматизированным.

Если подводить итог, то AI не заменяет разработчиков, а изменяет области, где мы создаем ценность. Понимание этих паттернов поможет инженерам эффективно позиционировать себя и свои команды в меняющемся ландшафте разработки.

#AI #Software #Engineering #Architecture #Agents #Leadership