ИИ-код убивает инженеров. Как разработчики теряют смысл разработки и о деградации компетентности

«Люди вкалывают по двенадцать часов в день, и всё, что они делают, это нажимают Enter под ответами различных моделей. Никто не читает код, тесты, тикеты и PRD. Всё генерирует Claude».

Пост с этим признанием написал инженер из крупной корпорации: за пару недель он увидел, как выглядит ИИ в разработке изнутри. Работу команды он описывает так: код, тесты, тикеты и PRD генерирует нейросеть, никто их не читает. Люди от L1 до L7 уровней переписываются с моделью и отправляют результат в прод. Итог он формулирует коротко: никто уже не думает, работа вызывает внутреннее истощение, а каждый день похож на «День сурка».

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

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

Я один из немногих, кто считает, что на текущем этапе развития ИИ это только инструмент. Адекватной серединой я называю соотношение 60/40: шестьдесят процентов рутины забирает ИИ, сорок остаются за человеком. В эти сорок входит принятие взвешенных решений и соблюдение компромиссов на этапе проектирования сисдиза, валидация работы LLM-моделей и умение рассказать, как устроен код в любой части системы, особенно в зоне своей ответственности. Из этой рамки я и смотрю на всё, что происходит вокруг.

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

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

Справедливости ради, углы в разработке резали всегда. Забавно наблюдать, что менеджмент не меняется: ему всегда и всё медленно. Тот же инженер ThePrimeagen вспоминает 2007 год и десять лет в Netflix: те же разговоры про скорость, экономию на качестве и «починим потом». Разница в масштабе. Раньше ты понимал, на чём можно сэкономить для быстрого завершения фичи, и решение было пусть компромиссным, но осознанным. Сейчас инженер оторван от кода настолько, что не знает, что там упростили без него. Файл вроде работает, но открываешь его и не понимаешь, как эта конструкция держится.

Самый практичный тест на понимание, который я встречал, прозвучал как раз в видео ThePrimeagen. Он приписывает его Митчеллу Хашимото: сможешь ли ты защитить свою систему стоя у доски, как в школьные годы, рассказывая выученный материал?

Вопросы простые. Почему здесь такая структура данных. Где система падает. Что произойдёт при сбое. Помнить каждую строку не нужно, этого никто и не просит. Нужно показать, что ты понимаешь то, что выпустил в прод. Если ответить не получается, значит, руль ты отпустил, но ответственность за систему всё равно осталась на тебе.

У меня в работе похожее правило: агент может писать код, но объяснить его обязан я. Если я не понимаю, что наворотила модель, дальше черновика это не уходит.

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

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

А сверху звучит успокаивающее: думать и помнить, оказывается, необязательно. Дженсен Хуанг, основатель Nvidia, в свежем интервью The Ezra Klein Show разложил это почти по пунктам. Дети хуже знают таблицу умножения, деление столбиком и квадратные корни, и это не беда. «Какая разница», отвечает он. Часть интеллектуальной ловкости мы потеряем, зато научимся мыслить системно, как инженеры, которым не нужно знать устройство транзистора. В подтверждение личный пример: свой почтовый индекс и номер телефона Хуанг не помнит и с этим давно смирился.

Звучит бодро, пока не вспомнишь контекст. Разговор шёл про исследование с участием двадцати шести тысяч школьников и студентов: с ИИ задания выполняются быстрее, а результаты экзаменов и удержание знаний проседают. Ответ главы компании, продающей чипы для ИИ, всё то же «какая разница». Получается, системное мышление советуют строить на фундаменте, который сам же Хуанг предлагает не тренировать. Про разряженный телефон и забытые номера в интервью, конечно, ни слова. И это, пожалуй, самая честная часть разговора: чем меньше человек думает и помнит, тем важнее, чтобы под рукой было железо.

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

ThePrimeagen рассказывает про себя похожее: изучая новый инструмент, он садится писать руками. Ему мало прочитать документацию, логику надо прочувствовать. Мне эта привычка близка, с новым я разбираюсь так же. Только если это мой прототип или пет-проект, я где-то могу схалтурить.

В разборе материала от ThePrimeagen есть и объяснение, почему одни считают ИИ всемогущим, а другие осторожничают. Мир разработки разделился на два лагеря. В первом простые проекты: сайт, сервер, база данных. Там нейросеть действительно закрывает большую часть работы, и из этого мира растёт у людей уверенность, что «ИИ может всё».

Второй мир это распределённые системы: много сервисов, нестандартные сценарии, редкие состояния. Сложность здесь растёт быстро, и без понимания механики всё заканчивается коллапсом. Нейросети в разработке не спасут, если рядом нет инженера, который держит картину целиком.

Я сам разбирал, как ИИ-агенты ведут себя на большой кодовой базе: Проблемы ИИ-агентов с большой кодовой базой и пути решения. Выводы там похожие: чем сложнее система, тем быстрее заканчивается магия и начинается ручная отладка.

Нейросети тут ни при чём. Виноваты процессы и люди, которые решили, что можно не думать. У инженера всегда было право сказать «нет»: без скандалов, спокойно. Качество требует времени, а «быстро и вечно» не бывает. За спринт из сгенерированных токенов кто-то однажды заплатит.

Деградация компетентности начинается с молчаливого согласия сотрудника, особенно когда стоит вопрос увольнения или летят жалобы о некомпетентности со стороны менеджеров. С того, что человек в ленте релизов давно не помнит, что там внутри. И это уже общая проблема, не только корпораций.

О будущем программирования я писал и раньше: Будущее профессии программиста в эпоху ИИ. Вывод с тех пор укрепился. Выигрывают не те, кто быстрее жмёт Enter, а те, кто понимает, что собирает. Смысл разработки никуда не уходил, он просто стал «необязательным пунктом».