AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms (Рубрика #AI)

В середине мая Google выпустила интересную статью про своего агента AlphaEvolve, который способен разрабатывать продвинутые алгоритмы для решения задач оптимизации. По-факту, это эволюционирующий coding agent на базе пары LLM от Google. Более подробный рассказ о внутренностях этого агента доступен в отдельной научной статье (на 44 страницы). Этот алгоритм AlphaEvolve – результат коллективной работы команды Google DeepMind под руководством восьми ведущих исследователей, внесших равный вклад: Alexander Novikov, Ngân Vũ, Marvin Eisenberger, Emilien Dupont, Po-Sen Huang, Adam Zsolt Wagner, Sergey Shirobokov и Borislav Kozlovskii. Среди других авторов: Francisco J. R. Ruiz, Abbas Mehrabian, M. Pawan Kumar, Abigail See, Swarat Chaudhuri, George Holland, Alex Davies, Sebastian Nowozin, Pushmeet Kohli и Matej Balog. Данный коллектив объединил специалистов в области машинного обучения, алгоритмической оптимизации и математического моделирования.

Если говорить про схему работы агента, то ключевые моменты следующие
1. В системе используется два типа моделей
- Gemini Flash – более быстрая и эффективная модель с низкой задержкой, максимизирующая объем генерируемых идей за единицу времени
- Gemini Pro – более мощная модель, обеспечивающая периодические высококачественные предложения для прорывных решений
2. Система использует эволюционный подход к модификации кода
AlphaEvolve использует эволюционную структуру, где агенты предлагают программы, реализующие алгоритмические решения в виде кода. Эти решения автоматически оцениваются при помощи чего-то типа fitness functions
3.Автоматизированная оценка
Система включает автоматизированные оценщики, которые проверяют, запускают и оценивают предложенные программы по объективным метрикам. Это обеспечивает количественную оценку точности и качества каждого решения, делая систему особенно эффективной в областях, где прогресс может быть четко и систематически измерен. Вот цитата из научной статьи, на которую я давал ссылку выше

The LLM-directed evolution process is grounded using code execution and automatic evaluation

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

Эти достижения базируются на предудыщих исследованиях
- AI Co-scientist (2025) - мультиагентная система на базе Gemini 2.0, предназначенная для помощи ученым в генерации новых гипотез и исследовательских предложений.
- AlphaTensor (2022) - система от DeepMind, специализирующаяся на автоматическом обнаружении новых алгоритмов умножения матриц с использованием глубокого обучения с подкреплением.
- AlphaZero (2018) - Технология глубокого обучения с подкреплением, лежащая в основе этих систем, берет свое начало от AlphaZero – самообучающейся системы DeepMind, которая освоила настольные игры, такие как го, шахматы и сёги.

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

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

Moving Faster and Reducing Risk: Using LLMs in Release Deployment (Рубрика #AI)

Интересный lighting talk с DPE Summit 2024 от Руи Абреу из Meta на тему повышения надежности релизов при помощи LLMs (Meta признана экстремисткой организацией и ее деятельность запрещена на территории России).

Основные моменты из этого выступления представлены ниже

1. Проблема масштаба в релизной инженерии - на масштабах Meta невозможно централизованно решать, что выпускать в продакшн. Ответственность передается разработчикам, пишущим и ревьюящим код.
2. Треугольник продуктивности - для ребят продуктивность является балансом между тремя измерениями: скорость (velocity), надежность (reliability) и читаемость кода (readability). Оптимизация одного параметра влияет на остальные.
3. Система оценки рисков диффов - ребята разработали модели для предсказания вероятности того, что diff вызовет серьезный сбой, влияющий на пользователей
4. Эволюция практик code freeze - ребята перешли от полной блокировки изменений к интеллектуальному гейтингу на основе оценки рисков.
5. Многоуровневое гейтирование - ввели четыре типа ограничений: зеленый (без ограничений), выходные дни (5%), средний риск (10%) и высокий риск (50% самых рискованных диффов).
6. Сравнение подходов к ML - проверяли модели на базе логистической регрессии, BERT-based моделей (StarBERT) и генеративных LLM для предсказания рисков.
7. Превосходство risk-aligned LLM - по результатам тестов победили risk-aligned модели iDiffLlama-13B
8. Упрощение feature engineering - для LLM моделей потребовались только три входных параметра: название изменений , план тестирования и сами изменения кода (интересно, что summary изменений в модель не подаются, так как они позволяют манипуляции).
9. Практические применения - по итогу внедрения этих рисковых моделей ребята смогли прийти к рекомендациям ревьюеров для рискованных диффов, автоматическому одобрению низкорискованных изменений, ну и общему улучшению процесса релизов.
10. Баланс скорости и качества - появилась возможность "разморозить" некоторые диффы во время code freeze, не блокируя все изменения на 100%, что повышает продуктивность инженеров.

В итоге, это интересный подход для повышения качества через гибкое управление рисками релизов. Интересно, насколько это реально работает в Meta и раскатано ли на все продукты/проекты.

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

Круглый стол «Техлид и развитие в Individual Contributor: как превратить код в карьеру» (Рубрика #Engineering)

Сегодня буду в рамках круглого стола на Techlead Conf X обсуждать этот вопрос с джентельменами из разных компаний, где у нас соберется квартет представленный ниже
- Максим Вишневский, ведущий (Mindbox)
- Глеб Михеев (Сбер)
- Александр Белотуркин (Делимобиль)
- Александр Поломодов (Т-Банк)

И вместе мы точно поговорим про то
- Как роль техлида влияет на бизнес: от компаний с развитой IC-веткой до тех, где влияние минимально?
- Какие навыки и подходы нужны техлиду в бизнесе, архитектуре и технической экспертизе, а также как расти по IC-ветке?
- Почему в российском IT IC-ветка слабо развита и какие перспективы для роста?
- Как формируется роль техлида в разных компаниях, почему она часто остается неофициальной и как развивать навыки без продуктового контекста?

Думаю, что мне будет, что добавить к этой дискуссии, так как раньше я уже много рассказывал на эту тему
- Code of Leadership #6 Staff+ инженеры, архитектура и SDLC
- Варианты роста инженера, если он уже Senior на Tinkoff Meetup 2023
- Как нанимать технических руководителей на Teamlead Conf 2023
- Архитектура в масштабе на ArchDays 2020
- System Design Interview на ArchDays 2021
- Как подготовиться и пройти System Design Interview на ArchDays 2022
- Книга Will Larson "Staff Engineer" и мои обзоры этой книги в двух частях: 1 и 2
- Книга Tanya Reilly "The Staff Engineer's Path" (перевод этой книги есть в издательстве Питер под названием "Карьера разработчика. Стафф - круче, чем senior")

#Staff #SoftwareDevelopment #Software #SelfDevelopment #Career

[2/2] What's the Use?: The Unreasonable Effectiveness of Mathematics (Это база. Зачем нужна математика в повседневной жизни) (Рубрика #Math)

Продолжая рассказ, об этой научно-популярной книге, расскажу содержание оставшихся глав

4. Почки Кенигсберга - все начинается с задачи о мостах Кёнигсберга, появления теории графов, а дальше их применения для трансплантации органов в UK.
5. Будьте осторожны в киберпространстве - здесь по классике идет речь про шифрование, дальше про ассиметричное шифрование, использование для этого разложения на простые числа, а потом переход к эллиптическим кривым
6. Числовая плоскость - здесь автор рассказывает про натуральные числа, рациональные, иррациональные и комплексные. Он рассказывает как появились комплексные числа и что их представление - это уже не числовая прямая, а числовая плоскость, где интерпретация связана с синусами и косинусами. Интересно, что для многих физических задач использование комплексных чисел позволяет проще описывать и решать задать задачи
7. Папа, ты научился перемножать триплеты - рассказ про квартернионы Гамильтона, которые позволяют проще описывать и решать задачи преобразования положения объектов в трехмерном пространстве. Это очень пригождается в трехмерной графике.
8. Вот это отскок - интересная глава, где автор переходит от расчета параметров пружин к аттракторам Лоренца и теории хаоса
9. Верь мне, я ряд Фурье - здесь автор рассказывает про разложение в ряд Фурье, дальше про преобразование Родона и как все это используется в условных КТ аппаратах для восстановления трехмерного изображения по большому количеству двумерных проекций с разных направлений
10. Улыбнитесь, пожалуйста! - коротенькая глава про сохранение изображений, где есть рассказ про jpeg, а также про использование вейвлетов для хранения изображений отпечатков пальцев в архиве ФБР
11. Мы уже почти приехали? - автор рассказывает про то, как работает GPS и какие области физики и математики нужны для работы геопозиционирования
12. Оттаивание Арктики - рассказ как модель для магнитов была переиспользована для анализа таяния прудов на поверхности льдин. Очень интересный и нетривиальный пример
13. Позовите тополога - базовый рассказ, что начинается с ленты Мебиуса, бутылки Клейна и быстро переходит к инвариантам и рассказом про гомологиям, когомологиям, а также к прикладной топологии, где автор рассказывает про постоянные гомологии, что можно использовать для анализа покрытия некоторой территории датчиками. В общем, эту главу не так уж и просто читать.
14. Лиса и еж - эта глава завершает книгу и в ней автор размышляет о природе математического мышления и его роли в человеческой цивилизации, используя метафору лисы и ежа, а также фантастический образ математикоядных инопланетян. Стюарт опирается на знаменитое высказывание: «Лиса знает много разных вещей, а ёж — одну, но большую». Для иллюстрации он вводит образ «математикоядных инопланетян». Представьте себе цивилизацию, которая охотится на математику, чтобы выжить, и потому вынуждена искать новые математические идеи везде, где только можно. Тут она прилетает в гости к нам и начинает есть нашу математику, начиная с изысков высшей математики. Дальше у нас начинают исчезать общепринятые вещи - телефоны, компьютеры, интернет, геопозиционирование, ... Эти инопланетяне останавливаются, но у нас остается только арифметика, которой они побрезговали, а также каменный век вокруг нас.

Через эту историю Иэн показывает принципиальное значение математики для окружающего нас мира, хотя большая часть людей не знает об этом. Иэн предлагает популяризировать это и увеличивать количество людей занимающихся математикой, где она воспринимается как насыщенная творческая дисциплина, а не примитивная карикатура, какой ее нередко представляют. И завершается книга фразой
Да, лиса знает много секретов, а математики - всего один, но очень большой. Он называется математикой, и он преобразует наш мир.
#PopularScience #Math #Physics

[1/3] Интегрируем AI в процессы разработки большой компании: почему разрешить всем Cursor — не вариант (Рубрика #Management)

Сегодня в 17.00 я выступаю с таким докладом на CTO Conf X, профессиональной конференции для технических директоров, от компании "Онтико". Я расскажу о хайповой теме об интеграции искусственного интеллекта в жизненный цикл разработки софта в больших компаниях. Ниже я расскажу про структуру доклада и приведу ссылки на дополнительные материалы, которые я использую для референсов в моем выступлении.
В своем докладе я начинаю выступление с того, что вспоминаю об copilot инструментах разработчиков: GitHub Copilot, Cursor, Windsurf, которые задали некоторый стандарт AI ассистентов для разработчиков и позволили делать многое автоматически. В феврале 2025 года Andrej Karpathy дал начало новому тренду разработки под названием vibe coding

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

Этот тренд подхватили ребята из акселлератора стартапов Y Combinator и уже в марте начали обсуждать эту тему в подкастах:
- "Vibe Coding Is The Future" (я его уже разбирал)
- "Интервью с CEO Windsurf про будущее программирования" (я его уже разбирал)
- и даже "Vibe coding tips в их Startup Schools".

Отдельно можно добавить, что хайпа добавляют заявления Сэма Альтмана, CEO OpenAI, или Дарио Амодея, CEO Antrophic. Например, Дарио три месяца назад на выступлении "The Future of U.S. AI Leadership with CEO of Anthropic Dario Amodei", про которое я уже рассказывал, выдал предсказание про будущее разработки

I think we will be there in three to six months, where AI is writing 90% of the code. And then, in 12 months, we may be in a world where AI is writing essentially all of the code

Возникает вопрос, а как этого можно добиться? Ответ в использовании агентов:
- В прошлом году ребята из Antrophic представили MCP (model context protocol) для предоставления LLM доступа к дополнительным инструментам
- А уже в этом году Google представили протокол уже для взаимодействия агентов A2A (Agent2Agent) протокол
В общем, тема сейчас хайповая и для создания MVP в стартапах или pet проектов разработчиками этот подход к использованию copilots в режиме vibe coding отлично подходит. А вот для крупных компаний не все так просто и дальше я объясню почему

Инженерные процессы в крупных компаниях эволюционировали следующим образом:
- Когда-то разработка и эксплуатация была разделена и этот разрыв мешал достигать бизнес-результатов. В итоге, с середины 2000х по конец 2010х евангелировался DevOps подход, который с научной точки зрения был обоснован в книге "Accelerate", про которую я рассказывал раньше в трех частях: 1, 2 и 3.
- Этот подход зачастую приводил к гетерогенному ИТ-ландшафту с большим дублированием систем, что не позволяло получить эффект масштаа - крупные компании пошли в сторону разделения stream-aligned команд и platform команд, которые должны были создать платформы, навроде Internal developer platform, которая позволяла бы инженером в формате self service пользоваться инструментами навроде работы с кодом, артефактами, CI/CD пайплайнами, рантаймом, observability и так далее
- Дальше платформы стали достаточно сложными и владельцы платформ решили идти в сторону user experience своих пользователей, которыми являются разработчики. Так появилась концепция developer experience, в которую входит flow state, cognitive load, feedback loops (про это можно почитать в whitepaper "DevEx: What Actually Drives Productivity", про которую я рассказывал раньше). Это важно, так как сложность платформ может зашкаливать - этом можно продемонстрировать, взглянув на картинку с CNCF landscape, где количество карточек продуктов зашкаливает и разобраться с тем, что и как обычному человеку крайне сложно.

Продолжение в следующем посте.

#AI #PlatformEngineering #Engineering #Software #Processes #Productivity

[2/3] Интегрируем AI в процессы разработки большой компании: почему разрешить всем Cursor — не вариант (Рубрика #Management)

Мы остановились в прошлом посте на платформах и их сложности. А что делать для борьбы с такой сложностью?

- Для работы над сложностью отдельных инструментов ребята в Google пошли в продуктовую сторону и решили понять, а какие цели у инженеров в разработке софта. Свой подход они описали в whitepaper "Measuring developer goals", про которую я рассказывал раньше. Смысл в том, чтобы выделить фазы жизненного цикла разработки софта, а внутри них определить аля jobs to be done сценарии, которые нужны инженерам. Дальше эти сценарии можно оцифровать с помощью телеметрии от платформенных инструментов и при помощи опросов инженеров. Сами сценарии расскладываются на использование нескольких инструментов и дальше можно оптимизировать и AI-фицировать не отдельные инструменты, а весь сценарий (в перспективе его можно попробовать отдать AI агентам)
- Одновременно, интересно взглянуть на ожидания самих инженеров от AI внутри платформ. Ребята из Google летом 2024 года выпустили whitepaper "What Do Developers Want From AI?" (мой обзор), где рассказали про три уровня улучшения AI для инженеров (интересно, что они провели параллели с автомобильной промышленностью и водителями)
1. Enhancing human capabilities - гидроусилитель руля и анти-блокировочная система в машинах, автодополнение кода в IDE
2. Extending human capabilities - камера заднего вида и контроль слепых зон в машинах, чат и code review suggests в разработке
3. Delegating human capabilities - улучшенный круиз-контроль и держание полосы в машинах (включая автопилот от Tesla), агентские workflow в AI, включая автоматическое удаление dead code, а также генерацию тестов
В общем, этот подход неплохо показывает как AI постепенно может проникать в процессы разработки. А дальше интересно глянуть на подходы западных bigtech компаний к реализации второго и третьего уровня
- Google и дизайн API. У ребят из Google были 2 научные статьи в середине 2024 года "API Governance at Scale" (мой разбор) и "AI-Enhanced API Design: A New Paradigm in Usability and Efficiency" (мой разбор). В них они рассказывали про свой подход к дизайну API, который у них отлично стандартизован (подробнее в aip.dev), а дальше они попробовали поверх этих стандартов прикрутить api architect (это LLM модель для генерации спеки по продуктовым требованиям).
- ByteDance и code review. У ребят из ByteDance есть научная статья 2025 года "BitsAI-CR: Automated Code Review via LLM in Practice" (мой разбор: 1, 2 и 3). В ней они рассказывают про свой pipeline для работы с code review, где есть 200+ категорий, моделька для генерации комментов для ревью, моделька для фильтрации сгенерированного, а также feedback loop от инженеров для тюнинга эффективности все системы
- Uber и крупномасштабная миграция с Java на Kotlin. Они рассказывали это докладе "This Year in Uber’s AI-Driven Developer Productivity Revolution" на конференции DPE 2024 (мой разбор: 1 и 2). Если кратко, то у ребят было много Java кода, что они хотели переписать на Kotlin. В децентрализованном варианте команды делали бы это вялотекуще 10+ лет, ребята прикрутили сначала LLM и сократили оценку в 3 раза, а потом скомбинировали LLM и AST и смогли по оценке уложиться в 18 месяцев на всю миграцию кодовой базы.
- Booking и внешнее партнерство с Sourcegraph. Booking решил приобщаться к AI через внешнего партнера (подробнее здесь). Sourcegraph сделали для Uber генерации QraphQL request из API Booking по текстовому описанию запроса, сделали code review, а также вывели из анабиоза проект по миграции кодовой базы, что шел уже 14 лет.
- Datadog и AI oncall engineer. Datadog - это observability платформа, которая решила сделать oncall engineer. Про это они рассказывали в начале этого года, а я писал об этом раньше

В финальном посте мы обсудим как дела обстоят в Т, а также завершим рассказ выводами.

#AI #PlatformEngineering #Engineering #Software #Processes #Productivity

[3/3] Интегрируем AI в процессы разработки большой компании: почему разрешить всем Cursor — не вариант (Рубрика #Management)

Из примеров больших компаний в предыдущем посте видно, что они идут от сценариев расширения возможности людей, а часть из них успешно агентизируют. И если посмотреть на наш подход в Т-Банке, то мы идет примерно этим же путем. На самом деле какой этот путь можно подробно узнать из выступлений моих коллег на Platform Engineering Night
- AI и Platform Engineering" от Игоря Маслова
- Разработка собственного AI-ассистента для кода: спринт или марафон? от Дениса Артюшина
Если кратко, то мы прошли гигиенический первый уровень, сейчас закрыли многие сценарии из второго уровня и вплотную добрались до делегировании работы инженеров агентам. Интересно, что у нас есть централизованная команда, что делает нашего copilot Nestor, но одновременно это зонтичный бренд для остальных инициатив, которые драйвятся у нас рабочими группами по планированию, анализу, проектированию, разработке, тестированию, SRE. Например, вот выступление про внедрение SRE AI-ассистента. В общем, мы со своей observability платформой Sage идем примерно в ту же сторону по AI-фикации, что и Datadog, упомянутый ранее.

Интенесно, что это общая тенденция про развитие платформ в мире genAI отлично видна из отчета RedHat от ноября 2024 года "State of platform engineering in the age of AI" (мой обзор), где основные выводы такие
- Платформенная инженерия становится стратегической
62% компаний уже имеют выделенные команды платформенной инженерии. Платформенная инженерия — это не просто автоматизация инфраструктуры, а стратегический инструмент для ускорения инноваций и внедрения ИИ.
- Влияние искусственного интеллекта
76% организаций уже используют генеративный ИИ для задач разработки (документация, генерация кода, подсказки). 45% считают ИИ центральным элементом своей платформенной стратегии.

В итоге, если отвечать на вынесенный в название вопрос "почему разрешить всем Cursor — не вариант?", то можно сказать так

Для маленьких компаний это очень и очень вариант, так как
- Эти инструменты позволяют быстро выдавать код для лендингов, прототипов, MVP
- Они стоят не очень дорого, а также обычно нет особых рисков с intellectual property, данными, санкциями
- Все равно нужны инженерные навыки - чтобы не получилось как в истории с тем, как агент снес весь код, а восстановить из git нельзя, так как vibe coder не знал что такое git и что им стоит пользоваться

Для больших компаний нужен подход посложнее, как я описывал выше, из-за
- Из коробки Copilot, Cursor, Windsurf не умеют работать с платформенными инструментами. Этому можно их научить если реализовать для платформенных продуктов MCP сервера, но ...
- Для больших компаний риски вокруг информационной безопасности, интеллектуальной собственности, персональных данных часто слишком велики для использования внешних SaaS решений
- В процессе работы над LLM внутри SDLC такие компании хотят потренироваться на кошечках и научиться AI-фицировать продукты, которые безопасны и понятны. А дальше с этой экспертизой идти в сторону customer продуктов компании.
- Ну и большие риски возникают из-за санкций, так как внешние SaaS решения могут быть официально недоступны, а получив доступ по другому его легко можно потерять и остаться у разбитого корыта.
В итоге, большие компании часто создают свои LLM решения и учатся интегрировать их внутрь своего SDLC и продуктов. Часто это может быть оправдано экономически на их масштабе. Интересно, что этому способствует публикация весов для моделей навроде LLama, DeepSeek, Mistral, что позволяет не слишком сильно отставать от mainstream.

А вот средним компаниям приходится сложно - внешние решения могут быть слишком рискованными, а на создание своих может не хватать денег. Но благо сейчас некоторые российские компании пытаются делать свои продукты вокруг SDLC, в которых AI становится жителем первого класса:)

#AI #PlatformEngineering #Engineering #Software #Processes #Productivity

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