Как ИИ незаметно меняет мышление разработчиков

Я заметил это примерно через полгода регулярной работы с Copilot. Я отлаживал Python-скрипт и потянулся к ИИ-ассистенту, даже не дочитав ошибку. Трейсбек был прямо передо мной — KeyError: 'user_id', — но мой первый импульс уже стал «вставить в чат», а не «прочитать и подумать». Этот момент беспокоил меня сильнее любых споров о том, заменит ли ИИ разработчиков.

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

Фреймворк Канемана для кода

Различие Даниэля Канемана между Системой 1 (быстрой, автоматической, интуитивной) и Системой 2 (медленной, осознанной, аналитической) удивительно хорошо описывает работу разработчика. Чтение знакомых шаблонов кода, написание шаблонного кода, работа с известными API — это Система 1. Отладка гонок, проектирование распределённых систем, анализ последствий для безопасности — это Система 2.

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

Но риск в том, что ИИ также позволяет полностью обходить Систему 2. Когда ИИ предлагает целую функцию, принять её требует меньше усилий, чем понять. Когда он предлагает исправление бага, соблазн — применить его и двигаться дальше, не разобравшись, почему это работает. Со временем это может атрофировать аналитические навыки, которые отличают старшего инженера от того, кто просто быстро печатает.

Что действительно стало лучше

Было бы нечестно описывать это исключительно негативно. ИИ-инструменты действительно улучшили некоторые аспекты разработки.

Исследование незнакомых территорий

Когда мне нужно работать с языком или фреймворком, которые я не использую каждый день, ИИ-ассистенты меняют правила игры. Не потому, что пишут идеальный код — не пишут, — а потому, что дают отправную точку, которая обычно идёт в правильном направлении. Вместо часа чтения документации, чтобы разобраться с базовым шаблоном пула соединений PostgreSQL в Go, я за 30 секунд получаю разумный каркас и трачу этот час на части, которые действительно требуют суждения.

Это снижает порог для экспериментов с новыми инструментами. Я пробовал технологии, которые раньше пропустил бы только потому, что стартовый барьер казался слишком высоким. Это реальная польза: разработчики, которые уверенно работают с большей частью стека, эффективнее.

Меньше трения при переключении контекста

В современной разработке постоянно приходится переключаться между языками, фреймворками и парадигмами. Какой тест-раннер в этом проекте: Jest или Vitest? Возвращает ли этот API промисы или использует колбэки? Это кодовая база в snake_case или camelCase? ИИ-инструменты берут эти детали на себя и генерируют код, который соответствует контексту, снижая трение при переходе между проектами.

Ускоряем код-ревью

Когда ИИ суммирует большой дифф, отмечает потенциальные проблемы или объясняет незнакомые паттерны, код-ревью перестаёт быть таким утомительным. Я всё равно читаю код сам: сводка ИИ — это отправная точка, а не замена. Но она помогает сосредоточить внимание на важном, а не тратить одинаково много времени на правки шаблонного кода и на сложную логику.

Что стало хуже

Разрыв в понимании

На код-ревью я начал замечать закономерность: разработчики, которые активно используют ИИ, пишут код, который работает, но не могут его полностью объяснить. Спросишь «почему здесь WeakMap, а не обычный Map?», а в ответ слышишь «ИИ так предложил», а не объяснение последствий для сборки мусора. Код нормальный. Понимания нет.

Это важно, потому что понимание позволяет отлаживать под давлением, развивать код в неожиданных направлениях и принимать архитектурные решения. Можно выкатывать код, который не понимаешь, — люди делают это постоянно, — но поддерживать его не получится, и научить других тому, чего сам не знаешь, тоже.

Мышца отладки

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

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

Притяжение посредственности

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

Я наблюдал, как разработчики принимают сгенерированные ИИ решения, которые технически работают, но упускают ключевую идею, которая сделала бы код проще, быстрее или легче в поддержке. ИИ не подскажет то самое наблюдение, что «это на самом деле задача топологической сортировки». Он выдаёт рабочее решение методом грубой силы, и никто его не ставит под вопрос, потому что оно проходит тесты.

Проблема обучения

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

ИИ-инструменты сокращают эту борьбу. Джуниор, который мгновенно получает ответ на каждую ошибку, не вырабатывает такой же интуиции, как тот, кто 30 минут разбирал стектрейс и шагал по отладчику. Аналогия, к которой я постоянно возвращаюсь, — GPS-навигация: люди, которые всегда пользуются GPS, хуже развивают пространственное мышление, чем те, кто иногда ориентируется по карте. Пункт назначения тот же, но ментальная модель другая.

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

Поиск баланса

Поразмыслив над тем, как изменились мои собственные привычки, я выработал несколько правил, которые работают для меня. Это не универсальные законы: у разных разработчиков баланс будет своим.

• Сначала читайте ошибку, потом тянитесь к ИИ. Дайте себе 60 секунд на сообщение об ошибке или неожиданное поведение. Часто проблему видно сразу. Если нет, спрашивайте ИИ, но просите объяснить ошибку, а не только исправить её.
• Понимайте, прежде чем принимать. Когда ИИ предлагает код, читайте его так же, как PR коллеги. Можете ли вы объяснить, что делает каждая строка? Если нет, либо разберитесь, либо не мержите. «Работает» недостаточно для кода, за который вы отвечаете.
• Используйте ИИ для рутины, а не для сложных частей. Пусть он генерирует тестовый каркас, шаблонный код API, конфиги и оформление документации. Архитектуру, выбор алгоритмов и отладку делайте сами. Сложные части — это то, где вы учитесь и где ваше суждение дает наибольшую ценность.
• Периодически работайте без него. Как и любая зависимость от инструмента, полезно иногда работать без ИИ-ассистента. Не потому, что инструмент плохой, а потому, что нужно поддерживать навыки, которые он замещает. Я стараюсь проводить одну серьёзную сессию отладки в неделю без помощи ИИ.
• Объясняйте и обучайте других. Лучшая проверка понимания — умение объяснить что-то другому человеку. Если вы не можете объяснить, почему сгенерированный ИИ код работает, значит, вы недостаточно хорошо его понимаете.

Общая картина

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

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

Вопрос не в том, использовать ли ИИ-инструменты для программирования. Вопрос в том, используете ли вы их как электроинструмент, который усиливает ваши навыки, или как костыль, который не даёт этим навыкам развиться. Ответ зависит от задачи, контекста и того, на каком этапе карьеры вы находитесь. Но задавать этот вопрос стоит регулярно, потому что по умолчанию всё скатывается к зависимости, и противовес ей — только осознанность.