Skip to content

ROI ИИ в разработке. Почему без зрелой платформы и стандарта вы покупаете ускоритель хаоса

«Если у вас уже есть бутылочное горло, ИИ сделает поток перед ним толще. Само горло — не сделает шире.»

— переформулированный тезис DORA 2026

В апреле 2026 команда DORA опубликовала отчёт «The ROI of AI-assisted Software Development». Это не очередная вендорская методичка про «внедрили Copilot — стали быстрее на 35%». Это финансовая рамка для разговора про ИИ, где ИИ описан буквально одним словом: amplifier, усилитель. Усилитель сильных сторон высокопроизводительных организаций. И усилитель дисфункций — у всех остальных.

Эта статья — синтез трёх отчётов DORA (2024, 2025, ROI 2026), сверенный с независимыми исследованиями: METR, Faros, Veracode, Apiiro, GitClear, MIT NANDA, MIT/Microsoft/Accenture, Stack Overflow Developer Survey. Она для тех, кому интересно управляемое ИТ-производство с ИИ. Не вендорская сказка про «35% ускорения» и не академическая неопределённость про «требуется дальнейшее исследование».

В этой главе рассмотрим:

Главный тезис DORA 2026: AI is an amplifier

Открываем executive summary отчёта и читаем:

«AI магнифицирует сильные стороны высокопроизводительных организаций и дисфункции барахтающихся. Наибольший возврат на инвестиции в ИИ приходит не от инструментов, а от стратегического фокуса на нижележащей организационной системе: качестве внутренней платформы, ясности рабочих процессов и согласованности команд. Без этого фундамента ИИ создаёт локальные карманы продуктивности, которые теряются в downstream-хаосе.»

И тут же — формулировка для бизнес-кейса, которую стоит зачитать дословно при любом серьёзном разговоре про инвестицию в ИИ-инструменты:

«Если ваша организация обладает зрелыми internal developer platforms и оптимизированными deployment pipelines, ИИ быстро масштабирует вашу способность поставлять пользовательскую ценность. Однако, если ваши инженерные команды уже сталкиваются с узкими местами из-за ручного тестирования, тяжёлой бюрократии или фрагментированных данных, инъекция ИИ в такую систему просто ускорит накопление технического долга и затрат на сопровождение.»

Это не риторика. Это формулировка крупнейшего независимого исследования индустрии 2026 года. И это исследование, которое впервые ставит знак равенства между «возвратом на ИИ» и «зрелостью платформы».

DORA 2026 формулирует это ещё прямее: «ROI измеряется не количеством сгенерированных строк, а количеством устранённых узких мест.»

Парадокс продуктивности: семь независимых исследований, один вывод

Тех, кто читает только хедлайны вендоров, ждёт сюрприз. Разрыв между ощущениями разработчика и измеримой поставкой — главный сюжет 2025–2026 годов.

Источник Методология Что получили
METR (2025) RCT, 16 senior-разработчиков, 246 задач, случайное распределение «с ИИ / без ИИ» Прогнозировали ускорение на 24%, оценили постфактум +20%. Фактически — минус 19%
Faros AI (2025) Лонгитюдная телеметрия, 10 000+ разработчиков, 1 255 команд 75% инженеров используют ИИ, большинство организаций не видят измеримого прироста поставки
DX / Laura Tacho (Q4 2025) 121 000 разработчиков, 450+ компаний 92,6% пользуются ИИ ежемесячно, 75% — еженедельно. Организационный прирост — около 10%
Stack Overflow 2025 n ≈ 50 000+ 84% используют или планируют. Только 16,3% сообщают о значимом росте продуктивности. 41,4% — об отсутствии заметного эффекта
DORA 2024 Опрос ~5 000, регрессионный анализ ИИ-внедрение снизило throughput на 1,5% и стабильность на 7,2%
DORA 2025 Опрос, регрессионный анализ Throughput вышел в плюс там, где зрелая платформа. Стабильность по-прежнему деградирует
MIT NANDA (2025) 300 корпоративных ИИ-кейсов 95% корпоративных ИИ-инициатив не дают финансового возврата

Семь независимых методологий — от RCT до телеметрии, от опросов до регрессии, до полевого исследования кейсов — сошлись в одной точке: индивидуальная скорость растёт, организационная поставка либо не меняется, либо ухудшается.

