State of platform engineering in the age of AI (Рубрика #AI)

Интересный отчет конца 2024 года, который подготовлен компанией Red Hat совместно с исследовательским агентством Illuminas. Red Hat — мировой лидер в области корпоративных open source-решений, активно развивает платформенную инженерию и внедрение ИИ в инфраструктуру предприятий. Illuminas — опытная исследовательская компания, специализирующаяся на IT и B2B-рынках. Этот отчет построен на опросе 1000 инженеров платформ и IT-руководителей из США, Великобритании и стран Азиатско-Тихоокеанского региона.

Методология исследования была следующей
- Это был онлайн-опрос на 20 минут, где было 1000 респондентов (поровну инженеров и руководителей)
- 35% участников представляло средние компании, а 65% — крупные
- Участвовали сотрудники компаний из отраслей: IT, финансы, ритейл, здравоохранение, профессиональные сервисы
- География опроса: США, Великобритания, англоязычные страны APAC

Ключевые идеи и выводы опроса следующие
1. Платформенная инженерия становится стратегической
62% компаний уже имеют выделенные команды платформенной инженерии. Платформенная инженерия — это не просто автоматизация инфраструктуры, а стратегический инструмент для ускорения инноваций и внедрения ИИ.
2. Влияние искусственного интеллекта
76% организаций уже используют генеративный ИИ для задач разработки (документация, генерация кода, подсказки). 45% считают ИИ центральным элементом своей платформенной стратегии.
3. Модель зрелости платформенной инженерии
Red Hat выделяет 4 уровня зрелости:
- Exploring - исследование
- Emerging - начало внедрения
- Established - устоявшаяся практика
- Advanced - продвинутый уровень
Компании с высокой зрелостью достигают на 41% лучших результатов (по продуктивности, инновациям, безопасности).
4. Основные драйверы внедрения
- Безопасность
- Улучшение взаимодействия между командами
- Автоматизация и ускорение процессов
5. Эволюция инвестиций
- На ранних этапах — фокус на модернизации инфраструктуры (55%)
- На продвинутых этапах — автоматизация (85%), безопасность (59%), инструменты для разработчиков (55%)
6. Проблемы и вызовы
На всех уровнях зрелости сохраняются сложности с интеграцией рабочих процессов и рисками безопасности (по 37%).
- На ранних этапах — нехватка навыков и бюджета (40%)
- На продвинутых этапах — несовместимость инструментов, нестабильность платформ, дефицит знаний (около 30%)
7. Метрики успеха
Зрелые компании отслеживают больше показателей (в среднем 7), включая продуктивность, безопасность, производительность приложений, удовлетворённость разработчиков. На ранних этапах чаще фокус на снижении затрат.

Если подводить итоги отчета, то можно заключить, что
- Платформенная инженерия становится отдельной профессией, требующей новых навыков и командной структуры.
- Компании и вендоры должны интегрировать ИИ в платформенные решения, а не рассматривать ИИ как отдельный инструмент.
- Стандартизация архитектур и best practices ускоряет внедрение и снижает риски.
- Безопасность и автоматизация — ключевые приоритеты для будущего развития.

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

ArchDays 2025 - CFP (Рубрика #Architecture)

Этой осенью пройдет уже 7 ежегодная конференция ArchDays по software architecture. Я в программном комитете этой конференции с момента ее появления, поэтому не могу не поделиться стартом CFP (call for paper). Если вы хотите выступить на конференции и рассказать доклад об одной из тем: процессы проектирования, практики, инструменты, обучение архитектуре или про собственную разработку, то you are welcome. В этом году, как и в прошлом у нас упор на практику - можно подать заявку на проведение арх каты, порешать арх кейсы или подискутировать насчет разных концепций архитектуры.

В общем, если планируете стать спикером, то вам сюда.
А если вы планируете прийти послушать, то уже можно покупать билеты:)

P.S.
Я выступал на всех предыдущих конференциях ArchDays, что были до этого с разными докладами на тему архитектуры. По ним даже можно отследить как менялась архитектурная повестка у нас в компании:)
1) "Эволюция web’а tinkoff.ru за последние 3 года" в 2019 (youtube)
2) "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения" в 2020 (youtube, статья с расшифровкой)
3) "System Design Interview как проверка навыков проектирования систем на собеседованиях" в 2021 (youtube, статья с расшифровкой)
4) "Как подготовиться и пройти System Design Interview" в 2022 (youtube, статья с расшифровкой)
5) "Публичное интервью по System Design про бронирование отелей" в 2022 (youtube, статья с расшифровкой)
6) "Публичное интервью по System Design про простую a/b платформу" в 2023 (youtube)
7) "Архитектура в Т-Банке: вчера, сегодня, завтра" в 2024 (youtube, статья с расшифровкой)

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #SystemDesignInterview #DistributedSystems

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://xn--r1a.website/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

