Дисклеймер

Скрытый текст

Этот текст — не учебник и не строгий гайд. Скорее, разгрузочный рассказ про то, как ChatGPT вписывается (или не вписывается) в жизнь разработчиков. Немного моих историй, немного боли, немного юмора. Холивар приветствуется. ?

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

Хочется немного порассуждать на эту тему. И рассказать пару историй из жизни.


Среди моих друзей…

Среди моих друзей есть рьяные адепты чата GPT. Да-да, привет, Александр!

Помните мем:

«AI стали писать код как настоящие программисты — мой код не компилируется, и у AI тоже.»

Примерно такое у меня было отношение к чатику. Но вот Александр, ни разу не будучи разработчиком, говорит:

«Спорим, я напишу код с чатиком? Чат может ВСЁ!»

Окей. Спорим.

Я открываю JIRA, нахожу реальную задачу. И, с моей небольшой помощью и помощью чатика, Александр её делает за не самое большое время. Потом экспериментировать начинаю уже я. Быстро упираюсь в лимиты запросов, и следом летит платная подписка. И буквально за час-два я пишу основу небольшого микросервиса, который команда делала чуть ли не неделю. Так примерно и началась моя дружба с чатиком.

Эксперимент

Следующей безумной гипотезой было: а может ли человек «с улицы» писать код вместе с чатом GPT не хуже джуна?

И эксперимент мне посчастливилось провести.

Человек был не совсем с улицы, но всё же с весьма слабым техническим бэкграундом. Даже курсы у него были условные. Но глаза горели, был готов работать день и ночь — и за дешево. Осваивать промт-инжиниринг. ?

А я как раз уволил дорогого джуна, который, кажется, уже не хотел работать вовсе. О чём он, кстати, откровенно признавался. Условная производительность — 30-50 строчек кода в день, причём довольно банального и рядового. Меня это никак не устраивало. Ну чем не повод поэкспериментировать?


Ну всё. Джун-стажёр на своём рабочем месте. Платная подписка куплена, курок взведён, к бою готов. Перед джуном два монитора, практически две клавиатуры. Всё по-взрослому. Кодогенерация началась.

На каком-то этапе начинается лютая самодеятельность. Грубо говоря, просишь поменять формулу, проверяешь MR — а там уже половина сервиса переписана. Потом начинаются разборы полётов. Оказывается, чатик увёл по ложному следу, не в ту сторону.

В общем, генерация кода возросла — уже не 30-50 строк кода, а сильно больше. Но всё этот код приходится переписывать или даже полностью откатывать.


С утра ставлю задачу:

— Всё понятно?

Джун:

— Понятно. Дай мне пять минут.

Проходит полдня. Спрашиваю:

— Ну как дела?

Джун:

— Да опять чатик на**л.

Иногда я начинаю кричать матом:

— Убирай на**й чатик, гугли по старинке!

Но джун меня успокаивает:

— Щас-щас, всё будет. Немного чатик меня запутал. Щас другой запрос введу.

Я говорю:

— Вводи при мне.

И так мы ещё полдня переделываем код.

Галлюцинации чатика

Другой пример. Писал фрагмент одного сервиса. Нужно было сгенерить DTO по примеру из документации. А DTO большой, с вложенными объектами, плюс ещё комментарии нужно было перенести из документации.

Целый час маялся с запросами. Было видно невооружённым взглядом: столько полей и объектов чатик не тянет. То комментарии от себя пишет, то лишние поля придумывает. В общем, галлюцинирует.

Говорю джуну:

— Есть задачка.

Джун:

— Как обычно, дай мне пять минут. Щас мы с чатиком всё сгенерируем.

Ай нет. Сам только что час генерил.

Говорю:

— Давай в ручном режиме. Внимательно пройдись по документации и проверь все поля и комментарии.

Проходит полдня. DTO — отличный. Зато фабрика по созданию объекта сильно пострадала. И тесты тоже.

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

Промежуточный подытог

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

Для меня это чаще всего:

  • генерация тестов,

  • создание DTO,

  • аналитические запросы к базе данных,

  • какие-то конфиги, которые самому лень гуглить,

  • или исправление ошибок, которые тоже иногда лень разбирать вручную.

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


В случае с джуном всё иначе. Он пишет код практически от и до. От чего, видимо, его стоит отучать. У него пока мало насмотренности на код. Он не всегда чётко понимает, что должно получиться в итоге.