DORA называет это «vacuum hypothesis»: ИИ освобождает время разработчика, но это время втягивает не высокоценная работа, а другая низкоценная. Faros — «AI productivity paradox». METR — «illusion of speed». Разные имена, одно явление.

J-кривая: финансовая модель того, что мы и так чувствуем

Главная методологическая новинка DORA 2026 — J-Curve of AI value realization.

Любое внедрение ИИ даёт временное падение продуктивности. Не «может дать». Даёт. DORA называет это «tuition cost of transformation» — плата за обучение. Кривая имеет три фазы:

  1. The learning curve. Команды отвлекаются от регулярной поставки, учатся новым интерфейсам, перестраивают рабочие процессы.
  2. The verification tax. Разработчики тратят время на верификацию сгенерированного. Чем меньше доверия — тем глубже провал.
  3. Pipeline adaptation. Downstream-процессы (тестирование, ревью, релизы) масштабируются под возросший поток. Здесь обнажаются legacy-ограничения.

Только после прохождения этих трёх фаз начинается экспоненциальный рост — та самая «правая палочка» в букве J.

В калькуляторе DORA даны эталонные цифры:

  • Технический штат: 500 FTE.
  • Средняя загруженная зарплата: $176 000.
  • J-Curve productivity drop: 15%.
  • Длительность дропа: 3 месяца.

Итого «налог на обучение»: $3,3M. Прямой денежный эквивалент потерянной продуктивности.

Это не сценарий. Это прогноз. И если этот налог не забюджетирован заранее, проект режут на дне J-кривой. Финансовый директор смотрит на квартальные показатели и не понимает, почему ИТ-операционный бюджет растёт, а delivery throughput падает. Инвестиция теряется.

DORA пишет про это с редкой прямотой:

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

Арифметика lead time: ИИ ускоряет одну колонку из десяти

Это, пожалуй, самая отрезвляющая арифметика в разговоре про ИИ. Прежде чем предполагать ROI от ИИ — посчитайте, какой процент lead time вообще занимает та фаза, которую ИИ может ускорить.

Типичный поток от идеи до production в крупной организации:

Идея → Архдокумент → Согласование → Сетевые доступы →
Разработка → Ревью → Security review → Release approval → Деплой

Типичные lead time по этапам (медианы по крупным организациям):

Этап Lead time Process time Process efficiency
Архдокумент 14 дней 2 дня 14%
Согласования документов 21 день 4 часа 2%
Сетевые доступы 9 дней 30 минут < 1%
Разработка 8 дней 8 дней 100%
Code review 3 дня 1 день 33%
Security review 7 дней — —
Release approval 5 дней — —
Деплой 1 день — —
Итого ~71 день ~14 дней ~20%

Process efficiency — 20%. Это значит, что 80% lead time задача проводит в очередях, а не в работе.

Теперь арифметика. ИИ ускоряет, в основном, колонку «Разработка». Допустим, мы ускоряем её вдвое — 8 дней превращаются в 4. Выигрыш — 4 дня из 71. Это 5,6% общего lead time.

Теперь другой сценарий. Убираем два главных time killer'а — «Согласования документов» (21 день) и «Архдокумент» (14 дней) — например, вдвое каждый. Выигрыш — 17 дней из 71. Это 24% общего lead time. Без покупки ИИ.

Это и есть арифметика, против которой нечего возразить. ИИ — мощный инструмент для одной колонки из десяти. Если эта колонка не главный bottleneck — экономическая эффективность ИИ ограничена сверху самой природой потока. И в большинстве крупных организаций главный bottleneck — это не разработка. Это очереди вокруг разработки.

Управленческий вывод. Прежде чем покупать ИИ для разработчиков — сделайте value stream mapping. Найдите свои time killer'ы. Если 80% времени уходит в согласования и доступы, ИИ для написания кода — это покупка спорткара для езды по пробкам.

Восемь узких мест, которые ИИ ускоряет, а не лечит

Если ИИ — амплифайер, главный вопрос: что именно вы усиливаете? Ниже — те самые узкие места по приоритету риска, с источниками.

# Узкое место Что происходит при добавлении ИИ Источник
1 Code review PR на автора +20% YoY, инциденты на PR +23,5%. Циклы ревью становятся в 2× длиннее, post-merge фиксы — в 3× больше. DORA называет это «verification tax» — налог на верификацию DORA 2026, Apiiro
2 Тестирование Тесты, генерируемые ИИ под код, тоже генерируемый ИИ — это замыкание контура без независимой спецификации. Растёт ложное покрытие, а не защита от регрессий DORA 2026: small batches + test automation как критические capabilities
3 Безопасность 45% AI-кода вносит уязвимости из OWASP Top 10. У Fortune 50: +322% privilege escalation, +153% design flaws, +40% secrets exposure Veracode 2025, Apiiro
4 Deployment pipelines Традиционный CI/CD рассчитан на предсказуемые партии от людей. ИИ генерирует синтаксически корректный, но контекстно неверный код быстрее, чем пайплайн успевает валидировать CircleCI 2025, DORA 2026
5 Maintainability Code churn 3,1% (2020) → 5,7% (2024). Дублирование кода ×4. Хардинг из GitClear называет это «AI-induced tech debt» GitClear 2025
6 Стандартизация и контекст LLM не имеют достаточного контекстного понимания целей проекта, параметров I/O и пользовательских паттернов. Без AGENTS.md, ADR, спецификаций — ИИ галлюцинирует архитектуру DORA AI Capabilities Model
7 Люди и компетенции Парадокс: junior получают наибольший прирост скорости, но не приобретают модель отладки. Senior замедляются на 19% (METR RCT). Знание становится менее воспроизводимым METR 2025, MIT/MS/Accenture 2025
8 Shadow AI MIT NANDA: внутренние корпоративные ИИ-сборки часто проваливаются. Это толкает сотрудников в shadow AI — несанкционированные потребительские приложения, мимо security review MIT NANDA, DORA 2026

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

Безопасность: системная проблема, не проблема масштабирования

Безопасность стоит обсудить отдельно, потому что здесь сходятся независимые методологии и независимые исследования.

Veracode 2025 GenAI Code Security Report — 100+ LLM, 80 задач по MITRE CWE, 4 языка. Результат: 45% сгенерированного кода содержит уязвимости из OWASP Top 10. Для Java — 72%. Для CWE-80 (XSS) — 86%.

Самое важное замечание CTO Veracode:

«Большие модели работают не лучше малых, что говорит о системной природе проблемы уязвимостей, а не о проблеме масштабирования LLM.»

Это конец стратегии «подождём следующей модели». Проблема не в размере. Проблема в обучающем сигнале: модели обучены на открытом коде, который содержит и безопасные, и небезопасные паттерны, и воспроизводят их без разбора.

Apiiro / Fortune 50 (2025):

  • +322% privilege escalation paths.
  • +153% design flaws.
  • +40% secrets exposure.
  • Более 10 000 новых security findings в месяц к июню 2025 (10× рост с декабря 2024).

SoftwareSeni meta-analysis: AI-сгенерированный код содержит в 2,74× больше уязвимостей, чем человеческий.

Если ваш security pipeline на сегодня работает на пределе — добавление ИИ-генерации без перестройки security gates не «слегка увеличит нагрузку». Оно умножит её на три. И уровень атак растёт быстрее уровня защиты: ИИ снижает порог входа атакующего быстрее, чем повышает защитный потенциал защищающегося.

Зрелая платформа и стандарт: почему это и есть инвестиция

Здесь — кульминация отчёта DORA 2026. Он формулирует пять системных предпосылок успеха ИИ-внедрения. Первая в списке — буквально:

Treat your Internal Developer Platform (IDP) as a product. Исследование 2025 года подтверждает, что качественная внутренняя платформа — это первичная соединительная ткань для ценности ИИ. В агентной эре IDP больше не просто портал к инфраструктуре — это митигатор риска и поставщик контекста для ИИ-агентов. Когда ИИ-агенты могут навигировать по хорошо определённой платформе, они тратят меньше времени на галлюцинирование архитектурных паттернов и больше — на доставку ценного кода.

И отдельно про стандарт разработки — DORA 2026 называет это «context layer» и определяет как CapEx-инвестицию №1 в roadmap:

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

И ещё прямее — про последствия отсутствия стандарта:

«Когда внутренний knowledge graph организации фрагментирован или устарел, ИИ генерирует bloat — дублированный или нерелевантный код, который создаёт долгосрочный технический долг.»

Что делает зрелая платформа + стандарт конкретно. В терминах «упирается в людей и зоопарк решений»:

  1. Снижает verification tax. Когда у вас стандартизованные API, schema, ADR, AGENTS.md и pre/post-conditions в контрактах модулей — у ревьюера есть на что опереться. У ИИ-агента — тем более.
  2. Гасит зоопарк через self-service. Один путь к production. Один CI с встроенным SAST/SCA/secrets scanning. Один наблюдаемый формат логов и метрик. Разработчик может выбирать инструмент написания, но не путь поставки.
  3. Делает компетенцию воспроизводимой, а не уникальной. Если каждый ваш разработчик — «уникальный носитель знания» о том, как деплоить сервис X, это IT-коррупция в её самой банальной форме: знание захвачено инсайдером. Платформа национализирует это знание.
  4. Превращает галлюцинацию в раннюю ошибку. Хорошо определённая платформа отказывает агенту, если тот генерирует код вне стандарта. Это дешевле, чем отлавливать на post-merge.
  5. Защищает от security debt. Гейты в пайплайне работают вне зависимости от того, кто (или что) написал код.

Это и есть ответ на тезис «иначе хаос будет множиться». ИИ не строит порядок там, где его нет. ИИ ускоряет то, что есть.

Сначала baseline, потом стратегия. Шесть срезов

Стратегия без baseline — это вкусовщина. Перед тем как масштабировать ИИ — оцените, что именно вы собираетесь усилить. Это занимает примерно 10 недель и даёт картину, на которой можно принимать решения, а не верить в обещания вендора.

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

Срез 1. Инвентарь

Что у вас вообще есть. До этого среза все остальные — средние по больнице.

Артефакт Зачем смотрим Сигнал тревоги
Живые сервисы по стримам и платформам Отличить актив от мумии Из 500 сервисов живых обычно 250–350
README.md осмысленный (LLM-проверка JTBD) Контекст для людей и преемников < 50% — стандарта нет
AGENTS.md Контекст для ИИ-агентов нет — агент будет галлюцинировать
OpenAPI Контракт синхронных API нет / drift с реализацией
AsyncAPI Контракт асинхронных API (брокеры) нет / drift с реализацией
Компонентные тесты через реальный вход Спецификация поведения < 5% от тестов — нет спецификации
Соответствие тестов спецификациям OpenAPI/AsyncAPI Реализация = спецификация, не разъезжается с ней Тесты живут параллельно спеке
CODEOWNERS / явный владелец Кто отвечает orphan-сервисы — прямой риск
ADR / architecture.md Решения зафиксированы нет — решения в головах
Охват стандартным пайплайном Сколько команд используют один путь к prod < 50% — IDP не product, а артефакт

Особое внимание — соответствие тестов спецификациям. Это и есть главная защита от ИИ-галлюцинации контракта. Когда спецификация — единственный источник истины и компонентный тест её проверяет (импорт OpenAPI/AsyncAPI в тестовом коде, runtime-валидация ответов против схемы), ИИ-агент не сможет втихую разойтись с контрактом. Без этой проверки спека и реализация живут параллельно, и одна из них всегда врёт. С ИИ — обе врут одинаково правдоподобно.

Срез 2. DORA-поток

Пять метрик — критическая база для любого разговора про поставку:

  • Deployment frequency
  • Lead time for changes
  • Change failure rate
  • Failed deployment recovery time
  • Rework rate (новая метрика DORA 2025 — прямой ответ на рост code churn)

Меряем по живым сервисам, не по всем. И не в среднем по организации, а по стриму, по платформе, по типу сервиса. Среднее по 500 сервисам ничего не скажет, кроме того, что у вас, в среднем, всё нормально.

Срез 3. Качество кода и тестов

Здесь меряем то, что DORA называет «verification tax» и «AI-induced tech debt». Количество тестов — не индикатор. Сервис с 300 тестами при mutation score 35% хуже сервиса с 50 тестами при mutation score 75%.

Метрика Здоровье Тревога
Mutation score (PIT/Stryker/go-mutesting) > 70% < 40% — тесты декоративные, проходят на сломанном коде
Доля тестов с моками < 30% > 60% — тестируется эхо, а не код
Flaky rate < 1% > 5% — разработчики сами не доверяют
Время прогона полного набора < 10 мин > 30 мин — pipeline-killer
Code churn (% строк, переписанных за < 2 недели) 3–5% > 7% — AI-tax уже идёт
Дублирование (jscpd/sonar-clones) < 5% > 15%
Vulnerabilities на сервис в месяц стабильно растёт ×N — security pipeline не справляется

Срез 4. Shadow AI

Без этого среза вы оцениваете систему, не зная, что в ней уже происходит:

  • Опрос лидов: «у вашей команды есть Cursor / Copilot? Через корпоративную подписку или личные?»
  • DLP-логи: случаи отправки кода во внешние ИИ.
  • Анализ outbound-трафика на домены AI-вендоров.
  • % стримов с собственной политикой по ИИ.

Если 60% разработчиков уже на Cursor через личные карты — вы уже в J-кривой, просто без управления.

Срез 5. Онбординг и дифф платформ

Самый недооценённый baseline-вопрос. Меряем не «что есть», а сколько времени между «новый человек или новый сервис» и «первый коммит в prod».

Метрика Здоровье Тревога
Time-to-first-commit нового разработчика < 2 дня > 2 недели
Time-to-first-deploy-to-prod < 1 месяц > 3 месяцев
Шагов в инструкции «как начать» < 10 > 30
Зависимостей от ручных тикетов для старта 0–1 4+

Здесь же — golden path test: даём пятерым одинаковым junior'ам одно задание («сделать сервис на платформе X, который принимает HTTP POST и пишет в БД») и засекаем время от «получил задание» до «работает в test-окружении». Результат — таблица:

Платформа A: 4 часа, 0 тикетов   → golden path работает
Платформа B: 2 дня, 3 тикета     → есть процесс, но трение
Платформа C: 9 дней, 12 тикетов  → по сути нет платформы
Платформа D: «не смог»           → legacy-зона, кандидат на decommission
Платформа E: 1 день, 1 тикет     → норма

Это жесточайший аргумент в управленческом разговоре. Не абстрактная «зрелость платформы», а конкретный наблюдаемый показатель.

Срез 6. Value Stream Mapping и time killers

Сам процесс производства. См. раздел про арифметику lead time. На каждом этапе пути от идеи до production меряем lead time и process time, считаем efficiency. Это даёт карту, где видно, где деньги горят прямо сейчас — и где ИИ может реально помочь, а где нет.

Источники для этого среза:

  • Опрос команд про частотность time killers (1 неделя): «сколько раз за 3 месяца вы ждали более 2 дней архревью / сетевой доступ / security review / согласования релиза?»
  • Тикет-анализ Jira / SD за 90 дней по типам тикетов.
  • Полный VSM на 5–7 типичных сервисах разных профилей.

Heatmap как единственное полезное представление

После сбора шести срезов сводим всё в одну матрицу:

                │ Платф A │ Платф B │ Платф C │ Платф D │ Платф E │
────────────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
Стрим 1 (15сс)  │ 🟢🟢🟢  │ 🟡🔴🔴  │   —     │   —     │   —     │
Стрим 2 (8сс)   │ 🟢🔴🔴  │   —     │   —     │   —     │   —     │
Стрим 3 (30сс)  │ 🔴🔴🔴  │ 🔴🔴🔴  │ 🔴🟠🔴  │ orphan  │   —     │

Три цвета в ячейке: DORA-поток, качество тестов, RRA-score (I/O-граница + JTBD).

  • 🟢🟢🟢 — пилоты для ИИ (обычно 5–10 стримов из 40).
  • 🟢🔴🔴 — главная зона риска: быстро поставляют, защиты нет. ИИ добьёт первой.
  • 🔴🟢🟢 — задушены платформой или процессом. Сюда — инвестиции в IDP.
  • 🔴🔴🔴 — санация: контракты, AGENTS.md, переписывание тестов как спецификации.
  • orphan — кандидаты на decommission.

Последовательность измерений

Нед 1–2  → Срез 1 (инвентарь) + Срез 6 (опрос time killers)
Нед 2–4  → Срез 4 (Shadow AI) + Срез 6 (тикет-анализ)
Нед 3–8  → Срезы 2, 3 — на 8–10 пилотных стримах разных профилей
Нед 4–8  → Срез 5 (онбординг) — golden path test на платформах
Нед 8–10 → Срез 6 (полный VSM) + сборка heatmap
Нед 10+  → Стратегия на основе данных, а не вкусовщины

10 недель — реалистичный темп. Кто обещает «оценим за 2 недели» — врёт. Кто растягивает на полгода — не вернёт деньги бизнесу.

Что делать. Roadmap без розовых очков

Roadmap построен по DORA 2026 + независимым источникам. Без вендорского оптимизма и без академической нейтральности.

