Какие ошибки допускают разработчики при кодировании с AI-ассистентами?

AI-ассистенты вроде Copilot, Claude и встроенных моделей Cursor изменили скорость написания кода. Они не изменили, как тщательно его нужно проверять. Большая часть проблем, которые я видел от AI-assisted кодирования, происходит из-за горстки повторяющихся привычек, а не из-за самих моделей.

Принятие предложений без их прочтения

Самая большая ошибка — просто нажать Tab на завершении, потому что оно выглядит правдоподобно и компилируется. Правдоподобное не означает правильное. Я видел, как предложенный SQL-запрос молча потерял WHERE-предложение во время рефакторинга, и человек принял его, потому что названия переменных совпадали. Если вы не читаете каждую строку, которую вам выдаёт ассистент, с той же скоростью, с которой читали бы pull request коллеги, вы отправите то, что не понимаете. Относитесь к каждому предложению как к первому варианту от молодого разработчика, который работает быстро, но не помнит соглашений вашей кодовой базы.

Доверие к коду, чувствительному к безопасности

AI-ассистенты обучены на огромных кучах публичного кода, и много этого кода имеет встроенные проблемы безопасности. Попросите быстрый обработчик загрузки файлов и вы часто получите что-то без проверки расширения, без ограничения размера и с путём, построенным через конкатенацию строк вместо os.path.join или безопасного вызова библиотеки. То же самое с аутентификацией: ассистенты обожают предлагать хранение JWT в localStorage или сравнение секретов через == вместо сравнения с постоянным временем. Ничего из этого не злонамеренно, это просто статистически распространено в обучающих данных. Для всего, что касается аутентификации, файлового ввода-вывода, десериализации или SQL, напишите логику сами или пропустите вывод AI через те же вопросы моделирования угроз, которые вы задавали бы к любому новому коду: что происходит с враждебным входом, что происходит, если этот вызов не выполнится, кто ещё может получить доступ к этой точке входа.

Позволение моделям придумывать зависимости и API

Модели галлюцинируют названия пакетов и сигнатуры функций с полной уверенностью. Это проблема "slopsquatting" — злоумышленники регистрируют поддельные названия пакетов, которые модели часто предлагают, поэтому непроверенный pip install или npm install может подтянуть что-то, что вообще не ваша библиотека логирования. Перед добавлением любой зависимости, которую порекомендует ассистент, проверьте, что она действительно существует на PyPI или npm, посмотрите количество загрузок и дату последней публикации и просмотрите исходный код, если он достаточно небольшой. То же самое касается вызовов API: если ассистент ссылается на метод, который вы не узнаёте, проверьте реальную документацию перед тем как предполагать, что он существует.

Потеря понимания своего собственного кода

Когда вы пишете код сами, вы строите мысленную карту того, почему существует каждый кусок. Когда вы принимаете большие блоки AI-generated кода на протяжении сессии, эта карта быстро становится тонкой. Затем баг появляется три недели спустя и вы отлаживаете код, который вы никогда не писали и не полностью помните. Решение не в том, чтобы избегать AI-generated кода, а в том, чтобы замедлиться достаточно, чтобы объяснить каждый кусок себе или коллеге перед его слиянием. Если вы не можете объяснить, что делает функция и почему она делает это так, не объединяйте её ещё.

Пропуск тестов, потому что код