AI не решит проблему плохого фокуса
Есть соблазнительная мысль:
если разработчики будут использовать AI, команда начнёт работать быстрее.
В каком-то смысле это правда. AI действительно может ускорить много локальных задач: написать boilerplate, накидать тесты, объяснить кусок кода, помочь с рефакторингом, подготовить черновик документации.
Но есть нюанс.
AI ускоряет исполнение внутри задачи. Он не чинит систему, в которой задачи постоянно прерываются, переоткрываются, ждут ревью, меняют приоритет и теряют контекст.
Если у команды плохой фокус, AI может сделать ситуацию даже хуже.
Почему?
Потому что раньше человек физически не успевал создать слишком много незавершённой работы. А теперь успевает.
Можно быстрее написать код. Быстрее открыть pull request. Быстрее нагенерировать вариантов. Быстрее начать следующую задачу.
Но если ревью и принятие решений не ускорились, очередь просто переезжает в другое место.
Получается странная картина:
— кода стало больше; — pull request’ов стало больше; — обсуждений стало больше; — а delivery быстрее не стал.
И тимлид в этот момент может попасть в ловушку.
На уровне активности всё выглядит хорошо. Команда “использует AI”, задач в работе много, артефакты появляются быстрее.
Но продуктовая ценность всё равно выходит медленно.
Проблема в том, что AI хорошо помогает на уровне отдельного исполнителя, но delivery — это командная система.
В ней есть:
— постановка задачи; — понимание цели; — декомпозиция; — архитектурные решения; — ревью; — тестирование; — релиз; — обратная связь от пользователей.
Если узкое место не в написании кода, ускорение написания кода не даст большого эффекта.
Простой пример.
Команда страдает от того, что задачи плохо подготовлены. Разработчики постоянно уточняют требования, спорят с аналитиками, ждут решений от бизнеса.
Внедрили AI.
Теперь код по неясным требованиям появляется быстрее. Но требования от этого не стали яснее.
Или другой пример.
Главный bottleneck — code review. Ревью и раньше висели по 2–3 дня.
С AI разработчики стали быстрее открывать pull request’ы. Очередь на ревью выросла. Lead time не улучшился, а ревьюеры начали уставать ещё сильнее.
Поэтому я бы не начинал внедрение AI с вопроса:
“Как нам писать код быстрее?”
Я бы начал с другого:
“Где у нас сейчас реально тормозит поток работы?”
Если тормозит boilerplate — AI поможет.
Если тормозит ревью — нужны правила ревью, размер PR, ownership, возможно, AI-помощники для первичной проверки. Если тормозит постановка задач — нужен лучший discovery и Definition of Ready. Если тормозит релиз — надо смотреть CI/CD, тесты, согласования и rollback.
AI — это усилитель. Но он усиливает не только хорошее.
Если в команде порядок, он может дать хороший прирост. Если в команде хаос, он может просто помочь производить хаос быстрее.
Что можно сделать тимлиду:
1. Перед внедрением AI посмотреть текущий flow. 2. Найти реальное узкое место. 3. Не мерить эффект только количеством написанного кода. 4. Смотреть на lead time, cycle time, ревью, баги и возвраты. 5. Договориться с командой, где AI помогает, а где создаёт риск.
Мне кажется, главный вопрос про AI в разработке сейчас не “заменит ли он программистов”.
Более практичный вопрос:
какую часть нашей системы он ускорит, и не сломается ли от этого всё остальное?
А у вас AI уже ускорил delivery или пока только написание кода?