Круглый стол «Техлид и развитие в 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

Research Insights Made Simple #11 - Measuring AI Code Assistants and Agents (Рубрика #DevEx)

Очередной выпуск подкаста с разбором whitepaper "Measuring AI Code Assistants and Agents" посвящен разбору измерения эффекта от AI в разработке. Этот отчет интересен, так как ребята из DX являются одними из законодателей мод в мире developer productivity. Для разбора этой статьи ко мне пришел гость, Евгений Сергеев, engineering director в Flo Health.

За полчаса мы разобрали whitepaper и осудили темы
- Платформа DX и оценка влияния кодовых ассистентов и агентов на продуктивность инженеров
- Структура фреймворка DX: этапы зрелости, метрики и риски неправильного внедрения
- Оценка adoption и утилизации
- Оценка импакта и метрики
- Коммуникация внедрения метрик в разработку
- Обсуждение фреймворков DORA, SPACE, DevEx, DX Core 4 для измерения эффективности продуктивности инженеров в общем

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

P.S.
Я разбирал этот whitepaper раньше в своем tg канале раньше.

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

[1/2] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Рубрика #AI)

Я достаточно оперативно познакомился с этим whitepaper, где показано замедление разработчиков при использовании AI. Но изначально я не хотел про него писать - методология мне показалось хоть и интересной, но объем выборки аж в 16 инженеров казался мне маловатым для того, чтобы делать громкие заявления о замедлении разработки. Но я поменял свое мнение после того, как посыпались заголовки в стиле "Учёный изнасиловал журналиста" и дальше падкие на громкие заголовки люди начали присылать это исследование с аргументацией "вот они доказательства: усы, лапы и хвост".

После этого я пошел и прочитал не только краткую выжимку с сайта METR (Model Evaluation & Threat Research), но и все 50 страниц основного whitepaper, где авторы описали всю методологию эксперимента, свои мысли о результатах и их причинах (конечно, без стат значимости) и даже инструкции для участников экспериментов. Дальше я поделюсь своими мыслями насчет этого эксперимента.

Начнем с того, почему это исследование получило столько внимания и тут есть несколько причин
1. Противоречие общепринятому мнению
Результаты исследования прямо противоречат широко распространенному убеждению о том, что AI-инструменты неизбежно повышают продуктивность разработчиков. Исследование показало, что AI-инструменты фактически замедляют опытных разработчиков на 19%, что стало шокирующим открытием даже для самих авторов.
2. Методологическая точность
Авторы провели исследование используя рандомизированные контролируемые испытания (фактически, a/b тест) для оценки реального влияния AI на продуктивность разработчиков в их обычной рабочей среде. Исследование отличается от предыдущих работ использованием фиксированных задач и опытных разработчиков, работающих в знакомых кодовых базах. Правда, тут участники знали про сам эксперимент, а значит мог проявляться эффект Хоторна
3. Актуальность для индустрии
Результаты исследований про влияние AI имеют огромное значение для оценки многомиллиардных инвестиций в AI-инструменты для разработки. Предыдущие исследования по другому подходили к оценке эффекта и все поголовно показывали увеличение продуктивности. А это исследование поднимает вопросы о реальной окупаемости инвестиций в AI-инструменты разработки.

