Современная разработка благодаря LLM все чаще превращается в многопоточный конвейер. Сегодня Claude Code или ChatGPT могут написать вам целое приложение или микросервис буквально по небольшому промту.
Будет ли это качественно? Зависит от задачи.
Если вы автоматизируете свои рутинные дела, то даже костыльная автоматизация часто будет приносить пользу (я, например написал много рутинных помощников для личного пользования).
А вот если вы проектируете сложный многоуровневый пайплайн, то брать код “as is” как минимум опрометчиво.
Поэтому главный навык программиста в век нейросетей, как мне кажется, - это уже не написание кода, но и быстрая вычитка, понимание и дебагинг чужого кода.
Допустим, вы сильный разработчик и можете с помощью LLM сразу собрать хороший микросервис или устойчивый пайплайн. Вы контролируете процесс от этапа промптинга до деплоя, понимаете за что отвечает каждый декоратор в вашем flask приложении и как точно классы описывают поведение сущностей.
Но что делать в ситуации когда вы сталкиваетесь с чужим кодом который вам нужно задебажить или что еще хуже перестроить/достроить. И вот тут начинается самая сложная часть. Те, кто часто сталкивался с генерацией кода нейросетью, знают, что она нередко добавляет лишние проверки, избыточные исключения, усложняет функции и строит многоступенчатую логику там, где можно было проще.
Чтобы понять суть этой проблемы, надо вспомнить, как работают большие языковые модели. LLM предсказывает следующий токен, опираясь на контекст задачи, то есть на промт и историю чата. И если в промте явно, четко и однозначно не заданы требования к простоте, читабельности и воспроизводимости кода, нейросеть будет использовать усредненные паттерны и подбирать решение, которое на подходящую задачу решенную ранее.
Вы скажете, что LLM часто пишет в стиле "опытного разработчика": с большим количеством проверок, исключений и вспомогательных обвязок. Да, НО если вы это понимаете. Однако если вы не можете воспроизвести логику кода, его доработать или быстро починить, то его практическая ценность резко падает, независимо от того, насколько "профессионально" он выглядит.
Проще говоря, если при чтении вам кажется, что код понятен, но вы не можете потом воспроизвести его логику хотя бы в виде псевдокода, значит, скорее всего, вы поняли его лишь поверхностно.
Один из ключевых навыков, который надо качать в век нейросетей, - это не "грокание алгоритмов" и борьба за O(N), а дебагинг, упрощение и оптимизация уже написанного кода. Та скорость, с которой сейчас пишутся OSS и коммерческие проекты впечатляет и даже пугает. Через N лет нейросети, возможно, будут обучаться на коде, который уже частично был сгенерирован другими нейросетями. Но кто скажет хороший ли это код или нет?
Можно заметить, что если код выполняет задачу то он хороший. Но воспроизводимость в случае ЧП, быстрая доработка, работа в NDA или GOV проектах - это как минимум те сценарии, где нейросети невозможно быстро или безопасно дать весь нужный контекст (ну не скармливать же ей целые приватные репы?).
Писать код с помощью нейросети - не проблема. Проблема начинается тогда, когда вы принимаете в работу код, который сами не понимаете и за который не готовы отвечать. Вы можете не идеально ориентироваться в каждой библиотеке или каждом методе, и в эпоху LLM это нормально. Но управлять архитектурой и логикой кода обязаны.
Я взял за ежедневную практику такое упражнение: прошу LLM подготовить мне сложный pipeline (классический ML или deep learning) с большим количеством комментариев и пояснений. Потом я читаю этот код как книгу и пытаюсь воспроизвести базовую логику, упростить отдельные места и предложить улучшения.
Попробуйте провести эксперимент:
- Попросите LLM сгенерировать сложный pipeline (ML / backend / любой стек).
- Попросите добавить максимум комментариев и пояснений.
- Прочитайте код.
- Попробуйте воспроизвести логику словами или в виде псевдокода.
- Найдите несколько мест, которые можно упростить.
Если не получается - значит вы понимаете проблему которую я описал.
p.s. Можно возразить, что опытные разработчики и так умеют быстро читать чужой код - это правда. Но проблема в том, что в эпоху LLM резко вырос не только объем кода, но и его сложность и неоднородность. В результате даже сильные разработчики все чаще тратят огромное количество времени на разбор и упрощение сгенерированного кода, чем на его написание с нуля.