Почему я перестал доверять ИИ в разработке и начал проверять каждый чих
Что не так с ИИ-генерацией кода?
Первое, что бросается в глаза — сгенерированный код часто выглядит правдоподобно, но содержит логические ловушки. ChatGPT может написать функцию, которая проходит тривиальные тесты, но при edge-кейсах падает. Copilot предлагает автодополнения, которые вроде бы вписываются в контекст, но нарушают архитектурные принципы. Проблема в том, что эти инструменты не понимают семантики — они работают на уровне статистики и вероятностей.
«ИИ не знает, что делает. Он просто угадывает следующий токен. Вся ответственность за корректность ложится на разработчика».
Из-за этого возникает ложное чувство безопасности. Разработчик начинает меньше вчитываться в код, полагаясь на то, что «ИИ же не мог ошибиться». В итоге баги проникают глубже, и их исправление занимает больше времени.
Потеря навыков и критического мышления
Регулярное использование ИИ для написания рутинных конструкций приводит к атрофии навыков. Вы перестаёте держать в голове паттерны, забываете синтаксис, теряете способность быстро оценивать алгоритмическую сложность. Критическое мышление притупляется — вы принимаете сгенерированный ответ как истину, не проверяя альтернативы.
Это особенно опасно для джуниоров, которые ещё не сформировали «чувство кода». Они привыкают к тому, что ИИ решает за них, и не учатся самостоятельно разбираться в проблемах. В долгосрочной перспективе это ведёт к снижению компетенции целого поколения разработчиков.
Качество и безопасность: иллюзия надёжности
ИИ-модели обучаются на открытых репозиториях, в которых полно устаревших практик, уязвимостей и просто плохого кода. Соответственно, на выходе вы получаете код, который может содержать SQL-инъекции, небезопасное хранение данных или неправильную обработку ошибок. Пример из реального проекта: Copilot сгенерировал функцию для проверки прав доступа, которая пропускала всех, если в массиве ролей оказывался null. Это привело к утечке данных на staging-сервере.
| Параметр | Без ИИ | С ИИ (без проверки) | С ИИ (с code review) |
|---|---|---|---|
| Скорость написания | Низкая | Высокая | Средняя |
| Качество кода | Высокое (при опыте) | Низкое — среднее | Высокое (при хорошем ревью) |
| Количество багов | Низкое | Высокое | Среднее |
| Обучающий эффект для джуна | Высокий | Низкий | Средний |
| Риск уязвимостей | Низкий (при опыте) | Высокий | Средний |
Как видно из таблицы, единственный сценарий, при котором ИИ даёт чистое преимущество — это когда разработчик тщательно проверяет каждую строку. Но тогда пропадает смысл в ускорении: время экономится за счёт качества.
Психологический аспект: раздражение от потери контроля
Настоящая причина моего раздражения — это ощущение, что я перестаю контролировать процесс. Раньше я писал код и понимал каждую строчку. Теперь я трачу полдня на то, чтобы разобраться, почему сгенерированная функция работает не так. ИИ лишает меня главного удовольствия от программирования — возможности творить и решать задачи осмысленно. Вместо этого я превращаюсь в надзирателя, который проверяет работу чёрного ящика.
Особенно бесит, когда ИИ «упорно» предлагает один и тот же неправильный паттерн, несмотря на то, что я его уже трижды исправлял. Приходится тратить время на то, чтобы «обучить» инструмент, хотя проще написать самому.
Как использовать ИИ с умом?
Я не предлагаю полностью отказаться от ИИ. Инструменты могут быть полезны, если соблюдать несколько правил:
- Никогда не принимайте код без проверки. Каждая строка должна быть осмыслена.
- Используйте ИИ только для шаблонных задач (генерация boilerplate, написание тестов, документации).
- Не давайте ИИ решать алгоритмические или бизнес-задачи, требующие глубокого понимания.
- Регулярно практикуйтесь без ИИ, чтобы поддерживать навыки.
Личное наблюдение автора: Я заметил, что самый продуктивный режим — это сначала написать код самому, а потом попросить ИИ найти ошибки или предложить альтернативы. Тогда инструмент работает как ревьюер, а не как замена мышлению.
Источник: IT Фишки
