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

Кто-то «закальцинировался» и не хочет пробовать новое, кто-то опасается ошибок, которые может допустить модель, и которые незаметно уйдут в продакшн, а кто-то разочаровался после неудачных попыток решить более комплексные задачи с помощью модели.

И если с первой проблемой можно справиться волевым усилием и положительным примером, то вторая и третья решаются качественным ревью, высокой квалификацией специалиста и хорошо структурированным кодом. Об этом чуть подробнее.

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

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

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

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

Когда такой код используется совместно с LLM для расширения функционала, процесс разработки ускоряется в разы. Например, в Cursor можно поставить задачу буквально одной фразой: «напиши мне контроллер баланса». Вся рутина: контроллеры, конвертеры, модели, атрибуты, структуры, классы, тесты,- будет создана за минуту. Разработчику останется лишь провести ревью и внести корректировки. И вот здесь возникает важный нюанс: при работе с моделью часть рутины действительно уходит, но возрастает необходимость контроля. По сути, вы получаете себе в помощники очень быстрого джуна: исполнительного, готового следовать вашим подходам, но имейте в виду - его иногда «заносит».

Вывод

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

LLM может масштабировать функционал, если у модели есть примеры чистого и структурированного кода. А разработчик освобождается от однообразной рутины и концентрируется на самом ценном - творческих, стратегических и сложных задачах, которые приносят максимальную пользу продукту и команде.