Почему ИИ не всегда ускоряет разработку — и где IT-команда теряет выигранное время

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

Представим, что раньше разработчик готовил изменение два дня, а с ИИ справляется за один.

На первый взгляд производительность выросла вдвое.

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

Первый этап действительно ускорился. Полный цикл задачи — почти нет.

Так возникает одна из главных иллюзий AI-трансформации:

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

ИИ может ускорять разработчика — и не ускорять разработку

Исследования влияния ИИ на программирование дают на первый взгляд противоречивые результаты.

В контролируемом эксперименте GitHub 95 разработчиков выполняли одну и ту же ограниченную задачу — создавали HTTP-сервер на JavaScript. Участники с GitHub Copilot справились в среднем на 55,8% быстрее. (github.blog)

В исследовании METR опытные разработчики работали уже не с учебной задачей, а с реальными проблемами в собственных зрелых open-source-проектах. В исследовании участвовали 16 разработчиков, выполнивших 246 задач. При разрешённом использовании AI-инструментов работа заняла в среднем на 19% больше времени. При этом сами участники считали, что ИИ их ускорил. (metr.org)

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

В первом случае:

• задача была ограниченной и одинаковой для всех;
• результат можно было автоматически проверить;
• участникам не требовалось глубоко знать многолетнюю историю проекта;
• основная работа заключалась непосредственно в написании решения.

Во втором:

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

Важно и то, что это не вечные коэффициенты. В феврале 2026 года METR сообщила, что более новые инструменты, вероятно, уже сильнее ускоряют часть разработчиков, но новое исследование оказалось подвержено серьёзным искажениям выборки, поэтому надёжно определить размер эффекта не удалось. (metr.org)

Практический вывод для компании прост:

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

Куда перемещается работа после генерации

ИИ редко устраняет работу полностью. Чаще он меняет её расположение.

Раньше значительная часть времени уходила на самостоятельное создание первого варианта. Теперь он появляется быстрее, но вокруг него возникает новая работа:

• точно описать задачу и ограничения;
• подобрать и передать контекст;
• сравнить предложенные варианты;
• проверить факты и предположения;
• найти ошибки, которые выглядят правдоподобно;
• привести решение к стандартам проекта;
• объяснить логику коллегам;
• интегрировать результат в существующую систему;
• исправить последствия неточного решения.

Часть этой работы выполняет сам автор. Часть переносится на ревьюеров, архитекторов, QA, аналитиков и руководителей.

Поэтому вопрос не в том, сколько времени ИИ сэкономил разработчику при создании кода. Важнее понять:

Уменьшилось ли полное время от постановки задачи до принятого и работающего результата?

Локальное ускорение создаёт новое узкое место

Представим команду из восьми разработчиков и двух опытных ревьюеров.

До внедрения ИИ разработчики создавали в среднем десять изменений в неделю. После внедрения — пятнадцать.

Пропускная способность ревью при этом осталась прежней.

Теперь изменения быстрее появляются, но дольше ждут проверки. Ревьюеры переключаются между большим количеством задач, глубина проверки снижается, возвраты становятся чаще. Незавершённая работа накапливается.

По отдельности разработчики действительно стали быстрее. На уровне команды выросла очередь.

Такая ситуация возможна не только в разработке:

• аналитики быстрее выпускают отчёты, но руководители не успевают их разбирать;
• поддержка быстрее готовит ответы, но эксперты чаще проверяют спорные случаи;
• сотрудники быстрее создают документы, но согласование становится длиннее;
• продуктовые команды генерируют больше гипотез, чем способны качественно проверить;
• junior-специалисты создают больше кода, но увеличивают нагрузку на senior-команду.

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

Почему ревью становится сложнее

На первый взгляд проверить готовый результат легче, чем создать его самостоятельно. Но это верно не всегда.

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

При работе с результатом ИИ эту модель приходится восстанавливать после генерации.

Код может выглядеть аккуратно, проходить базовые тесты и при этом:

• нарушать неочевидное архитектурное правило;
• дублировать уже существующую функцию;
• неправильно обрабатывать редкий сценарий;
• создавать проблему безопасности;
• усложнять дальнейшее сопровождение;
• не соответствовать реальной бизнес-логике.

Проверяющему нужно не просто прочитать результат. Ему приходится понять чужую, а иногда и несуществующую логику его создания.

Особенно опасен результат, который выглядит убедительно. Явная ошибка быстро привлекает внимание. Правдоподобное решение снижает настороженность и требует более дисциплинированной проверки.

Больше результата не всегда означает больше ценности

ИИ делает производство текста, кода и вариантов дешевле. Поэтому организации естественно начинают получать больше артефактов:

• больше pull request;
• больше документации;
• больше отчётов;
• больше идей;
• больше тестов;
• больше вариантов решений.

Но каждый новый результат требует внимания.

Его нужно прочитать, оценить, сопоставить с контекстом, принять или отклонить. Поэтому ограничивающим ресурсом постепенно становится не создание, а человеческая способность проверять и принимать решения.

Это меняет задачу руководителя.

Раньше вопрос мог звучать так:

Как помочь команде создавать больше?

Теперь всё чаще нужно спрашивать:

Какие результаты действительно стоит создавать и хватит ли у системы способности их качественно обработать?

Пять причин, по которым команда не получает ускорения

1. ИИ применяют к неподходящим задачам

Система хорошо помогает там, где задача понятна, контекст доступен, а результат легко проверить.

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

2. Контекст приходится собирать вручную

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

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

3. Растёт количество итераций

Первый вариант появляется быстро, но затем начинается цепочка уточнений:

сгенерировать → проверить → исправить запрос → сгенерировать снова → адаптировать → перепроверить.

Сотруднику кажется, что работа движется быстро, потому что результат постоянно меняется. Но полное время задачи не сокращается.

4. Нагрузка переносится на экспертов

Менее опытные сотрудники способны создавать больше внешне законченных результатов. Однако проверять архитектуру, риски и соответствие контексту по-прежнему должны senior-специалисты.

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

5. Измеряется не тот показатель

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

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

Что измерять вместо объёма генерации

Чтобы понять, ускоряет ли ИИ команду, нужно смотреть на полный поток работы.

Для выбранного процесса полезно сравнивать:

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

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

Например, для разработки это могут быть:

lead time задачи + время ревью + количество возвратов + дефекты после выпуска.

Для аналитики:

время от запроса до принятого решения + количество уточнений + доля выводов, подтверждённых данными.

Так становится видно, где ИИ действительно убрал работу, а где лишь переместил её.

Как проектировать процесс, чтобы ускорение не потерялось

Первый шаг — нарисовать полный путь задачи, а не только этап взаимодействия с ИИ:

постановка → подготовка контекста → генерация → проверка → доработка → согласование → интеграция → использование.

Затем для каждого этапа определить:

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

После этого решения становятся точнее.

Где-то стоит ограничить размер AI-сгенерированных изменений. Где-то — добавить автоматические тесты до ревью. Где-то — передавать ИИ только подготовку черновика. А где-то — наоборот, расширить автономность, потому что результат легко проверить и безопасно отменить.

Цель не в том, чтобы использовать ИИ меньше.

Цель — не производить больше работы, чем организация способна качественно завершить.

Вопросы для самопроверки

Команде полезно проверить:

1. Какой этап работы действительно стал быстрее?
2. Сократилось ли полное время задачи?
3. Не выросла ли очередь на ревью или согласование?
4. Кто теперь выполняет работу, которую раньше делал автор?
5. Увеличилось ли количество возвратов и доработок?
6. Что компания измеряет: генерацию или принятый результат?
7. Сохраняет ли автор достаточное понимание созданного решения?

Если ответы неизвестны, утверждать, что ИИ повысил производительность команды, пока рано.

Главный принцип

ИИ приносит пользу не тогда, когда сотрудник быстрее создаёт первый вариант.

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

Поэтому внедрение AI-инструмента без перепроектирования процесса может дать локальное ускорение и одновременно создать новые очереди, перегрузить экспертов и увеличить объём незавершённой работы.

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

Продолжение темы

Даже когда компания определила этапы проверки, остаётся вопрос: действительно ли человек контролирует результат — или лишь формально присутствует в процессе?

Следующий материал

Человек в контуре ещё не означает человеческий контроль

Разберём, почему присутствие человека в процессе не гарантирует реального контроля над результатом — и что нужно проектировать специально.

Материал готовится