ИИ-ассистенты в коде: где реально ускоряют, а где вредят

Dmitry_Volkov

New member
За последние полтора года я прошёл с ИИ-ассистентами весь путь от детского восторга до спокойной настороженности. Начиналось всё как магия: пишешь короткий комментарий, жмёшь Tab и получаешь готовый рабочий блок. Сейчас у меня в голове чёткое разделение: есть задачи, которые я без ассистента делать уже не хочу, а есть такие, к которым я его даже не подпускаю. Об этом и хочу поговорить честно, с примерами из своей практики.

Где реально ускоряют. Первое — скучная рутина и шаблонный код: обёртки над API, структуры данных, сериализация, миграции схемы, конфиги, однотипные экраны, тесты на уже написанную логику. Тут ассистент экономит мне реально часы. Второе — регулярки и запросы к базе. Я не держу в голове всю регулярку целиком, а рабочий вариант приходит за секунды. Третье — незнакомая технология: быстро накидать минимальный работающий пример, поднять проект с нуля, перейти с одного фреймворка на другой. Это огромный выигрыш по времени и нервам.

Ещё один сценарий, где ассистент стал моим любимым резиновым собеседником, — разбор чужого кода. Открываешь легаси-сервис на сотни тысяч строк и спрашиваешь: что делает эта функция, где её вызывают, что сломается, если поменять поле. Отвечает не всегда верно, но это гораздо быстрее, чем читать всё вручную, и отлично работает как точка старта для собственных вопросов.

А теперь где начинает вредить. Главная беда — уверенный тон при неверных фактах. Ассистент придумывает методы, которых нет, параметры, которых никогда не было, и библиотеки, существующие только в его воображении. Компилятор спасает не всегда, а в динамических языках такая ошибка спокойно доживает до продакшена. Вторая беда — код под копирку: выглядит аккуратно, проходит ревью на глаз и тихо дублирует одну и ту же логику в трёх местах. Потом это правится неделями.

Архитектуру и бизнес-логику я ассистенту не доверяю категорически. Он не знает историю решений, компромиссы, реальные ограничения по нагрузке, договорённости с заказчиком и то, почему в этом месте стоит странный костыль. Он предложит правильный вариант, который сломает три других сценария. Отдельно опасен размытый код-ревью: когда человек смотрит на сгенерированный diff и думает, ну, выглядит нормально. Именно так и проходят самые неприятные баги.

Есть и скрытая цена. Когда ассистент пишет за тебя, ты перестаёшь тренировать навык: читать документацию, отлаживать, держать в голове модель системы. Через полгода такой работы ловишь себя на том, что без подсказки тяжело написать простой цикл или разобраться в стектрейсе. Это не катастрофа, но иногда стоит сознательно выключать автодополнение, чтобы не терять форму.

Вот мои правила, которые я вывел для себя. Даю задачу маленькими порциями и всегда читаю полученное строчку за строчкой. Не принимаю сгенерированный код в архитектурные модули без полного понимания. Обязательно закрываю его тестами, линтерами и статическим анализом. Не вставляю в ассистента закрытый код, ключи, персональные данные и внутренние документы. И главное: ответственность за строку в репозитории всегда на мне, а не на модели.

Итог простой: ассистент — это мощный ускоритель для рутины и очень плохой советчик в вопросах смысла. Относитесь к нему как к стажёру, который быстро печатает и никогда не устаёт, но чьи ответы надо проверять. Тогда выигрыш будет заметным, а проблем минимум. А как у вас? Расскажите, какой случай работы с ИИ-ассистентом впечатлил вас больше всего — или наоборот заставил схватиться за голову?
 
Назад
Вверх