Мышление, скепсис и бизнес-ценность

Где AI даёт бизнес-результат, а где — модная нагрузка?

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

Отчёт DORA за 2024 год (свыше 39 тысяч респондентов) зафиксировал парадокс: рост освоения ИИ на 25% сопровождался снижением пропускной способности поставки на 1.5% и стабильности поставки на 7.2%. При этом ИИ улучшал промежуточные метрики процесса — качество документации, скорость ревью, читаемость кода. Причина расхождения — раздувание размера изменений: ИИ позволяет за то же время произвести больше кода, а большие изменения давно известны как более медленные и менее стабильные. В отчёте DORA за 2025 год (около 5 тысяч специалистов) картина смягчилась: ИИ описан как усилитель — он масштабирует и сильные, и слабые стороны организации. Связь освоения ИИ с пропускной способностью и продуктовыми результатами стала положительной (команды учатся встраивать инструмент), но связь со стабильностью поставки осталась отрицательной.

На уровне бизнеса разрыв ещё резче. Отчёт MIT NANDA The GenAI Divide (2025) на данных 300+ инициатив, интервью 52 организаций и опроса 153 руководителей показал: при вложениях в 30–40 млрд долларов 95% организаций не получают измеримого возврата на прибыль (P&L), и лишь 5% интегрированных пилотов приносят миллионы. Массовые инструменты вроде ChatGPT и Copilot освоены (80%+ пробовали, около 40% внедрили), но поднимают личную продуктивность, а не прибыль. Ключевой барьер — не инфраструктура и не таланты, а обучение: системы не запоминают контекст и не подстраиваются под процесс. И ещё один измеримый факт: внешние партнёрства доходят до результата вдвое чаще, чем внутренние сборки с нуля.

Почему проекты не взлетают, независимо разобрал RAND (65 интервью с инженерами): более 80% AI-проектов проваливаются — вдвое чаще обычных IT-проектов. Первая из пяти корневых причин — неверно понятая или неверно сформулированная задача; отдельная причина — погоня за самой модной технологией вместо решения реальной задачи. Это ровно тот механизм, который превращает ИИ в нагрузку.

Что делать, чтобы попасть в те самые 5%:

Мерьте бизнес-исход, а не активность. Строки, коммиты и число пилотов — метрики видимости, а не ценности. Заранее зафиксируйте базовую линию и метрику успеха, иначе по умолчанию получите отсутствие измеримого эффекта.
Направляйте ИИ на конкретную боль пользователя. DORA-2025 показывает: фокус на пользователе усиливает положительное влияние ИИ на результат команды.
Покупайте под непрофильное, стройте под ядро. Раз внешние решения выигрывают вдвое чаще — не переизобретайте типовое внутри.
Сначала система, потом инструмент. Наибольший возврат даёт не сам ИИ, а зрелость платформы, тестов и версионного контроля вокруг него.

Что пойдёт не так: если внедрять ИИ под лозунгом вокруг все о нём говорят и мерить успех строками и коммитами, вы ускорите производство изменений без контроля качества — и получите ту самую просадку стабильности из данных DORA, оплаченную бюджетом из отчёта MIT.

Ссылки

Скептичное отношение к AI инструментам

Скепсис здесь — не помеха, а измеримо полезная позиция. Начнём с самого неудобного факта.

Рандомизированный эксперимент METR (2025) на 16 опытных разработчиках и 246 реальных задачах в их же зрелых репозиториях (в среднем 23 тысячи звёзд, миллион с лишним строк) показал: с современными на тот момент ИИ-инструментами (в основном Cursor Pro и Claude 3.5/3.7 Sonnet) задачи занимали на 19% больше времени. Самое важное — разрыв между ощущением и фактом: до эксперимента разработчики ждали ускорения на 24%, после — были уверены, что ИИ ускорил их на 20%, хотя по факту он их замедлил. Эксперты по экономике и машинному обучению прогнозировали ускорение на 38–39%. То есть переоценка пользы системна и держится даже после десятков часов работы с инструментом. По итогу разработчики принимали без правок менее 44% сгенерированного кода.

Скепсис окупается и по безопасности. Стэнфордское исследование Perry и коллег (47 участников, 5 задач по безопасности на трёх языках) показало: у группы с ИИ-ассистентом код выходил менее безопасным в четырёх задачах из пяти — и при этом участники чаще верили, что написали безопасно. Ключевая находка: те, кто меньше доверял ИИ и активнее работал с формулировкой промпта (переформулировал, добавлял контекст, менял параметры), писали более безопасный и корректный код. Скепсис, переведённый в действие, буквально улучшал результат.

Отраслевой фон подтверждает, что вы не одиноки: по DORA-2025 30% специалистов по-прежнему мало или совсем не доверяют сгенерированному коду (годом ранее было 39%).

Как превратить скепсис в калибровку, а не в отказ:

Относитесь к выводу ИИ как к черновику под проверку. Доверяйте не рассуждению модели, а прогону — тестам, линтеру, статическому анализу.
Мерьте на себе, а не на ощущении. METR показал, что ощущение врёт. Возьмите несколько реальных задач с ИИ и без и сравните фактическое время.
Калибруйте по типу задачи. На типовом гринфилде ИИ действительно ускоряет: в контролируемом эксперименте с GitHub Copilot задача HTTP-сервера решалась на 55.8% быстрее. А на зрелом сложном коде — тормозит. Скепсис здесь не блокировка, а выбор, где инструмент уместен.
Учитывайте кривую навыка. В METR единственный разработчик с опытом Cursor больше 50 часов получил ускорение — доверие стоит наращивать по мере роста навыка, а не выдавать авансом.

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

Ссылки

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

Вопросы участников:

Все хотят результата от ИИ, никто не хочет учиться по-новому этот результат делать

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

Самое наглядное — та же RCT METR. При среднем замедлении на 19% единственным, кто получил ускорение, оказался разработчик с опытом Cursor больше 50 часов. У инструмента высокий порог входа: чтобы он начал помогать, навык надо наработать, а не просто открыть редактор. Стэнфордское исследование Perry показывает ту же механику с другой стороны: участники, которые владели промптингом — давали спецификацию, объявления функций, переформулировали запрос, управляли параметрами — получали более корректный и безопасный код. Навык работы с моделью измеримо менял исход.

На уровне организации это же формулирует MIT NANDA: главный барьер между 5% успешных и 95% буксующих — не железо и не регуляторика, а обучение. Массовая ошибка — считать, что ценность придёт вместе с закупкой лицензий; отчёт прямо фиксирует, что универсальные инструменты поднимают личную продуктивность, но не прибыль, пока процесс не перестроен. RAND добавляет: среди корневых причин провалов — завышенные ожидания и подмена решения задачи погоней за технологией.

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

Ясная и объявленная позиция по ИИ — правила игры, при которых команда экспериментирует уверенно.
Фокус на пользователе — ИИ полезен, когда нацелен на конкретную задачу, а не на всё сразу.
Малые партии изменений и сильный версионный контроль — навык отката спасает от нестабильности, которую приносит рост объёма изменений.
Качественная внутренняя платформа и доступ ИИ к внутренним данным — контекст компании превращает общий инструмент в по-настоящему полезный.

Практический вывод: относитесь к ИИ как к навыку, который нарабатывают, а не как к кнопке результата. Это целенаправленная практика, внутреннее обучение, подключение модели к своему контексту (через RAG и MCP), работа малыми партиями и измерение прогресса во времени.

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

Ссылки

Какие ограничения следует учитывать в AI driven development?

Разложим ограничения по слоям — от кода до бизнеса — и сразу с обходом.

1. Сложный зрелый код — слепая зона. RCT METR дала замедление на 19% именно на больших зрелых репозиториях с высокой планкой качества: модель не владеет неявным знанием кодовой базы, а ограниченное окно контекста не вмещает всю систему. Обход — маленькие изолированные задачи, подключение внутреннего контекста, человек на архитектуре.

2. Деградация поддерживаемости. Исследование GitClear (211 млн изменённых строк за 2020–2024) зафиксировало: в 2024 году впервые скопированных строк стало больше, чем перемещённых (перемещение — признак рефакторинга и переиспользования), частота дублирующихся блоков выросла кратно, а доля рефакторинга падает. Прогноз авторов: если мерить продуктивность строками и коммитами, основной работой разработчика может стать устранение дефектов, а не новые фичи. Обход — ревьюить на дубли, выносить повторы в общие модули, не поощрять метрику строк.

3. Безопасность и ложная уверенность. В исследовании Perry ИИ-ассистент повышал долю небезопасного кода в четырёх задачах из пяти при завышенной уверенности пользователя: модель не всегда выбирает безопасные библиотеки и плохо очищает ввод. Обход — обязательный скан безопасности и ревью, а не доверие на слово.

4. Нестабильность поставки от роста объёма. По DORA рост освоения ИИ давал просадку стабильности (−7.2% на каждые +25% освоения в 2024 году; отрицательная связь сохранилась и в 2025-м) — потому что растёт размер изменений. Обход — малые партии, автотесты как страховка, зрелый версионный контроль с быстрым откатом.

5. Проверка съедает выигрыш. METR по видеозаписям экрана показал: сэкономленное на наборе кода время уходит на чтение, правку промптов и ожидание генераций. Отсюда правило — доверять исполнению (прогон, тесты), а не тексту модели.

6. Ограничения на уровне бизнеса. MIT NANDA — 95% без измеримого возврата из-за разрыва в обучении; RAND — более 80% AI-проектов проваливаются, чаще всего из-за нехватки данных, неверно понятой задачи и незрелой инфраструктуры, а не из-за самой модели.

Как собрать это в рабочий процесс: относитесь к выводу ИИ как к черновику, стройте пайплайн вокруг исполняемых проверок, работайте малыми партиями с быстрым откатом, держите человека на архитектуре и безопасности и мерьте бизнес-исход, а не активность. Практический ориентир — семь способностей из DORA AI Capabilities Model.

Что пойдёт не так: без тестов-страховки и с метрикой строк ИИ ускоряет не поставку ценности, а накопление дефектов и дублей — ровно то, что показывают данные GitClear и DORA.