Исследование, проведённое DX в 2025 году с участием 18 компаний — включая GitHub, Microsoft, Google, Dropbox, Atlassian, Booking.com, Monzo, Webflow и другие — выявило системные закономерности в оценке влияния AI на инженерные процессы. Эти данные позволяют экстраполировать изменения, которые затронут не только инженерию, но и бизнес-модели, организационные структуры и сам рынок разработки ПО в ближайшие 3–5 лет.

Общие тезисы Давайте уже признаемся себе: AI — не гипотеза, а часть повседневной работы инженеров. Но одно дело — видеть, как Copilot подсказывает или исправляет строки кода, и совсем другое — понимать, ускоряет ли это бизнес или создаёт скрытый технический долг.

Вот как раз именно этот разрыв между активностью и воздействием стал главной проблемой для 60% инженерных лидеров, согласно LeadDev’s 2025 AI Impact Report. Они видят использование, слышат положительные отзывы, но не могут связать AI с реальным бизнес-воздействием.

AI не создаёт новых целей и правил Самый важны вывод отчета DX звучит парадоксально: внедрение AI не требует новых KPI. “You don’t need totally new metrics now that AI is here. These companies assess AI's impact against the standards that have always defined their high-performing organizations.”

Таким образом, AI не создаёт новую цель — он проверяет, достигаете ли вы старых целей эффективнее. Качество, скорость delivery, поддерживаемость, DevEx (developer experience) опыт разработчика — всё это осталось прежним. Вопрос лишь в том: а стал ли AI катализатором или иллюзией?

Dropbox — яркий пример. При 90% охвата AI среди инженеров компания не останавливается на метриках использования. Она смотрит на Core 4:

• PR throughput (пропускная способность PR)
• Change Failure Rate (частота отказов при внесении изменений)
• Deployment Frequency (частота внедрения изменений)
• Lead Time for Changes (время выполнения изменений, включая адаптацию к изменению)

Результат: инженеры, активно использующие AI, сливают на 20% больше pull request’ов и одновременно улучшают качество. Это возможно только потому, что baseline по Core 4 существовал до внедрения ИИ. Без него любое ускорение — шум!

Developer Experience — что это и зачем Многие сводят Developer Experience (DevEx) к опросам удовлетворённости. Но ведущие компании используют DevEx как ранний индикатор системного риска.

Microsoft, например, ввела понятие Bad Developer Day (BDD) — это день, когда когнитивная нагрузка, рутина и контекст-свичинг подавляют продуктивность инженеров. BDD учитывает не только время в митингах или инцидентах, но и баланс с реальной активностью — кодинг, проектирование и тп. “A day might include some tasks that are toilsome or feel low-value, but if the developer still gets some time to code and submit changes, this can tip the balance toward having a good day.”

И это как раз не субъективная оценка — это операционный сигнал.

• Если AI снижает частоту BDD, он действительно вносит улучшения в процесс.
• Если нет — он добавляет сложность под видом помощи.

Компания Webflow идёт дальше: используется сочетание системных метрики (PR revert rate, Change Failure Rate) с самоотчётами по change confidence и maintainability. Почему? Потому что AI-генерируемый код может выглядеть идеально, но быть нечитаемым или хрупким при внедрении в фреймворки и работающие проекты. В данном случае только разработчик может оценить импакт от работы AI, причем сделать это только в связке с объективными данными. Вот тогда это становится измеримым риском.

Продолжение в ч2 ⏩