AI и Platform Engineering (Рубрика #AI)

Интересное выступление Игоря Маслова, VP of Coretech & Data в Т-Банке, на открытии конференции Platform Engineering Night, про которую я уже рассказывал. Игорь открывал конференцию и рассказал о том, как AI влияет на работу инженеров и развитие инженерных платформ. Основные мысли выступления примерно следующие

1. AI как усилитель существующих платформ
Сейчас нужно "обмазывать" существующие инженерные сценарии AI - от создания пайплайнов до анализа телеметрии. В этом разрезе интересно глянуть whitepaper Google "Measuring Developer Goals", чтобы посмоттреть какие основные сценарии выделяет Google (я рассказывал о нем раньше), а также девятый выпуск "Research Insights Made Simple", в котором мы с коллегой Колей Бушковым разбирали whitepaper "What Do Developers Want From AI?" от ребят из Google
2. Когнитивная нагрузка и потеря навыков
Игорь отмечает, что активное использование AI приводит к потере низкоуровневых навыков, но считает это нормальной эволюцией - условно, мало кто пишет на ассемблере и большая часть инженеров его уже не понимает и это никого не смущает. Примерно также мы будем писать код с ассистентами на условной Java и часть людей без ассистентов его уже не смогут написать/прочитать:)
3. Режим "копайлота" как базовый уровень
Ответственность за финальный результат остаётся за человеком, что минимизирует риски "галлюцинаций" AI-моделей. Anthropic реализует эту философию в Claude, где модель действует как ассистент, а не замена разработчика. Такой подход особенно важен в критически важных системах, таких как финансы или здравоохранение, где ошибки AI недопустимы
4. Будущее: AI как платформенная инженерия
В долгосрочной перспективе AI может стать основным интерфейсом для управления инженерными процессами, устраняя необходимость в традиционных инструментах. Это направление напоминает эволюцию Kubernetes, который стал стандартом для оркестрации контейнеров, но для AI аналогичный "момент" ещё не наступил
5. Vibe Coding и персонализированный софт
Генерация кода под конкретные бизнес-кейсы или индивидуальные потребности пользователей — ключевой тренд. Однако, как предупреждает Игорь, подобные системы требуют тщательной валидации, чтобы избежать проблем с поддерживаемостью кода
6. Разгрузка разработчиков от рутины
80% экспериментальной работы можно автоматизировать, освободив время для более важных задач. OpenAI's Code Interpreter позволяет итеративно решать сложные задачи программирования и анализа данных.
7. ML-платформы: гибкость и готовность к изменениям
Инвестиции в ML-платформы оправданы, но требуют готовности к технологическим сдвигам. Например, переход от традиционных нейросетей к трансформерам в 2020-х потребовал полного пересмотра инфраструктуры у большого количества компаний. Спикер подчёркивает, что платформы должны сохранять модульность, чтобы адаптироваться к новым алгоритмам и аппаратным решениям
8. Отсутствие "момента Kubernetes" в AI
Пока нет универсального стандарта для AI-платформ, и стоит дождаться его появления. Каждая компания развивает свои подходы: OpenAI с Agents SDK, Anthropic с фокусом на безопасность, Google с комплексными AI решениями.
9. Высокорискованная природа current AI R&D
Современные AI-решения требуют больших ресурсов и подходят в основном крупным компаниям. Это подтверждается масштабными инвестициями OpenAI, Google и Microsoft в платформенные решения.
10. Постепенный подход к внедрению
Рекомендация: начинать с улучшения инструментов, но пока воздержаться от сложных low-code процессов. Anthropic следует схожей философии, предоставляя мощные модели с акцентом на контролируемое внедрение.

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

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

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

