Research Insights Made Simple #10 - Measuring Developer Experience With a Longitudinal Survey (Рубрика #DevEx)

Очередной выпуск подкаста с разбором whitepapers посвящен разбору темы проведения опросов инженеров "Measuring Developer Experience With a Longitudinal Survey". Для разбора этой статьи ко мне пришел гость, Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Артем отвечает за развитие платформы для разработчиков, а раньше в Сбере занимался развитие платформы Сбербанк онлайн и рекомендательной платформы. Артем ведет интересный телеграм канал - https://t.me/badTechProject

За 40 минут мы успели обсудить следующие темы

- Опыт Google в проведении опросов
- Преимущества и процесс проведения опросов
- Методология и анализ опросов
- Важность коммуникации и внедрения изменений по итогам опросов
- Роль менеджера и сменяемость ролей в команде
- Масштабирование и частота опросов
- Продуктовый подход и интеграция онлайн-опросов
- Двухсторонний анализ: опросы и логи

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

P.S.
Я разбирал этот whitepaper раньше в своем tg канале в двух частях: 1 и 2

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

AI-помощники при работе с кодом. Взгляд в будущее - Евгений Колесников - Platform Engineering Night (Рубрика #AI)

Крутое выступление Евгения из команды Yandex Infrastructure, в котором он делится глубокими мыслями про развитие AI copilot инструментами. Женя выступал с этим докладом на Platform Engineering Night в Т-Банке. Я уже рассказывал про выступления моих коллег оттуда: "AI и Platform Engineering" от Игоря Маслова и "Разработка собственного AI-ассистента для кода: спринт или марафон?" Дениса Артюшина. Ребята рассказывали про наши подходы к интеграции AI в SDLC) и интересно сравнить мысли из тех докладов с идеями Жени, что я постарался изложить ниже

1. Реальность разработки
По стате разработчики пишут код всего 40 минут - 120 минут в день, при этом комитят в среднем только 40 строк кода в день. Основная проблема не в скорости печати, а в сложности мыслительных процессов, что идут на трех уровнях
- Ментальная модель - что мы хотим сделать
- Семантическая модель - как мы это будем делать
- Синтаксическая модель - непосредственно сам код
ИИ сейчас помогает в основном на последнем этапе, что объясняет ограниченность эффекта.
2. Режимы работы разработчиков
Существуют два основных режима:
- Flow - сотояние потока, когда код "летит из-под пальцев". Интересно, что в DevEx фреймворке Flow - это одна из составлящих, кстати, я делал обзор whitepaper о нем
- Exploration - поиск информации в документации, интернете, общение с ИИ
Понимание этих режимов критично для эффективного использования ИИ-инструментов.
3. Чего хотят разработчики от ИИ
По мнению Евгения ожидания инженеров такие
- Переложить на AI рутинные операции, например, написание юнит-тестов
- Общаться на естественном языке с последующим уточнением через промпты
- Получить детерминированные результаты от недетерминированного genAI
Интересно, что у Google был whitepaper буквально с таким названием "What Do Developers Want From AI?" - я его разбирал раньше, а потом еще записал эпизод подкаста "Research Insights" вместе с моим коллегой, Колей Бушковым, где мы разбирали этот whitepaper
4. Бизнес-приоритеты
Бизнес хочет сокращения time to market, снижения издержек, а также предсказуемости. Но обычно все упирают на сокращение издержек, когда говорят, что "90% кода будет писаться ИИ". Но часто это не означает увольнение 90% программистов, а увеличение продуктивности существующих команд. Евгений привел пример Дарио Амодея с его тезисами из цитаты выше - а я разбирал это выступление раньше
5. Проблема измерения эффективности
Критически относитесь к цифрам вроде "повышение продуктивности на 55%". Продуктивность - неопределенный термин, зависящий от множества факторов. Пока нет единого способа точно измерить пользу от ИИ-инструментов. Интересно, что я уже пару раз выступал с темой навроде "Зачем заниматься темой developer productivity в большой компании"
6. LLM ≠ Продукт
Использование последней языковой модели не гарантирует успех продукта. UX/UI, правильный промптинг и интеграция в рабочий процесс часто важнее, чем выбор конкретной модели.
7. Правильные метрики
Стоит измерять NPS, CSAT в связке с retention (у SourceCraft от Yandex между 60-70%), cycle time, lead time и влияние на бизнес-метрики. Метрика счастья пользователя - интегральный показатель принятия/отклонения подсказок.
8. Снижение хайпа - это хорошо
За 2023-2024 год интерес к ИИ в некоторых областях упал и это хорошо - разработчики начинают реалистично оценивать возможности и ограничения ИИ-инструментов, что ведет к более эффективному использованию.
9. Будущее: от генерации к агентам
Развитие сейчас идет от генеративных моделей к агентским. Агенты проактивно решают задачи, но пока крайне ненадежны. Следующий этап развития - сделать агентов более надежными и предсказуемыми. Чем глубже интеграция ИИ в инфраструктуру компании, тем больше выигрыш.

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

#AI #Software #Engineering #Architecture #Agents

[1/3] Acing the System Design Interview (System Design: пережить интервью) (Рубрика #Architecture)

Последний месяц я потихоньку читаю книгу Zhiyong Tan, что посвящена system design interview и в виде перевода выпущена издательством Питер. Книгу я решил прочесть из интереса, чтобы сравнить с тем подходом, который близок мне и про который я рассказывал и долгое время развивал у нас внутри компании.
TLDR; книга мне показалась полезной и понравилась, причем больше, чем книга Alex Xu, про которую я тоже рассказывал.

Начнем с того, что автор, Zhiyong Tan, сейчас engineering manager в Paypal, а до этого был senior fullstack инженером в Uber, data инженером в небольших стартапах, а также инженером в Teradata. В общем, этот опыт позволил ему посмотреть на вопросы проектирования решений и найма сотрудников в компаниях разного масштаба и уровня зрелости. Сама книга поделена на три части:
1) Первая часть состоит из 6 глав и содержит стрктурированное введение в system design interview - про эту часть мы поговорим ниже подробнее
2) Вторая часть содержит 11 примеров system design задачек
3) В приложениях есть сравнения монолитов и микросервисов, базовыый разбор OAuth 2.0 и OpenID Connect, рассказ про C4 Model, а также разбор того, как устроен двух-фазный коммит. В принципе, все эти темы так или иначе могут быть затронуты на собеседовании

Дальше я расскажу про первые шесть глав, которые показались довольно здравыми

1. A walkthrough of system design concepts
В первой главе автор вводит базовые понятия system design, знакомит с ключевой терминологией и объясняет, что system design - это про дискуссию вокруг компромиссов, на которые надо пойти при проектировании решения:) Дальше автор быстро и по верхам рассазывает про масштабирование различных сервисов, начиная с маленькой инсталляции приложения и накручивая сверху GeoDNS, кеширование, CDN, горизонтальное и вертикальное масштабирование, управление кластерами, разделение на функционально-независимые части. Интересно, что автор разбирает историю про работу с аналитическими данными (ETL), выделение общих сервисов, а также размещение рабочих нагрузок на bare metall, cloud или вообще внутри FaaS:) В общем, большая часть этих блоков может быть раскрыта в отдельную главу, если не книгу, но автор дает неплохое общее представление о самих концепциях

2. A typical system design interview flow
Здесь автор описывает типичный процесс system design interview, акцентируя внимание на важности уточнения требований до начала проектирования. Особое внимание уделяется разделению functional и non-functional requirements. Интересно, что я как-то с ребятами из клуба {между скобок} разбирал flow собеседования, предложенный в книге Alex Xu, а также сравнивал с тем, что принято в Т. Если говорить подробнее про содержание главы, то тут идет речь про
- Уточнение требований
- Создание драфта спек API
- Связь пользователей и данных
- Моделирование моделей данных
- Обсуждение логгирования, мониторинга и алертинга (я часто это оставляю на финал собеседования)

Продолжение обзора первой части книги в следующем посте.

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

