«Насколько ИИ ускоряет вашу работу?» Честный ответ звучит сложнее, чем «в два раза». Руководители спрашивают об этом, потому что платят за инструменты и хотят понять отдачу. Кандидат, который умеет говорить о пользе без преувеличений, выглядит зрелым.
Ощущение против измерения
Главная ловушка: субъективное ощущение скорости и измеренная скорость могут расходиться. Генерация кода создаёт сильное чувство продвижения: экран быстро наполняется. Но время уходит в другие места:
- чтение и понимание сгенерированного кода;
- исправление правдоподобных ошибок;
- переформулировку запросов и повторные попытки;
- ревью, которое стало тяжелее у коллег;
- поиск багов, найденных позже, уже в проде.
Публичные исследования эффекта от ИИ-ассистентов дают противоречивые результаты: в одних условиях заметное ускорение, в других замедление опытных разработчиков на знакомом коде. Результат сильно зависит от задачи, опыта человека и кодовой базы. Поэтому на собесе лучше не называть чужие цифры, а рассказать, как вы мерили сами.
Что мерить
Количество сгенерированных строк и доля принятых подсказок это метрики активности, а не пользы. Больше кода не значит лучше. Полезнее смотреть на результат по всей цепочке:
- Время от начала задачи до прода (lead time), а не до первого коммита.
- Время и число раундов ревью. Если оно выросло, часть работы просто переехала к коллегам.
- Дефекты после релиза и откаты.
- Размер пулреквестов. Резкий рост часто плохой знак.
- Доля переделок: код, который переписали вскоре после мержа.
- Опросы команды, но как дополнение, а не единственный источник.
Сравнивать честно: похожие задачи до и после, или пилот на части команды. Важно учитывать, что в первые недели люди осваивают инструмент и могут работать медленнее.
Где ИИ обычно помогает
- Шаблонный код: обвязка, маппинг, конфигурация, типовые CRUD.
- Работа с незнакомым синтаксисом или библиотекой, когда вы понимаете суть.
- Разовые скрипты и утилиты, которые не пойдут в прод.
- Объяснение чужого кода, первый проход по незнакомому модулю.
- Перечисление краевых случаев, черновики тестов и документации.
- Миграции и механические замены по понятному правилу.
Где ИИ вредит или не окупается
- Критичный код: платежи, права доступа, криптография. Цена ошибки выше выигрыша во времени.
- Сложная бизнес-логика, которой нет в коде: ассистент не знает договорённостей и угадывает.
- Мелкие правки в знакомом коде: быстрее сделать руками, чем сформулировать запрос и проверить ответ.
- Обучение новому: если цель понять тему, готовое решение мешает разобраться.
- Огромные изменения за раз: их невозможно проверить, и долг копится незаметно.
Навыки и долг понимания
Если код пишет ассистент, а человек только принимает его, понимание системы в команде падает. Через полгода никто не может объяснить, почему модуль устроен так. Это похоже на технический долг, только в головах.
Особенно это касается джунов. Ассистент помогает им быстрее выдать результат, но может отнять опыт самостоятельного решения задач, из которого и вырастает инженер. Разумная практика: джун сначала пробует сам, потом сверяется с ассистентом, а на ревью объясняет решение своими словами.
Для себя тоже полезно иногда работать без подсказок: на собеседовании их может не быть, а базовые навыки нужны, чтобы проверять чужой и сгенерированный код.
Как отвечать на вопрос про продуктивность
Хороший ответ содержит три части:
- Где именно вам помогает: конкретные типы задач.
- Где не помогает и почему: критичный код, сложная логика, мелочи.
- Как вы это поняли: по каким признакам или метрикам, а не по ощущению.
Пример: «На шаблонном коде и тестовых данных экономлю заметно. На бизнес-логике выигрыша почти нет, потому что проверка занимает столько же, сколько написание. Понял это, когда сравнил время задач и число правок после ревью».