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

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

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

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

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

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

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

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

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

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

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

В любом случае, подходы к разработке меняются, рынок меняется, растут скорости — и мы становимся свидетелями по-настоящему захватывающих преобразований.