А чатик рассказывает всегда очень уверенно. «Давай исправим это. А теперь ещё это. А если не сработает, есть ещё два варианта.»

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

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

Позитивная сторона

Положа руку на сердце, у джуна всё-таки случился полный deep-dive в разработку.

Для справки: это человек, который изначально целился в тестировщики. Знал Java лишь в какой-то степени. Где-то одним ухом слышал про Spring — «ну, это вроде фреймворк такой». Да-да, специфические качества для найма. ?

А теперь:

  • пишет микросервисы,

  • начинает разбираться в слоистой архитектуре,

  • отличает домен от инфраструктурного слоя,

  • делает REST API,

  • работает с файловыми хранилищами S3, интеграцией с Google Drive,

  • сам выделяет интерфейсы,

  • работает с Kafka и Spring Cloud Stream,

  • пишет сервисы колбеков и уведомлений,

  • реализует отложенные задачи через планировщик с ретраями,

  • подключает Swagger и документирует API,

  • валидирует всё это через юнит-тесты, интеграционные тесты и системные тесты с SpringBootTest.

И между делом ещё читает книги, документацию и подтягивает общее понимание. Честно — от такого объёма информации голова реально может закипеть. Там не то что галлюцинациям чатика поддашься — просто забудешь, как тебя зовут.

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

Выводы

Существует мнение, что ChatGPT способен заменить реальных разработчиков. Мол, джуны вовсе не нужны — их место займут специальные операторы для чата.

Я всё-таки пока не согласен с этим мнением.

Чтобы писать правильные запросы и валидировать результат GPT, нужен навык код-ревью и насмотренность на код. Какая, в принципе, разница, откуда взялся код — написал его человек или бот? Его всё равно нужно читать, анализировать, критиковать и иногда подталкивать чат к улучшениям.

А джун, по сути, пока этими навыками не обладает. Он чаще выполняет Ctrl+C / Ctrl+V и запускает приложение или тесты — и то, если после изменений всё это ещё компилируется и запускается. А ChatGPT рассказывает за свой код, как настоящий сеньор. Но пишет далеко не всегда на том же уровне. И с ним нужно уметь спорить.

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

Так что пока чаты не научились сами себе ставить задачи и сами себя ревьюить, роль тимлида никто не отменяет. По сути, лид и есть оператор чата, только вместо prompt он пишет задачи в JIRA. ?


Для джуна же важно помнить: ChatGPT — это инструмент, но не замена голове. Он может ускорить обучение и подсказать решение. Но без понимания сути есть риск уйти по ложному следу и переписать полпроекта там, где нужно было поменять одну строку.

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

Ну и, видимо, джунам остаётся одно — практиковаться в код-ревью. Вводить методики экстремального программирования (отсылка к парному программированию), кросс-ревью в команде и всё такое. ?

А вы уже пробовали работать с ChatGPT? Он вас выручал или заводил в дебри?

Делитесь в комментариях.

P.S.

Если хотите обсудить ChatGPT, джунов, архитектуру или просто поугарать над кодом — залетайте в мой Telegram-канал.

CTO / архитектор для старта или перезапуска проекта — пишите: @korobovn, t.me/cto_way, korobovn@gmail.com

Ну ждемс… ?

Комментарии (33)


  1. Indemsys
    02.07.2025 16:35

    Любой из ChatGPT каждый день показывают гораздо худшие результаты чем Cloude Sonnet 4 в режиме агента.
    ChatGPT всегда делает меньше и требует более детальных заданий.
    Годен только для того чтобы на пять минут заменить Cloude пока тот перегружен.


  1. LeshaRB
    02.07.2025 16:35

    Раньше на Хабре были статьи, что Джун не может написать код без stackoverflow
    Прошло время...


    1. Sly_tom_cat
      02.07.2025 16:35

      ... когда "джуны" и с IA - тоже не могут написать ничего толкового.


    1. saag
      02.07.2025 16:35

      ...Джун не может написать код без импланта.

      Прошло время...

      june(dynamic args) не может написать код без библиотеки

      Прошло время...


    1. ZlayaBelka1985
      02.07.2025 16:35

      Теперь те джуны , это сеньоры которые пишут статьи на хабре и говорят что джуны без АИ ничего не могут)))