Редакционное уточнение r6 · 8 августа 2026: выпуск теперь ведёт от разбора к точным рабочим листам Практикума. Факты, источники и общий вывод не менялись.
ИИ может ускорить написание текста, анализа или кода — и не ускорить работу в целом. Выпуск о том, почему локальная производительность и системный результат расходятся и что измерять вместо числа сгенерированных строк.
Что изменилось на самом деле
В исследовании программной разработки DORA рост внедрения ИИ на 25% был связан со снижением пропускной способности доставки на 1,5% и стабильности доставки на 7,2%. Авторы одновременно увидели улучшения в документации, качестве кода и скорости ревью. Источник: DORA, “Impact of Generative AI in Software Development”, 2024.
Это не доказательство, что ИИ вызывает ухудшение. DORA описывает наблюдаемую связь в конкретной области — разработке и доставке ПО. Но результат важен: более быстрый отдельный шаг не гарантирует более быстрый и устойчивый поток работы.
Что стало дешевле, а что — ценнее
Дешевле стало произвести первую версию: написать функцию, тест, документ или объяснение. Ценнее становятся постановка задачи, проверка изменений, управление зависимостями и способность команды не превращать дополнительный output в очередь незавершённой работы.
Вывод выпуска: ИИ часто переносит узкое место. Если производство ускорилось, ограничением могут стать ревью, интеграция, решение о выпуске или исправление ошибок.
Три проверяемых сигнала
- −1,5% пропускной способности доставки было связано с ростом внедрения ИИ на 25% в данных DORA. Это показатель потока изменений, а не скорости набора кода. Источник: DORA, “Impact of Generative AI in Software Development”, 2024. До расширения доступа к ИИ зафиксируйте для одного типа задач базовые cycle time и очередь ревью; сравнивайте с ними полный путь до принятого изменения, а не число сгенерированных строк.
- −7,2% стабильности доставки наблюдалось при том же росте внедрения. Авторы связывают риск с увеличением размера изменений: с ИИ проще произвести больше кода, который всё ещё нужно проверить. Источник: DORA, “Impact of Generative AI in Software Development”, 2024. Ограничьте размер AI-предложений и заранее назначьте воспроизводимый тест, review и откат; если после пилота растёт доля возвратов или ошибок, остановите масштабирование, а не ускоряйте генерацию.
- В раннем рандомизированном исследовании METR 16 опытных open-source-разработчиков выполняли 246 задач с ИИ в среднем на 19% медленнее, хотя ожидали ускорения. Сам METR теперь прямо помечает этот результат как устаревающий для новых инструментов. В продолжении участвовали 57 разработчиков, 143 репозитория и более 800 задач, но сильный самоотбор при использовании ИИ не позволяет надёжно назвать величину эффекта. Источники: раннее исследование METR, 2025 и обновление METR, 2026. Проведите короткий A/B-пилот на знакомом стеке с заранее выбранными метриками качества, времени цикла и переделок; покупка или продление инструмента оправданы только результатом этого процесса, а не ожиданием скорости.
Как это читать
DORA изучает организации и поставку ПО; METR — выполнение задач опытными разработчиками в знакомых репозиториях. Эти результаты нельзя переносить на любую профессию или складывать в одну универсальную цифру. Они подтверждают более скромный тезис: эффект зависит от границы измерения и от того, где после внедрения оказался новый контрольный участок.
Что это меняет для человека и работы
- Специалисту: измеряйте не ощущение скорости, а время от принятой задачи до принятого результата, включая проверку и переделку.
- Руководителю: рост объёма черновиков — не рост пропускной способности. Следите за очередью ревью, временем цикла, долей возвратов и ошибками после выпуска.
- Команде: договоритесь, какие изменения ИИ может готовить самостоятельно, а где нужен независимый проверяющий и явный критерий готовности.
Что это меняет для команды и бизнеса
Покупка AI-инструмента не является изменением процесса. Если прежние согласования, лимиты работы в процессе и ответственность за выпуск остались прежними, дополнительный output лишь быстрее заполнит очередь. Экономический эффект появляется, когда команда перестраивает весь путь до результата.
Рабочая карта недели
| Решение | Когда это ваш случай | Первый ход | Граница |
|---|---|---|---|
| Расширять доступ к ИИ | Есть повторяемый тип задач | Две недели измерять cycle time, ревью, возвраты и ошибки до пилота | Не считать набор текста метрикой потока |
| Давать модели готовить изменения | Есть тесты и review | Ограничить размер предложения и назначить тест, проверяющего и откат | Не масштабировать при росте возвратов или ошибок после релиза |
| Продлевать или покупать инструмент | Можно сравнить одинаковые задачи | Провести короткий A/B-пилот на знакомом стеке | Не оплачивать ожидание скорости вместо результата процесса |
Продолжить в Практикуме
Не начинайте с закупки или общего разрешения на ИИ. Сначала пройдите один процесс через Human Review Matrix: она отделит задачи, которые можно отдать машине, от задач под проверкой и задач, где решение остаётся за человеком. Для выбранного режима соберите эталонный набор, чтобы измерять качество и возвраты до масштабирования, а не объяснять их после релиза.
Следующий разумный ход
Выберите один повторяемый тип задачи и две недели измеряйте четыре величины: полное время цикла, время проверки, долю возвратов и ошибки после применения. Затем включите ИИ ещё на две недели для сопоставимых задач. Если производство ускорилось, а полный цикл нет, ищите переместившееся узкое место, а не просите модель генерировать ещё быстрее.
Уровень доверия и источники
DORA даёт наблюдаемую связь, а не причинный эффект. Раннее исследование METR было рандомизированным, но небольшим и относится к инструментам начала 2025 года; последующее исследование больше, однако страдает от самоотбора. Редакционный вывод о перемещении узкого места — интерпретация Практикума, которую следует проверять на собственном процессе.