ИИ ускоряет код, но не продуктивность

Дискуссия о влиянии ИИ на продуктивность разработчиков вышла на новый виток: ожидания, что инструменты генерации кода дадут трёх- или четырёхкратный рост выпуска качественного кода, пока не подтверждаются на практике. Причина, по мнению авторов перевода на «Хабр», в том, что традиционные метрики измеряют не то, что нужно. Классические показатели — строки кода, коммиты, story points и закрытые заявки — легко подделать, они демотивируют сильных инженеров и слабо связаны с реальными потребностями бизнеса.

На этом фоне всё большее внимание привлекает фреймворк DevEx, который смещает акцент с результатов на условия работы. Он оценивает три аспекта: скорость петель обратной связи (проверка, сборка, развёртывание), когнитивную нагрузку и способность инженера удерживать состояние потока. По данным Gartner, которые приводит автор, в 78% организаций уже есть официальная инициатива по DevEx или её внедрение запланировано — то есть подход перестал быть опциональным.

Автор напоминает, что сами по себе фреймворки DORA и SPACE не панацея. DORA с его четырьмя метриками — временем выполнения изменений, процентом отказов, средним временем восстановления и частотой развёртывания — стал отраслевым стандартом, но объясняет, что произошло, а не почему. SPACE, предложенный Microsoft в 2021 году, добавил человеческий фактор: удовлетворённость, производительность, активность, коммуникацию и эффективность. Однако конкретные метрики в нём не прописаны, что открывает простор для некорректного применения.

Ключевая мысль материала: разработчик — не «сферический конь в вакууме». Значительная часть времени уходит на общение с коллегами, поиск документации и ожидание согласований, и именно эти скрытые хронофаги не видны в количественных отчётах. Команда может редко выпускать обновления не из-за лени, а потому что ждёт проверки или коллегу в часовом поясе с разницей +8 часов.

Поэтому автор предлагает комбинировать DORA, SPACE и DevEx: первые два показывают общую картину доставки ПО, третий указывает на конкретные точки, которые руководитель может изменить. Медленный CI сигналит о проблемах в петлях обратной связи, неудобная внутренняя платформа повышает когнитивную нагрузку, а переполненный календарь мешает войти в поток. Именно эти метрики, по мнению автора, и стоит отслеживать в 2026 году, когда ИИ-инструменты для написания кода становятся массовыми.

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