Как незаметно DORA метрик стало не четыре, а пять (Рубрика #Productivity)

Долгие году у DevOps Research & Assesment или попросту DORA было 4 метрики, на которых строилась кластеризация команд по разным уровням элитности. Эти метрики были про скорость поставки и стабильность
- Скорость поставки: deployment frequency и lead time for changes
- Стабильнсоть: MTTR / time to restore service и change fail rate
Подробнее эту историю можно прочитать в моем разборе книги "Accelerate")

С января 2026 года у DORA стало 5 software delivery performance metrics, которые на их сайте тоже разбиты на две категории

1️⃣ Throughput - пропускная способность системы
- Change lead time - время от коммита до успешного деплоя в прод
- Deployment frequency - как часто вы выкатываете изменения
- Failed deployment recovery time - как быстро вы восстанавливаетесь именно после неудачного деплоя

2️⃣ Instability
- Change fail rate - доля деплоев, требующих немедленного вмешательства
- Deployment rework rate - доля незапланированных деплоев, которые пришлось делать из-за прод-инцидента / дефекта

Возникает вопрос, а что именно изменилось по сравнению со старой моделью и зачем это было сделано?
Вообще, измений было два и оба они важные
1) Старый MTTR / time to restore service в 2023 был уточнен и переопределен как failed deployment recovery time. DORA прямо объясняет это тем, что старое определение смешивало проблемы, вызванные изменением в коде, и внешние инциденты вроде outage в датацентре. Новая формулировка лучше статистически "сцепляется" именно с delivery-метриками.
2) В 2024 DORA добавила новую пятую метрику - deployment rework rate. Их логика была такой: change fail rate хорошо ловит немедленные проблемы после релиза, но плохо отражает объем последующей незапланированной переделки. Поэтому DORA решила отдельно измерять rework как самостоятельную часть instability.

Если же говорить про использование метрик, то возникает вопрос: а теперь классификация будет идти по 5 метрикам?
И тут по сути ответ "да", но есть нюансы ... ребята из DORA отдельно подчеркивают, что число кластеров не фиксировано и не задается вручную. В FAQ они пишут, что кластеры у них emergent from the data: до 2018 обычно было 3, с 2018 по 2021 - 4, в 2022 снова 3, а в 2023 и 2024 - опять 4. То есть фиксированного "всегда 4 класса команд" больше воспринимать не стоит.

Если подумать, а что это значит для обычных технических руководителей (кто не упарывается по методолгии и метрикам)?
Кажется, что DORA стала лучше различать два разных вида проблем:
- Немедленный фейл после релиза → change fail rate
- Отложенная незапланированная переделка из-за продовых проблем → deployment rework rate
Это полезно, потому что команда может выглядеть "нормально" по rollback/hotfix сразу после релиза, но при этом системно тонуть в незапланированном rework через день-два. В старой 4-метричной модели это было видно хуже; в новой - видно лучше. Это и есть главное содержательное обновление модели.

Отдельно стоит сказать, что 5 метрик бывало в DORA и раньше, а именно в 2021/2022 годах, когда была операционная метрика reliability, но она была не про software delivery performance, а вот текущая великолепная пятерка - это уже именно delivery metrics.

P.S.
В чате @ai4sdlc вчера обсуждали метрики и было предложение просто использовать DORA. В итоге, я решил написать этот пост, чтобы показать, что даже DORA не просто так посчитать, а еще само понимание метрик дрифтит со временем:)

#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership

DORA AI Capabilities Model - Разбор отчета (Рубрика #Productivity)

Прочитал на выходных отчет про эту модель-компаньон отчета 2025 года, который называется "State of AI-assisted Software Development". Основная мысль "DORA AI Capabilities Model" в том, что AI сам по себе не гарантирует улучшения, но он усиливает уже существующую социотехническую систему - хорошие практики усиливает, плохие тоже. Модель выделяет 7 capabilities, которые повышают шанс, что AI даст заметный положительный эффект. Отдельно отмечу, что я уже рассказывал как собираются отчеты DORA, как анонсировали AI Capabilities и что было в DORA 2025 - State of AI-assisted Software Development

Но если возвращаться к новому отчету, то вот эта великолепная семерка capabilities и вратарь AI
1. Clear and communicated AI stance - у организации есть понятная и донесенная позиция по использованию AI: что разрешено, что ожидается, какие инструменты можно применять.
2. Healthy data ecosystems - внутренние данные качественные, доступные и не разрозненные.
3. AI-accessible internal data - AI-инструменты могут безопасно получать контекст из внутренних кодовых баз, wiki, систем и документов.
4. Strong version control practices - зрелые практики version control, включая частые коммиты и возможность rollback.
5. Working in small batches - маленькие изменения, маленькие релизы, короткий цикл обратной связи.
6. User-centric focus - команда держит в центре пользователя и пользовательскую ценность.
7. Quality internal platforms - качественная внутренняя платформа помогает масштабировать эффект AI на уровне организации.


Исследователи из DORA нашли следующие связи между этими семью capabilities и интересующими всех outcomes
1. Clear and communicated AI stance ~ individual effectiveness и organizational performance
2. Healthy data ecosystems ~ organizational performance
3. AI-accessible internal data ~ individual effectiveness и code quality
4. Strong version control practices ~ individual effectiveness и team performance
5. Working in small batches ~ product performance и снижении friction
6. User-centric focus ~ team performance, но без этого фокуса AI даже может ухудшать team performace (команда будет быстрее двигаться не туда)
7. Quality internal platforms ~ organizational performance

Отдельно надо отметить, что эти новые capabilities напрямую связаны с классической DORA Core Model - новые capabilities дополняют core модель
- Core Model - это более консервативное ядро DORA: capabilities, metrics и outcomes, которые многократно подтверждались в исследованиях за многие годы.
- AI Capabilities Model - это надстройка поверх Core, которая отвечает на другой вопрос: при каких условиях AI-assisted development реально улучшает результаты
DORA отдельно подчеркивает, что многие AI-capabilities - это те же самые базовые инженерные и организационные способности, которые и раньше были связаны с high performance.

Интересно отметить, что 7 факторов получилось не совсем из головы - по описанию DORA, процесс был таким:
- Сначала исследователи сформировали широкий список гипотез о capability, которые могут влиять на успех AI-assisted development, опираясь на 78 in-depth interviews, мнения domain experts и прошлые исследования DORA
- Затем через приоритизацию они отобрали 15 кандидатов в capabilities для включения в опрос
- Потом в количественном анализе они оставили те, по которым нашлось существенное evidence of interaction with AI use
В общем, в итоговую модель вошли те 7 capabilities, которые статистически усиливали эффект AI adoption на значимые outcomes

#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership

What Makes a Great Developer Experience? (Рубрика #Productivity)

Интересный доклад Макса Канат-Александра с DPE Summit 2025 (подробнее про саммит здесь). Макс рассказывает про трех китов хорошего опыта разработчиков
1. Cycle time - сколько времени проходит от идеи до работающего результата
2. Focus - сколько у разработчика непрерывного времени на работу без дёрганий
3. Cognitive load - сколько лишнего нужно держать в голове, чтобы сделать полезную задачу

Идея в том, что почти любую проблему инженерной продуктивности можно разложить по этим трём осям по мнению Макса. А он знает толк в DevEx, так как он занимался этим всю инженерную карьеру
- как главный архитектор Bugzilla
- работая над Code Health в Google
- отвечая за Developer Experience в LinkedIn
- а сейчас он Executive Distinguished Engineer в Capital One (банк чьей моделью бизнеса вдохновлялись при создании Тинькофф)
Поэтому мне взгляд Макса на productivity кажется не абстрактной теорией, а опытом полученным на практике.

Главная мысль доклада в том, что отличный developer experience - это не про красивый интерфейс внутреннего портала разработки. Это про системное снятие барьеров, которые замедляют инженера, выбивают его из фокуса и заставляют тратить мозг не на продукт, а на инфраструктурный шум. Макс по сути говорит: если улучшение не сокращает цикл, не защищает фокус и не снижает когнитивную нагрузку, то его ценность для DevEx сомнительна.

А теперь про инсайты

1️⃣ Скорость - это не мантра "работайте быстрее"
От призывов ускориться или поднажать появляется только стресс, а для реального ускорения надо ускорять внутренние циклы разработки (между внутренними этапами цикла), например можно сделать
- Быстрее ревью
- Меньше и понятнее PR
- Короче сборки
- Прозрачнее CI/CD
- Быстрее локальную обратную связь
Настоящая скорость рождается не из героизма, а из хорошо настроенной системы.

2️⃣ Фокус - это недооценённый актив
Каждое прерывание стоит дорого. Непонятная ошибка, внезапный статус-митинг, кривой tooling, шумные алерты - всё это рвёт контекст. А восстановление контекста часто занимает заметно больше времени, чем само прерывание. Интересна мысль про то, что developer productivity часто тонет не в больших проблемах, а в постоянной мелкой фрагментации внимания.

3️⃣ Когнитивная нагрузка - главный скрытый налог
Если для обычной продуктовой задачи инженеру нужно помнить особенности пяти пайплайнов, трёх систем мониторинга и семи способов доставки, то проблема не в инженере. Плохой DevEx часто выглядит именно так: разработчик пришёл делать бизнес-фичу, а вместо этого изучает внутренний зоопарк платформенных решений.

Из доклада можно извлечь очень практичные советы для технических руководителей
1) Оптимизируйте не лозунги, а путь работы
Смотрите не на абстрактную "производительность", а на конкретные бутылочные горлышки: сборка, ревью, тесты, деплой, ожидание доступа, диагностика падений.
2) Убирайте фазу угадывания
Если CI/CD падает с сообщением уровня "something went wrong", вы создаёте анти-DevEx. Хорошая система не просто сообщает о сбое, а помогает сразу понять причину и следующий шаг.
3) Берегите инженерный фокус как ограниченный ресурс
Линейных инженеров не стоит без необходимости тащить на статусные синки. Контекст-свитчинг - один из самых дорогих видов потерь в разработке.
4) Снижайте вариативность базовой платформы
Один стандартный CI, один понятный observability stack, единый способ запуска типовых сценариев - это не "ограничение свободы", а способ вернуть командам внимание к продукту.
5) Не путайте внутренний портал платформы с решением проблемы
Склеить 20 плохих процессов в один красивый UI - не значит улучшить DevEx. Иногда лучший интерфейс - это вообще отсутствие ручного шага.

P.S.
У Макса есть много интересных выступлений, например, про "Developer Experience in the Age of AI Coding Agents" я уже рассказывал

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

От классического PDLC к AI-native разработке (Рубрика #ai4sdlc)

Написал статью на Medium про то, как AI меняет не только скорость написания кода, а саму организацию инженерного труда. Мы постепенно движемся от SE 1.0 - процесса с ролями, стадиями и handoff’ами - к SE 2.0, где часть инженерной работы берут на себя AI-инструменты и агенты. Но это не бесплатное ускорение. Если не перестроить review, тесты, CI/CD и guardrails, AI просто переносит bottleneck дальше по цепочке. Для больших компаний рабочая стратегия - не ломать всё сразу, а использовать SE 2.0 как полигон новых практик и затем переносить лучшие из них в основной производственный контур.

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

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

[1/2] Measuring the Impact of AI on Developer Productivity at Meta (Рубрика #AI)

Превосходное выступление от ребят из запрещенной в России Meta, которое я пересматривал раза 3, чтобы получше разобраться со всеми деталями. Выступали Payam Shodjai (senior director of product management) и Pavel Avgustinov (techlead) направления developer productivity в Meta и они рассказали кучу интересных подходов + технических деталей того, как они подходят к этому вопросу. После этого выстулпения я гораздо лучше понял концепты из статьи "What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time" (см. мой разбор).

Основная идея доклада крутилась вокруг вопроса "а как измерять влияние AI-инструментов на реальную инженерную продуктивность в большой компании?". И из доклада видно, что Meta построила всеобъемлющий набор метрик, собрала исчерпывающую телеметрию, научилась учитывать сложные операции в системах контроля версий (это обещали пошарить в новом whitepaper, так как базовый git не умеет делать так, как Sapling от Meta). Дальше они искали прямые корелляции между использованием AI и классическими метриками productivity/business value. И речь тут шла не про стандартный code completion, а о более широком наборе AI-инструментов по всему SDLC.

Если упрощать, то ребята показали, что без хорошей инструментализации разговор про ROI от AI быстро превращается в мнения и ощущения. Поэтому Meta делает ставку не на опросы как единственный источник, а на связку из телеметрии, diff-метрик, поведенческих данных и проверки этих данных на реальных рабочих сессиях. Это хорошо согласуется с описанной Meta системой Diff Authoring Time (DAT), которая объединяет privacy-aware telemetry из IDE, ОС и version control и затем валидируется наблюдательными исследованиями, опросами и визуализациями.

1️⃣ Умная классификация пулл-реквестов с помощью LLM
Долгое время главной метрикой в компании был DDM (Diffs per Developer per Month - количество диффов/коммитов на разработчика в месяц). Однако с внедрением ИИ эта метрика стала уязвима для "закона Гудхарта": разработчики могли искусственно завышать показатели, нарезая задачи на мелкие коммиты, а ИИ генерировал много бойлерплейта (шаблонного кода). Чтобы измерять реальную бизнес-ценность, Meta внедрила метрику Feature DDM. Для этого они используют LLM, которые автоматически анализируют содержимое каждого пулл-реквеста и классифицируют его на:
- Feature Diffs: код, создающий новую продуктовую ценность для пользователя.
- Non-Feature Diffs: рефакторинг, обновление конфигураций, тесты и документация.
ИИ-ассистенты оцениваются именно по тому, насколько они увеличивают количество продуктовых диффов.

2️⃣ Посимвольная телеметрия и внутренние инструменты (Devmate)
Meta не полагается на базовую статистику системы контроля версий. Для сбора данных они используют свой внутренний ИИ-инструмент - Devmate (кастомное расширение для IDE). Главный нюанс их телеметрии - посимвольное отслеживание (character-level tracking). Система точно знает происхождение каждого символа в коде. Meta может с абсолютной точностью сказать, какой процент символов в итоговом слитом пулл-реквесте был напечатан инженером вручную, а какой - сгенерирован нейросетью и оставлен без изменений. Отдельно упоминается про то, что Sapling позволяет умно отслеживать transition между commits и правильнее считать как трансформируется код при помощи edit/rebase и остального, а также кем именно (людьми или автоматикой). Помимо этого, телеметрия отслеживает узкие места всего цикла (SDLC): время нахождения задачи на код-ревью, циклы одобрения и прохождение автоматических тестов.

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

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

[2/2] Measuring the Impact of AI on Developer Productivity at Meta (Рубрика #AI)

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

1️⃣ У пользователей DevMate (внутренний аналог Claude Code или Cursor) выше среднего Meta наблюдала примерно 6–12% рост DDM (Diffs per developer per month). Это не звучит как "революция в 2 раза", но для большой инженерной организации такой прирост уже выглядит существенным, особенно если он устойчиво воспроизводится на больших массивах внутренних данных.

2️⃣ Эффект использования AI был неравномерным. Пока ИИ генерирует условные 10–30% изменений в диффе, выигрыш по времени почти не виден. А заметные улучшения появлялись, когда AI вносил более 60% кода в diff. Это намекает, что максимальный выигрыш возникает не тогда, когда AI используется "понемногу везде", а когда задача и workflow действительно позволяют передать инструменту большой кусок рутинной работы. То есть AI окупается сильнее в задачах, где можно делегировать значимый объем механического кода, а не только подсказки по мелочам.

​3️⃣ Senior engineers использовали AI эффективнее, чем junior, хотя junior могли обращаться к нему чаще. Это важный анти-интуитивный момент: более частое использование не равно большему эффекту. Похоже, выигрывают те, кто лучше задает контекст, умеет проверять ответ модели и понимает, где AI стоит доверять, а где нет. В итоге, в среднем диффы синьоров содержат заметно больший процент AI‑кода, чем диффы джунов. Тезис ребят в том, что опыт, архитектурное мышление и умение формулировать точные инструкции сильно усиливают эффект от ИИ - синьор как будто просто даёт ТЗ не джуну, а модели.
​
4️⃣ После внедрения AI сначала может быть просадка, а уже потом рост продуктивности (J-кривая адаптации). По данным Meta наблюдается просадка продуктивности порядка 15%: люди учатся промптить, перепроверяют код, меняют привычный процесс. Уже после адаптации (через несколько месяцев) начинается устойчивый плюс к DDM и сокращение времени кодинга на дифф, что и даёт итоговые 6–12% роста выхода. Практический смысл тут простой: если компания смотрит на эффект AI только в первые недели после rollout, она может ошибочно решить, что инструмент "не работает".

​5️⃣ Телеметрия показала, что инженеры меньше сидят в чатах и документах, потому что ответы и контекст получают прямо в IDE через DevMate. Из‑за этого время "coding time per diff" формально растёт, но авторы считают это хорошим сигналом: меньше дёрганья по ссылкам и мессенджерам, больше фокуса в одном инструменте.
​
6️⃣ Не все команды выигрывают одинаково - команды с высокой долей ML/ресёрча показывают меньший рост DDM, потому что много времени уходит на ноутбуки, эксперименты и аналитику, которые плохо отражаются в "диффах". Также DDM сильно "шумит" от праздников и внешних факторов, поэтому Meta не использует его в лоб как KPI для людей, а только как агрегированную продуктовую метрику влияния ИИ‑инструментов.
​
Если подводить итог, то я могу порекомендовать это видео и сопутстующие whitepaper тем, кто занимается вопросами измерения эффекта AI в разработке - это хороший методологический и практический подход к этой сложной теме.

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

The Software Development Lifecycle Is Dead (Рубрика #Software)

В это интересной февральской статье 2026 Boris Tane делает громкое заявление о смерти SDLC, которое по моему мнению хорошо отражает ситуацию стратегически, но опережает текущие подходы на годик. Сам я думаю, что мы перейдем от классического PDLC к AI-native разработке и эту статью Бориса упомянул @brolnickij в канале @ai4sdlc, где можно обсудить посты из этого канала и не только.

Если возвращаться к главному тезису Бориса в его статье, то он такой
- Классический SDLC с фазами requirements → design → implementation → testing → code review → deployment → monitoring больше не распадается на отдельные этапы
- Вместо этого появляется короткий цикл: intent + context → agent → build/test/deploy → observe → repeat

Ну и дальше очень интересен взгляд автора на новый lifecycle по стадиям
- Требования больше не замораживаются перед стартом задачи, а уточняются по ходу итераций
- System design теперь не предписывается заранее, а обнаруживается в диалоге с агентом
- Имплементация изменений в коде почти целиком уходит агенту
- Тестирование теперь существует не отдельно, а тесты пишутся вместе с кодом (как многие хотели раньше)
- PR/code review как отдельный ритуал должны исчезнуть и стать exception-based (на случай, если автоматика не спрашивала)
- Деплои становятся действивтельно continuous и by design отделяются от release через flags/rollbacks
- Мониторинг превращается из последнего этапа в главный safety layer всей системы

Из этого у него следует довольно жесткий вывод: новый главный навык - context engineering, а новый контур safety - это observability. То есть выигрывает не та команда, у которой больше церемоний, а та, которая лучше умеет собирать контекст, задавать ограничения агенту и быстро замыкать telemetry обратно в цикл изменений. Это хорошо бьется и с DORA: они отдельно выделяют AI-accessible internal data и context engineering как ключевую capability для AI-assisted разработки.

Все это выглядит очень реалистично для небольших компаний или на greenfield проектах - инструменты уже реально умеют работать на уровне всего репозитория: читать codebase, менять много файлов, запускать команды и тесты, делать refactoring и code review. OpenAI пишет, что Codex заточен под длинные инженерные задачи и review, а Anthropic показывает, что опытные пользователи со временем дают агенту больше автономии, хотя продолжают активно вмешиваться по ходу работы. Плюс бенчмарки вроде SWE-bench Verified показывают, что agentic systems уже решают заметную долю реальных issue из open-source.

А вот что ждет большие компании и как будет выглядеть переход я рассказывал в статье "От классического PDLC к AI-native разработке"

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

Just-in-Time Catching Test Generation at Meta (Рубрика #Engineering)

Исследователи запрещенной в России Meta написали интересный whitepaper про новый класс автотестов - regression catching tests. Стандартные hardening тесты должны проходить на текущем коде и страховать от будущих регрессий. Новые catching tests специально должны упасть на конкретном входящем diff и при этом пройти на родительской версии. Идея в том, чтобы не ждать, пока баг всплывет потом, а попытаться поймать его в момент ревью или CI, до вливания кода. Интересно, что сгенерированные авторами тесты должны детектировать регрессии не на основе implicit oracle (что реагирует на очевидные проблемы типа крашей), а на основе общего оракула (general oracle), который представляет собой правильное поведение, зачастую плохо определенное и только частично известное.
Авторы отдельно различают weak catch и strong catch:
- Weak catch просто тот, что падает на текущей ревизии
- Strong catch означает, что тест действительно указывает (true positive) на реальную ошибку в ожидаемом поведении (на основе general oracle)
- Strictly weak catch - это false positive, что указывает на проблему с тестовым набором
Основная задача в том, чтобы научиться определять, что weak catch на самом деле является strong catch. Это интересно, так как LLM используется не как еще один генератор unit-тестов ради покрытия, а как часть системы раннего перехвата регрессий. В Meta этот контур запускается на высокорисковых diffs (аналог PRs в GitHub) и работает на системах в сотни миллионов строк кода и целится именно в тяжелые, дорогие ошибки, а не в косметические поломки.

Основные результаты статьи присустствуют прямо в абстракте (первой части любой статьи). Собственно, цель была в том, чтобы победить замедление разработки из-за false positive тестов. Авторы проанализировали 22,126 сгенерированных тестов и показали, что
- Code-change-aware методы улучшают генерацию кандидатов, ловящих проблемы в 4 раза по сравнению с обычными hardening tests и на в 20 раз по сравнению с случайно упавшими тестами
- Для борьбы с false positives авторы использовали rule-based and LLM-based ассессоры. Эти подходы уменьшают нагрузку на людей на 70%
- Inferential statistical analysis показывает, что human-accepted code changes имеют значительно больше false positives, а human-rejected changes имеют больше true positives
- Авторы сообщают о 41 candidate catches на инженере, 8 из которых true positives, а 4 из которых могли привести к значительным проблемам на проде, если бы их не поймали

При этом ложные тревоги, по словам авторов, обычно закрывались за минуты и почти не били по developer velocity. Авторы при этом не перегибают палку: они прямо пишут, что выборка пока слишком маленькая, чтобы делать слишком сильные научные выводы о доле тяжелых багов. Но они отмечают, что этот подход масштабируем, применим в индустрии и позволяет предотвращаться серьезные проблемы

Главный вывод для меня такой: это не paper про "магическую автоматизацию QA", а paper про рабочий инженерный контур. LLM + мутационное тестирование + дешевый human-in-the-loop уже дают способ спорить с incoming diff’ом и задавать автору очень полезный вопрос: "ты точно хотел изменить поведение именно так?". В следующих сериях авторы планируют добавить лучшее восстановление намерения изменения + брать более богатый контекст diff’а и прийти к более уверенному отделению weak catch от strong catch.

#AI #QA #Engineering #Whitepaper #Software #LLM #DevOps

[1/2] Agentic coding at Airbnb (Рубрика #Agents)

Это очередной интересный доклад с сентябрьского DPE Summit, про который я рассказывал раньше. В нем ребята из Airnbnb рассказывали как они выстроили у себя агентскую модель разработки и двинулись от классического PDLC к AI-native разработке (примерно в ту сторону, что я описывал в одноименной статье). И тут речь не про какие-то игрушечные приложения, создаваемые агентами, а про агентскую разработку в их монорепе со стандартными требованиями по безопасности, комплаенсу и с 1к+ инженерами в ней. Причем авторы для описания подхода использовали метафору из парного программирования, практики XP (extreme programming), где два инженера вместе делали фичи: один был навигатором и думал о стратегии, а второй был пилотом, держал клавиатуру и писал код. В этой метафоре роль пилота забрал агент, а роль навигатора осталась за инженером. В начале 2025 года ребята ожидали, что такой режим распространиться на 20% - 40%, но к сентябрю они уже перевыполнили план и достигли примерно 60%

Путь Airbnb к этому выглядит достаточно предсказумым и понятным
1) Сначала у них был IDE-first подход: внутренние плагины с хорошим UX, доступом к контексту редактора и собственной knowledge/RAG-пайплайном для учета специфики Airbnb
2) Потом рынок резко двинулся в сторону CLI-агентов: они оказались сильнее как агентские инструменты, умели сами делать несколько шагов подряд, вызывать инструменты и принимать локальные решения
3) Airbnb адаптировались и попробовали посмотреть на мир как на CLI-first, но быстро увидели проблему: внешние CLI-инструменты давали классные ответы для внешних проектов, но плохо знали их монорепы, внутренние паттерны и кодовую базу компании
4) Дальше они сделали очень зрелый ход: не стали спорить IDE или CLI, а собрали небольшую core-команду и кросс-функциональную рабочую группу, чтобы привести все поверхности к одному уровню. У команды было всего четыре инженера плюс продуктовая поддержка, поэтому они сознательно сузили фокус до трех ставок:
- Принести агентов в Airbnb
- Принести знания Airbnb в агентов
- Стандартизироваться вокруг MCP
Параллельно они развернули champion/community-модель через хакатоны, talks и внутреннюю рабочую группу

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

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

[2/2] Agentic coding at Airbnb (Рубрика #Agents)

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

Для того, чтобы реализовать первую цель, а именно "принести агентов в Airbnb", они построили Air Chat - абстракцию-обертку над несколькими движками. Это дало единую входную точку: можно быстро выкатывать новые CLI-агенты и обновления, не привязывая всю платформу к одному вендору или одному инструменту. Дальше они очень рано пошли в MCP, потому что стандарт был близок к их уже существующему tool-calling подходу. В результате Airbnb смогли: завернуть любимые IDE инструменты в MCP сервера, встроить MCP клиентов в IDE-плагины, а конфигурацию и синхронизацию серверов централизовать через Air Chat CLI. Со временем это выросло в экосистему с более чем дюжиной внутренних MCP-серверов, включая аналитические и CI-инструменты.

Для того, чтобы реализовать вторую цель, а именно "принести знания Airbnb в агентов" они поменяли свой подход к работе с базой знаний (knowledge base). Раньше у них была "линейная" one-shot схема: запрос → knowledge endpoint → ответ. Для агентного режима это работало плохо. Но они решили не играть в дообучение моделей (fine-tunning) как главный путь, а просто завернули получение знаний из базы знаний (knowledge base) в MCP, а дальше позволили агентам итеративно доуточнять информацию: если первый ответ не подошел, агент сам уточняет поиск, меняет термины и делает deeper research внутри ваших внутренних знаний.

Еще они рассказали как пытались строить собственную multi-agent orchestration-модель с planning/coding/validation agents, но рынок двигался слишком быстро, а маленькая команда не успевала наращивать нужную "мышцу". Поэтому Airbnb не уперлись в "мы обязаны написать свой оркестратор", а сделали прагматичный поворот (pivot): основной агент теперь живет как CLI-agent, а сверху у него тонкая прокладка для других поверхностей. Круто, что ребята честно рассказали про свое решение - зачастую синдром NIH (Not Invented Here) не позволяет принять такое решение или даже если оно принято, то не позволяет о его принятии рассказывать:)

Если подбивать выводы ребят из их пути, то они примерно такие
1) Agentic coding - это не просто чат в IDE, это новый inner loop, где агент многократно дергает LLM, инструменты и внутренние знания, а на выходе приносит код, который все равно должен быть просмотрен человеком до PR
2) Рост идет не только от auto-approve настройки агента, а от умения инженера управлять несколькими параллельными workspaces; в Airbnb некоторые продвинутые пользователи открывают до пяти агентных сессий одновременно
3) Агент сам по себе ничего не решает: вокруг него нужны sandbox/workspace-инфраструктура, auth, security paved path, шаблоны, установка в одну команду и нормальная review-культура
4) А организационный вывод ребят такой - не надо ломать существующие привычки команд ради модного AI UX. Они прямо говорят, что идея "давайте всех пользователей IntelliJ переведем в VS Code, потому что там лучше agentic tooling" быстро провалилась. Вместо этого нужно убирать барьеры, встречать разработчиков там, где они уже работают, и стандартизировать только то, что действительно стабилизировалось на рынке. При этом качество нельзя опускать "потому что это AI": стандарты остаются прежними, ревью обязателен, код тоже должен быть готовым к проду, а пользоваться auto-approve без набитой руки - опасно.

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

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