Angular: The Documentary | An origin story (Рубрика #Engineering)

Посмотрел интересный документальный фильм про создание и развитие фронтового фреймворка Angular. Этот фильм интересно посмотреть даже если вам не интересна история фронтовых фреймворков (кстати, про react тоже есть документалка и я уже про нее рассказывал). Фильм рассказывает как Angular родился как внутренний эксперимент в Google, который поначалу отмахнули большие команды (Gmail и Maps), а затем стал массовым фреймворком и прошёл через болезненную «вторую жизнь» (Angular 2+). А теперь чуть

1. Как Angular появился внутри Google (локальная инициатива)
Старт проекту дала команда, работавшая над Google Feedback. Она утонула в 17 000 строк фронтенда и низкой тестопригодности. Тогда Ми́шко Хевери предложил дерзкий ход: переписать всё за две недели своим хобби‑проектом (GetAngular/AngularJS). Вышло за три, но код сжался до ~1 500 строк, и это стало моментом истины — менеджмент увидел в подходе ценность и дал зелёный свет на развитие. В общем, видно, что Angular родился не как глобальная инциатива "сверху-вниз", а скорее как локальная инженерная идея, доказавшаяся прототипом лечение реальной боли команды.
2. Борьба за ресурсы и «нет» по дороге
На старте AngularJS не получал аппрув от флагманов внутри Google - многие говорили что-то в стиле "хорошая игрушка, удачи". Поддержка пришла после демонстрации драматической экономии сложности/кода и скорости разработки. Сначала - маленькая команда, много скепсиса, мало ресурсов; дальше - органический рост вокруг первых успешных внедрений. Итого, в большой компании лучше один раз радикально показать ценность на рабочем кейсе, чем долго убеждать словами.
3. Как в Angular появился Dart и почему далее произошёл «раскол» AngularJS и Angular
Следующей развилкой стала производительность, статанализ и tree‑shaking. Внутри Google к этому моменту крепки были позиции Dart (с его dart2js и агрессивным tree‑shaking), а команда Angular экспериментировала между JS, AtScript и Dart. В итоге Google и Microsoft сошлись на TypeScript: ключевые идеи AtScript попали в TS 1.5, а Angular 2 строили уже на TypeScript, параллельно поддерживая AngularDart для крупных внутренних продуктов (Ads/AdSense). Это и закрепило исторический «раскол»: AngularJS (1.x) и Angular (2+) — два разных мира. В итоге, видно, что Dart повлиял на выделение дополнительных ресурсов, архитектуру фреймворка и компиляцию (статичность, AOT, tree‑shaking), но "языковая ставка" в открытой экосистеме ушла в сторону TypeScript.
4. Большие миграции
У Angular было две ключевые миграции:
- Архитектурный разрыв AngularJS → Angular (2+) - без обратной совместимости. Перепроектирование ради мобильности, модульности, типизации и будущей компиляции. Это самая болезненная точка истории.
- Смена движка рендера на Ivy (Angular 9) - уже внутренняя замена View Engine на новый компилятор/рендерер, специально спроектированный под мелкогранулярный tree‑shaking и меньшие бандлы. Переход стал дефолтом в v9 и принёс ощутимую экономию размера без переписывания приложений с нуля.
Обе миграции были болезненны, но кажется, что необходимы.
5. Как Angular чувствует себя сейчас и планы
Angular снова на подъёме: зрелая реактивность (Signals), сильный SSR/гидрация, фокус на DX и производительности, аккуратные мажоры без «лома мира». А Google планирует переносить фичи Wiz (внутреннего фреймворка внутри Google) в публичный Angular. Акутальная дорожная карта есть на angular.dev/roadmap.

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

#Software #SoftwareDevelopment #Architecture #Engineering #Management #OpenSource

Эволюция метрик и практика применения SPACE (Рубрика #DevEx)

Мои коллеги Саша Кусургашев и Дима Гаевский на IT Пикнике летом рассказывали про то, как мы используем фреймворк SPACE для оценки продуктивности инженеров. Недавно появилась запись выступления Саши (который отдувался за двоих) и я решил поделится кратким саммари этого рассказа.

Если уложить это саммари в одну мысль, то она примерно такая "инженеров нельзя адекватно оценить одной цифрой или простым количественным показателем" - хотя часто это пытались сделать (например, число коммитов, строк кода, выполненных задач), но каждая такая метрика отражает лишь одну сторону дела и сильно зависит от контекста. Например, большое число изменений в коде может свидетельствовать как о высоком темпе команды, так и о переработках или неэффективном процессе – без контекста такие цифры вводят в заблуждение. Ребята привели в докладе кучу примеров того, как приходится учитывать множество граней эффективности: скорость работы, качество результата, командное взаимодействие, удовлетворённость сотрудников и другие факторы.

Собственно, первая половина доклада была про сам фреймворк "SPACE", где рассказ строился на статье "The SPACE of Developer Productivity", о которой я уже рассказывал раньше. Сам акроним SPACE расшифровывается как
- Satisfaction & Well being (удовлетворённость)
- Performance (результативность)
- Activity (активность)
- Communication & Collaboration (коммуникация)
- Efficiency (эффективность)
Каждое из этих измерений дополняет остальные, создавая целостную картину. В выступлении отмечалось, что такой многомерный подход родился как реакция на злоупотребления однобокими метриками и нацелена на то, чтобы сделать оценку работы инженеров более справедливой и осмысленной.

Вторая часть доклада была посвящена опыту внедрения SPACE и мне она кажется самой полезной частью выступления. Саша рассказал с чего начать сбор метрик и как интерпретировать.Внедрение многомерной системы измерений оказалось непростой задачей – потребовалось агрегировать данные из разных источников (систем контроля версий, трекеров задач, CI/CD, опросов сотрудников и пр.) и привести их к единой основе для сравнения. Авторы подчеркнули важность нормализации данных и правильных «разрезов» – нужно решать, по каким сечениям анализировать метрики (по командам, по проектам, по временным периодам), чтобы выявлять закономерности и проблемные зоны. Это оказалось нетривиально: разные сегменты показывали разную картину, и неправильный выбор среза мог скрыть проблему или создать иллюзию успеха. Например, сравнение по командам требует учёта специфики проектов; сравнение по времени – учёта сезонности и изменений обстоятельств.

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

Из выступления можно забрать такие мысли
1) Комбинируйте объективные метрики с обратной связью от людей
2) Используйте метрики как инструмент для улучшения, а не для наказания. Стоит выявлять узкие места и точки роста, а не устраивать «соревнование разработчиков» или повышать бюрократию
3) Вводите метрики постепенно и осмысленно. Начать с пилотной команды или направления, выбрать небольшое подмножество SPACE-метрик, относящихся к наиболее болезненной проблеме, и опробовать их в деле
4) Важна роль культуры и поддержки руководства. Внедрение SPACE – это не разовая акция, а изменение подхода к управлению

