← Back to blog

AI не решит проблему плохого фокуса

AI не решит проблему плохого фокуса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 или пока только написание кода?