[2/3] Acing the System Design Interview (System Design: пережить интервью) (Рубрика #Architecture)

Продолжая рассказ про книгу о system design, расскажу про оставшиеся четыре главы первой части.

3. Non-functional requirements
Эта глава целиком посвящена нефункциональным требованиям, которые часто называются архитектурными характеристиками ("-ilities") или атрибутами качества. Автор отдельно разбирает такие штуки как scalability, availability, fault-tolerance, performance/latency и throughput, consistency, accuracy, maintainability, cost, security, privacy, cloud native. Интересно, что я много раз рассказывал про НФТ или "-ilities", например с теми же ребятами из {между скобок} мы как-то разбирали работу с архитектурными характеристиками. Ну и недавно у меня был обзор whitepaper "Quality Metrics in Software Architecture" в трех частях: 1, 2 и 3.

4. Scaling databases
Эта глава целиком посвящена том, а как жить с состоянием, которое надо где-то хранить. В system deisgn задачах обычно эта stateful часть одна из самых интересных и она требует умения ее масштабировать и отвечачть на вопрос, а как обрабатывать сотни миллионов пользователей и миллиарды запросов. Здесь автор рассказывает про репликацию и шардирование, аггрегацию событий, батчинг и стриминг. Дальше наступает время денормализации и кеширования, где обсуждаются разные техники кеширования, инвалидации кешей, а также их прогрева. Рекомендую почитать книгу "Database Internals", про которую я рассказывал в двух частях: storage engines и distributed systems.

5. Distributed transactions
Целая глава посвящена распределенным транзакциям, хотя двух-фазный коммит вынесен в приложение и автор рассказывает о спрособах избежать распределенных транзакций. Для этого он говорит про крупные темы вида
- Event driven architecture и event sourcing - интересно, что эту тему отличо разбирает Влад Хононов в книге ""Learning Domain-Driven Design", я даже делал обзор этой темы в виде статьи в своем блоге.
- CDC - описание как отливать изменения из баз данных, используя условный Debezium
- Использование супервизоров транзакций, а также использование саг (оркестрируемых и хореографируемых)
В общем, интересная глава, но короткая - для реального понимания затронутых тем придется почитать книги поглубже

6. Common services for functional partitioning queue
В этой главе автор рассказывает про общую функциональность, что нужна сервисам:
- Аутентификация, авторизация, шифрование
- Проверка ошибок: валидация, дедубликация
- Производительность и надежность: опять кеширование, rate limiting
- Логгирование и аналитика
Дальше идут паттерны для декомпозиции вида service mesh (istio) и sidecars, service discovery, использование библиотек для общей функциональности или вынос сервисов. Ну и финализируется все обсуждением API, которое автор начинает с рассказа про модель OSI, а дальше идут стандартные REST, RPC, GraphQL, WebSocket и их сравнения.

В общем, в первой части излагаются важные концепции, которые полезны не только на собеседованиях, но и в практической работе:) Структурированный подход к работе с требованиями, анализу trade-offs и принятию архитектурных решений помогает в реальных проектах. Особое внимание автор книги уделяет коммуникации и зрелости инженеров — умению объяснять решения, обсуждать компромиссы, адаптироваться к изменяющимся требованиям. Эти качества важны для взаимодействия с другими командами и бизнес-стейкхолдерами.

#Software #Architecture #DistributedSystems #SystemDesign #Engineering

How To Design Better AI Apps (Рубрика #AI)

Интересное интервью с Pete Koomen, генерального партнера Y Combinator и основателя Optimizely, где обсуждаются идеи из его эссе "AI Horseless Carriages", в котором он создал демо с использование AI для работы с почтой с нуля. Собственно, в этом интервью речь идет о следующих темах

1. Проблема "AI-колясок без лошадей"
Многие разработчики используют старые подходы разработки софта для создания AI-функций, не раскрывая полный потенциал технологии. Как отмечает Koomen: "Мы используем старую ментальность разработки ПО, старые техники для создания этих функций, и мы на самом деле не используем полностью то, что может AI".
2. Скрытые системные промпты ограничивают возможности
Gmail AI создает формальные, безликие письма из-за скрытого системного промпта, который пользователи не могут увидеть или изменить. Это приводит к тому, что AI-помощник пишет как "универсальный писатель электронных писем для всех", а не как конкретный пользователь.
3. Пользователи должны иметь доступ к системным промптам
Возможность редактировать системные промпты позволяет персонализировать AI под конкретного пользователя. Koomen демонстрирует в своем демо, как изменение промпта с универсального на персональный кардинально улучшает результат.
4. Преодоление разделения "разработчик-пользователь"
Традиционное ПО требует разделения: разработчик пишет код, пользователь использует интерфейс. AI позволяет пользователям "программировать" приложения на естественном языке, что меняет эту парадигму.
5. AI-агенты для чтения писем эффективнее чат-ботов
Koomen показывает пример email agent, который может автоматически сортировать, помечать и отвечать на письма на основе пользовательских инструкций. Это более мощный подход, чем простые чат-боты.
6. Важность инструментов (tools) для AI-агентов
AI-агенты становятся по-настоящему полезными, когда у них есть доступ к инструментам для выполнения действий в реальном мире. Разработчики должны фокусироваться на создании богатой экосистемы инструментов. Здесь можно вспомнить про MCP протокол, который сейчас популярен для предоставления доступа агентам к внешним инструментам
7. Coding agents показывают правильное направление
Coding agents как Cursor и Windsurf работают лучше других AI-приложений, потому что они дают полный доступ к возможностям модели без ограничений (ну или почти без ограничений)
8. Чат-бот парадигма ограничивает AI
Большинство продуктов просто встраивают чат-агентов в существующие интерфейсы, что не использует истинные возможности AI (мы не знаем какие системные промпты есть на стороне чатботов)
9. Каждый может стать prompt engineer
Написание промптов интуитивно понятно - это просто объяснение AI того, как вы принимаете решения. "Это не навык, с которым мы рождаемся, но это довольно интуитивно".
10. Переосмысление продуктов с нуля для AI
Основателям стартапов следует спрашивать не "Как вставить AI в мой инструмент?", а "Как я бы спроектировал этот инструмент с нуля, чтобы максимально автоматизировать повторяющуюся работу пользователя?".

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

#AI #ML #Software #DevEx #Engineering #Development

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