Продолжим тем, а почему нам стоит доверять исследователям из METR.
Начать надо с того, что METR - это некоммерческая исследовательская организация, специализирующаяся на оценке возможностей фронтирных AI-систем и их потенциальных рисков. Организация работает с ведущими AI-компаниями, включая OpenAI и Anthropic, и сотрудничает с государственными институтами AI-безопасности. В группу исследователей входили технические сотрудники Joel Becker, Nate Rush, David Rein, а также Beth Barnes - основатель и главный исследователь METR, бывший исследователь OpenAI и DeepMind, ведущий эксперт по AI-безопасности и оценке AI-систем.

И как же выглядела методология рандомизированных контролируемых испытаний?
- Участвовали 16 опытных разработчиков open-source проектов со средним опытом работы с репозиториями 5 лет и 1500 коммитов в среднем.
- Решали они 246 реальных задач из крупных open-source репозиториев (в среднем 23,000 звезд, 1,100,000 строк кода).
- Дизайн эксперимента предполагал, что каждая задача случайным образом назначалась в одну из двух групп
-- AI-разрешенная группа: разработчики могли использовать любые AI-инструменты (преимущественно Cursor Pro с Claude 3.5/3.7 Sonnet)
-- AI-запрещенная группа: использование генеративного AI запрещено
- Измерялось время выполнения задачи, что разработчики отслеживали самостоятельно. Дополнительно собирались записи экрана, интервью и детальная аналитика использования AI.
- Помимо этого все задачи проходили стандартный процесс code review и должны были соответствовать высоким стандартам качества репозиториев.

Про результаты и почему его результаты надо воспринимать с осторожностью я расскажу в продолжении.

#AI #ML #Management #Leadership #Software #SoftwareDevelopment #Architecture #Metrics #Devops #Processes

[2/2] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Рубрика #AI)

Продолжая пост про исследование, расскажу про полученные результаты
- Было получено статистически значимое замедление на 19% при использовании AI-инструментов с 95% доверительным интервалом
- Авторы отдельно указали на ограничения обобщаемости этих выводов
-- Опыт разработчиков. Результаты специфичны для опытных разработчиков (5+ лет опыта с репозиториями). Для менее опытных разработчиков результаты могут быть противоположными.
-- Размер и сложность кодовых баз. Исследование проводилось на крупных, зрелых проектах (1M+ строк кода). На меньших или новых проектах AI может показать положительный эффект.
-- Знакомство с проектом. Разработчики работали в знакомых им репозиториях.
-- Тип задач. Задачи уже были декомпозированы до размера не больше 2х часов, что может не отражать весь спектр разработческих задач.
-- Внешняя валидность. Результаты не означают, что AI-инструменты бесполезны во всех контекстах разработки.

По результатам авторы сдели следующие выводы
1. AI-инструменты замедляют опытных разработчиков на 19% при работе в знакомых кодовых базах, что противоречит ожиданиям как разработчиков (предсказывали ускорение на 24%), так и экспертов (предсказывали ускорение на 38-39%).
2. Также они поразмышляли насчет факторов замедления, выделив 5 основных, хотя и сделали такую ремарку

However, we strongly caution against over-indexing on the basis of any individual pieces of evidence, as we are not powered for statistically significant multiple comparisons when subsetting our data. This analysis is intended to provide speculative, suggestive evidence about the mechanisms behind slowdown.

Вот эти факторы
- Чрезмерный оптимизм относительно полезности AI
- Высокая знакомость разработчиков с репозиториями
- Большие и сложные кодовые базы
- Низкая надежность AI (принимается <44% предложений)
- Неявный контекст репозиториев, недоступный AI

В итоге, авторы подчеркивают, что результаты не означают, что AI-инструменты бесполезны.

А теперь поговорим про проблемы исследования и почему его результаты надо воспринимать с осторожностью
1. Малый размер выборки
Только 16 разработчиков, что ограничивает статистическую мощность, а также ставит под вопрос репрезентативность выборки относительно генеральной совокупности. Сетап эксперимента не позволил ответить на вопросы, какие факторы повлияли на результаты
2. Краткосрочность
Исследование не учитывает долгосрочные эффекты обучения использованию AI-инструментов.
3. Специфичность контекста
Были выбраны крупные open source репозитории, что говорит о том, что результаты могут не обобщаться на другие типы проектов по размеру или специфике (web, мобильная разработка)
4. Эффект Хоторна
Участники знали о том, что участвуют в исследовании, что могло влиять на их поведение.
5. Субъективность измерений
Время выполнения задач измерялось самими разработчиками, что могло вносить систематические ошибки.
6. Определение продуктивности
Исследование фокусировалось только на времени выполнения, не учитывая другие аспекты продуктивности: качество кода (главное было пройти code review), удовлетворенность работой

Итого, мне кажется сам эксперимент интересным, но я больше верю в измерения практических эффектов в организациях, где есть измерение developer productivity и AI там добавляется в экосистему разработчиков постепенно и через a/b эксперименты на большом масштабе, которые позволяют отследить эффекты. Конкретно, про такие подходы можно почиитать в постах
- Про Google и их подходы из серии статей "Developer Productivity for Humans" (подробнее в постах: 1 и 2)
- Про подход запрещенной в России компании Meta, который они описали в статье "What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time" (подробнее в постах: 1, 2 и 3)
- Ну или на крайний случай можно глянуть мое выступление "Зачем заниматься темой developer productivity в большой компании"

#AI #ML #Management #Leadership #Software #SoftwareDevelopment #Architecture #Metrics #Devops #Processes

Research Insights Made Simple #12 - Measuring developer productivity with the DX Core 4 (Рубрика #DevEx)

Выпуск посвящен разбору "Measuring developer productivity with the DX Core 4" от ребят из DX, которые активно развивают тему developer productivity. Для разбора этой статьи ко мне пришел гость, Евгений Сергеев, engineering director в Flo Health.

- Введение, история и предпосылки появления DX Core 4
- Основые принципы измерения продуктивности, проблемы опросов
- 4 метрики DORA: deployment frequency, lead time for changes, change failure rate, time to restore service
- Простота внедрения DORA, интеграция с инструментами и его ограничения
- Фреймворк SPACE: опросы и системные метрики как фактор эффективности
- Дизайн фреймворков - разработка для решения конкретных проблем, добавление метрик по необходимости
- Развитие платформы DX
- Многомерные измерения внутри фреймворка DX Core 4 (качество, эффективность, скорость и импакт.)
- Настройка метрик, балансирующие метрики
- Роль технического директора и анализ метрик
- Анализ метрик и критерии их оценки
- Внедрение метрик в организации

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

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

Research Insights Made Simple (Рубрика #Engineering)

Наконец-то у меня дошли руки для подготовки расшифровок подкастов, которые посвящены разбору всяких научных работ в области software engineering. Правда, у меня получилось пока сделать краткие саммари по первым шести выпускам research insights made simple:
1. Разбор whitepaper "API Governance at Scale" от ребят из Google. В разборе мне помогал Даниил Кулешов, staff+ инженер в Т-Банке, что ведет несколько больших архитектурных проектов и участвует в процессах архревью на всю компанию. Саммари разбора есть в статье на моем сайте tellmeabout.tech
2. Разбор whitepaper "Defining, Measuring, and Managing Technical Debt" от ребят из Google. В разборе мне помогал Дмитрий Гаевский, staff+ инженер и технический CPO платформы Spirit в Т-Банке. Саммари разбора есть в статье на моем сайте
3. Разбор whitepaper "Security by Design at Google" от ребят из Google. В разборе мне помагал Артем Меретц, staff+ инженер и архитектор безопасности в Т-Банке. Саммари разбора есть в статье на моем сайте
4. Разбор whitepaper "AI-Enhanced API Design" от ребят из Google. В разборе мне помогал Павел Каравашкин, staff+ инженер в Т-Банке. Саммари разбора есть в статье на моем сайте
5. Разбор подходов к продуктивности разработки: DORA Metrics, SPACE, DevEx, Human Approach to Dev Productivity. В разборе мне помогал Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Саммари разбора есть в статье на моем сайте
6. Интервью с Николаем Головым про эволюцию data platform от начала времен и до текущего момента. Саммари разбора есть в статье на моем сайте

P.S.
Осталось расшифровать еще 6 выпусков, а потом новые выпуски подкаста я смогу публиковать сразу с текстовой версией для удобства.

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

Patrick Collinson on programming languages, AI, and Stripe's biggest engineering decisions (Рубрика #AI)

Посмотрел на выходных интересное интервью Патрика Коллинсона, со-основателя Stripe и энтузиаста языков программированния. Это интервью у него брал Майкл Трюэлл, сооснователь и генеральный директор Anysphere, компании, которая создала Cursor. Ребята обсуждали широкий список тем, включая будущее языков программирования, разработки в целом, как дела в Stripe и не только:) Основные идеи как обычно я привел ниже

1. Эксперименты с Smalltalk и Lisp
Первый стартап Патрика был написан на Smalltalk, который предлагал интерактивную среду разработки с возможностью редактирования кода в режиме реального времени. Найм сотрудников не был проблемой - умные люди быстро изучают новые языки. На Lisp Патрик делал бота для MSN Messenger с использованием байесовского предсказателя (он мог болтать с людьми). Также он экспериментировал с генетическими алгоритмами для оптимизации раскладки клавиатуры (подтвердил эффективность Dvorak). Но все эти side-проекты были далеки от текущих возможностей AI
2. Философия программирования и сред разработки
Патрик выступает за объединение времени выполнения, редактирования текста и среды исполнения кода. В качестве примера он упоминает Mathematica (сейчас это просто Wolfram). Патрик хочет в IDE видеть информацию профилирования при наведении курсора на код, а также logs и error messages. Здесь Патрик вспоминает еще некомерческую компанию Dynamicland, что занимается пространственными вычислениями. Он восхищается работой Брета Виктора в этой компании, но он не уверен, что этот подход применим к произвольным системам.
3. Технические решения в Stripe
Здесь Патрик обсуждает влияние закон Конвея на архитектуру, подчеркивая важность API и моделей данных для формирования организации. Странно, что Патрик при этом вспоминает про экосистему iOS и говорит, что она превосходит Android благодаря лучшему дизайну API - как по мне, экосистема iOS выглядит хорошо для потребителя, а инженерно это просто дно.
4.Выбор технологий
MongoDB и Ruby остаются фундаментальными технологиями Stripe с 2010 года (для меня это legaсу технологии). Правда, ребята переписали часть сервисов на Java для повышения производительности. Интересно, что в 2022 году стартанул масштабный проект по унификации абстракций Stripe API v2, который сейчас постепенно выкатывается на прод. Патрик достаточно подробно рассказывает про сложности больших миграций
5. Будущее программирования с AI
Патрик использует LLM в основном для фактических вопросов и программирования через Cursor. А дальше своим видением делился Майкл, что разраатываевает Cursor
- Языки программирования могут стать менее формальными и более ориентированными на результат
- AI может помочь в рефакторинге кодовых баз и улучшении архитектуры
- Cursor планирует создать более интегрированную среду разработки с AI в фоновом режиме
6. Экономические аспекты и исследования прогресса
Здесь ребята обсужали разные тезисы и мнения, забавно, что касались и whitepaper "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", но Патрик его еще не успел изучить (а я уже изучил и разобрал для вас: 1 и 2). Если суммировать их мысли, то пока нет чётких доказательств роста производительности от LLM
7. Исследования прогресса и пример с биомедициной
Патрик считает, что потребность в исследованиях прогресса возросла из-за увеличения степеней свободы. Например, Патрик соосновал Arc Institute в 2021 году для биомедицинских исследований. Они работают над базовыми моделями для биологии с использованием ДНК, а также пытаются создать виртуальную клетку для понимания сложных заболеваний, чтобы бороться со сложными заболеваниями типа рака и нейродегенерации

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

#AI #ML #Management #Leadership #Software #SoftwareDevelopment #Architecture #Processes