[2/2] Atlassian "State of Developer Experience 2025" (Рубрика #DevEx)

Продолжим разбор отчета Atlassian выводами и рекомендациями его авторов

1️⃣ ИИ – мощный инструмент, но не "серебряная пуля"
По мнению авторов, автоматизация с помощью AI способна заметно улучшить опыт разработчиков лишь при условии, что она нацелена на реальные проблемные места процесса разработки. Если же организации концентрируются только на ускорении приятных частей работы (например, написания кода), не устраняя корневые причины трения – возникает ложное ощущение эффективности. В результате время, выигранное за счёт ИИ, тут же теряется из-за других задержек, а требования по скорости растут несправедливо относительно возможностей команды.

2️⃣ Системный подход к Developer Experience
Лучшие компании начали пересматривать подход к опыту разработчиков комплексно – выстраивая процессы вокруг прозрачности, автономности команд и высокой скорости выпуска продукта. Улучшение DevEx требует постоянной работы: авторы призывают организации целенаправленно выявлять узкие места и устранять фрикции на всех этапах жизненного цикла разработки, от планирования до деплоя. Благо, что теперь у пользователей Atlassian будет доступ к купленной платформе DX, которая позволяет системно работать над DevEx.

3️⃣ Диалог между лидерами и разработчиками
Первый шаг к улучшению – спросить самих разработчиков о том, что мешает их продуктивности. Руководителям команд рекомендуют плотно общаться с инженерами и вместе тестировать решения проблем. В одних случаях частичное решение дадут AI-инструменты, в других – даже простые меры вроде самообслуживаемых справочных материалов или шаблонов, упрощающих рутину.

4️⃣ Совместная ответственность за изменения
Авторы отчёта отмечают, что и менеджеры, и сами инженеры должны активно участвовать в улучшении процессов. Разработчикам стоит доносить до руководства свои проблемы на языке влияния на результат – показывая, как конкретные препятствия задерживают релизы или снижают качество. Такое представление превращает "жалобу" в осязаемую задачу, требующую решения. В ответ лидерам важно не отвергать сигналы, а вместе с командами искать пути улучшения. Регулярная двусторонняя связь помогает выявлять проблемы заранее, укрепляет доверие и держит всех в фокусе на приоритетных целях.

Итого, чтобы в полной мере воспользоваться потенциалом AI в разработке, компаниям необходимо улучшать Developer Experience системно. Это подразумевает устранение внутренних неэффективностей, выравнивание ожиданий между инженерами и менеджерами и внедрение культуры, где новые инструменты (включая ИИ) используются осознанно – для облегчения самых болезненных участков работы, а не в ущерб им. Только так удастся превратить сэкономленные часы в устойчивый рост продуктивности и удовлетворённости команд работой.

#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops

[1/3] Octoverse 2025: A new developer joins GitHub every second as AI leads TypeScript to #1 (Рубрика #Engineering)

В конце октября появился очередной отчет Octoverse от GitHub, где авторы рассказывают про состояние дел в мире OSS (Open Source Software), а точнее о состоянии экосистемы разработки софта на GitHub. В 2025 году в отчете рассказывают про рекордный рост сообщества разработчиков в 2025 году и кардинальное влияние инструментов искусственного интеллекта на процесс разработки и выбор технологий.

Но начать стоит с методологии, так как она в отличие от многих других похожих отчетов основана не на опросах (что хорошо и позволяет оценить что происходит реально с репозиториями, кодом, разработчиками):
- Источник и период данных: отчет основан на анализе всех активностей пользователей на платформе GitHub за период с 1 сентября 2024 года по 31 августа 2025 (это так называемый Octoverse Year). Данные получены непосредственно из событий на платформе (коммиты, pull request’ы, issue и др.) – преимущественно из публичных репозиториев, если не оговорено иначе. Такой подход позволил сопоставлять метрики год к году с учётом сезонности (для трендов использовали сравнение одного и того же месяца в 2024 и 2025).
- Охват и размер выборки: тут тоже все здорово - отчет Octoverse опирается на всю популяцию разработчиков на GitHub, которых в 2025 году стало больше 180 миллионов (на 36 млн больше, чем годом ранее).
- Географическая представленность: данные отражают глобальное распределение разработчиков. Быстрее всего сообщество растёт в Азии и других развивающихся регионах, а Индия вышла на первое место по скорости добавления разработчиков (более 5.2 млн за год), а также на второе место по размеру сообщества (сразу после США).
- Отраслевая представленность: в конексте отчета разработчиком считают любого пользователя GitHub, связанный с созданием ПО. Отчёт охватывает как открытые проекты, так и корпоративные: хотя 81,5% всех зафиксированных вкладов пришлось на приватные репозитории (внутренние компании разработки), более 63% всех репозиториев на GitHub остаются публичными или open source. Иными словами, анализ учитывает и повседневную корпоративную разработку, и масштабную открытую экосистему, на которую она опирается.
- Дополнительные исследования: Отчёт носит количественный характер, основанный на телеметрии GitHub, а не на анкетировании. Однако авторы включили точечные качественные данные – например, серии интервью с разработчиками о практике ревью кода, чтобы оценить пользу нового инструмента GitHub Copilot Code Review. Результаты этих интервью встроены в анализ, например, 72,6% опрошенных отметили рост эффективности кода-ревью благодаря ИИ.

Ну а теперь, когда стало ясно почему отчет так интересен, стоит перейти к его результатами и ключевым выводам

👀 Основные показатели экосистемы Octoverse 2025
- Общее число проектов достигло 630 миллионов, AI-проектов – 4,3 млн, а разработчиков –-более 180 миллионов
- Количество публичных contributions (commits, PRs, gits, ...) - 1,12 млрд, в среднем 43,2 млн слияний pull request’ов в месяц (+23% г/г)
- Самыми популярными языками стали TypeScript и Python

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

#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture

[1/4] Сравнительный анализ Octoverse 2023–2025 от GitHub (Рубрика #OpenSource)

Недавно я рассказывал про отчет Octoverse 2025 от GitHub, а дальше мне стало интересно глянуть на тренды за последние три года (с ChatGPT момента). Кажется, что это достаточный срок, чтобы увидеть изменения в процессах разработки, популярности инструментов, продуктивности инженеров и whatever else. Поэтому сегодня мы посмотрим на тренды из отчетов за года
- 2023 год - Octoverse: The state of open source and rise of AI in 2023
- 2024 год - Octoverse: AI leads Python to top language as the number of global developers surges
- 2025 год - Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1

Рост сообщества GitHub и объём разработки
За последние три года произошел бурный рост сообщества:
- В начале 2023 года количество зарегистрированных разработчиков на GitHub превысило 100 миллионов (рост ~26% год к году)
- В 2024 году темпы ускорились - за год на платформу пришло около 36 млн новых пользователей (в основном за счёт стран Азии, Африки и Латинской Америки)
- К октябрю 2025 года совокупное число разработчиков превысило 180 млн, что стало самым быстрым абсолютным ростом за всю историю GitHub. В среднем в 2025 году каждую секунду присоединялся как минимум один новый разработчик, что соответствует >36 млн новичков за год.

Репозитории и коммиты
Вместе с сообществом резко увеличился и объём разрабатываемого кода:
- В 2023 году на GitHub было зафиксировано порядка 4,5 млрд совокупных contributions (коммитов, пул-реквестов, комментариев и др.), из них ~4,2 млрд в приватных репо, а 0.31 млрд в публичных
- К 2024 году общий годовой вклад вырос до 5,2–5,6 млрд contributions, причём почти 1 млрд из них пришёлся на публичные проекты (видно, что вклад в публичные проекты вырос где-то в 3 раза, а в приватные остался +/- таким же)
- В 2025-м наблюдался новый рекорд: более 6 млрд contributions, в том числе 1,12 млрд - в open-source (рост +13% за год). Разработчики за 2025 год в сумме пушили около 1 млрд коммитов (+25% год к году), а среднее число слияний пул-реквестов достигло 43,2 млн в месяц (~519 млн за год, +23% год к году). Общее количество хостящихся на GitHub репозиториев достигло 630 млн к 2025 году против ~518 млн годом ранее.

Open-source vs private
Во все три года большая часть активности приходилась на частные репозитории.
- В 2023 около 80% всех вкладов было в приватных проектах
- В 2024 эта доля составила ~82% (4,3 млрд из 5,2 млрд)
- В 2025 –-около 81,5% (почти 5 млрд из 6 млрд)
Однако публичных репозиториев количественно больше: в 2025 году 63% всех проектов на платформе были публичными (≈395 млн открытых репозиториев, +72 млн за год). Это подчёркивает двойственную роль GitHub: активная повседневная работа идёт в частных репозиториях, но она во многом опирается на открытые библиотеки и фреймворки из open-source сообщества.

#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture

[2/4] Сравнительный анализ Octoverse 2023–2025 от GitHub (Рубрика #OpenSource)

Продолжим сравнительный разбор этих отчетов от GitHub обсуждение AI:)

Проекты с искусственным интеллектом
Здесь можно говорить про рост количества и проникновения.
- В 2023 году был дан взрывной старт ИИ-проектов. Количество проектов, связанных с генеративным ИИ, увеличилось на 248% по сравнению с 2022 годом. Уже к середине 2023-го число новых репозиториев с генеративным ИИ превысило итоговое значение всего 2022 года. Впервые такие проекты вошли в топ-10 самых популярных репозиториев по числу контрибьюторов (например, Stable Diffusion и LangChain). Кроме того, 2023 год стал переломным: open-source разработчики активно экспериментировали с моделями (OpenAI и другие), что выдвинуло ИИ-проекты из исследовательской ниши в мейнстрим. Число разработчиков, участвующих в генеритивных ИИ-проектах, выросло на 148% за год.
- В 2024 волна ИИ в разработке продолжила нарастать. На GitHub к концу 2024 г. насчитывалось около 137 000 публичных проектов, связанных с генеративным ИИ - почти двукратный рост (+98%) год к году. Объём вкладов в такие проекты тоже резко вырос: число совокупных contributions в ИИ-репозитории увеличилось на 59% по сравнению с предыдущим годом. Интересно, что 6 из 10 самых быстрорастущих open-source проектов по количеству контрибьюторов в 2024 году были связаны с инфраструктурой ИИ (модели, оркестрация, оптимизация). Это свидетельствует, что сообщество всё активнее вовлекается в разработку ИИ-инструментов, выходя за рамки одной лишь генерации кода.
- В 2025 ИИ-проекты уверенно перешли в категорию массовых. Всего на GitHub к 2025 г. насчитывалось ≈4,3 млн репозиториев, помеченных как связанные с ИИ (учитывая и приватные). Из них более 1,1 млн публичных репозиториев используют SDK больших языковых моделей (LLM), причём 693 тыс. таких проектов были созданы всего за последний год (+178% по сравнению с августом 2024). Другими словами, почти каждый четвёртый новый репозиторий в 2025 содержал ИИ/ML-компоненты. Более того, 60% из топ-10 самых популярных open-source проектов 2025 года (по числу участников) имеют ИИ-фокус.

В итоге можно сделать вывод о том, что с 2023 по 2025 год ИИ прошёл путь от экспериментального тренда до неотъемлемой части экосистемы разработки.

Внедрение ИИ-инструментов среди разработчиков
- В 2023 году 92% разработчиков так или иначе пробовали инструменты с ИИ для программирования (например, GitHub Copilot). Это указывает на почти полное проникновение ассистентов на базе ИИ в рабочие процессы разработчиков по всему миру. Кроме того, почти треть всех open-source проектов со звёздами на GitHub имела хотя бы одного мейнтейнера, использующего GitHub Copilot. GitHub предоставил бесплатный Copilot для поддерживающих OSS мейнтейнеров, и многие воспользовались этим: ИИ-автодополнение кода стало повсеместным помощником в open-source сообществе. Кажется, что это проникновение обусловлено тем, что Copilot был встроен в сам GitHub:)
- В 2024 году GitHub отметил, что более 1 000 000 студентов, преподавателей и open-source разработчиков воспользовались Copilot через бесплатную программу для образования и OSS. За год число таких пользователей выросло на 100%. В общем, ребята продолжили работать над расширением охвата Copilot внутри GitHib и начали прививать его новичкам с первых их дней на платформе.
- Выпуск GitHub Copilot Free в конце 2024-го привёл к заметному скачку регистраций и активности на платформе. В результате в 2025 году новые пользователи практически сразу начинают работать с ИИ: 80% разработчиков-новичков включали Copilot в работу в первую же неделю на GitHub. Иными словами, для нового поколения кодеров ИИ-ассистент стал ожидаемым по умолчанию инструментом. В итоге, в 2025 году почти каждый новичок сразу осваивает ИИ-кодогенерацию, закрепляя её роль как стандартной части рабочего процесса разработчика.

#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture

[3/4] Сравнительный анализ Octoverse 2023–2025 от GitHub (Рубрика #OpenSource)

Продолжим сравнительный разбор отчетов Octoverse от GitHub темой developer productivity.

Влияние ИИ на продуктивность и процессы разработки
- В 2023 году подавляющее большинство разработчиков верило, что ИИ-инструменты улучшат эффективность командной работы, удовлетворённость и продуктивность. 81% респондентов считали, что ИИ-средства повышения кода сделают команды более сплочёнными, облегчат сотрудничество.
- В 2024 году Octoverse привёл конкретные данные о влиянии Copilot на работу. Предыдущее исследование показало до +55% роста продуктивности при решении задач у разработчиков, использующих ИИ-помощник. В самом отчёте отмечена корреляция: те, кто регулярно пользуется Copilot, демонстрируют большую активность на GitHub. Например, среди активно работающих на платформе разработчиков, применяющих Copilot, объём видимой работы (коммиты, пул-реквесты и т.д.) примерно на 12–15% выше (для ежедневно активных) по сравнению с их коллегами без ИИ. Это напрямую подтверждает и количественно, и по субъективным ощущениям, что ИИ-инструменты экономят время и увеличивают результативность разработки. При помощи ИИ инженеры успевают решать больше задач за единицу времени.
- В 2025 году влияние ИИ проявилось не только в количестве кода, но и в быстроте его доставки и исправления проблем. Благодаря новым функциям (например, Copilot Autofix) разработчики стали устранять уязвимости в коде значительно быстрее. По данным GitHub, автогенерируемые исправления снижали время на фиксы безопасности в разы: некоторые баги (SQL-инъекции, XSS) устранялись в 3–12 раз быстрее по сравнению с ручным исправлением (минуты вместо часов). Автоматизация обновлений зависимостей через Dependabot тоже стала нормой (разработчики сливают всё больше auto pull requests, ускоряя закрытие уязвимостей). В совокупности, 2025 год продемонстрировал рекордный объём выпусков: за месяц сливалось более 43 млн PR, а за год выполнено почти 520 млн слияний pull requests. Такой масштаб работы стал возможен во многом благодаря росту эффективности с ИИ.

Сдвиги в популярности языков под влиянием ИИ
Ежегодные отчёты Octoverse фиксируют заметные перемены в рейтинге языков программирования, связанные в том числе с влиянием ИИ.
- В 2023 году JavaScript сохранил звание самого популярного языка на GitHub, однако TypeScript стремительно набирал долю - впервые обогнав Java и заняв 3-е место по используемости в open-source (рост сообщества TS +37% за год)
- По итогам 2024 года Python вышел на первое место, обогнав JS. Этот сдвиг связывают с бумом анализа данных и машинного обучения на GitHub: Python доминирует в сферах AI/ML, научных вычислений, образования, что и подтолкнуло его на вершину. Одновременно отмечен всплеск популярности Jupyter Notebook на 92% – знак притока на GitHub специалистов по данным и исследователей.
- В 2025 году произошёл беспрецедентный сдвиг: TypeScript впервые стал языком №1 по количеству разработчиков на GitHub, обойдя и Python, и JavaScript. По данным отчёта, это крупнейшая перемена в рейтинге языков за десятилетие. Главная причина - влияние ИИ и «агентов» на выбор технологий. Типизированные языки вроде TS дают более надёжные подсказки и код при использовании ИИ-инструментов, особенно в production-системах. Разработчики переориентируют свой стек в пользу TypeScript, поскольку автодополнение и генерация кода работают точнее при строгой типизации. К тому же практически каждый современный фронтенд-фреймворк (React, Next.js и др.) теперь по умолчанию предлагает TypeScript, а не JavaScript. Важно: хотя TS вышел на первое место, экосистема JS/TS в целом продолжает доминировать (вместе они всё ещё генерируют активности больше, чем один Python). При этом Python остаётся безоговорочным лидером для проектов в области ИИ, анализа данных и научных исследований - эти области продолжили интенсивно расти на платформе.

#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture

[4/4] Сравнительный анализ Octoverse 2023–2025 от GitHub (Рубрика #OpenSource)

И зафиналим этим постом сравнительный разбор отчетов Octoverse за последние три года.

Помимо тройки лидеров (Typescript, Python Javascipt), отчёты отмечали рост интереса к системным языкам и языкам для работы с облачными технологиями.
- В 2023–2024 гг. заметно набирал популярность HashiCorp HCL (+36% за год) благодаря распространению Infrastructure-as-Code практик
- Язык Rust также демонстрировал высокие темпы (+40% в 2023) - его ценят за безопасность и производительность; Rust стал наиболее "любимым" языком по версии опросов разработчиков, а в 2024 продолжил рост за счёт использования в системном ПО и ядре Linux.
К 2025 году шесть языков фактически доминируют в новых репозиториях, покрывая ~80% проектов: это Python, JavaScript, TypeScript, Java, C++ и C#. Такой ландшафт указывает, что ИИ не заменил разработчиков (как некоторые опасались), но изменил их предпочтения и инструменты: сообщество адаптировалось, выбирая технологии, которые лучше сочетаются с ИИ-усилением разработки.

Если подводить итоги, то видно, что
- C 2023 по 2025 годы GitHub пережил рекордный приток новых разработчиков и проектов, во многом стимулированный распространением ИИ
- Open-source сообщество активно приняло ИИ-инструменты: к 2025 году они рассматриваются как неотъемлемая часть работы, повышающая продуктивность и позволяющая разрабатывать больше программ быстрее.
- Количество проектов, связанных с ИИ, выросло на порядки, а языковой ландшафт начал смещаться в сторону технологий, максимально эффективных при поддержке ИИ (это важный тренд и я думаю, что это будет происходить и внутри больших компаний).
- При этом общий тренд позитивный: данные GitHub показывают, что приток ИИ-инструментов не ухудшил качество вкладов или здоровье open-source сообщества - напротив, разработчики стали сотрудничать ещё активнее, осваивать новые области (AI/ML) и вместе двигать экосистему вперёд.

#AI #ML #Software #Architecture #Processes #DevEx #Devops #Metrics #Engineering #OpenSource #Architecture

ASML Statement on Strengthening Focus on Engineering and Innovation (Рубрика #Engineering)

Вышла интересная новость от ASML, чьи литографы хотят все производители чипов. Так вот ASML внезапно обнаружила, что стала… less agile, процессы усложнились, скорость упала, матричная оргструктура начала мешать инженерии и пора принимать меры.

Если переводить с корпоративного, то можно прочитать это письмо так
- Matrix-структура больше не вывозит - слишком много пересечений, согласований и «непонятно кто владелец результата»
- Хотим product-ориентированную модель - чёткие продуктовые направления, end-to-end ownership, меньше размазанной ответственности
- Processes became “less agile” - для компании, которая живёт на скорости R&D, это почти диагноз.

В итоге, ребята решили сократить лишние уровни менеджмента и уволить 1.7к сотрудников, что я прочитал примерно так "кажется, у нас слишком много людей, которые управляют людьми, которые управляют процессами". Интересно будет дальше посмотреть как пройдет эта трансформация.

#Engineering #Management #Leadership #Software #Processes

[1/2] Achieving Productivity Gains with AI-based IDE features: A Journey at Google∗ (Рубрика #Whitepaper)

Прочитал ночью свежую статью (27 января 2026 года) от Google про их опыт к внедрению двух AI-функций в своей внутренней IDE: стандартного code completion и более интересной трансформации кода (где выделяешь код и дальше пишешь промпт о том, как поменять). Эти фичи были призваны ускорить работу разработчиков, но по пути инженерам пришлось решить проблемы с задержкой, UX и качеством подсказок, опираясь на эксперименты и данные. По-факту, ребята посмотрели на процесс продуктово - построили воронку и оценили потери на каждом шаге из-за разных факторов: неуверенности модели, задержек, нерелевантных рекомендаций или низкого вовлечения пользователей. Это позволило системно бороться с этими факторами, понимая на какие из них стоит сделать больший упор.

Дальше рассмотрим оба сценария

1️⃣ AI-автодополнение кода
В основе автодополнения - трансформер, обученный предсказывать код сразу за курсором (fill-in-the-middle), причем модель дообучена на реальных историях правок Google-разработчиков (приближая ее к живым сценариям). Для ускорения отклика и повышения качества применяются адаптивное кэширование (повторно использует недавние подсказки, устраняя лаг при быстром наборе), спекулятивное декодирование (параллельный запуск небольшой модели-прогнозера для снижения латентности) и другие оптимизации latency. Кроме того, модель получает расширенный контекст - фрагменты кода из открытых файлов вместе с их окружением (релевантные части, ближайшие к месту редактирования).

Совсетно все эти приседания дали следующие эффекты:
- Адаптивный кэш дал ~35% кеш-хитов и снизил медианную задержку на 9% (p90 –2%), а acceptance rate подсказок вырос на ~17%, увеличив долю кода, генерируемого ML, на 41%
- Добавление контекста дало еще +5% к принятию и +11% к FCML (хоть задержка выросла, медиана +46%)

Совокупно acceptance rate достиг ~45%, а ~28,7% всего кода теперь генерируется моделью (до 70,6%, если исключить copy-paste). В среднем принятый фрагмент подсказки составляет ~62 символа.

2️⃣ Transform Code (авто-правки по описанию)
Этот инструмент позволяет по запросу разработчика отредактировать выделенный код согласно текстовой инструкции (например, “замени X на Y”). Под капотом – модель Gemini, дообученная на внутреннем коде; она получает контекст файла с выделенным фрагментом и текст запроса, а выдает изменения в формате диффа. Основные сложности внедрения - как подсказать пользователю воспользоваться функцией (discoverability), как удобно отобразить крупные правки и как обеспечить высокое качество предложений даже на незавершённом коде.

Google решил эти проблемы несколькими улучшениями:
- Кнопка при выделении (+40% запросов, +64% новых пользователей).
- Упрощенный дифф (ревью быстрее на 7%, acceptance +2.2%, до +4.5% на крупных изменениях).
- Дообучение на правках (acceptance вырос ~55% → 63%).

Transform Code уже приносит пользу: ~68% предложенных правок принимаются разработчиками, а средний отклик < 1 с.

В продолжении я расскажу про то, как ребята оценивали изменения продуктивности от этих инструментов (это интересно).

#Engineering #AI #ML #Software #Bigtech #Productivity #Management #Leadership #Processes #Architecture

[2/2] Achieving Productivity Gains with AI-based IDE features: A Journey at Google∗ (Рубрика #Whitepaper)

В продолжении разбора обсудим на подход с оценкой изменения продуктивности в реальном использовании. Для этого они проанализировали показатели работы инженеров (подробнее про подход Google можно прочитать в whitepaper "Enabling the Study of Software Development Behavior With Cross-Tool Logs", который я уже разбирал). Измеряли, сколько Change Lists (CL, завершённых кодовых изменений) сдаёт разработчик в месяц, сколько времени он активно пишет код на один CL, и сколько времени тратит на поиск информации вне IDE. Эффект от Transform Code оценили через онлайн-эксперимент и Difference-in-Differences анализ, сравнив метрики пользователей инструмента с контрольной группой (2023–2024).

Результаты: У разработчиков, начавших пользоваться Transform Code
- CL throughput (CL в месяц) вырос на +17.5%.
- Среднее время поисковых сессий вне IDE сократилось на –3.6%.
- Active coding time per CL не изменился значимо.
Эти эффекты статистически значимы и свидетельствуют о росте продуктивности благодаря инструменту.

Из этой работы видно, что повысить продуктивность позволяют только комплексные улучшения во всех слоях инструмента. Важны UX (чтобы фичей легко пользовались), оптимизация интеграции (латентность, контекст), тюнинг модели на данных реального использования, мониторинг метрик вроде acceptance/FCML и проверка общей отдачи на уровне throughput. Все эти аспекты взаимозависимы и требуют координации между ML-, платформенными и UX-командами.

Кроме того видно, что такая работа по своей природе итеративна. Начните с MVP и улучшайте его на основе обратной связи. Подход “сделал → замерил → улучшил” (A/B-тесты, дообучение на пользовательских правках, доработка UI) оказался решающим для превращения прототипа в инструмент, давший +17.5% к выпуску кода.

В конце статьи приводится прогноз относительно AI в разработке
1) Сегодня это умные помощники для программиста
2) Завтра - полуавтономные агенты для рутинных задач
3) В перспективе - полностью автоматизированная разработка под контролем человека

Мне кажется, что часть людей вне корпораций уже живет в "завтра" по этой классификации. Но в любом случае конечная цель в том, чтобы ИИ ускорял весь цикл от идеи до продукта.

#Engineering #AI #ML #Software #Bigtech #Productivity #Management #Leadership #Processes #Architecture

T-Sync Conf и итоги исследования AI4SDLC 2025 от Т-Банка (Рубрика #Engineering)

Сегодня я проведу весь день на конференции T-Sync, где нет докладов, а больше дискуссий и зон для общения. Собственно, у меня будет такая зона на втором этаже, где мы сможем поговрить про исследование AI4SDLC, которое мы стартанули в прошлом году опросом сообщества. Само исследование доступно на сайте ai4sdlc.tbank.ru при клике на вкладку "Исследование". Оно состоит из двух частей:

1️⃣ Раздел с мета-исследованием 2023–2025, где мы взяли порядка 50 отдельных исследований за последние годы и посмотрели на их результаты. Особенно интересно было смотреть на тренды серийных исследований, что проводятся ежегодно - по ним видно, как менялось отношение к AI в среде разработки, проникновение AI в разные сценарии, оценки его эффектов и так далее. Среди таких серийных исследований были исследования от: DORA, GitHub, Stack Overflow, JetBrains, Atlassian, McKinsey, Яков и Партнёры / Yandex, Express42, МФТИ. На сайте есть список серий, где можно посмотреть основные тренды каждой серии. Также есть таймлайн со всеми учтенными исследованиями + можно изучить краткое саммари по каждому из них

2️⃣ Раздел с результатами опроса, который мы проводили в конце прошлого года. Опрос получился объемным и я хотел бы поблагодарить всех поучавствовавших в нем. По результатам получилось примерно следующее: начали заполнять опрос порядка 1к человек и хорошо, что мы вопросы про использование и влияние AI вынесли в самое начало, так как до конца опроса дошли не все:) Если говорить, про профиль респондентов, то он получился такой:
- 50% разработчики, 17% технические руководители, 7% топ-менеджеры, 6% qa-инженеры, 4% AI/ML инженеры и так далее
- 24% работают в крупных компаниях (1к - 10к), 23% в очень крупных (10к+ сотрудников), 18% в средних (100 - 500 сотрудников), 16% в маленьких (10-100)
- основные представленные отрасли: финансы - 25%, технологии - 20%, розничная торговля и e-com - 15%, телеком - 7%, образование - 5%
- основные приложения/сервисы, над которыми работают респонденты распределились довольно равномерно: внутреннее/внешнее для пользователей - 45% vs 37% и b2c vs b2b - 34% vs 41%

Если говорить про executive summary результатов опроса, то они такие
- AI для генерации / автодополнения кода используют "часто/всегда" 58%; для code review 24%; для модернизации legacy 18% (при 42% "никогда").
- Производительность выросла у 64% (18% "значительно"); способность писать код улучшилась у 37%.
- Качество кода: улучшение 32%, ухудшение 14%, без изменений 42%.
- Доверие к AI-коду низкое: 49% не доверяют, 11% доверяют (остальные — нейтрально).
- Роль AI внутри компании выросла у 54%; прозрачность планов внедрения ощущают 50%, не ощущают 21%.
- "Системная готовность": commit→prod у заметной части измеряется неделями/месяцами; документация как источник правды работает плохо (около 39–42% не опираются на нее в критичных ситуациях).

И эти результаты хорошо откликаются в результатах мета-исследования
- Охват AI приближается к "почти у всех" (например, в сводках DORA к 2025 — около 90%); при этом личный эффект обычно сильнее командного.
- Узкие места переезжают в интеграцию, тестирование, ревью, релизы, коммуникации; в исследованиях регулярно всплывает тезис, что кодинг - лишь часть времени инженера (и что организационные барьеры съедают ощутимую долю недели).
- Качество и доверие - центральная проблема зрелости: "almost right" ответы создают новый долг проверки и дебага.
- Экспериментальные данные показывают: на сложных задачах эффект может быть нулевым или отрицательным; AI - усилитель системы, а не замена инженерии.
- Без guardrails (тесты, quality gates, small batch, ревью, наблюдаемость) "ускорение" легко превращается в "ускорение хаоса".

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

#AI #RnD #Software #Engineering #Management #Leadership #Metrics #Processes #Productivity

Two decades of Git: A conversation with creator Linus Torvalds (Рубрика #Software)

Интересный рассказ Линуса Торвальдаса о том, как 20 лет назад, в апреле 2005-го, Линус за 10 дней накатал первую версию Git. Он сделал это потому, что у разработчиков ядра Linux отобрали любимый инструмент (BitKeeper). Git родился из боли: CVS Линус терпеть не мог, SVN считал «тем же CVS». Он признаётся, что изначально писал Git "под себя", не парясь об удобстве для других.

Линус всего несколько месяцев сам поддерживал Git, а уже к осени 2005 передал бразды другому разработчику – Junio Hamano (он и по сей день мейнтейнер). Торвальдс вернулся к любимому детищу (ядру Linux), а Git зажил своей жизнью. Постепенно что-то переключилось в сообществе: через пару лет народ распробовал инструмент. Особенно помог приток молодых разработчиков, для которых Git стал первой системой контроля версий. Вместо возни с устаревшим CVS они с удовольствием юзали Git и удивлялись, почему раньше было иначе. В итоге Git взлетел и практически монополизировал рынок VCS – сейчас, по словам Линуса, порядка 98% проектов на нём. Даже дочь Торвальдса однажды сказала ему, что в университетской лабе его знают больше как автора Git, а не Linux 😅.

Ключевые идеи и фишки Git следующие

1️⃣ Распределённость
В Git нет главного репозитория, каждый клонированный репо - полноценный. Это не просто философия, а огромное практическое удобство: разработчик может работать локально без центрального сервера, а при надобности выложить код куда угодно (GitHub и появился благодаря этой идее). Как мне кажется, это local-first приложение by design.
2️⃣ Скорость и масштабируемость
Git проектировался под гигантский Linux-репозиторий, поэтому все операции (патчи, слияния) должны быть быстры. Линус шутит, что применить 100 патчей должно быть делом секунд – «не надо успевать пить кофе, пока ждёшь».
3️⃣ Надёжность данных
Каждый коммит и объект помечаются крипто-хешем (SHA-1): это больше про защиту от случайной порчи или ошибок, чем про безопасность. Такая проверка целостности на каждом шаге отличала Git от предыдущих систем (в BitKeeper, например, были слабее CRC/MD5 и не всё покрывали).
4️⃣ Простота ядра
В основе Git всего несколько концепций (объекты, индексы, ветки), за счёт этого первую версию удалось написать быстро и она до сих пор совместима (почти полностью) с нынешней. Всё сложное вынесено либо “наверх” (в командный интерфейс, скрипты), либо появилось позже.

Интересно, что Линус, вдохновляясь философией Unix, нарочно не копировал привычные команды CVS – делал по-своему, даже названия дал другие (commit-tree, index и т.д.), чем вызывал баталии на почтовых списках. Но он сознательно ломал устои: слишком уж его раздражали старые подходы, хотелось кардинально другой инструмент.

Вообще, история Git - это отличный пример, как разработчик решает свою проблему, а в результате меняет индустрию. Линус просто хотел продолжать разрабатывать ядро, не мучаясь с отвратительным инструментом, - и из этого родился Git, без которого сейчас не мыслят работу ни разработчики, ни тимлиды. Порой действительно стоит взять и сделать «как надо», даже если изначально продукт сырой и неудобный: если в основе заложены верные принципы, сообщество подтянется и доведёт до ума. Мы видим, как открытые инструменты побеждают закрытые (BitKeeper канул в лету, Git царит).

Торвальдс отмечает, что теперь вокруг Git выросла экосистема, которая решает проблемы, о которых он и не думал. Например, появились расширения для больших файлов и монорепозиториев (привет корпорациям) – изначально Git не планировался для этого, но жизнь заставила. Интересна его мысль о трекере задач/багов: сейчас у каждого хостинга своя система issues, и Линусу хочется единого открытого стандарта (чтобы не было привязки к конкретному сервису). Возможно, это намёк сообществу, где ещё есть простор для инноваций 😉.

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

Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment - a Large-Scale Study (ICSE’25) (Рубрика #Architecture)

Наконец-то у меня дошли руки написать про этот интересный whitepaper про связь качества архитектуры с нагрузкой на поддержку решения и восприятия инженерами самого проекта. Лид автором этой статьи была Yuanfang Cai, профессор в Drexel University и автор метрик применяемых метрик, а также команда Google Developer Infrastructure / Engineering Productivity Research (Ciera Jaspan и др.)

Авторы взяли данные
- 1200+ проектов внутри Google (C++/Java).
- Логи разработки: commits, LOC (lines of code) и Active Coding Time; отдельно мерили их в разрезе "фичи" vs "багфиксы"
- 7200 ответов инженеров из регулярного опроса: насколько техдолг/избыточная сложность мешали работе (подробнее про этот опрос было в статье ребят из Google "Measuring Developer Experience With a Longitudinal Survey", что я уже разбирал)

Цель всего приседания была в том, чтобы заменить "ощущения техдолга" на измеримые связи: архитектура → бремя сопровождения → настроение разработчиков. Кстати, про техдолг ребята из Google уже публиковали крутую статью "Defining, measuring and managing technical debt", которую я уже разбирал

Измеряли они следующие три категории
1️⃣ Архитектурная сложность
- Propagation Cost (PC): насколько широко расползаются изменения по зависимостям
- Decoupling Level (DL): насколько хорошо система декомпозирована на независимые модули
- Архитектурные запахи: циклические зависимости, co-change без явных зависимостей, нестабильные интерфейсы, проблемы наследования и т.п.
2️⃣ Maintenance burden
- Доля усилий на багфиксы: по commits, LOC (lines of code), ACT (active coding time)
3️⃣ Developer sentiment
- Ответы на вопросы из опросы вида "тормозит ли меня техдолг"

Методология выглядела так
- Для каждого проекта считают PC/DL/запахи по dependency graph + считают "bugfix ratio" по истории изменений
- Дальше делают статистический анализ (корреляции/значимость) между тремя слоями

В итоге у них на выходе получились результаты, что
- Более сложная архитектура (PC↑, smells↑) связана с тем, что команда тратит больше доли усилий на багфиксы и меньше - на развитие
- Чем больше "feature work" у команды, тем реже инженеры говорят, что техдолг их тормозит
- "Архитектура <-> недовольство" во многом проявляется через рост багфиксов: когда вы живёте в поддержке, техдолг становится осязаемым

Отдельно стоит отметить, что исследование нашло корелляцию, но это не причинно-следственная связь. Но это частая картина для сложных методологий исследований, что через a/b тест не катанешь.

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

P.S.
Я рассказывал про многие статьи ребят из Google, у них отлично выстроена методология и есть очень интересные результаты - подробнее можно посмотреть в подборке из двух постов: 1 и 2

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

Как взять идеи Google и построить себе похожий контроль качества архитектуры (Рубрика #Architecture)

В прошлом посте мы разбирали whitepaper от ребят из Google "Understanding Architectural Complexity, Maintenance Burden, and Developer Sentiment - a Large-Scale Study". А сейчас я хотел бы поговорить про практические шаги, что можно сделать у себя в компании, если вы не Google, но тоже хотите контролировать качество архитектуры и размер техдолга.

1️⃣ Сформулируйте "maintenance burden" так, чтобы его можно было считать
Самый практичный вариант - доля багфиксов vs фич за период:
- % задач типа Bug в трекере
- % PR/коммитов, привязанных к Bug
- % LOC (или хотя бы файлов), изменённых ради Bug

2️⃣ Соберите минимум данных (обычно уже есть)
- Git/PR-логи: кто/когда/что менял (changed files, размер).
- Issue tracker (Jira и т.п.): тип задачи (bug/feature), компонент/сервис, команда.
- Dependency graph: зависимости между пакетами/модулями/сервисами (из build graph, import graph, API calls).
- Active coding time по задачам или DAT (Diff Authoring TIme), которым так хвалилась запрещенная в России Meta и про который я уже рассказывал
- Если нет Active Coding Time, то начните с прокси: lead time PR, время ревью, размер batch’ей (а потом все-таки соберите ACT)

3️⃣ Архитектурные метрики: начните "дёшево", потом усложняйте
Метрики из приведенного выше whitepaper конечно крутые, но сложные. Я говорю про
- Propagation Cost (PC): насколько широко расползаются изменения по зависимостям
- Decoupling Level (DL): насколько хорошо система декомпозирована на независимые модули
В академии есть DV8 от авторов оригинального исследования (Yuanfang Cai, Rick Kazman) или условный Sonar в качестве коммерческого инструмента. Но для старта хватит
- Отслеживать циклы на уровне модулей/сервисов (SCC)
- Считать fan-in/fan-out, транзитивный fan-out
- Отслеживать co-change кластеры: файлы часто меняются вместе, хотя "по архитектуре" не должны
По правилу Парето мы так найдем 20% проблем, что приносят 80% боли

4️⃣ Склейте всё в регулярный отчёт (по кварталам/месяцам)
На уровне repo/сервиса/команды:
- Тренд coupling/циклов/co-change
- Тренд bugfix ratio
- Микро-опрос 1 вопрос раз в квартал: "насколько техдолг/сложность мешали вам работать?"
Важно искать не виноватых, а проблему в системе: high coupling + растущий bugfix ratio = кандидат #1 на тех-инвестиции

Если воспользоваться этим алгоритмом, то у вас будет набор карт на руках, с которыми никакой техдолг не страшен
- У вас будут аргументы для рефакторинга в цифрах (и разговор с бизнесом пройдет на понятном им языке)
- У вас будет внятная приоритизация: какие 2–3 hotspot’а чинить в первую очередь
- Вы увидите ранние сигналы деградации: поймаете тренды до того, как команда уйдёт в вечный багфикс
- Вы улучшите DevEx и скорость доставки фич как следствие

Но важно не облажаться и не наступить в анти-паттерны
- Не превращайте метрики в KPI людей/команд - будет гейминг
- Не ставьте одинаковые абсолютные пороги по метрикам - нужны базовые нормы "что ок" для вашего домена;
- Не пытайтесь получить одну метрику техдолга - он многомерен и метрики - это сигнал, а не приговор. Дальше нужны дизайн‑ревью и инженерная оценка найденных проблем

Если бы я делал это в компании, то попробовал бы
- Катануть пилот на 10–20 репозиториях/сервисах
- Собрал бы базовую панель метрик, перечисленных выше
- Подождал сбора результатов, напрмер, квартал
- Дальше сделал бы точечные рефакторинги (благо сейчас рефакторинг становится сильно дешевле, если его делать с помощью AI-инструментов)
- Сравнил бы "до/после" по bugfix ratio и скорости доставки
- Если бы метрики улучшили, то планировал бы дальше раскатку

В общем, с точки зрения алгоритма примерения тут нет никакого rocket science, но дьявол кроется в деталях:)

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes

[1/2] Retired Netflix Engineering Director On Regrets, Video Engineering, Hiring Stories (Рубрика #Engineering)

Интересное интервью Дэвида Ронка, экс Engineering Director в Netflix (пришёл в 2007), позже Director/Principal в Meta (видеотехнологии), которое он дал Райану Питерману , Staff SWE в Instagram. В этом интервью Дэвид, который уже вышел на пенсию, делится ретроспективой своей карьеры и управленческих решений. Основные инсайты следующие

1️⃣ "No brilliant jerks" - это не HR-лозунг, а инженерная оптимизация throughput
Токсичная "звезда" может быть сильной индивидуально, но снижает скорость и качество всей команды (а значит и системы).

2️⃣ Героизм и 24/7 - симптом организационного бага, а не доблесть
Если команда не переживает нормальный отпуск ключевого инженера, проблема почти всегда в устройстве системы: ownership, знания, ротации, процессы, приоритеты.

3️⃣ Culture Memo "aspirational": культура без инфраструктуры ломается при росте
На небольшом масштабе "контекст вместо контроля" и сильные люди могут вытягивать многое. На большом масштабе без уровней/процессов/прозрачности вклада начинаются перекосы: вклад размывается, аттрибуция успехов уезжает вверх, компенсации сложнее объяснять.

4️⃣ Масштаб реально меняет физику инженерных решений
Переход в Meta показал ему, что некоторые задачи (например, видео на уровне платформы) нельзя "дожать CPU’шками и количеством серверов" - нужна другая парадигма.

5️⃣ Найм: конфликт "точность оценки <=> масштабируемость процесса"
У него жёсткая позиция про LeetCode (как не очень хороший сигнал качества инженера), но при этом он признаёт: в big tech стандартизация этапов часто неизбежна. Плюс важный тезис: over‑leveling - дорогая ошибка, потому что "мягко опустить ожидания" потом почти невозможно.

6️⃣ Performance/калибрации могут быть отличной школой управленческой объективности
Да, это тяжело и неприятно, но заставляет формулировать вклад инженеров так, чтобы он держался на фактах и impact’е, а не на харизме менеджера.

7️⃣ Риск формализованных систем: перекос в "индивидуальную аттрибуцию результатов"
Вклад становится видимым, но риск в том, что люди начинают оптимизировать "видимость" и личную победу, а не командный результат.

В продолжении расскажу как можно этот опыт переложить на практические рекомендации инженерам и техническим руководителям.

#Culture #Management #Leadership #Processes #Engineering #Software #Career #Interview

[2/2] Retired Netflix Engineering Director On Regrets, Video Engineering, Hiring Stories (Рубрика #Engineering)

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

Что это значит для разработчиков (IC)
- Если ты single point of failure - это не "круто", это риск. Документация, runbook’и, ротации on-call, передача контекста, “absence drill” (плановая недоступность) — это то, что делает команду взрослой.
- Собирай "evidence of impact" до того, как тебя об этом попросят. Простая привычка: раз в месяц фиксировать “что сделал → какой эффект → какие риски снял → какие метрики/сигналы подтверждают”. Это помогает и в оценке, и в повышении, и в переговорах.
- Не путай "много работал" с "много решил". В разговоре красной нитью: часы - плохой KPI. Системы и команды должны работать так, чтобы не требовать постоянного героизма.
- Про собесы: будь готов к стандартизированным фильтрам, но выигрывает инженерная зрелость. Умение рассуждать про trade‑offs, неопределённость, дизайн систем и реальные решения - то, что отличает сильных на дистанции.

Что это значит для техлидов и технических руководителей
- Культура должна "исполняться", а не декларироваться. Например, "No brilliant jerks" работает только когда есть реальный enforcement: обратная связь, понятные ожидания и готовность расставаться даже с сильными, если они ломают команду.
- Сделайте отпуск диагностическим инструментом. "Vacation/bus‑factor тест": кто уходит на неделю → что ломается → какие знания/доступы/процессы надо распаковать из головы в систему.
- Видимость вклада - это инфраструктура роста. Не обязательно сразу “как в Meta”. Но вам нужна лёгкая версия: цели → зафиксированный impact → регулярная синхронизация ожиданий между командами, иначе на масштабе всё начнёт “тонуть в тумане”.
- Найм: определитесь, что вы реально измеряете, и структурируйте процесс. Если хотите системное мышление и зрелость - добавляйте этапы, которые это проявляют (work‑sample / разбор реального кейса / обсуждение решений при неполных данных), а не только "задачки".
- Компенсируйте перекос в индивидуальной аттрибуции резульататов. Если "светится" только личный вклад - получите локальную оптимизацию. Добавляйте командные сигналы, качество взаимодействия, ownership на длинной дистанции, культуру совместного результата.

#Culture #Management #Leadership #Processes #Engineering #Software #Career #Interview