10 years of engineering at Nubank: Lessons from scaling to 122+ million customers (Рубрика #Architecture)
Недавно прочитал статью про эволюцию NuBank за 10 лет от Lucas Cavalcant, Distinguished Software Engineer and Senior Architect. Эта история эволюции мне показалась интересной, поэтому я решил рассказать про lessons learned
Лидерство вне кода
Техническое лидерство требует не только писать отличный код, но и умения ясно доносить идеи, вдохновлять команду и направлять её к решению - особенно когда у вас нет формальных "рычагов" руководителя (это особенность staff+ ветки IC). По мере роста роли инженера - ему приходится заниматься стратегическим планированием, координировать несколько команд и принимать крупные технические решения. У нас в Т тоже есть такая ветка, о которой я много рассказывал.
Карьерный путь (техника vs менеджмент)
В первые годы Nubank инженеры работали в режиме выживания - проблемы возникали ежедневно, и каждый бросался их чинить. Лишь к 2017 году появились первые менеджеры, и многие сеньоры (включая Лукаса Кавалканти) тогда осознали, что им ближе трек IC (individual contributor) и компания это учла: в 2018-м Lucas стал первым Principal Engineer, а недавно поднялся до Distinguished Engineer.
Эволюция архитектуры под гиперрост
Масштабирование с нуля (в 2013 году) до десятков и сотен миллионов клиентов потребовало постоянных архитектурных переделок.
- Изначально система Nubank была написана на Clojure с базой Datomic и развёртывалась монолитно в AWS (CloudFormation + AMI). Подробнее в выступлении 2017 года на QCon. А про использование AWS здесь
- С ростом нагрузки перешли на Docker и Kubernetes, распилили монолит на микросервисы, а позже создали core-банкинг платформу, способную поддерживать множество продуктов в разных странах. Подробнее в статье 2019 года про микросервисы
- Международная экспансия внесла новые требования (локальные регуляции, языки и т.д.)
Но не все масштабные решения оказались долговечны: шардирование данных, введённое в 2016-м, сначала выручало, но в итоге уткнулось в физические пределы (AWS не успевало выдавать новые сервера). Сегодня, как отмечает спикер, для дальнейшего роста нужны уже принципиально новые архитектурные подходы.
Стандарты vs инновации
На заре Nubank инженеры сами объединялись в "гильдии" для экспериментов с технологиями и инструментами помимо основной продуктовой работы. Такой подход породил культуру инноваций, но плохо масштабировался. Сейчас в компании есть отдельные платформенные команды, создающие общие инструменты и инфраструктуру - это позволяет продуктовым командам фокусироваться на своих фичах. Причем платформенным командам приходится изобретать новые подходы, инструменты и операционные практики, т.к. на масштабе Nubank часто нет готовых решений
Производительность команды без выгорания
Спикер делит свой путь на два этапа: ранние стартап-годы с бешеным темпом (постоянный "пожарный режим") и более структурированное настоящее, где выстроены процессы, не допускающие бесконечного тушения инцидентов. Его совет: на старте карьеры или продукта стоит выкладываться по максимуму, но постоянно так работать невозможно. Со временем Nubank сознательно улучшил work-life balance команд.
Взгляд в будущее (AI и финтех)
В качестве следующего большого рывка названы технологии искусственного интеллекта - прежде всего большие языковые модели (LLM). Они могут резко повысить продуктивность разработчиков, но есть риск генерировать больше изменений, чем команды смогут осмысленно потребить и сопровождать. Вызов в том, чтобы найти правильные кейсы, где AI действительно даёт стабильную пользу, а не тонны лишнего кода. Параллельно в самом финтехе происходят прорывы: например, запущенная в Бразилии система мгновенных платежей Pix радикально изменила то, как люди обращаются с деньгами . Подобные инновации, по мнению спикера, будут и дальше стирать границы между рынками и странами, задавая новые требования к масштабируемой архитектуре финансовых сервисов.
#Software #Engineering #Management #Architecture #Processes #Staff #SRE #DevOps
Недавно прочитал статью про эволюцию NuBank за 10 лет от Lucas Cavalcant, Distinguished Software Engineer and Senior Architect. Эта история эволюции мне показалась интересной, поэтому я решил рассказать про lessons learned
Лидерство вне кода
Техническое лидерство требует не только писать отличный код, но и умения ясно доносить идеи, вдохновлять команду и направлять её к решению - особенно когда у вас нет формальных "рычагов" руководителя (это особенность staff+ ветки IC). По мере роста роли инженера - ему приходится заниматься стратегическим планированием, координировать несколько команд и принимать крупные технические решения. У нас в Т тоже есть такая ветка, о которой я много рассказывал.
Карьерный путь (техника vs менеджмент)
В первые годы Nubank инженеры работали в режиме выживания - проблемы возникали ежедневно, и каждый бросался их чинить. Лишь к 2017 году появились первые менеджеры, и многие сеньоры (включая Лукаса Кавалканти) тогда осознали, что им ближе трек IC (individual contributor) и компания это учла: в 2018-м Lucas стал первым Principal Engineer, а недавно поднялся до Distinguished Engineer.
Эволюция архитектуры под гиперрост
Масштабирование с нуля (в 2013 году) до десятков и сотен миллионов клиентов потребовало постоянных архитектурных переделок.
- Изначально система Nubank была написана на Clojure с базой Datomic и развёртывалась монолитно в AWS (CloudFormation + AMI). Подробнее в выступлении 2017 года на QCon. А про использование AWS здесь
- С ростом нагрузки перешли на Docker и Kubernetes, распилили монолит на микросервисы, а позже создали core-банкинг платформу, способную поддерживать множество продуктов в разных странах. Подробнее в статье 2019 года про микросервисы
- Международная экспансия внесла новые требования (локальные регуляции, языки и т.д.)
Но не все масштабные решения оказались долговечны: шардирование данных, введённое в 2016-м, сначала выручало, но в итоге уткнулось в физические пределы (AWS не успевало выдавать новые сервера). Сегодня, как отмечает спикер, для дальнейшего роста нужны уже принципиально новые архитектурные подходы.
Стандарты vs инновации
На заре Nubank инженеры сами объединялись в "гильдии" для экспериментов с технологиями и инструментами помимо основной продуктовой работы. Такой подход породил культуру инноваций, но плохо масштабировался. Сейчас в компании есть отдельные платформенные команды, создающие общие инструменты и инфраструктуру - это позволяет продуктовым командам фокусироваться на своих фичах. Причем платформенным командам приходится изобретать новые подходы, инструменты и операционные практики, т.к. на масштабе Nubank часто нет готовых решений
Производительность команды без выгорания
Спикер делит свой путь на два этапа: ранние стартап-годы с бешеным темпом (постоянный "пожарный режим") и более структурированное настоящее, где выстроены процессы, не допускающие бесконечного тушения инцидентов. Его совет: на старте карьеры или продукта стоит выкладываться по максимуму, но постоянно так работать невозможно. Со временем Nubank сознательно улучшил work-life balance команд.
Взгляд в будущее (AI и финтех)
В качестве следующего большого рывка названы технологии искусственного интеллекта - прежде всего большие языковые модели (LLM). Они могут резко повысить продуктивность разработчиков, но есть риск генерировать больше изменений, чем команды смогут осмысленно потребить и сопровождать. Вызов в том, чтобы найти правильные кейсы, где AI действительно даёт стабильную пользу, а не тонны лишнего кода. Параллельно в самом финтехе происходят прорывы: например, запущенная в Бразилии система мгновенных платежей Pix радикально изменила то, как люди обращаются с деньгами . Подобные инновации, по мнению спикера, будут и дальше стирать границы между рынками и странами, задавая новые требования к масштабируемой архитектуре финансовых сервисов.
#Software #Engineering #Management #Architecture #Processes #Staff #SRE #DevOps
Building Nubank
10 years of engineering at Nubank: Lessons from scaling to 122+ million customers - Building Nubank
From first lines of code to massive architectural shifts, learn what it takes to scale engineering, culture, and innovation to 122+ million customers
❤8👍5🔥5
[2/2] Про Nubank (Рубрика #Business)
Продолжая рассказ про Nubank, я хотел кратко изложить тезисы Витора Оливейра, который рассказывал про технологии в Nubank в подкасте "Hippsters Ponto Tech #459" (правда, подкаст на португальском) в апреле 2025 года, а уже в августе 2025 года его сменил Eric Young (экс-VP Engineering Snap, Google, Amazon), что, как по мне, дало ясный знак инвесторам на то, что Nubank готов масштабировать свою инженерную ветку для глобальной экспании, о которой было рассказано в предыдущем посте.
1️⃣ Тесты как “первая линия обороны” Nubank
- В Nubank большой фокус на тестировании: юнит-тесты, интеграционные, multi-service-тесты и эксперименты с genAI генерацией тестов
- Обоснование в том, что для крупного финтеха это не “nice to have”, а "must have", чтобы защитить чувствительные финансовые данные клиентов и держать высокую планку по стабильности, безопасности и приватности
2️⃣ Эволюция архитектуры: от JVM-стека к cloud-first
- Исторически Nubank строился вокруг JVM-стека (Clojure + Kafka), что задавало определённый стиль архитектуры и инженерной культуры (подробнее про историю можно глянуть в посте "10 years of engineering at Nubank")
- Сейчас у ребят стратегия cloud-first, но не "cloud at any cost": они осознанно балансируют между облаком и on-prem, учитывая три критерия: стоимость, контроль и сущность бизнеса
3️⃣ Ключевые инженерные принципы
Витор подчеркнул фундаментальные принципы, которые направляют технические решения
- Иммутабельность - immutable инфраструктура и сервисы
- Стандартизация - однообразие подходов вместо зоопарка технологий
- Continuous Delivery - непрерыная поставка и безопасные релизы
- Минимизация сложности - сознательное сопротивление "архитектурному энтузиазму", который раздувает систему
4️⃣ Компания как система - это не только про технологии
- Nubank смотрит на себя как на целостную систему, где культура и люди не менее важны, чем код и кластеры
- Важно уметь масштабировать команды и процессы под глобальное развитие (новые рынки, разные регуляции, распределённые команды), а не просто "накидывать микросервисы"
- Витор упоминает Conway’s Law: как структура коммуникаций влияет на архитектуру, и почему без правильного оргдизайна хорошую архитектуру не получить
5️⃣ Generative AI - осторожный, прагматичный подход
- Nubank уже использует gen AU, но очень аккуратно: они не гонятся за хайпом, а ищут конкретные, измеримые проблемы, где ИИ реально улучшает эффективность
- У ребят есть отдельные бюджеты и команды, которые экспериментируют с AI-подходами в тестировании и других задачах, системно отсеивая то, что “не взлетает”.
- Главный фильтр: безопасность и приватность данных
6️⃣ Главная мысль выпуска примерно такая
Зрелый финтех строится не вокруг модной технологии, а вокруг
- Строгой инженерной дисциплины (тесты, стандарты, CD)
- Осознанных архитектурных решений (JVM-ядро, cloud-first, но с пониманием ограничений)
- Системного взгляда на организацию и культуру
- Осторожного, прагматичного внедрения AI, где безопасность и ценность важнее демонстраций "магии"
P.S.
Интересно потом будет сравнить эти тезисы Витора с выступлениями Eric Young, нового CTO, что вышел только в конце лета.
#Software #Engineering #Management #Architecture #Processes #SRE #DevOps #Leadership
Продолжая рассказ про Nubank, я хотел кратко изложить тезисы Витора Оливейра, который рассказывал про технологии в Nubank в подкасте "Hippsters Ponto Tech #459" (правда, подкаст на португальском) в апреле 2025 года, а уже в августе 2025 года его сменил Eric Young (экс-VP Engineering Snap, Google, Amazon), что, как по мне, дало ясный знак инвесторам на то, что Nubank готов масштабировать свою инженерную ветку для глобальной экспании, о которой было рассказано в предыдущем посте.
1️⃣ Тесты как “первая линия обороны” Nubank
- В Nubank большой фокус на тестировании: юнит-тесты, интеграционные, multi-service-тесты и эксперименты с genAI генерацией тестов
- Обоснование в том, что для крупного финтеха это не “nice to have”, а "must have", чтобы защитить чувствительные финансовые данные клиентов и держать высокую планку по стабильности, безопасности и приватности
2️⃣ Эволюция архитектуры: от JVM-стека к cloud-first
- Исторически Nubank строился вокруг JVM-стека (Clojure + Kafka), что задавало определённый стиль архитектуры и инженерной культуры (подробнее про историю можно глянуть в посте "10 years of engineering at Nubank")
- Сейчас у ребят стратегия cloud-first, но не "cloud at any cost": они осознанно балансируют между облаком и on-prem, учитывая три критерия: стоимость, контроль и сущность бизнеса
3️⃣ Ключевые инженерные принципы
Витор подчеркнул фундаментальные принципы, которые направляют технические решения
- Иммутабельность - immutable инфраструктура и сервисы
- Стандартизация - однообразие подходов вместо зоопарка технологий
- Continuous Delivery - непрерыная поставка и безопасные релизы
- Минимизация сложности - сознательное сопротивление "архитектурному энтузиазму", который раздувает систему
4️⃣ Компания как система - это не только про технологии
- Nubank смотрит на себя как на целостную систему, где культура и люди не менее важны, чем код и кластеры
- Важно уметь масштабировать команды и процессы под глобальное развитие (новые рынки, разные регуляции, распределённые команды), а не просто "накидывать микросервисы"
- Витор упоминает Conway’s Law: как структура коммуникаций влияет на архитектуру, и почему без правильного оргдизайна хорошую архитектуру не получить
5️⃣ Generative AI - осторожный, прагматичный подход
- Nubank уже использует gen AU, но очень аккуратно: они не гонятся за хайпом, а ищут конкретные, измеримые проблемы, где ИИ реально улучшает эффективность
- У ребят есть отдельные бюджеты и команды, которые экспериментируют с AI-подходами в тестировании и других задачах, системно отсеивая то, что “не взлетает”.
- Главный фильтр: безопасность и приватность данных
6️⃣ Главная мысль выпуска примерно такая
Зрелый финтех строится не вокруг модной технологии, а вокруг
- Строгой инженерной дисциплины (тесты, стандарты, CD)
- Осознанных архитектурных решений (JVM-ядро, cloud-first, но с пониманием ограничений)
- Системного взгляда на организацию и культуру
- Осторожного, прагматичного внедрения AI, где безопасность и ценность важнее демонстраций "магии"
P.S.
Интересно потом будет сравнить эти тезисы Витора с выступлениями Eric Young, нового CTO, что вышел только в конце лета.
#Software #Engineering #Management #Architecture #Processes #SRE #DevOps #Leadership
Telegram
Книжный куб
[1/2] Про Nubank (Рубрика #Business)
После изучения истории Lucas Cavalcant (distingueshed engineer @ Nubank) про развитие разработки в Nubank мне стало интересно, а какая у них глобальная стратегия и как IT поддерживает эту стратегию. В принципе, при текущем…
После изучения истории Lucas Cavalcant (distingueshed engineer @ Nubank) про развитие разработки в Nubank мне стало интересно, а какая у них глобальная стратегия и как IT поддерживает эту стратегию. В принципе, при текущем…
🔥5❤4👍1
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
Несколько дней назад были опубликованы результаты большого опроса про состояние 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
State of DevOps Russia 2025
Результаты масштабного исследования состояния DevOps в России. Полная версия отчета!
👍10❤5🔥3
Postcriptum State of Devops Russia 2025 (Рубрика #Devops)
Отдельно поделюсь заключительной частью этого отчета, в которой приведена цитата Димы Гаевского, моего друга и коллеги, который у нас отвечает за развитие нашей внутренней платформы разработки.
#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment
Отдельно поделюсь заключительной частью этого отчета, в которой приведена цитата Димы Гаевского, моего друга и коллеги, который у нас отвечает за развитие нашей внутренней платформы разработки.
Российский рынок ПО продолжает идти своим, местами парадоксальным путём: с одной стороны — жёсткое внешнее давление, с другой — необратимое взросление ИТ-ландшафта. В 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
Telegram
Книжный куб
State of Devops Russia 2025 (Рубрика #Devops)
Несколько дней назад были опубликованы результаты большого опроса про состояние DevOps в России. Наступили выходные, я его дочитал и решил написать тезисный разбор. Кстати, если этот разбор понравится, то можно…
Несколько дней назад были опубликованы результаты большого опроса про состояние DevOps в России. Наступили выходные, я его дочитал и решил написать тезисный разбор. Кстати, если этот разбор понравится, то можно…
👍10❤7🔥4
Atlassian покупает платформу DX (developer experience) за $1 млрд - причины и последствия (Рубрика #DevEx)
18 сентября 2025 года компания Atlassian официально объявила о приобретении платформы DX (Developer Experience) приблизительно за $1 млрд с оплатой наличными средствами и акциями Atlassian (крупнейшее поглощение в истории Atlassian). DX представляет собой платформу инженерной аналитики, которая позволяет организациям оценивать продуктивность команд разработки и выявлять "узкие места" в их процессах. Мне это поглощение интересно тем, что среди создателей DX есть авторы подходов DORA, SPACE, DevEx, про которые я много рассказывал.
Руководство Atlassian объясняет покупку DX стратегическим стремлением помочь своим клиентам эффективнее использовать инвестиции в ИИ и улучшить работу инженерных команд. Компания отмечает, что всё больше предприятий вкладываются в инструменты искусственного интеллекта, но сталкиваются с вопросом, приносят ли эти вложения реальную отдачу в ускорении разработки (DX недавно опубликовали методологию "Measuring AI code assistants and agents")
Дополнительным обоснованием сделки стал синергетический эффект: около 90% клиентов DX уже используют продукты Atlassian (Jira, Confluence, Bitbucket и др.), что сделало DX очевидным кандидатом для присоединения. Кэннон-Брукс, соучредитель и CEO Atlassian, отмечал, что Atlassian несколько лет пыталась создать собственный инструмент для анализа продуктивности инженеров, однако в итоге решила приобрести готовое решение (сам стартап DX был основан 5 лет назад)
Atlassian планирует глубоко интегрировать DX в свою экосистему. В октябре 2025 года CTO Atlassian представил новый комплект Atlassian Software Collection, куда DX вошла в качестве новейшего компонента: платформа DX дополняет существующие решения, объединяя качественные опросы разработчиков с количественными метриками такими, как время прохождения pull request, частота сбоев сборки и уровень использования AI-инструментов. Данные DX будут напрямую доступны в продуктах Atlassian, а также DX продолжит поддерживать интеграции и с сторонними инструментами, чтобы клиенты могли извлекать пользу из DX независимо от стека Atlassian.
В будущем пользователям Atlassian станут доступны следующие возможности благодаря интеграции DX
- Измерение продуктивности и узких мест: система автоматически собирает ключевые показатели развития софта (скорость цикла код-ревью, частоту неудачных билдов, время внедрения фич) и выявляет узкие места в процессе
- Аналитика использования ИИ: DX позволяет отслеживать, как активно и с каким эффектом разработчики применяют AI-инструменты (код-ассистентов, агентов и пр.), отсекая шум и показывая реальную отдачу от AI-внедрений.
- Оценка опыта разработчиков: Помимо технических метрик, DX регулярно собирает качественные данные об опыте инженеров (опросы удовлетворённости, индексы Developer Experience). Совмещая цифры с мнением самих разработчиков, платформа определяет, что мешает людям работать продуктивно, и где возникают точки напряжения в взаимодействии команд
В целом, покупка DX сигнализирует о появлении в линейке Atlassian нового класса функций - “инженерной аналитики” - благодаря которому разработчики и менеджеры смогут совместно измерять и улучшать продуктивность, основываясь на данных, а не интуиции. Atlassian позиционирует этот шаг как часть более широкой стратегии по созданию интегрированной платформы для управления разработкой в эпоху ИИ, где связаны воедино планирование (Jira/Confluence), выполнение (код и CI/CD) и анализ эффективности (DX) для непрерывного совершенствования процесса создания софта
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
18 сентября 2025 года компания Atlassian официально объявила о приобретении платформы DX (Developer Experience) приблизительно за $1 млрд с оплатой наличными средствами и акциями Atlassian (крупнейшее поглощение в истории Atlassian). DX представляет собой платформу инженерной аналитики, которая позволяет организациям оценивать продуктивность команд разработки и выявлять "узкие места" в их процессах. Мне это поглощение интересно тем, что среди создателей DX есть авторы подходов DORA, SPACE, DevEx, про которые я много рассказывал.
Руководство Atlassian объясняет покупку DX стратегическим стремлением помочь своим клиентам эффективнее использовать инвестиции в ИИ и улучшить работу инженерных команд. Компания отмечает, что всё больше предприятий вкладываются в инструменты искусственного интеллекта, но сталкиваются с вопросом, приносят ли эти вложения реальную отдачу в ускорении разработки (DX недавно опубликовали методологию "Measuring AI code assistants and agents")
Дополнительным обоснованием сделки стал синергетический эффект: около 90% клиентов DX уже используют продукты Atlassian (Jira, Confluence, Bitbucket и др.), что сделало DX очевидным кандидатом для присоединения. Кэннон-Брукс, соучредитель и CEO Atlassian, отмечал, что Atlassian несколько лет пыталась создать собственный инструмент для анализа продуктивности инженеров, однако в итоге решила приобрести готовое решение (сам стартап DX был основан 5 лет назад)
Atlassian планирует глубоко интегрировать DX в свою экосистему. В октябре 2025 года CTO Atlassian представил новый комплект Atlassian Software Collection, куда DX вошла в качестве новейшего компонента: платформа DX дополняет существующие решения, объединяя качественные опросы разработчиков с количественными метриками такими, как время прохождения pull request, частота сбоев сборки и уровень использования AI-инструментов. Данные DX будут напрямую доступны в продуктах Atlassian, а также DX продолжит поддерживать интеграции и с сторонними инструментами, чтобы клиенты могли извлекать пользу из DX независимо от стека Atlassian.
В будущем пользователям Atlassian станут доступны следующие возможности благодаря интеграции DX
- Измерение продуктивности и узких мест: система автоматически собирает ключевые показатели развития софта (скорость цикла код-ревью, частоту неудачных билдов, время внедрения фич) и выявляет узкие места в процессе
- Аналитика использования ИИ: DX позволяет отслеживать, как активно и с каким эффектом разработчики применяют AI-инструменты (код-ассистентов, агентов и пр.), отсекая шум и показывая реальную отдачу от AI-внедрений.
- Оценка опыта разработчиков: Помимо технических метрик, DX регулярно собирает качественные данные об опыте инженеров (опросы удовлетворённости, индексы Developer Experience). Совмещая цифры с мнением самих разработчиков, платформа определяет, что мешает людям работать продуктивно, и где возникают точки напряжения в взаимодействии команд
В целом, покупка DX сигнализирует о появлении в линейке Atlassian нового класса функций - “инженерной аналитики” - благодаря которому разработчики и менеджеры смогут совместно измерять и улучшать продуктивность, основываясь на данных, а не интуиции. Atlassian позиционирует этот шаг как часть более широкой стратегии по созданию интегрированной платформы для управления разработкой в эпоху ИИ, где связаны воедино планирование (Jira/Confluence), выполнение (код и CI/CD) и анализ эффективности (DX) для непрерывного совершенствования процесса создания софта
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
TechCrunch
Atlassian acquires DX, a developer productivity platform, for $1B | TechCrunch
Atlassian is making its largest acquisition yet by buying DX so it can offer a developer productivity tool.
❤5🔥5🤯2⚡1
The Infinite Software Crisis (Рубрика #AI)
Посмотрел на выходных интересный доклад Джейка Нэйшнса (Jake Nations), staff engineer из Netflix. Джейк занимается встраиванием AI инструментов в процессы разработки в Netflix, а в этом докладе он делится трезвым взглядом инженера о том, как генеративный код ломает архитектуру. Если говорить про ключевые тезисы, то они такие
1️⃣ Бесконечный кризис софта
Исторически (от Дейкстры в 60-х до Cloud Native) каждый новый инструмент обещал решить проблему сложности, но лишь позволял нам строить еще более запутанные системы. AI просто разогнал этот процесс до предела.
2️⃣ Vibe Coding => Tech Debt
Разработка через чат-интерфейс (conversational interface) - это ловушка. Архитектура начинает зеркалить вашу беседу: каждое уточнение "а поправь еще это" наслаивается поверх предыдущего, создавая спагетти-код с мертвыми ветками логики. Интересно, что я сейчас пробую разрабатывать в Lovable и вижу как мои запросы приводят к появлению архитектуры (правда, я еще и в привязанном GitHub вижу как и какой код появляется)
3️⃣ Simple vs Easy
Джейк цитирует Рича Хики:
- Easy - это то, что под рукой: скопировать со StackOverflow или попросить AI сгенерить портянку кода
- Simple - это отсутствие переплетений (entanglement)
AI делает часть про "easy" почти бесплатным, но убивает "simple", так как агенты не умеют отличать "существенную" сложность задачи от "случайной" (наследия костылей)
4️⃣ Решение что предлагает Джейк
Использовать трёхфазный метод, чтобы не утонуть в хаосе, нужно вернуть инженерную строгость и разделить процесс:
- Research. Скормить агенту доки и диаграммы, чтобы он составил карту системы. Обязательно вычитать и поправить вручную
- Planning. Написать спецификацию изменений (вплоть до сигнатур функций). План должен быть настолько детальным, чтобы джун мог реализовать его механически (paint-by-numbers).
- Implementation. Только теперь запускать генерацию. Вы ревьюите соответствие плану, а не пытаетесь угадать, что там нафантазировал AI.
Если подумать об этом, то мы входим в эпоху, где написание кода стоит примерно 0. И главным дефицитом становится понимание системы (context & understanding). Если раньше вы могли "прочитать" код и понять, как он работает, то в мире, где джун генерирует 10к строк за вечер, это становится невозможным. Техлидам придется сместить фокус с код-ревью на дизайн-ревью и валидацию планов. Те, кто продолжит просто "чатиться с кодом", скоро обнаружат у себя в проде системы, которые невозможно поддерживать и безопасно изменять.
В докладе Джейк опирается на классику Software Engineering, которую стоит перечитать:
- Fred Brooks, "No Silver Bullet" (1986)
- Rich Hickey, "Simple Made Easy" (2011)
- Edsger W. Dijkstra, "The Humble Programmer" (1972)
#DevOps #AI #Architecture #Culture #Engineering #ML #Future #Software
Посмотрел на выходных интересный доклад Джейка Нэйшнса (Jake Nations), staff engineer из Netflix. Джейк занимается встраиванием AI инструментов в процессы разработки в Netflix, а в этом докладе он делится трезвым взглядом инженера о том, как генеративный код ломает архитектуру. Если говорить про ключевые тезисы, то они такие
1️⃣ Бесконечный кризис софта
Исторически (от Дейкстры в 60-х до Cloud Native) каждый новый инструмент обещал решить проблему сложности, но лишь позволял нам строить еще более запутанные системы. AI просто разогнал этот процесс до предела.
2️⃣ Vibe Coding => Tech Debt
Разработка через чат-интерфейс (conversational interface) - это ловушка. Архитектура начинает зеркалить вашу беседу: каждое уточнение "а поправь еще это" наслаивается поверх предыдущего, создавая спагетти-код с мертвыми ветками логики. Интересно, что я сейчас пробую разрабатывать в Lovable и вижу как мои запросы приводят к появлению архитектуры (правда, я еще и в привязанном GitHub вижу как и какой код появляется)
3️⃣ Simple vs Easy
Джейк цитирует Рича Хики:
- Easy - это то, что под рукой: скопировать со StackOverflow или попросить AI сгенерить портянку кода
- Simple - это отсутствие переплетений (entanglement)
AI делает часть про "easy" почти бесплатным, но убивает "simple", так как агенты не умеют отличать "существенную" сложность задачи от "случайной" (наследия костылей)
4️⃣ Решение что предлагает Джейк
Использовать трёхфазный метод, чтобы не утонуть в хаосе, нужно вернуть инженерную строгость и разделить процесс:
- Research. Скормить агенту доки и диаграммы, чтобы он составил карту системы. Обязательно вычитать и поправить вручную
- Planning. Написать спецификацию изменений (вплоть до сигнатур функций). План должен быть настолько детальным, чтобы джун мог реализовать его механически (paint-by-numbers).
- Implementation. Только теперь запускать генерацию. Вы ревьюите соответствие плану, а не пытаетесь угадать, что там нафантазировал AI.
Если подумать об этом, то мы входим в эпоху, где написание кода стоит примерно 0. И главным дефицитом становится понимание системы (context & understanding). Если раньше вы могли "прочитать" код и понять, как он работает, то в мире, где джун генерирует 10к строк за вечер, это становится невозможным. Техлидам придется сместить фокус с код-ревью на дизайн-ревью и валидацию планов. Те, кто продолжит просто "чатиться с кодом", скоро обнаружат у себя в проде системы, которые невозможно поддерживать и безопасно изменять.
В докладе Джейк опирается на классику Software Engineering, которую стоит перечитать:
- Fred Brooks, "No Silver Bullet" (1986)
- Rich Hickey, "Simple Made Easy" (2011)
- Edsger W. Dijkstra, "The Humble Programmer" (1972)
#DevOps #AI #Architecture #Culture #Engineering #ML #Future #Software
YouTube
The Infinite Software Crisis – Jake Nations, Netflix
In 1968, the term ""Software Crisis"" emerged when systems grew beyond what developers could manage. Every generation since has ""solved"" it with more powerful tools, only to create even bigger problems.
Today, AI accelerates the pattern into the Infinite…
Today, AI accelerates the pattern into the Infinite…
👍24❤10🔥6🥱1
DORA 2025 - State of AI-assisted Software Development - Общая информация по отчету (Рубрика #Devops)
Я уже как-то кратко рассказывал про исследование "DORA Research: 2025" в одном из прошлых постов. Тогда я внимательно прочитал отчет, но тогда рассказал про его результаты очень кратко. А сейчас мне потребовался более подробный разбор для нашего исследования влияния AI на инженерную культуру и я решил расписать его и для своих подписчиков.
Отчет “State of AI-assisted Software Development 2025” подготовлен исследовательской командой программы DORA (DevOps Research and Assessment), что является частью Google Cloud. Ведущими авторами стали специалисты Google Cloud при участии приглашенных экспертов. Партнерами исследования были IT Revolution, GitHub, GitLab, SkillBench и Workhelix. Кроме того инициативу поддержал ряд спонсоров (Swarmia, Thoughtworks, Deloitte, Atlassian и др.).
В рамках исследования был проведен глобальный опрос почти 5 000 технических специалистов из разных стран и компаний. Респонденты включали инженеров-разработчиков, DevOps/SRE, тимлидов, продакт-менеджеров. Опрос охватил широкий спектр тем: от степени и способов использования ИИ (какие инструменты и LLM-модели применяются, для каких задач, сколько времени тратится, как часто доверяют советам ИИ) до характеристик команд и процессов (архитектура и платформы разработки, культура обучения, Value Stream Management, практики контроля версий, размер батчей изменений и т.п.). Также оценивались результаты работы команд: классические метрики DORA (например, скорость доставки и стабильность выпуска ПО), качество кода, продуктивность разработчиков, частота фрикций в работе и выгорание сотрудников. Для углубления анализа исследователи собрали и более 100 часов качественных данных – интервью и разборов практик, чтобы дополнить цифры живыми инсайтами.
Интересно, что полгода назад я рассказывал про то, как работает методология DORA для составления таких отчетов, но для отчета 2025 авторы отдельно описали "Measurement Framework" и то, как это можно использовать для управления изменениями в своей компании. Если же говорить про самих ребят и их отчет DORA 2025, то обработка данных сочетала статистические и аналитические методы. Масштабный опрос позволил провести корреляционный анализ и регрессионные модели, выявляя взаимосвязи между практиками и итоговыми показателями эффективности.
В итоге, получился отчет состоящий из следующих частей
- "Beyond the tools": обсуждается, почему успешное внедрение ИИ – это системная задача, а не просто выбор инструмента.
- Анализ текущего состояния AI-assisted разработки: представлены результаты опроса об уровне адаптации ИИ в индустрии, о практиках использования и влиянии на ключевые показатели.
- "Understanding your teams: 7 profiles": в этом разделе DORA представляет обнаруженные семь архетипов команд разработки
- "DORA AI Capabilities Model": центральная глава, вводящая новую модель способностей для успеха с ИИ. Здесь подробно перечисляются семь технических и культурных практик (системных факторов), которые статистически усиливают положительное влияние ИИ на эффективность команд
- "Directing AI’s potential": раздел, посвященный тому, как направить усилия по внедрению ИИ в правильное русло. В частности, разбирается роль Value Stream Management (VSM) как механизма, позволяющего конвертировать локальные улучшения от ИИ в конечный результат для бизнеса
- Рекомендации и выводы для лидеров: заключительная часть отчета переводит результаты в практическую плоскость. Здесь дается “дорожная карта” для внедрения ИИ – на каких направлениях сфокусироваться в первую очередь. В отчете прямо говорится, что руководители должны рассматривать внедрение AI как трансформацию организации, а не просто ИТ-проект
P.S.
В комментариях приложу сам PDF с отчетом.
#AI #Software #Engineering #Management #Whitepaper
Я уже как-то кратко рассказывал про исследование "DORA Research: 2025" в одном из прошлых постов. Тогда я внимательно прочитал отчет, но тогда рассказал про его результаты очень кратко. А сейчас мне потребовался более подробный разбор для нашего исследования влияния AI на инженерную культуру и я решил расписать его и для своих подписчиков.
Отчет “State of AI-assisted Software Development 2025” подготовлен исследовательской командой программы DORA (DevOps Research and Assessment), что является частью Google Cloud. Ведущими авторами стали специалисты Google Cloud при участии приглашенных экспертов. Партнерами исследования были IT Revolution, GitHub, GitLab, SkillBench и Workhelix. Кроме того инициативу поддержал ряд спонсоров (Swarmia, Thoughtworks, Deloitte, Atlassian и др.).
В рамках исследования был проведен глобальный опрос почти 5 000 технических специалистов из разных стран и компаний. Респонденты включали инженеров-разработчиков, DevOps/SRE, тимлидов, продакт-менеджеров. Опрос охватил широкий спектр тем: от степени и способов использования ИИ (какие инструменты и LLM-модели применяются, для каких задач, сколько времени тратится, как часто доверяют советам ИИ) до характеристик команд и процессов (архитектура и платформы разработки, культура обучения, Value Stream Management, практики контроля версий, размер батчей изменений и т.п.). Также оценивались результаты работы команд: классические метрики DORA (например, скорость доставки и стабильность выпуска ПО), качество кода, продуктивность разработчиков, частота фрикций в работе и выгорание сотрудников. Для углубления анализа исследователи собрали и более 100 часов качественных данных – интервью и разборов практик, чтобы дополнить цифры живыми инсайтами.
Интересно, что полгода назад я рассказывал про то, как работает методология DORA для составления таких отчетов, но для отчета 2025 авторы отдельно описали "Measurement Framework" и то, как это можно использовать для управления изменениями в своей компании. Если же говорить про самих ребят и их отчет DORA 2025, то обработка данных сочетала статистические и аналитические методы. Масштабный опрос позволил провести корреляционный анализ и регрессионные модели, выявляя взаимосвязи между практиками и итоговыми показателями эффективности.
В итоге, получился отчет состоящий из следующих частей
- "Beyond the tools": обсуждается, почему успешное внедрение ИИ – это системная задача, а не просто выбор инструмента.
- Анализ текущего состояния AI-assisted разработки: представлены результаты опроса об уровне адаптации ИИ в индустрии, о практиках использования и влиянии на ключевые показатели.
- "Understanding your teams: 7 profiles": в этом разделе DORA представляет обнаруженные семь архетипов команд разработки
- "DORA AI Capabilities Model": центральная глава, вводящая новую модель способностей для успеха с ИИ. Здесь подробно перечисляются семь технических и культурных практик (системных факторов), которые статистически усиливают положительное влияние ИИ на эффективность команд
- "Directing AI’s potential": раздел, посвященный тому, как направить усилия по внедрению ИИ в правильное русло. В частности, разбирается роль Value Stream Management (VSM) как механизма, позволяющего конвертировать локальные улучшения от ИИ в конечный результат для бизнеса
- Рекомендации и выводы для лидеров: заключительная часть отчета переводит результаты в практическую плоскость. Здесь дается “дорожная карта” для внедрения ИИ – на каких направлениях сфокусироваться в первую очередь. В отчете прямо говорится, что руководители должны рассматривать внедрение AI как трансформацию организации, а не просто ИТ-проект
P.S.
В комментариях приложу сам PDF с отчетом.
#AI #Software #Engineering #Management #Whitepaper
dora.dev
DORA | State of AI-assisted Software Development 2025
DORA is a long running research program that seeks to understand the capabilities that drive software delivery and operations performance. DORA helps teams apply those capabilities, leading to better organizational performance.
❤10👍3🔥3
[1/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики в сфере технологий. Этот опрос проводился среди читателей рассылки "The Pragmatic Engineer" в апреле–мае 2025, причем в нем приняли участие 3k инженеров. Респондентами преимущественно являются инженеры-разработчики софта причем из компаний всех масштабов (от стартапа до бигтехов), причем так получилось, что половина работала в мелких и половина в крупных компаниях. Следует отметить, что выборка не случайна, а основана на подписчиках технического блога, поэтому она может смещаться в сторону продуктовых IT-компаний. Например, среди читателей заметно выше доля пользователей AWS и ниже - Azure по сравнению с традиционными корпоративными сегментами. В целом же охват опроса по ролям и компаниям очень широк, что даёт основание доверять тенденциям, выявленным в данных.
Результаты Гергели оформил в трех частях, каждая из которых посвящена определённым категориям инструментов разработки. Вот эти три части
1️⃣ Часть
Демография респондентов; использование AI-инструментов; наиболее используемые и любимые языки программирования; рейтинг самых нелюбимых и самых любимых инструментов; среды разработки (IDE) и терминалы; системы контроля версий и CI/CD; облачные платформы (IaaS/PaaS)
2️⃣ Часть
Наиболее часто упоминаемые инструменты (лидируют JIRA, VS Code и AWS); средства управления проектами; инструменты коммуникации и совместной работы (Slack, MS Teams, Confluence, Miro, Figma); базы данных и хранилища (PostgreSQL и мн. др.); бекенд-инфраструктура (Docker, Kubernetes, Terraform, облачные сервисы); балансировщики нагрузки; а также
3️⃣ Часть
Средства наблюдаемости, мониторинга и логирования; инструменты для дежурств и управления инцидентами; системы feature flags, аналитики и экспериментов; инструменты фронтенд- и мобильной разработки; различные утилиты для разработчиков; собственные (custom) внутренние инструменты команд; и нишевые любимые инструменты энтузиастов
Среди ключевых результатов можно выделить следующие
🤖 Широкое внедрение ИИ-инструментов
85% опрошенных инженеров используют в работе хотя бы один инструмент с элементами AI, например кодового помощника. Каждый второй респондент применяет GitHub Copilot – этот AI-помощник для программирования стал самым популярным средством из своего класса. Лишь около 4% принципиально не пользуются AI (по причинам корпоративного запрета, неэффективности или этических убеждений), что подчёркивает массовое проникновение данных технологий в разработку.
🐍 Популярные языки программирования
TypeScript вышел на первое место по частоте использования среди языков разработки (ожидаемо, учитывая его применение и в фронтенде, и в бекенде). Широко распространены также Python, JavaScript, Java, C# и другие языки, при этом все основные языковые экосистемы оцениваются разработчиками положительно - ни один язык не получил значимого перевеса негатива в отзывах. Это говорит о зрелости современных языков: откровенно "плохие" решения попросту не становятся массовыми. В топ-10 самых любимых языков неожиданно вошёл даже нишевый Elixir, а фреймворк Ruby on Rails оказался одновременно 5-м по использованию и 3-м по любви, что подчёркивает лояльность его сообщества (чтобы понять любовь к нему можно глянуть документалку про RoR)
Продолжение в следующем посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики в сфере технологий. Этот опрос проводился среди читателей рассылки "The Pragmatic Engineer" в апреле–мае 2025, причем в нем приняли участие 3k инженеров. Респондентами преимущественно являются инженеры-разработчики софта причем из компаний всех масштабов (от стартапа до бигтехов), причем так получилось, что половина работала в мелких и половина в крупных компаниях. Следует отметить, что выборка не случайна, а основана на подписчиках технического блога, поэтому она может смещаться в сторону продуктовых IT-компаний. Например, среди читателей заметно выше доля пользователей AWS и ниже - Azure по сравнению с традиционными корпоративными сегментами. В целом же охват опроса по ролям и компаниям очень широк, что даёт основание доверять тенденциям, выявленным в данных.
Результаты Гергели оформил в трех частях, каждая из которых посвящена определённым категориям инструментов разработки. Вот эти три части
1️⃣ Часть
Демография респондентов; использование AI-инструментов; наиболее используемые и любимые языки программирования; рейтинг самых нелюбимых и самых любимых инструментов; среды разработки (IDE) и терминалы; системы контроля версий и CI/CD; облачные платформы (IaaS/PaaS)
2️⃣ Часть
Наиболее часто упоминаемые инструменты (лидируют JIRA, VS Code и AWS); средства управления проектами; инструменты коммуникации и совместной работы (Slack, MS Teams, Confluence, Miro, Figma); базы данных и хранилища (PostgreSQL и мн. др.); бекенд-инфраструктура (Docker, Kubernetes, Terraform, облачные сервисы); балансировщики нагрузки; а также
3️⃣ Часть
Средства наблюдаемости, мониторинга и логирования; инструменты для дежурств и управления инцидентами; системы feature flags, аналитики и экспериментов; инструменты фронтенд- и мобильной разработки; различные утилиты для разработчиков; собственные (custom) внутренние инструменты команд; и нишевые любимые инструменты энтузиастов
Среди ключевых результатов можно выделить следующие
85% опрошенных инженеров используют в работе хотя бы один инструмент с элементами AI, например кодового помощника. Каждый второй респондент применяет GitHub Copilot – этот AI-помощник для программирования стал самым популярным средством из своего класса. Лишь около 4% принципиально не пользуются AI (по причинам корпоративного запрета, неэффективности или этических убеждений), что подчёркивает массовое проникновение данных технологий в разработку.
TypeScript вышел на первое место по частоте использования среди языков разработки (ожидаемо, учитывая его применение и в фронтенде, и в бекенде). Широко распространены также Python, JavaScript, Java, C# и другие языки, при этом все основные языковые экосистемы оцениваются разработчиками положительно - ни один язык не получил значимого перевеса негатива в отзывах. Это говорит о зрелости современных языков: откровенно "плохие" решения попросту не становятся массовыми. В топ-10 самых любимых языков неожиданно вошёл даже нишевый Elixir, а фреймворк Ruby on Rails оказался одновременно 5-м по использованию и 3-м по любви, что подчёркивает лояльность его сообщества (чтобы понять любовь к нему можно глянуть документалку про RoR)
Продолжение в следующем посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Pragmaticengineer
The Pragmatic Engineer 2025 Survey: What’s in your tech stack? Part 1
Which tools do software engineers use for backend development, frontend, infrastructure, AI tooling, and more, today? Reader survey, with feedback and analysis, based on 3,000+ responses
❤5🔥2⚡1
Применение AI и LLM в разработке и управлении (Рубрика #AI)
Посмотрел на неделе выступление Александра Лукьянченко с конференции AvitoTechConf 2025, которую я посетил очно (но провел большую часть времени не за просмотром докладов, а общаясь со знакомыми и обсуждая примерно те же темы, но более открыто). Если же возвращаться к докладу Саши, то он поделился цифрами о том, как AI реально работает в процессах разработки внутри Авито. Сам Саша руководит разработкой PaaS внутри компании и его команда отвечает за эффективность 2000+ инженеров, внутренние инструменты, облако и SDLC.
Основные тезисы доклада примерно такие
⌨️ Кодинг - это не вся работа
Непосредственное написание кода занимает всего 20–40% времени инженера. Остальное - это коммуникация, дизайн систем, ревью и "археология" (разбор чужого кода). AI должен помогать именно здесь, а не только дописывать строки. Есть и другие сценарии, например
🗺 Авто-картирование архитектуры
В микросервисной архитектуре сложно понять, кто за что отвечает. В Avito использовали LLM, чтобы проанализировать код, API и README всех сервисов и разложить их по доменам.
Результат: Автоматика совпала с ручной разметкой экспертов на 80%. Сэкономлено ~200 человеко-дней ручной работы архитекторов.
☠️ Анализ постмортемов
Скормили LLM базу из 800+ инцидентов (postmortems). Модель нашла 22 системных паттерна проблем, которые не видели люди, и предложила сценарии для Chaos Engineering. Это позволило закрыть >1000 потенциальных уязвимостей.
⚙️ Эволюция инструментов
Ребята в индустрии переходят от фазы Copilot (автодополнение) к фазе Agents (автономное выполнение задач). В топе сейчас инструменты вроде Cline, Roo Code и режимы агентов в IDE, которые могут сами "ходить" по проекту и править файлы.
Что это значит для индустрии
1. Ощущение продуктивности обманчиво. Инженеры часто чувствуют, что стали работать быстрее с AI, но метрики говорят об обратном (особенно исследование METR на 16 инженеров, которое я разбирал). Если AI пишет много кода, который потом нужно долго дебажить - это не ускорение, а генерация техдолга.
2. Greenfield vs Brownfield. AI отлично бустит старт новых проектов (до 30-40%), но на старых, сложных легаси-проектах ("brownfield") прирост продуктивности падает до 0–10%, а иногда становится отрицательным из-за rework.
3. Сдвиг фокуса. Главная ценность AI сейчас не в написании кода, а в снижении когнитивной нагрузки (быстрый поиск по доке, саммари бесконечных тредов в Slack, объяснение легаси).
P.S.
Саша делал отсылку к исследованию Stanford на 120k инженеров. Недавно Егор Денисов-Бланш (Yegor Denisov-Blanch) рассказывал новый доклад "Can you prove AI ROI in Software Engineering?" на эту тему на AI Engineer кофне и я его уже разбирал, там много интересного, рекомендую к просмотру.
#AI #DevOps #Engineering #Management #Leadership #Software #Architecture #SRE
Посмотрел на неделе выступление Александра Лукьянченко с конференции AvitoTechConf 2025, которую я посетил очно (но провел большую часть времени не за просмотром докладов, а общаясь со знакомыми и обсуждая примерно те же темы, но более открыто). Если же возвращаться к докладу Саши, то он поделился цифрами о том, как AI реально работает в процессах разработки внутри Авито. Сам Саша руководит разработкой PaaS внутри компании и его команда отвечает за эффективность 2000+ инженеров, внутренние инструменты, облако и SDLC.
Основные тезисы доклада примерно такие
Непосредственное написание кода занимает всего 20–40% времени инженера. Остальное - это коммуникация, дизайн систем, ревью и "археология" (разбор чужого кода). AI должен помогать именно здесь, а не только дописывать строки. Есть и другие сценарии, например
В микросервисной архитектуре сложно понять, кто за что отвечает. В Avito использовали LLM, чтобы проанализировать код, API и README всех сервисов и разложить их по доменам.
Результат: Автоматика совпала с ручной разметкой экспертов на 80%. Сэкономлено ~200 человеко-дней ручной работы архитекторов.
Скормили LLM базу из 800+ инцидентов (postmortems). Модель нашла 22 системных паттерна проблем, которые не видели люди, и предложила сценарии для Chaos Engineering. Это позволило закрыть >1000 потенциальных уязвимостей.
Ребята в индустрии переходят от фазы Copilot (автодополнение) к фазе Agents (автономное выполнение задач). В топе сейчас инструменты вроде Cline, Roo Code и режимы агентов в IDE, которые могут сами "ходить" по проекту и править файлы.
Что это значит для индустрии
1. Ощущение продуктивности обманчиво. Инженеры часто чувствуют, что стали работать быстрее с AI, но метрики говорят об обратном (особенно исследование METR на 16 инженеров, которое я разбирал). Если AI пишет много кода, который потом нужно долго дебажить - это не ускорение, а генерация техдолга.
2. Greenfield vs Brownfield. AI отлично бустит старт новых проектов (до 30-40%), но на старых, сложных легаси-проектах ("brownfield") прирост продуктивности падает до 0–10%, а иногда становится отрицательным из-за rework.
3. Сдвиг фокуса. Главная ценность AI сейчас не в написании кода, а в снижении когнитивной нагрузки (быстрый поиск по доке, саммари бесконечных тредов в Slack, объяснение легаси).
P.S.
Саша делал отсылку к исследованию Stanford на 120k инженеров. Недавно Егор Денисов-Бланш (Yegor Denisov-Blanch) рассказывал новый доклад "Can you prove AI ROI in Software Engineering?" на эту тему на AI Engineer кофне и я его уже разбирал, там много интересного, рекомендую к просмотру.
#AI #DevOps #Engineering #Management #Leadership #Software #Architecture #SRE
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Применение AI и LLM в разработке и управлении | Александр Лукьянченко. AvitoTechConf 2025
GenAI инструменты позволяют решать и ускорять многие задачи, которые раньше было сложно автоматизировать. Мы часто слышим как AI заменяет целый класс задач в разработке, что инструменты вида Cursor сильно ускоряют вывод продуктов на рынок. Но как выглядит…
2👍16❤8🔥3👏1🤩1
[2/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Продолжая рассказ про опрос Гергели, рассмотрим оставшиеся темы
❤🔥 Инструменты разработки: любовь и ненависть
Список самых часто используемых инструментов возглавил неожиданно JIRA (чаще даже VS Code или AWS). Парадоксально, но JIRA же стал и самым ненавидимым инструментом (разработчики не любят JIRA за медлительность и громоздкость), а вот более лёгкий конкурент, Linear, напротив, попал в число самых любимых инструментов (№4) и рассматривается инженерами как желанная замена JIRA. В целом, два этих инструмента сейчас доминируют в управлении проектами (вместе 75% упоминаний project management инструментов). JIRA в крупных компаниях, а Linear в малых.
✈ Командная коммуникация и сотрудничество
Среди средств коммуникации лидируют проверенные решения: Slack - самый используемый чат для разработки, а Microsoft Teams - наиболее распространён для видеозвонков. Для хранения документации чаще всего применяют Confluence, для совместного brainstorming - онлайн-доску Miro, а для дизайна интерфейсов - Figma. Примечательно, что Figma упоминалась разработчиками даже чаще, чем такой профильный инструмент, как K8s. Это свидетельствует о глубоком вовлечении команд разработки в процесс проектирования UX/UI и тесной междисциплинарной работе с дизайнерами.
😶🌫️ Облачные платформы
В облачной инфраструктуре опрос подтвердил безусловное лидерство Amazon Web Services (AWS) - эту платформу используют ~44% респондентов, тогда как у ближайшего преследователя, Microsoft Azure, ~30%. Доля Google Cloud Platform составляет оставшиеся ~26%.
🐘 Инфраструктура и базы данных
Практически повсеместно используются контейнеры Docker и оркестратор K8s - де-факто стандарт развёртывания приложений. Для управления инфраструктурой как кодом лидирует Terraform. Кроме того, широко востребованы управляемые облачные сервисы (например, от AWS) для типовых задач backend. Что касается хранения данных, опрос показал безоговорочную популярность PostgreSQL (1/3 респондентов упоминало ее). Тем не менее, выбор технологий хранения невероятно разнообразен: профессионалы упомянули десятки разных баз данных (SQL, NoSQL, NewSQL, специализированные хранилища и т. д.). Это говорит о том, что современный стек данных очень неоднороден, и команды подбирают БД строго под свои задачи.
♾️ Мониторинг и надежность (DevOps)
В сфере observability данных наиболее популярны платформы Datadog, Grafana и Sentry - каждая из них используется примерно у 15-25% участников опроса. Эти инструменты (соответственно, облачный сервис мониторинга, open-source система дашбордов и сервис отслеживания ошибок) стали привычной частью инфраструктуры многих команд. Для оповещений и реагирования на инциденты подавляющее число инженеров применяют классические решения PagerDuty и OpsGenie.
📱 Фронтенд и мобильные технологии
Здесь наблюдается большая консолидация вокруг нескольких фреймворков. React практически без конкурентов доминирует как основной фронтенд-фреймворк (упоминается большинством веб-разработчиков), а Next.js стал самым популярным "мета"-фреймворком для React-приложений. Для мобильной разработки кроссплатформенно лидирует React Native - опрошенные отмечают его гораздо чаще любых альтернатив. Иными словами, стек фронтенда в 2025 году у большинства команд выглядит схоже. На бекенде разброс решений больше, но и там многие используют единый стек на TypeScript/Node.js либо популярные фреймворки вроде .NET и Spring.
🎌 Feature flags и внутренние инструменты
Практика feature flags и a/b тестирования прочно вошла в жизнь: для этого многие используют готовые сервисы, главным из которых является LaunchDarkly. Тем не менее, опрос показал, что весьма часто компании создают собственные системы фичефлагов, платформы экспериментов и кастомные конвейеры деплоя. Это может указывать на то, что существующие продукты не полностью покрывают нужды команд, либо на желание сэкономить на лицензиях, либо на требования безопасности.
Выводы из исследования в финальном посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Продолжая рассказ про опрос Гергели, рассмотрим оставшиеся темы
Список самых часто используемых инструментов возглавил неожиданно JIRA (чаще даже VS Code или AWS). Парадоксально, но JIRA же стал и самым ненавидимым инструментом (разработчики не любят JIRA за медлительность и громоздкость), а вот более лёгкий конкурент, Linear, напротив, попал в число самых любимых инструментов (№4) и рассматривается инженерами как желанная замена JIRA. В целом, два этих инструмента сейчас доминируют в управлении проектами (вместе 75% упоминаний project management инструментов). JIRA в крупных компаниях, а Linear в малых.
Среди средств коммуникации лидируют проверенные решения: Slack - самый используемый чат для разработки, а Microsoft Teams - наиболее распространён для видеозвонков. Для хранения документации чаще всего применяют Confluence, для совместного brainstorming - онлайн-доску Miro, а для дизайна интерфейсов - Figma. Примечательно, что Figma упоминалась разработчиками даже чаще, чем такой профильный инструмент, как K8s. Это свидетельствует о глубоком вовлечении команд разработки в процесс проектирования UX/UI и тесной междисциплинарной работе с дизайнерами.
😶🌫️ Облачные платформы
В облачной инфраструктуре опрос подтвердил безусловное лидерство Amazon Web Services (AWS) - эту платформу используют ~44% респондентов, тогда как у ближайшего преследователя, Microsoft Azure, ~30%. Доля Google Cloud Platform составляет оставшиеся ~26%.
Практически повсеместно используются контейнеры Docker и оркестратор K8s - де-факто стандарт развёртывания приложений. Для управления инфраструктурой как кодом лидирует Terraform. Кроме того, широко востребованы управляемые облачные сервисы (например, от AWS) для типовых задач backend. Что касается хранения данных, опрос показал безоговорочную популярность PostgreSQL (1/3 респондентов упоминало ее). Тем не менее, выбор технологий хранения невероятно разнообразен: профессионалы упомянули десятки разных баз данных (SQL, NoSQL, NewSQL, специализированные хранилища и т. д.). Это говорит о том, что современный стек данных очень неоднороден, и команды подбирают БД строго под свои задачи.
♾️ Мониторинг и надежность (DevOps)
В сфере observability данных наиболее популярны платформы Datadog, Grafana и Sentry - каждая из них используется примерно у 15-25% участников опроса. Эти инструменты (соответственно, облачный сервис мониторинга, open-source система дашбордов и сервис отслеживания ошибок) стали привычной частью инфраструктуры многих команд. Для оповещений и реагирования на инциденты подавляющее число инженеров применяют классические решения PagerDuty и OpsGenie.
📱 Фронтенд и мобильные технологии
Здесь наблюдается большая консолидация вокруг нескольких фреймворков. React практически без конкурентов доминирует как основной фронтенд-фреймворк (упоминается большинством веб-разработчиков), а Next.js стал самым популярным "мета"-фреймворком для React-приложений. Для мобильной разработки кроссплатформенно лидирует React Native - опрошенные отмечают его гораздо чаще любых альтернатив. Иными словами, стек фронтенда в 2025 году у большинства команд выглядит схоже. На бекенде разброс решений больше, но и там многие используют единый стек на TypeScript/Node.js либо популярные фреймворки вроде .NET и Spring.
🎌 Feature flags и внутренние инструменты
Практика feature flags и a/b тестирования прочно вошла в жизнь: для этого многие используют готовые сервисы, главным из которых является LaunchDarkly. Тем не менее, опрос показал, что весьма часто компании создают собственные системы фичефлагов, платформы экспериментов и кастомные конвейеры деплоя. Это может указывать на то, что существующие продукты не полностью покрывают нужды команд, либо на желание сэкономить на лицензиях, либо на требования безопасности.
Выводы из исследования в финальном посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Книжный куб
[1/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
❤6🔥4👍3