Які помилки допускають розробники, кодуючи з AI-помічниками?

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

Прийняття пропозицій без їх прочитання

Найбільша проблема — просто натиснути Tab і прийняти доповнення, тому що воно виглядає правдоподібно і компілюється. Правдоподібне — це не те ж саме, що правильне. Я бачив, як запропонований SQL-запит беззвучно пропустив предложення WHERE під час рефакторингу, а людина його прийняла, тому що імена змінних збіглися. Якщо ви не читаєте кожний рядок, який дає вам помічник, із тією ж швидкістю, з якою читали б pull request колеги, ви відправите щось, чого не розумієте. Ставтеся до кожної пропозиції як до першого варіанта від молодого розробника, який швидкий, але не пам'ятає конвенцій вашої кодової бази.

Довіра йому у коді, пов'язаному з безпекою

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

Дозволення йому вигадувати залежності та API

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

Втрата ментальної моделі вашого власного коду

Коли ви пишете код самостійно, ви будуєте ментальну карту того, чому існує кожна деталь. Коли ви приймаєте великі блоки AI-генерованого коду протягом сеансу, ця карта швидко розріджується. Потім баг з'являється три тижні потому, і ви дебажите код, який ви ніколи насправді не писали й не розпам'ятовуєте повністю. Рішення — це не уникати AI-генерованого коду, це сповільнитись настільки, щоб пояснити кожен блок собі чи команді перед мерженням. Якщо ви не можете пояснити, що робить функція й чому вона це робить саме так, не мержте це ще.