Горизонт Действие Почему
0–3 мес Собрать baseline по шести срезам (см. предыдущий раздел): инвентарь, DORA-поток, качество кода и тестов, shadow AI, онбординг и дифф платформ, value stream mapping Без baseline вы не отличите J-Curve dip от провала проекта. Без VSM не отличите узкое горло «разработки» от узких горлов «согласований» и «доступов»
0–6 мес Установить «AI stance» — официальную позицию организации: что можно, чего нельзя, какие инструменты одобрены DORA 2026 называет это критической capability. Без неё — shadow AI и неконтролируемый отток данных
3–12 мес Инвестировать в IDP как продукт. Self-service для типового сервиса. Стандарт скаффолдинга. Гейты безопасности в пайплайне — не опциональные DORA 2026: первая CapEx-инвестиция в roadmap
3–12 мес Развернуть AI-accessible internal data: машиночитаемая документация, чистые API-спецификации (OpenAPI, AsyncAPI), ADR DORA 2026 называет это «context layer» — без него агенты бесполезны
3–12 мес Атаковать главные time killer'ы, найденные через VSM: убрать ручные согласования, сделать сетевые доступы self-service, унифицировать архревью Каждый день, отыгранный здесь, даёт прирост lead time, сравнимый с месяцами работы над ИИ
6–18 мес Стандарт прикладной разработки: контракты модулей, pre/post-conditions, AGENTS.md в каждом репозитории, разделение логики и I/O. Компонентные тесты сверяются со спецификацией OpenAPI/AsyncAPI. Обязательное code review с AI-assisted scanning, но не AI-only Превращает ИИ из источника галлюцинаций в исполнителя по спецификации
Постоянно Не сокращать штат. Освобождённую капасити направлять на верификацию, рефакторинг, инновации Прямое управленческое указание DORA 2026

Особое внимание на последний пункт. DORA 2026 пишет про это в отдельном блоке:

«Мы настоятельно рекомендуем организациям не принимать стратегию сокращения штата. Производительность должна перенаправляться на инновации, а не на сокращение… Reducing the amount of unnecessary rework recovers engineering capacity equivalent to free headcount, который может быть напрямую реинвестирован в новые фичи.»

Логика проста: verification tax вырос, инциденты на PR выросли, security findings выросли. Если в этот момент сократить штат — у вас не останется людей, чтобы верифицировать ускоренный поток. ИИ-производительность сожжётся внутри организации, не дойдя до бизнеса.

Итог в одной фразе

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

DORA 2026 формулирует это финально и без оговорок:

«Истинный риск для технологических лидеров — не провалить ИИ, а не построить организационную систему и культуру, которые позволяют ИИ доставлять ценность. Цена бездействия высока, но броситься в адаптацию без подготовки среды — столь же разрушительно.»

Источники

Первичные источники DORA — основа синтеза:

  1. DORA. The ROI of AI-assisted Software Development. April 2026. dora.dev/ai/roi
  2. DORA. State of AI-assisted Software Development. 2025. dora.dev/dora-report-2025
  3. DORA. Accelerate State of DevOps. 2024. dora.dev/research/2024/dora-report/
  4. DORA. AI Capabilities Model. dora.dev/dora-aicmr
  5. DORA. ROI Calculator. dora.dev/ai/roi/calculator

Продуктивность и бизнес-эффект:

  1. METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. 2025. metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
  2. Faros AI. Productivity Paradox Report. 2025. faros.ai/blog/ai-software-engineering
  3. Cui, Demirer, Jaffe, Musolff. The Effects of Generative AI on High-Skilled Work. MIT / Microsoft / Accenture RCT, 2025. economics.mit.edu
  4. MIT NANDA. State of AI in Business 2025. mlq.ai
  5. Stack Overflow. Developer Survey 2025. survey.stackoverflow.co/2025
  6. Tacho L. This CTO says 93% of developers use AI, but productivity is still ~10%. Shiftmag / Pragmatic Summit 2026. shiftmag.dev

Качество кода и безопасность:

  1. Veracode. 2025 GenAI Code Security Report. veracode.com/resources/analyst-reports/2025-genai-code-security-report/
  2. Apiiro / Fortune 50 study, 2025. Обзор: softwareseni.com
  3. GitClear. AI Copilot Code Quality 2025. gitclear.com/ai_assistant_code_quality_2025_research
  4. Stanford HAI. 2025 AI Index Report. hai.stanford.edu/ai-index/2025-ai-index-report