#Processes #Management #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SRE

Vite: The Documentary (Рубрика #Frontend)

На прошлой неделе вышел документальный фильм про Vite или как один побочный проект Эвана Ю (автора Vue.js) за несколько лет изменил весь фронтенд. Начать стоит с того, а почему Vite так важен. Он появился в ответ на то, что Webpack стал слишком медленным и громоздким. В этот момент Эван Ю, автор Vue.js пытался улушить DevEx инженеров, что писали на Vue и он попробовал радикально другой подход: запускать dev-сервер без бандлинга, отдавая модули прямо в браузер через ESModules. Так появился Vite - инструмент, который:
- Стартует почти мгновенно;
- Обновляет код без перезагрузки страницы (hot module replacement, HMR);
- Компилирует зависимости через esbuild и Rollup, обеспечивая скорость на уровне Rust-решений.

В начале фильма звучит фраза «если вы пишете на современном JS-фреймворке, вы, скорее всего, используете Vite» и это уже не преувеличение. На нем работают Vue, SvelteKit, Nuxt, Astro, Remix, Qwik, Laravel, Shopify Hydrogen и десятки других фреймворков. Авторы фильма рассказывают про таймлайн развития технологии, который выглядит примерно так
- 2020 - Первая версия как dev-сервер для Vue.
- 2021 - Vite 2.0 — мультифреймворк, переход SvelteKit и Laravel.
- 2022 - Экосистема взрывается: ViteConf, Vitest, интеграции с Nuxt 3 и Astro.
- 2023 - Remix и RedwoodJS переходят на Vite; анонс Rust-бандлера Rolldown.
- 2024 - Основана компания VoidZero; Vite 6.0, 17 млн скачиваний в неделю.
- 2025 - Премьера фильма и планы на Rust-реализацию всего стека.

Ключевые факторы DevEx, за которые инженеры полюбили Vite
- Скорость: дев-сервер стартует за секунды, HMR - почти мгновенный.
- Простота: минимальная конфигурация и плагинная архитектура.
- Расширяемость: единая база для React, Vue, Svelte, Qwik и др.
- Интеграции: тестирование (Vitest), Storybook, E2E (Cypress, Playwright), Laravel, Rails.
- Сообщество: 850+ контрибьюторов, десятки компаний (Google, Shopify, Cloudflare, NASA, OpenAI).

Но Vite не стоит на месте и окмпания VoidZero уже пишет на Rust собственные инструменты:
- Rolldown - замена Rollup внутри Vite;
- Oxc - быстрый парсер и линтер;
- Есть планы на «Vite +» - единый стек для сборки, тестирования и форматирования.
- Есть движение в сторону AI - на ViteConf 2025 уже обсуждали агентов, помогающих создавать приложения на Vite.

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

Раньше я уже рассказывал про другие документальные фильмы из этой же серии и могу рекомендовать их любителям технологий и историй про их создание и развитие.
- Kubernetes Documentary
- eBPF Documentary
- Inside Envoy
- GraphQL: The Documentary
- Node.js Documentary
- Python: The Documentary
- Ruby on Rails: The Documentary
- React.js: The Documentary
- Angular: The Documentary

#Software #Documentary #Engineering #Architecture #Management #SoftwareDevelopment

State of Devops Russia 2025 (Рубрика #Devops)

Несколько дней назад были опубликованы результаты большого опроса про состояние DevOps в России. Наступили выходные, я его дочитал и решил написать тезисный разбор. Кстати, если этот разбор понравится, то можно его сравнить с глобальным DORA отчетом за 2025 год, о котром я уже писал. Но вернемся к этому опросу

- Производительность команд выросла: суммарная доля высокоэффективных команд (профили Elite и High) увеличилась на 6% по сравнению с прошлым годом, и ключевые показатели эффективности (частота релизов, скорость доставки, время восстановления, процент неудачных изменений) улучшились. Напомню, что в стандартном подходе все компании бьются на 4 кластера: low, medium, high, elite на основе 4 метрик DORA (deployment frequency, lead time for changes, change failure rate, mean time to restore).
- DevEx дает эффект: у высокоэффективных команд налажены быстрые и качественные циклы обратной связи, ниже когнитивная нагрузка и выше автономность инженеров (подробнее про модель DevEx я уже писал)
- Гибридная модель потребления: оркестраторы рабочих нагрузок не используют только ~15% опрошенных, остальные предпочитают c отрывом K8s (~51% разворачивают его on-prem, ~25% гибридно, еще 25% в облаке или нескольких). Данные треть хранит on-prem, треть гибридно, а треть в облаке.
- Повышение использования IDP: внутренние платформы разработки превращаются в обязательный атрибут крупных компаний с активной разработкой. Более 45% респондентов уже используют IDP для управления доступами и поиска необходимой информации. Главная цель развития внутренних платформ на 2025 год – максимальная автоматизация рутинных задач. Крупный бизнес рассматривает IDP как способ унификации процессов разработки и усиления контроля безопасности
- Информационная безопасность стала приоритетом: большинство команд теперь интегрируют её в процессы разработки (77% используют инструменты ИБ)
- Инструменты AI получили массовое распространение: ~71% опрошенных говорят, что применяют AI/ML в работе (чаще всего для генерации кода), при этом более половины уже отмечают рост продуктивности благодаря AI
- Продолжается импортозамещение: растёт использование российских OS и K8s-дистрибутивов вместо зарубежных аналогов
- Ситуация на рынке труда для devops инженеров изменилось: hh-индекс конкуренции (отношение резюме к вакансиям) вырос с 7,7 до 14,9 за год, то есть на одну позицию претендует больше инженеров

Исследование State of DevOps Russia 2025 проведено командой «Экспресс 42» (консалтинговое подразделение компании Flant) и стало пятым ежегодным отчётом о развитии DevOps в России. В опросе участвовало более 3300 специалистов из России и стран СНГ. Респонденты представляли широкий спектр отраслей и ролей в ИТ - среди них были как инженеры и DevOps-специалисты, так и руководители разных уровней из крупных, средних и небольших компаний. В общем, результаты можно с достаточной уверенностью считать репрезентативными для оценки текущего состояния DevOps практик.

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment

Postcriptum State of Devops Russia 2025 (Рубрика #Devops)

Отдельно поделюсь заключительной частью этого отчета, в которой приведена цитата Димы Гаевского, моего друга и коллеги, который у нас отвечает за развитие нашей внутренней платформы разработки.

Российский рынок ПО продолжает идти своим, местами парадоксальным путём: с одной стороны — жёсткое внешнее давление, с другой — необратимое взросление ИТ-ландшафта. В XL-сегменте тренд на интеграцию AI в производственные конвейеры только усилился. «Бигтехи» уже отстроили безопасные внутренние платформы, а теперь метят в AIOps и GenAI-копилотов, выжимая из DevOps максимум продуктивности. Но важно помнить, что даже крупнейшие игроки по-прежнему остаются «догоняющими» по
сравнению с США и Китаем — разрыв бюджетов и доступ к современным GPU остаются вопросом как минимум ближайших двух лет.

Средние и мелкие компании, пережившие кадровую турбулентность 2022 года, решали задачи автономно и почти поголовно выбрали проверенный OSS-стек — GitLab, Ansible, ELK, Kubernetes. Это был единственный рациональный путь на фоне дефицита зрелых российских предложений и высокой технологической неопределённости. Теперь же, когда регуляторика импортозамещения ужесточилась (реестр ПО, квоты в госзакупках, совместимость с «Альт»/Astra), к этому стеку постепенно добавляются отечественные надстройки — от SCA-плагинов с ГОСТ-крипто до репозиториев кода типа GitFlic.

Безопасность стала отдельным фронтом: массовый self-hosting GitLab без выстроенных процессов патч-менеджмента законсервировал множество уязвимостей. Компании начинают вкладываться в SBOM и DevSecOps, чтобы закрыть регуляторный и репутационный риск. Одновременно растёт популярность FinOps: стоимость GPU-кластеров растёт быстрее, чем ROI по экспериментальным AI-проектам, и советы директоров всё чаще спрашивают не «сколько мы натренируем моделей», а «сколько рублей мы сэкономим».

Аппаратные ограничения ощутимы: top-tier NVIDIA/AMD по-прежнему под экспортным контролем, китайские ASIC — решение рабочее, но ставит потолок производительности. Это подталкивает XL-компании к «федеративным» альянсам: банки и ритейл делятся дообученными LLM, промпредприятия — моделями предиктивного обслуживания; государство выступает ранним якорным заказчиком и субсидирует разработки, но объёмы субсидий пока несравнимы с глобальными CAPEX.

Прогноз на ближайшие годы — без паники, но и без иллюзий. Крупные продолжат апстримить AI-инновации и строить FinOps-офисы, страхуя TCO. SMB останутся на OSS-ядре, однако вынужденно потратятся на DevSecOps и аутсорс-SOC. Консолидация усилий пойдёт в двух плоскостях: горизонтальные коалиции гигантов для обмена моделями и вертикальная «надстройка» отечественных решений над универсальным OSS. В результате рынок получит не «западный стек против российского», а гибрид «OSS-база + локальные специализированные модули», что, пожалуй, и есть самый реалистичный сценарий 2025 – 2027 годов.

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment

AI changes *Nothing* — Dax Raad, OpenCode (Рубрика #AI)

Посмотрел интересный доклад Dax Raad из OpenCode на конференции AI Engineer, где создатель популярного coding agent выступил с провокационным тезисом: несмотря на весь ажиотаж вокруг AI, фундаментальные вызовы построения успешного продукта остаются прежними. В общем, AI не решает волшебным способом те проблемы, что раньше требовалось решать для развития продуктов. Основных тезисов в выступлении всего три

1️⃣ Маркетинг - это про "крутость", а AI слишком корявый
Dax утверждает, что настоящий top-of-funnel маркетинг - это способность создать что-то, чем люди захотят поделиться. Это не стандартные блог-посты о релизах или оплаченные упоминания у инфлюенсеров. Вам нужно вызвать у пользователя такую реакцию, чтобы он захотел показать это коллегам или друзьям со словами "можете в это поверить?".​
Проблема в том, что AI инструменты генерации контента выдают слишком банальные и/или корявые результаты. Они не способны создать крутые штуки, которые цепляют эмоционально. Даже используя AI как brainstorming-партнёра, Dax не получил ни одной действительно хорошей идеи. Маркетинг требует креативности, а AI пока не может её обеспечить.​​ В итоге, лучше не поручать маркетинг AI, а придумывать идеи самим, чтобы иметь ненулевой нулевой шанс стать вирусными.​

2️⃣ Aha-момент: безжалостное устранение фрикций
Второй критический этап - это aha-момент: момент в journey пользователя, когда он наконец "понимает" ценность продукта. Вы должны определить единственный самый важный момент озарения и безжалостно устранить все препятствия на пути к нему.​​ Кстати, про это рассказывал Петр Савостин, мой коллега, что занимается у нас развитием мобильных продуктов для физических лиц. Суть в том, что на каждом лишнем шаге customer journey вы теряете 10-20% пользователей и до aha-момента часто большинство пользователей не добираются. В итоге, это не про то, чтобы сделать много фич, а про то, чтобы сделать вылизанные фичи, где пользователь сразу чувствует ценность. Например
- ChatGPT: пустое поле ввода, куда можно написать что угодно и получить человекоподобный ответ - мгновенное понимание ценности​
- Facebook (retention): добавление 7 друзей в первые 10 дней коррелировало с долгосрочным удержанием​
- Spotify: прослушивание 10 песен в первые 2 часа​

AI не помогает с решением этой проблемы - создание правильного aha-момента требует глубокого понимания problem space, позиционирования, ясности в том, что вы делаете уникально. Это требует куса, который не может быть делегирован алгоритму.

3️⃣ Retention: примитивы важнее фич
Здесь Dax развенчивает миф о том, что продукт может быть либо простым, либо мощным. На самом деле никакого trade-off нет - можно и нужно строить оба качества одновременно.​ Суть в том, чтобы не строить сложные фичи сходу, а в том, чтобы создавать deep primitives (глубокие примитивы), которые можно собрать в нужную функциональность. Сначала проектируете мощный, широкий слой примитивов, а затем собираете из них простой опыт для 99% пользователей. Когда пользователи становятся более продвинутыми, они получают прямой доступ к этим примитивам и могут настраивать продукт под себя, никогда его не перерастая.​

Но с этим не справляются AI инсутрменты, так как проектирование правильных примитивов - это процесс exploration. Чтобы даже объяснить AI, что вы хотите, нужно самому очень хорошо это понимать. Задача - понять проблему настолько глубоко, чтобы спроектировать правильный набор примитивов. AI здесь бесполезен.​​

В итоге, автор отмечает, что AI - это мощный инструмент для технической работы, но он не решает фундаментальных задач создания успешного продукта: маркетинга (креативность), onboarding (taste и фокус) и retention (архитектурное мышление). Технические лидеры должны продолжать инвестировать в человеческие навыки и не попадаться на иллюзию, что AI сделает крутые продукты автоматически. Hard work, хороший вкус, и человеческая изобретательность остаются необходимыми - и это хорошая новость.​​

#ProductManagement #Software #SoftwareDevelopment #AI #Engineering #Management #Leadership

[1/2] AI, DevOps, and Kubernetes: Kelsey Hightower on What's Next (Рубрика #PlatformEngineering)

Посмотрел интервью Келси Хайтауэра с командой JetBrains про состояние индустрии в 2025 году. Помню как лет 7 назад изучал Kubernetes по его репозиторию Kubernetes The Hard Way, который был не прост, но помог мне сдать лабы для получения шилдика CKA (Certified Kubernetes Administrator) первым в компании. Это было в те времена, когда мы с моим коллегой Стасом (гостем из первого выпуска подкаста Code of Leadership), Андреем (гостем 43 выпуска Code ...) и Антоном (гостем 17 выпуска Code ..) продумывали как будем переезжать в Kubernetes с виртуалок:)

Но если возвращаться к Келси, то он уже завершил активную карьеру в Google и теперь может философски размышлять про devops и не только. Я выделил 5 тем, что были интересны мне в этом обсуждении

1️⃣ DevOps: Эволюция или провал?
Келси критически оценивает то, во что превратился DevOps во многих компаниях.
- "Футболка вместо навыков": Многие компании просто переименовали системных администраторов в DevOps-инженеров, не изменив суть работы. "О, теперь я DevOps-инженер, дадут ли мне за это футболку?" — иронизирует Келси.
- Правильная имплементация: DevOps был задуман как "чертеж" (blueprint), предполагающий расширение компетенций. Сисадмины должны были научиться программировать, а разработчики - понимать, как работает операционная система (например, тюнить JVM под ядро Linux).
- Проблема опыта: Келси упоминает людей, у которых "20 лет опыта, состоящих из одного и того же года, повторенного 20 раз" (20 years of one-year experience). Это те, кто просто чинит серверы, не пытаясь автоматизировать или изменить подход.
- Platform Engineering: Это не что-то принципиально новое, а эволюция DevOps. Это переход от "я починю сервер, когда он сломается" к созданию продукта (платформы) для внутренних клиентов.

2️⃣ Kubernetes и «скучные» технологии
- Kubernetes - это скучно (и это хорошо): Для stateless (веб) приложений Kubernetes стал скучным еще 6-7 лет назад. Келси сравнивает инфраструктуру с полетом на самолете: "Самолеты интересны только тогда, когда они делают не то, что мы ожидаем. Если при посадке люди хлопают - значит, что-то пошло не так. Мы хотим просто выйти из самолета и не думать о полете".
- Инфраструктура не должна вызывать восторг: Если ваша инфраструктура вызывает у вас сильные эмоции, значит, вы боретесь с поломками или трением. Восторг должен вызывать продукт, который вы строите поверх неё.
- Будущее Kubernetes: Если через 20–30 лет мы всё еще будем обсуждать Kubernetes, это будет провалом индустрии. Мы должны придумать что-то лучшее. Kubernetes должен стать просто деталью реализации (как BIOS или машинный код), скрытой под более удобными абстракциями.

3️⃣ API, Silos (Колодцы) и взаимодействие команд
Келси делает контринтуитивное заявление: "Мне нравятся silos (изолированные команды)", но при наличии четкого API.
- Аналогия с авиабилетом: Когда вы летите в другую страну, вы не идете в кабину пилота обсуждать маршрут. Вы покупаете билет. Билет - это API (контракт). Вы садитесь в кресло, засыпаете и просыпаетесь в другом месте.
- API как контракт: Платформенная команда и разработчики не должны сидеть рядом и постоянно разговаривать. Они должны взаимодействовать через четкий контракт (API): "Мне нужно столько-то памяти, такой-то регион, такая-то версия".
- Когда нужно общение: Разговаривать нужно только тогда, когда вы хотите изменить API или добавить новую фичу в платформу. Для рутинного деплоя общение - это лишние накладные расходы.
Забавно, что примерно эти же моменты про взаимодествие команд мы разбирали со Стасом Халупом в первом выпуске Code of Leadership.

Оставшиеся темы про AI и важность soft skills обсудим в продолжении разбора этого крутого интервью.

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

[2/2] AI, DevOps, and Kubernetes: Kelsey Hightower on What's Next (Рубрика #PlatformEngineering)

В продолжении разбора интервью Келси нужно упомянуть темы AI и важности soft skills

4️⃣ Искусственный интеллект (AI)
Хайтауэр скептичен к хайпу, но видит фундаментальную пользу.
- AI как новый DSL: Келси смеется над "Prompt Engineering", когда люди чекинят в git 500 markdown-файлов с промптами и версионируют их. По сути, мы изобрели еще один, очень нестабильный язык программирования.
- Недетерминированность: Всю карьеру инженеры боролись за предсказуемость (тесты, идемпотентность), а теперь мы внедряем AI, который по своей природе вероятностный ("Зачем гадать, если можно знать наверняка?").
- Главная польза AI: Он заставил вендоров и разработчиков наконец-то написать нормальные API и документацию, чтобы LLM могли с ними работать. То, что мы должны были сделать для людей (хорошие доки и интерфейсы), мы теперь делаем для роботов.
- Guardrails (Ограничения): В итоге все равно все сводится к созданию жестких рамок (guardrails), чтобы заставить AI выдавать предсказуемый, "скучный" результат.

5️⃣Развитие: Человек vs Инженер
В конце интервью фокус смещается на soft skills и личностный рост.
- Командный спорт: Келси сравнивает работу в IT с баскетболом или футболом, а не с легкой атлетикой. В беге ты побеждаешь или проигрываешь один. В IT, каким бы крутым инженером ты ни был, ты зависишь от команды.
- Эмпатия: Это не просто "быть милым". Это понимание того, что если разработчик боится деплоить в пятницу, проблема может быть не в его трусости, а в ненадежности платформы, которую вы построили.
- Профессионализм и «Ящик с инструментами»: Не будьте просто «коллекционером» инструментов. Профессионал регулярно перебирает свой ящик с инструментами (toolbox), чистит их и выбрасывает ненужные.
- Дисциплина важнее любопытства: В профессиональной среде нельзя тащить в продакшн Rust или новую технологию только потому, что вам "любопытно". Выбирайте инструменты, которые решают задачу бизнеса, а не тешают эго инженера.

#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes