В сентябре 2025 года вышел новый отчет
State of AI-assisted Software Development Report от DORA, подготовленный при поддержке Google Cloud и IT Revolution. Напомним, что исследования DORA проводятся ежегодно с 2014 года и за 11 лет в них приняли участие свыше 45 тысяч профессионалов по всему миру, работающих в компаниях различных размеров и отраслей. В этом году к авторам отчета присоединился Gene Kim, который также анонсировал выход новой
книги Vibe Coding. Отчет получился объемным — 140 страниц, мы внимательно изучили новый отчет и подготовили краткий обзор.
В этом году исследование сфокусировано на трех направлениях —
AI adoption,
Platform Engineering, Value Stream Management, а также и их влиянии на
Software Delivery Performance,
Organizational и
Product performance,
Individual effectiveness,
Code Quality,
Valuable work,
Friction и
Burnout.
В исследовании в этом году приняло участие 4 867 профессионалов (на 30% больше по сравнению с прошлым годом) из 3-х основных индустрий:
Technology,
Financial Services и
Retail/E-commerce. Большинство участников работают в компаниях с численностью более 200 сотрудников, половина в компаниях больше 1000 сотрудников. Основную аудиторию составляют инженеры (80%), в среднем у них 6 лет на текущей роли и 3 года в текущей команде. В опросе приняли участие специалисты из 100 стран, среди которых лидируют США, Великобритания, Индия, Германия, Канада, также есть участники из Китая и России. Дополнительно проведено 78 интервью для расширенного анализа.
Что интересного мы отметили в отчете:
1. Новая модель измерения Software Delivery Performance. В 2025 году команда DORA обновила подход к оценке производительности поставки ПО. Теперь она рассматривается через две ключевые категории:
Throughput и
Instability.
Throughput показывает, насколько быстро и эффективно изменения проходят через систему, и оценивается по трем метрикам —
Lead time for changes (время от коммита до развертывания в production окружение),
Deployment frequency (частота развертываний или интервал между ними) и
Failed deployment recovery time (время восстановления после неудачного развертывания, требующего немедленного вмешательства).
Instability отражает качество и надежность поставки, измеряется через
Change fail rate (доля развертываний, требующих отката или хотфикса) и новую метрику
Rework rate (доля незапланированных развертываний, вызванных инцидентами в production окружении).
2. Вместо профилей эффективности представлены Team Archetypes. Вместо прежней классификации команд по уровням
Elite, High, Medium, Low выделено семь типов команд на основе кластерного анализа:
- Foundational challenges (10%) — команды в режиме выживания, сталкивающиеся с фундаментальными проблемами;
- Legacy bottleneck (11%) — команды, чья работа постоянно ограничивается нестабильными системами и частыми сбоями;
- Constrained by process (17%) — команды, чью эффективность сдерживают громоздкие и неэффективные процессы;
- High impact, low cadence (7%) — команды с высокой результативностью, но низким ритмом поставки и низкой стабильностью;
- Stable and methodical (15%) — команды, демонстрирующие стабильную и последовательную работу с высоким качеством;
- Pragmatic performers (20%) — команды, демонстрирующие высокую скорость и стабильность, даже если вовлеченность не максимальна;
- Harmonious high-achievers (20%) — команды, работающие в сбалансированной и благоприятной среде, достигающие высокой продуктивности без признаков выгорания.
3. Сценарии применения AI и оценка влияния. 90% участников используют AI в работе (рост на 14% по сравнению с прошлым годом), медианный опыт применения — 16 месяцев. В среднем инженеры проводят 2 часа рабочего дня во взаимодействии с AI. Основные сценарии: написание кода (71%), literature review (68%), модификация существующего кода (66%), корректура (66%) и работа с изображениями (66%). Основные каналы взаимодействия — чат-боты и AI в IDE. Более 80% респондентов отметили рост продуктивности, 59% — улучшение качества кода. Высокий уровень использования AI коррелирует с повышением индивидуальной эффективности, производительностью команд и поставки.
4. Новая модель DORA AI Capabilities Model. Представлена модель, описывающая организационные практики, которые усиливают эффект от применения AI. Она включает как технические, так и культурные аспекты и базируется на гипотезе, что сами по себе AI-инструменты не гарантируют результата — важен контекст, в котором они внедряются. В модель вошли 7 ключевых практик:
- Clear and communicated AI stance — четкая позиция по применению AI, донесённая до сотрудников;
- Healthy data ecosystems — зрелая работа с данными, их качество, полнота и доступность;
- AI-accessible internal data — создание условий, при которых данные можно использовать для AI-инструментов без барьеров;
- Strong version control practices — зрелые практики контроля версий, обеспечивающие прозрачность и управляемость изменений;
- Working in small batches — культура частых и небольших изменений;
- User-centric focus — ориентация на конечного пользователя и его опыт;
- Quality internal platforms — наличие и качество внутренних платформ.
5. Развитие Platform Engineering. Согласно данным отчета, 90% компаний уже используют хотя бы одну платформу, а 29% перешли к нескольким платформам. 76% компаний имеют выделенные платформенные команды, и почти треть респондентов (29%) работают в компаниях где таких команд несколько. Основной вызов для лидеров сместился в сторону
Platform of platforms — сложной экосистеме взаимосвязанных внутренних платформ. В отчете отмечены типичные ловушки, в которые попадают компании при развитии платформ:
- Build it and they will come — платформа создается без исследований и обратной связи, исходя только из предположений команды о том, что нужно разработчикам;
- Ticket-ops trap — работа платформенной команды строится исключительно вокруг тикетов, без единой дорожной карты и продуктового подхода;
- Ivory tower platform — платформа разрабатывается централизованной командой сверху вниз, с жесткими стандартами и без учета потребностей пользователей.
Чтобы платформа приносила пользу, авторы отчета рекомендуют подход Platform as a product — рассматривать её как полноценный продукт, а не только как техническое решение. Это означает ориентацию на весь путь разработчика (Developer journey) и применение User-centric подхода.
6. Применение Value Stream Management. Результаты исследования подтвердили, что управление потоками создания ценности является ключевой практикой, напрямую влияющей на результаты команд и компаний. Команды, которые системно используют практику, тратят значительно больше времени на ценную работу, быстрее выявляют узкие места и достигают лучших показателей как в производительности, так и в качестве продукта. В отчете отмечены основные принципы, которые лежат в основе практики
Value Stream Management:
- визуализация всего цикла поставки — от идеи до пользователя;
- формирование понимания потока работ среди всех участников;
- использование карты потока для выявления реальных узких мест;
- регулярные улучшения, а не разовое упражнение.
7. Использование метрик и фреймворков. В отчете отмечено, что при измерении практик и аспектов разработки часто ссылаются на фреймворки
DORA, SPACE, DevEx и
HEART. Авторы подчеркивают, что первый шаг при выборе подхода — определить, какие цели и управленческие решения должны быть поддержаны измерением, так как разные фреймворки ориентированы на разные результаты. В отчете выделяют три категории фреймворков:
- Developer Experience — измеряют опыт разработчиков и то, как они работают, вне зависимости от создаваемых продуктов;
- Product Excellence — оценивают, насколько успешно продукт или процесс достигает поставленных целей (в том числе связанных с улучшением опыта разработчиков);
- Organizational Effectiveness — оценивают, насколько эффективно компания поставляет продукты и сервисы, включая командное взаимодействие, производительность систем и бизнес показатели.
Авторы рассматривают два варианта для сбора данных:
- Self-reported — данные, собираемые напрямую от инженеров, в форматах: опросы, интервью, фокус группы и исследования;
- Logs-based — данные, автоматически извлекаемые из платформ и систем. Они могут измерять: количество (например, число коммитов), время (например, длительность ревью кода или тестов) и частоту (например, количество релизов за месяц или PR на разработчика в неделю).
В отчете приведены примеры метрик, применяемых в разных фреймворках: Well-being, Velocity, Productivity, Collaboration, Delivery, Efficiency, Adoption/Retention. Их совместное использование позволяет формировать целостное понимание эффективности разработки — от опыта инженеров до восприятия продукта пользователями.
8. Методология исследования. В заключительной части отчета рассмотрен подход к проведению исследования. Авторы описывают разработку опроса, отбор и формулировку вопросов, учет пользовательского опыта при прохождении опроса, локализацию, сбор ответов и проведение интервью. Отдельно раскрыты методы статистического анализа: построение причинно-следственной модели в виде направленного ациклического графа (
DAG), проверка измерительной модели (
CFA), тестирование структуры модели (
SEM), использование байесовского подхода для сравнения, диагностика достоверности результатов и визуализация оцененных эффектов. Представленная модель исследования включает несколько категорий:
- AI adoption — интеграция AI в рабочие процессы, измеряемая через три индикатора: Trust, Reflexive use, Reliance;
- Processes and practices — процессы и практики на уровне компаний, команд и отдельных инженеров;
- Individual traits — индивидуальные характеристики, включая роль, возраст, стаж в команде, время и задачи, связанные с использованием AI;
- Environmental and organizational traits — характеристики окружения и компании;
- Service traits — характеристики предоставляемых сервисов;
- Team performance, Product performance, Software delivery performance — ключевые метрики производительности команд, продуктов и поставки;
- Individual outcomes — результаты на уровне инженера: Code quality, Individual effectiveness, Valuable work, Friction, Burnout.
Основные схемы и результаты из отчета и исследования
DORA 2025 приведены ниже: