Опытные разработчики с ИИ‑ассистентом нередко работают медленнее, а не быстрее. В рандомизированном эксперименте METR (июль 2025) опытные разработчики выполняли реальные задачи на 19% дольше с ИИ — и при этом были уверены, что ускорились примерно на 20%. Разрыв между ощущением и фактом — около 40 пунктов.
Это не значит, что ИИ бесполезен. Это значит, что выгода не появляется сама по себе от факта покупки инструмента. Данные по компаниям говорят о том же: в отчёте MIT (Project NANDA, «The GenAI Divide», июль 2025) при 30–40 млрд долларов вложений около 95% компаний не получили измеримой отдачи. Авторы связывают это не с моделями, а с разрывом в освоении — между «инструмент купили» и «процессы перестроили».
По моему опыту работы с командами картина повторяется: лицензии Copilot, Cursor, DeepSeek, Qwen раздают, а дальше каждый разбирается сам. Ниже — что при этом ломается и что с этим делать на уровне процесса, а не лозунгов.
Что ломается, когда ИИ раздают без правил
Сеньоры замедляются и не замечают этого. Тот самый разрыв между ощущением и реальностью из эксперимента METR. Человек чувствует ускорение, потому что меньше печатает руками, а суммарное время от задачи до рабочего результата растёт.
Технический долг копится молча. Растёт доля дублированного кода и churn — строк, которые переписывают в первые две недели после написания. Часть сгенерированного кода в чувствительных к безопасности местах содержит уязвимости, при этом тесты зелёные: ИИ пишет тесты, которые подтверждают, что код делает то, что делает, а не то, что требуется.
Джуны коммитят код, который не понимают. Сгенерировал, отправил, ревью по диагонали. Локально каждый фрагмент выглядит разумно, а ломается на стыках, где никто не смотрит.
Итог: индивидуальная скорость «писать строки» растёт, а скорость команды доставлять рабочий софт падает.
Почему так выходит
ИИ внедряют как покупку софта: оплатил лицензию — жди результата. Но так не работает даже с трекером задач. Купить Jira — минуты, а чтобы команда реально заработала по Scrum, годами нужен был скрам‑мастер: он внедрял и держал методологию, пока команда не усваивала её сама. Корпоративные agile‑трансформации шли годами, а не месяцами.
ИИ‑агент тоже меняет методологию работы, а методологию не покупают — её внедряют. На переходный период нужен тот, кто ставит правила, учит и измеряет. По замыслу роль временная, но без неё переход растворяется в «у нас же есть Cursor».
Дальше — конкретика, как этот переход выглядит на уровне процесса. Три вещи: правила, ревью, метрики.
1. Правила под стек, а не общие промпты
Абстрактное «как промптить» не помогает — помогает «как писать в нашем репозитории». Это выносится в файл правил, который агент читает на каждом запросе (cursor rules, .github/copilot-instructions.md, CLAUDE.md и аналоги). Грубый пример такого файла:
# Правила проекта для ИИ-агентов
## Контекст
- 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% у чисто внутренних. Структурированное обучение даёт примерно вдвое больше отдачи — что согласуется с тем, что дело в процессе, а не в самой модели.
Коротко
ИИ не провалился. Провалилась попытка получить выгоду, ничего не меняя в том, как работают люди: мощный инструмент раздали без правил, ревью и метрик. Инструмент уже есть — осталось выстроить вокруг него процесс.
А как ИИ раскатывали у вас: вводили правила и ревью под него или просто выдали доступы? Что из перечисленного сработало, а что нет?