От AI-native разработки к AI-native организации (с примерами из опыта бигтехов (Рубрика #AI)

Написал статью-продолжение к статье про ai-native разработку "От классического PDLC к AI-native разработке". Основная завязка новой статьи крутится вокруг идеи, что если переход к ai-native разработке меняет сам инженерный процесс, то дальше меняется оргструктура - это видно по анонсам и действиям бигтех компаний, что из больших активнее всего участвуют в гонке AI. А дальше это затронет и остальных. Суть в том, что когда требования, код, тесты и документация начинают собираться в разы быстрее, узким местом становится уже не написание артефактов, а принятие решений, передача контекста и количество организационных слоёв. Отсюда следующий шаг: компаниям мало просто выдать инженерам AI-инструменты. Нужна оргмодель, которая умеет переваривать новую скорость работы. Это обычно означает меньше слоёв управления, больший вес senior+/staff+ IC, сильную внутреннюю платформу, self-service, guardrails и agentic workflows. Важно, что переход к более плоской структуре (flattening) - это не только про срезание затрат. Это попытка повысить выхлоп на сотрудника и убрать организационное трение на единицу результата. Правда, такая модель не работает сама по себе: без сильной платформы, качественного CI/CD, прозрачных policy checks и понятных правил принятия решений AI просто ускорит хаос.

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

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #SystemDesign

State of Code Developer Survey report by SonarSource (Рубрика #AI)

Интересный 57-страничный отчет от производителя SonarQube, средства для верификации качества кода. Отчет вышел еще 8 января 2026 года, а основан был на опросе от октября 2025 года. Если обобщить одной фразой основную мысль, то она такая: AI не снял нагрузку с разработки - он просто перенёс бутылочное горлышко из написания в в верификацию кода.

Методология исследования выглядела как количественный онлайн-опрос на 1149 респондентов по всему миру. В выборке - взрослые специалисты в tech-ролях, которые пишут код или управляют разработчиками и использовали AI в работе за последний год. Вопросы были не просто "используете ли вы AI", а как именно он меняет инженерную работу:
- Где AI реально помогает
- Где есть разрыв между принятием (adoption) и эффетивностью (effectiveness)
- Доверяют ли разработчики AI-коду
- Как меняются безопасность и технический долг
- Что происходит с junior/senior инженерами и есть ли разница в их отношении к  AI
- Что с использованием AI агентов
- Что происходит с управлением всем этим зоопарком инструментов

Результаты вышли такие
- AI уже не эксперимент, а рутина: 72% тех, кто попробовал AI coding tools, используют их каждый день, а в среднем 42% кода в коммитах уже AI-generated или AI-assisted
- Ценность AI распределена неровно: лучше всего AI показывает себя в документации, объяснении существующего кода и генерации тестов; заметно хуже - в рефакторинге и изменении существующего кода (напомню этот опрос был до большого сдвига в возможностях моделей осенью 2025 года)
- Параллельно команды жонглируют в среднем 4 AI-инструментами, а 35% разработчиков используют часть из них через личные аккаунты, а не через санкционированный на работе доступ.

В итоге, скорость личная выросла, но доверие не появилось. 96% не полностью доверяют функциональной корректности AI-кода. 95% тратят время на review/testing/fixing AI output, 38% говорят, что ревьюить AI-код сложнее, чем человеческий, а только 48% всегда проверяют AI-assisted code перед commit. Неудивительно, что самым важным навыком в AI-era респонденты назвали ревью и валидацию AI-кода на качество и безопасность.

Если говорить про больные места, то 57% опасаются утечки чувствительных данных, 47% - появления новых subtle security vulnerabilities. По техническому долгу картина тоже двойственная: 88% увидели хотя бы один негативный эффект AI на долг, чаще всего “код выглядит правильным, но ненадёжен” (53%) и лишний/дублирующий код (40%). Но 93% одновременно увидели и пользу: AI помогает с документацией, тестами/debugging и частью refactoring work. Junior-разработчики чаще опираются на AI и чаще говорят, что проверка такого кода требует больше усилий, чем у senior.

Также заметна разница между организациями разного масштаба:
- Малые и средние компании (SMB) снимают больше пользы с ускорения поставки и быстрее улучшают time-to-market, а корпораты чаще видят улучшения в качестве кода и поддерживаемости - похоже, за счёт более жёсткой governance и контроля AI-рисков.

Выводы авторов отчета простые - процессам разработки нужно понимать происхожение кода, усилить ревью кода, добавить quality gates, статический анализ, и выстроить нормальный governance вокруг AI-инструментов. Иначе ускоряется не поставка, а производство непроверенного кода. Ну и конечно со всем этим может помочь SonarQube от авторов исследования:)

#Engineering #Software #DevOps #DevEx #Process #Management #Metrics

The End of Coding: Andrej Karpathy on Agents, AutoResearch, and the Loopy Era of AI (Рубрика #AI)

Посмотрел свежий выпуск подкаста "No Priors" с Andrej Karpathy. Эта серия была опубликована 20 марта 2026 и с Андреем общается Sarah Guo, основатель Conviction и ведущая подкаста, а главной мыслью выпуска была тема о том, что software engineering уже сдвигается от написания кода к оркестровке агентов. По словам Андрея, он с декабря почти перестал писать код руками и резко сместился в режим делегирования задач агентам; по его ощущению, у многих инженеров frontier-уровня default workflow уже успел радикально поменяться.

Другая интересная мысль в том, что бутылочное горлышко сместилось с IDE и даже вычислительных мощностей в сторону человека - Андрей описывает это как переход от мышления про FLOPS к мышлению про пропускную способность токенов (token throughput). Если агент может автономно 20 минут делать кусок работы, то ценность инженера смещается в правильную декомпозицию задач, параллельный запуск нескольких потоков и review на уровне архитектуры, а не строк кода.

Интересна также тема AutoResearch - если у задачи есть объективные метрики, то агент может сам менять код, запускать короткие эксперименты, измерять результат и оставлять только улучшения. В открытом репозитории Karpathy это оформлено почти как минимальная исследовательская ОС: агент правит train.py, работает в фиксированном 5-минутном бюджете и оптимизирует val_bpb; program.md фактически становится “кодом исследовательской организации”. Это и есть его автоматическая работа в цикле эксперимент → метрика → изменение → повтор, где человек уже не нужен.

Правда, Андрей отмечает, что такой режим работает не всегда, а только там, где есть верифицируемая награда и понятный способ оценки результата (eval). Там, где нужны вкус, есть неформализованные ожидания и мягкие критерии качества, то модели по-прежнему очень неконсистентны: в одном месте блестящие, в другом - удивительно наивные. Это важная поправка к хайпу про "автономных разработчиков".

Также Андрей рассказал про своего домашнего агента Dobby, который через WhatsApp управляет светом, HVAC, шторами, бассейном, спа и безопасностью дома. Из этого он делает жёсткий вывод: возможно, заметная часть сегодняшних приложений - это временный UX-слой, а более правильная архитектура будущего - это API/tool surface + агент как клей.

В общем, это действительно интересный подкаст, в котором Андрей делится практикой, а не футуристическими идеями.

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #SystemDesign

TAM-Eval и RM-RF от RnD центра Т-Технологий (Рубрика #Engineering)

Наш R&D-центр представил пару методов TAM-Eval и RM-RF, которые делают генерацию модульных тестов с помощью LLM заметно более практичной для наглядности разработки.

TAM-Eval задает воспроизводимые стандартные оценки качества тестов в живых репозиториях, а RM-RF еще умеет до сборки и запуска предсказать, какие тесты действительно полезны. На практике это означает меньшие дороги прогонов, меньшую нагрузку на инфраструктуру и цикл CI/CD. Это особенно важно в мире, который быстро движется в сторону AI-native разработки (см. пост) : когда код и тесты все чаще генерируют модели, главным конкурентным преимуществом становится уже не только генерация, но и надежная, быстрая оценка качества . Без этого AI-ускорение легко превращается в ИИ-хаос.

Эти статьи хорошо приняты академическим сообществом: RM-RF принята в основной трек SANER 2026 , а TAM-Eval - на VST 2026.

Напоследок процитирую Станислава Моисеева, руководителя RnD центра, который так описывал пользу этих методов

Эти методы делают работу больших языковых моделей с тестами более предсказуемой и эффективной для реальных процессов разработки. TAM-Eval задает стандарт сравнения моделей и агентов в сопровождении тестов по измеримым метрикам, а RM-RF позволяет отсеивать слабые тесты и ранжировать сильные без дорогостоящего запуска пайплайна на каждом шаге.

#Engineering #RnD #AI #DevOps #Software

Optimizing for Time: Dark Matter (Рубрика #DevEx)

С большим интересом посмотрел доклад с концеренции DPE Summit Карима Накада (Karim Nakad) из запрещенной в России компании Meta. Мне понравилось название, которое отсылает к космологическим теориям, объясняющим через темную материю состояние нашей Вселенной. Здесь эта метафора относится к тому, что мы часто фокусируемся на видимом спектре разработи: на улучшении IDE и ускорении сборок, но игнорируем огромные затраты времени на ежедневную рутину. Собственно, спикер называет "тёмной материей" невидимую нагрузку на сотрудкниов: чтение корпоративных чатов, стендапы, написание документации и помощь коллегам. Измерение этих скрытых активностей помогает выявить истинные причины снижения скорости работы технических команд.

Мне особенно нравится разбор метрик продуктивности Meta, про которые я говорил и в других постах, например, при разборе выступления "Measuring the Impact of AI on Developer Productivity at Meta" с этой же конференции. Но в этом выступлении этот рассказ сфокусирован именно на метриках. Отдельно отмечается, что в Meta применяют агрегированные показатели для анализа процессов, строго запрещая их использование для индивидуальной оценки инженеров во избежание накруток. Сами метрики такие

- By Tool -» TSD (Time Spent Coding per Diff): отражает время кодинга на один пулл-реквест, что позволяет инфраструктурным командам оценивать эффективность инструментов разработчика.
- By Intent -» PCT (Percent Time Coding): показывает долю чистого программирования по отношению ко всем остальным задачам, помогая сокращать количество лишних встреч. Метрика важна для продуктовых команд
- By Workflow -» WTS (Workflow Time Spent): отслеживает затраты времени в разрезе конкретного процесса (например, устранения инцидента) для поиска узких мест при переключении между системами.
- By Value -» но здесь не показали метрики, а привели метафору про карту и про движение в нужном направлении (как бы это нужное направление не измерялось)

Если говорить про подучу, то мне понравились слайды про фрагментацию дня. На слайдах видно, как день инженера распадается на десятки коротких переключений между IDE, чатом, календарём, review tools, notebook и SQL. Интересно, что Meta предлагает смотреть не только на raw coding time, но и на coding intent time - то есть считать инженерной работой не только минуты в редакторе, но и связанные с задачей походы в чат, wiki, SQL и документацию. Иначе очень легко оптимизировать не то место.

Мне показались полезными идеи для инженеров о том, что надо защищать длинные focus-блоки, группировать коммуникации, глушить некритичные уведомления и перестать думать, что "настоящая работа" происходит только внутри IDE. А руководителям полезно посчитать стоимость переключения контекста и сравнить со стоимостью медленного билда; отдельно посмотреть на фокусное время команды, структуру календаря, объём асинхронного шума и только потом уже докручивать инструментарий. Иначе можно ускорить pipeline и всё равно потерять пропускную способность команды.

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

От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear) (Рубрика #Management)

Написал статью про то, что эпоха фразы “заведи тикет в Jira” подходит к концу … и не потому, что тикеты исчезнут, и не потому, что завтра все команды внезапно переедут в какой-то новый инструмент, а потому, что тикет перестает быть центром мира. В классической модели он был основной единицей координации: в нем жили требования, приоритет, исполнитель, статус, комментарии, передача ответственности между ролями. В AI-native мире этой единицей постепенно становится не тикет, а context: намерение, ограничения, права доступа, история решений, автоматизации и агенты, которые способны доводить работу до результата.

В некотором смысле эта статья логично продолжает две предыдущие
- Про переход от классического PDLC к AI-native разработке
- Про переход от AI-native разработки к AI-native организации

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

#Engineering #Software #DevOps #DevEx #Process #Management #Metrics

The State of DevOps Modernization 2026 (Рубрика #Devops)

Изучил недавно вышедший отчет "The State of DevOps Modernization 2026" от Harness. Отчет основан на опросе ~700 инженеров и руководителе, что был проведен в феврале 2026 года компанией Coleman Parkes. Основной вывод отчета в том, что AI резко ускорил локальный цикл кодирования, а остальная часть delivery контура во многих командах внутри корпораций не успевает его переварить.

Основная аналитическая модель отчета очень простая: почти все выводы построены через cross-tab по вопросу "как часто вы используете AI инструменты для кодирования" - от нескольких раз в день до более редкого использования. То есть это не анализ телеметрии и не каузальный инференс как в DORA, а срез восприятия и самооценок респондентов.

Авторы выделил следующие ключевые результаты

1️⃣ Скорость действительно выросла. 45% very frequent AI пользователей говорят о ежедневных или чаще развертывания против 32% у frequent и 15% у occasional users. Но рядом с этим идет налог на стабильность: 69% very frequent users говорят, что AI-generated code приводит к проблемам с развертыванием как минимум в половине случаев; 22% deployments в этой когорте заканчиваются rollback, hotfix или customer-impacting incident; MTTR по таким инцидентам у них выше - 7.6 часа против 6.0 и 6.3 часа в соседних когортах.

2️⃣ Но это напряжение распространяется далеко за пределы инцидентов. Среди very frequent AI users 50% говорят о росте vulnerabilities/security инцидентов и 50% - о росте non-compliance issues; 49% видят больше проблемы с производительностью; 51% - больше code quality/efficiency problems. При этом сами авторы специально оговаривают: явной причинно-следственной связи между AI coding и этими проблемами отчет не доказывает (такой дизайн эксперимента может показать только корреляции)

3️⃣ Coding автоматизируется быстрее, чем остальной SDLC. 84% респондентов используют AI ежедневно для coding, но для QA testing этот показатель 68%, для performance/cost optimization 63%, для refactoring 62%. 47% very frequent users говорят, что ручная работа дальше по пайплайну после кода стала проблемнее (это QA, code review, remediation); 69% теряют время из-за медленных и ненадженых CI/CD; 70% считают, что их pipelines страдают от flaky тестов and неуспешных развертываний; 75% связывают давление на шиппинг с выгоранием; 73% говорят, что у них почти нет стандартных темплейтов и golden paths

В итоге, видно, что проблема в том, что AI усиливает throughput там, где платформа, CI/CD, гейты контроля и координация остались на старой скорости. Авторы сами это почти проговаривают: у них есть гипотеза, что heavy AI users просто пытаются доставлять больше кода и поэтому острее чувствуют flaky tests и deployment failures; их pipelines не обязательно хуже, просто потребности уже выше. Это сильный инсайт, но как доказательств причинности отчет не дает:)

Примерно эти же мысли я писал в статье "От классического PDLC к AI-native разработке", но в основном опирался на другие исследования типа DORA или нашего AI4SDLC, который мы проводили от "Т-Технологий" в конце прошлого года и проведем еще раз в этом году

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

[1/2] The State of DevOps Report 2026 от Perforce (Рубрика #DevOps)

Изучил новый "State of DevOps 2026" от Perforce, который фокусировался на вопросе: что на самом деле определяет успех AI в системе поставки ценности - сами AI-инструменты или зрелость инженерной системы. Этот вопрос обусловлен вендорской спецификой, так как Perforce - это вендор Devops стека, поэтому авторы исследовали связь между зрелостью DevOps процессов, глубиной внедрения AI, ролью платформенной инженерии и IDP, а также пробелами в измерениях и экономическим эффектом AI относительно стоимости. Ну и ребята пришли к логичному выводу, что для масштабирования AI нужны зрелые DevOps практики и процессы.

Методология выглядела как опрос 820 респондентов из глобального собщества, которые принимают IT решения, влияют на IT закупки, выбор инфраструктурных и платформеннных инструментов, а также на mission-critical приложения. С учетом такой выборки это скорее менеджерский взгляд на связь зрелости DevOps практик и AI, а не взгляд с позиции инженеров. Забавно, что авторы отфильтровывали из отчета менеджеров, которые не смогли бы объяснить коллегам термин "Agentic AI". А зрелость DevOps процессов авторы определяли операционно: через степень стандартизации delivery, качество работы с инцидентами, а также долю автоматизации деплоев, наличие автоматических rollback. В общем, авторы не претендуют на репрезентативность и выявление причинно-следственных связей, но дают интересную описательную статистику.

В основу исследования легли четыре ключевых вопроса
1) Влияет ли зрелость DevOps на успех AI?
2) Что нужно, чтобы AI масштабировался между командами - локальные инструменты или централизованные системы, IDP (внутренние платформы разрботки) и control planes?
3) Умеют ли компании измерять и аудировать AI, или пока просто "верят", что он помогает?
4) Есть ли экономический эффект, и не съедают ли его cloud/compute затраты?
Собственно, поэтому сам отчет и состоит из четырех частей:)

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

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

[2/2] The State of DevOps Report 2026 от Perforce (Рубрика #DevOps)

Продолжая рассказ про новый отчет "State of DevOps 2026" от Perforce, поделюсь основными результатами, которые представляют менеджерский взгляд на связь зрелости DevOps практик и AI (ребята так подбирали респондентов, чтобы это были в основном менеджеры, что принимают решения по инфраструктурным и платформенным решениям в своих компаниях).

1️⃣ 70% респондентов говорят, что зрелость DevOps заметно повлияла на успех AI
При этом только 38% организаций реально встроили AI глубоко в несколько стадий SDLC, еще 38% используют его часто, но без стандартизации, а 17% остаются на уровне ограниченных пилотов. Разрыв по зрелости огромный: в high-maturity организациях 72% лидеров говорят о deeply embedded AI, в mid - 43%, в low - 18%. В итоге, видно, что для масштабирования AI инициатив важна не покупка AI инструментов, а скорее подготовленная почва в виде зрелых инженерных процессов

2️⃣ AI наследует операционную модель работы, а не чинит ее
В отчете 32% организаций описаны как highly standardized, 35% - mostly standardized, а 34% продолжают жить в частичной или хаотичном деливери. То есть примерно треть рынка по‑прежнему находится в зоне, где результат зависит от конкретной команды. Perforce называет это проблемой вариантивности: пока рабочие процессы, окружения и governance отличаются от команды к команде, AI будет давать столь же неравномерный результат. Отсюда и акцент на control plane: не "еще один инструмент", а шаренные шаблоны, шаренные стандарты, шаренные пайплайны и управляемые окружения.

3️⃣ На рынка уже есть разрыв в уверенности между доверием к AI и реальной интеграцией AI инструментов в процессы
77% респондентов говорят, что доверяют AI outputs, но только 38% действительно глубоко встроили AI в delivery, и лишь 39% имеют полностью автоматизированные данные для аудита. В части про измерения авторы формулируют риск прямо: организации доверяют AI быстрее, чем успевают построить проверяемость, auditability и согласованную измеримость. Это важный антидот против иллюзии, что рост локальной продуктивности в IDE уже означает зрелый AI-native delivery.

4️⃣ Экономический эффект есть, но он не возникает автоматически
74% опрошенных считают, что AI встречается с завышенными ожиданиями. Отдельно Perforce показывает, что ROI сильнее у тех, у кого зрелая система поставки: high-maturity организации на 36% чаще автоматизируют 61%+ деплоев от коммита до прода и на 66% чаще "very effectively" отвечают на продовые инциденты. У low-maturity организаций, наоборот, 78% delivery не стандартизованы а только 19% очень эффективно реагируют на инциденты. Если на пальцах, то без зрелого DevOps AI может ускорить работу, но одновременно увеличить долю переделок, вариативность результатов, время downtime и затраты.

На мой взгляд, отчет Perforce очень хорошо подтверждает базовый тезис из моей статьи "От классического PDLC к AI-native разработке", что AI-native - это не еще один умный инструмент, а перестройка всей системы создания, проверки и поставки изменений. Только я иду еще дальше и размышляю про отдельные роли в этом новом процессе:)

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

State of AI4SDLC на DevOpsConf 2026 (Рубрика #DevOps)

Завтра я открываю конференцию DevOpsConf первым докладом в главном зале и расскажу про наше исследование AI4SDLC, а также что это значит для нас как инженеров, занимающихся разработкой и поставкой софта в продакшен. Я расскажу про то, как выглядят новые процессы разработки, а также про то, как их внедряют в зарубежных бигтехах, а также как действуем мы в Т-Банке.

Вообще мое выступление будет состоять из следующих частей

1️⃣ Как себя чувствует индустрия
Здесь я расскажу про наше исследование AI4SDLC, которое мы проводили в конце прошлого года и которое состояло из мета-исследования и опроса в котором поучаствовала примерно тысяча респондентов со всей России. Мы хотели ответить на вопросы
- В каких задачах разработки AI используется чаще всего, а где остаётся редким?
- Как соотносятся изменения продуктивности и качества (опросы, телеметрия, эксперименты)?
- Как доверие к AI-коду связано с практиками проверки (ревью, тесты, quality gates)?
- Какие элементы процесса превращают индивидуальный эффект в командный?
Сами результаты доступны здесь

2️⃣ От классического PDLC к AI-native-разработке
Здесь я расскажу про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Здесь я поделюсь сигналами от западных бигтех компаний, а также расскажу как мы идем примерно в эту же сторону. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.

3️⃣ От AI-native-разработки к AI-native-организации
Здесь я расскажу о том, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Тут опять будут сигналы от западных бигтех компаний + размышления о том, почему так происходит, какие преимущества дает и какие вопросы при этом требуется решить. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.

4️⃣ От классического task management к AI-native: как меняется сама единица работы. Тут я расскажу про подходы Atlassian и Linear, которые практикуют разные подходы к управлению задачами и являются лидерами рынка для корпораций и стартапов соответственно. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.

5️⃣ Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году. Тут я расскажу про то, как бигтехи подходят к организации этого перехода и постановке целей внутри организации, а также как они планируют измерять результат. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.

P.S.
У нас есть отдельный сайт ai4sdlc.tbank.ru про наши AI решения для разработки. И мы их не только используем внутри, но и продаем крупным компаниям.

P.P.S.
Если будете очно на кофне, то можете поймать меня и пообщаться.

#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes