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 или пока только написание кода?