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