ИИ раздали — пользоваться не научили. Почему он не окупается

В одном из RCT METR на early-2025 ИИ-инструментах опытные open-source разработчики выполняли реальные задачи на знакомых репозиториях на 19% дольше с ИИ — хотя субъективно считали, что ускорились примерно на 20%. Позже METR отдельно уточнил, что этот результат уже не стоит переносить на текущие инструменты как универсальный вывод. Но сам разрыв между ощущением продуктивности и фактическим результатом остаётся важным сигналом: внедрение ИИ нужно измерять, а не оценивать по впечатлению.

Это не значит, что ИИ бесполезен. Это значит, что выгода не появляется сама по себе от факта покупки инструмента. Данные по компаниям говорят о том же: в отчёте MIT (Project NANDA, «The GenAI Divide», июль 2025) ^[1] при 30–40 млрд долларов вложений около 95% компаний не получили измеримой отдачи. Авторы связывают это не с моделями, а с разрывом в освоении — между «инструмент купили» и «процессы перестроили».

По моему опыту работы с командами картина повторяется: лицензии Copilot, Cursor, DeepSeek, Qwen раздают, а дальше каждый разбирается сам. Ниже — что при этом ломается и что с этим делать на уровне процесса, а не лозунгов.

Что ломается, когда ИИ раздают без правил

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

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

Джуны коммитят код, который не понимают. Сгенерировал, отправил, ревью по диагонали. Локально каждый фрагмент выглядит разумно, а ломается на стыках, где никто не смотрит.

Итог: индивидуальная скорость «писать строки» растёт, а скорость команды доставлять рабочий софт падает.

Почему так выходит

ИИ внедряют как покупку софта: оплатил лицензию — жди результата. Но так не работает даже с трекером задач. Купить Jira — минуты, а чтобы команда реально заработала по Scrum, годами нужен был скрам‑мастер: он внедрял и держал методологию, пока команда не усваивала её сама. Корпоративные agile‑трансформации шли годами, а не месяцами.

ИИ‑агент тоже меняет методологию работы, а методологию не покупают — её внедряют. На переходный период нужен тот, кто ставит правила, учит и измеряет. По замыслу роль временная, но без неё переход растворяется в «у нас же есть Cursor».

Дальше — конкретика, как этот переход выглядит на уровне процесса. Три вещи: правила, ревью, метрики.

1. Правила под стек, а не общие промпты

Абстрактное «как промптить» не помогает — помогает «как писать в нашем репозитории». Это выносится в файл правил, который агент читает на каждом запросе (cursor rules, .github/copilot-instructions.md ^[2], CLAUDE.md ^[3] и аналоги). Грубый пример такого файла:

# Правила проекта для ИИ-агентов

## Контекст
- Backend: Python 3.12, FastAPI, SQLAlchemy 2.0 (async), Postgres.
- Линт: Ruff + mypy strict. Нового кода без типов нет.
- Доменная логика — в /domain, не в обработчиках роутов.

## Обязательно
- Прочитать спецификацию задачи целиком. Если в ней нет ограничений —
  спросить, а не догадываться.
- Следовать существующим паттернам модуля, который правишь.
- Покрывать логику тестами на поведение, а не на реализацию.

## Запрещено
- Добавлять новые зависимости без явного согласования.
- Дублировать утилиты — сначала искать в /shared.
- Менять сигнатуры публичного API, не пометив это явно.

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

2. Ревью, заточенное под ИИ‑код

ИИ‑код ломается не так, как человеческий, поэтому смотреть на него стоит отдельным чек‑листом. Минимальный набор:

• Контекст: реализация решает поставленную задачу, а не то, что было «удобно» сгенерировать?

• Дубли: нет ли копии существующей утилиты или логики? Искать по кодовой базе.

• Зависимости: не притащил ли агент новый пакет ради одной функции?

• Тесты: проверяют поведение или просто повторяют код? Падают ли, если намеренно сломать логику?

• Безопасность: валидация ввода, секреты, SQL‑инъекции, авторизация на новых эндпоинтах.

• Краевые случаи: обработаны ошибки и границы, а не только happy path?

• Понимание: автор PR может объяснить каждую строку? Если нет — на доработку.

3. Метрики до и после

Без чисел вы не знаете, помогает ИИ или вредит, — а ощущению, как показал METR, верить нельзя. Мерить полезно не «строки в день», а:

• время на ревью PR;

• долю переписанного кода (rework / churn);

• время цикла от коммита до прода;

• число багов на проде и инцидентов — выросло или нет;

• сопровождаемость: код держится в рамках принятых стандартов (SOLID, связанность модулей) или плывёт в свалку.

В том же отчёте MIT внедрения, где внутреннюю команду усиливали внешней экспертизой, окупались в 67% случаев против 22% у чисто внутренних. Структурированное обучение даёт примерно вдвое больше отдачи — что согласуется с тем, что дело в процессе, а не в самой модели.

Коротко

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

А как ИИ раскатывали у вас: вводили правила и ревью под него или просто выдали доступы? Что из перечисленного сработало, а что нет?