Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 35
Ууу. Covid ai дессидент.
Я И от гугла перестал помнить написанте половины слов, знаю только начало. Теперь выправляю бумагой с ручкой 😅
Я так-то с вами в целом абсолютно согласен, но пример с lru_cache — про другое. Я бы (если бы такое пролезло в продакшн) сделал (и делал сто раз в доиишную эпоху) ровно три вещи:
вызвал на 1-1 всех тех, кто делал код-ревью: не подумать про кластер и горизонталь — типичная ошибка даже для сеньора, но на ревью глаз обязан зацепиться;
создал бы в бэклоге задачу с самым приоритетным приоритетом: слой кэширования;
создал бы в бэклоге задачу с самым приоритетным приоритетом: телеметрия и метрики.
ИИ конкретно в данном случае ни при чем: ошибка стандартная, в терминах кластеров думать умеют немногие.
Сначала бы посмотреть в постановку задачи в жире, вспомнили ли там про ттэль, шэринг итд. прежде чем в пр обсуждать.
А то такие лиды только ходят и жалуются: "что же вы не подумали" - а что же вы такой фреймворк создали что у вас никто не думает?
Если в жире написано «закэшировать», этого достаточно. Может вам в жиру еще написать, как надо назвать функцию и сколько у нее должно быть аргументов?
Вы путаете (не)функциональные требования, которые в жире маст хэв, с деталями реализации, которые там опциональны.
Тем более тут эти требования были мандатори. Если их не было в жире, то это явный факап того кто ставил задачу.
А для нэймигов и пр. обычно есть принятые в проекте гайдланы и кодконвеншены, которые все и так соблюдают, и в том числе нейронки, если у них есть до них доступ. Поэтому дублировать это еще и в жире не нужно.
Есть у меня предположение, что от ИИ помощников у мясных LLM деградирует Step-by-Step Reasoning. И началось это раньше интернета, еще с калькуляторов.
→ https://habr.com/ru/articles/1002644/ ровно про это
единственный разумный паттерн применения генерации кода с пом ии: контролировать архитектуру, контролировать требования, просить дописать реализацию.
собрал требования, продумал как это дизайнить (можно отдельно посоветоваться в чатике с ии если надо), создал интерфейсы, создал тестовые методы с названиями и комментами о том что именно тестируется, раскидал там комменты про неочевидные моменты, попросил ии реализовать.
"вот интерфейс, реализуй", "вот тест, допиши".
в этом случае ии скорее автокомплит, чем думающая единица, и тогда это действительно полезный ассистент, который экономит время. меньше профита по времени, чем если бы он делал все полностью, но меньше и негативных последствий.
этот подход позволяет держать слопы под контролем, изолировать последствия: наворотил он фигни в рамках интерфейса - в худшем случае допишешь его сам.
как только ии позволяют работать выше, чем уровень реализации уже "набросанных" стабов - начинаются проблемы.
Вот это ключевое:
"Автогенерация снимает когнитивную нагрузку. "
А развитие возможно только при ее наличии. А если развития нет - начинается деградация, тут третьего не дано. Нужно двигаться, чтобы просто на месте оставаться.
Интересно понаблюдать за людьми с ещё более высоким грейдом – будет ли хотя бы там положительная тенденция в долгосроке
Тут либо деградация до мидла при условии выгорания или задач не по уровню, либо использование исключительно в качестве доработки/опровержения своего утверждения (даже вопросы по функциональной части некомфортно задавать)
Там обратная ситуация, потому что один из основных навыков сеньоров и архитекторов - валидация решений под внешние условия.
То есть как раз у тех ребят большой выигрыш, раньше скучные задачи после нарезки отдавались джунам, теперь ии.
Возможно, проблема не в автогенерации. А в том, что мы не учим людей сначала думать, а потом просить подсказку.
И это опять же ничего не изменит. Я подумал 5 минут – не получилось, пойду скопирую ИИ решение.
Проблема не в том, что человек сразу идёт за подсказкой, а в том, что он не умеет ей пользоваться. Да и идёт он не за подсказкой, а за решением, при этом он не имеет решения в своей голове, только образно понимает, что надо сделать (в лучшем случае).
Я как-то обсуждал с нейронкой (Gemini 3.1-pro) эту проблему.
И нейронка сказала что это уже довольно распространенная проблема в мире. И имя ей "AI Cargo Cult". Карго культ нейросетей.
Нейронка также подчеркнула что от бездумного использования нейросетей у людей атрофируется критическое мышление и они превращаются в "прокладку между ЛЛМ и ТЗ".
Раньше, когда человек писал фичу, он сначала думал:...
Неправда, если человек раньше задавался такими вопросами то и сейчас он задаёт ими, только обсуждает с ллмкой, и у него в артефактах будет и архитектура с объяснениями трейдофов и всё остальное.
А если он никогда об этом не думал, а писал как получится, то и промпты у него такие типа сделай збс)
Отправьте уже своих джунов на какие-нибудь курсы работы с агентами уже! А то они пользуются туллингом неумеючи, это же ваше лидская обязанность, а не только жаловаться на Хабре)
LLM — мощная штука для прототипирования и саморефлексии, но не продакшен код. Это сильно лучше чем поиск по интернету. Можно что-то сгенерировать и написать на основе этого что-то хорошее. Однако использовать то, что выдает LLM напрямую нельзя. Качество кода ужасное, пути решения не оптимальны. LLM выдает по 100 строк, там где я напишу 10.
Если вам подходит код, который пишет LLM, либо у вас какие то типовые решения, которые можно абстрагировать, либо вы плохо разбираетесь в языке, на котором сгенерирован код.
работал в команде с толпой джунов и мидлов - все их рукописные тесты были точно такие же - только покрытие и никакой реальной пользы 🤷♂️
И школьники и студенты так-же выполняют задачи при обучении.
Привет Идиократия)
То что вы описали я наблюдал и в разработке без ИИ.
На счёт того что "пропали споры об архитектуре" может оно и к лучшему, знаете у нас в какой-то момент они тоже пропали ещё до распространения ИИ, то ли зрелость то ли выгорание))
Но это интересное наблюдение, к сгенерированному коду нет этой "привязанности" как своему "детищу" вот и нет желания его защищать и с кем-то спорить ещё. Раньше это имело смысл, выиграть в споре чтобы сэкономить свои ресурсы, а теперь ты ничего особо не вложил, не сложно всё удалить и сгенерировать иначе, теперь чтобы сэкономить ресурсы нужно не спорить.
А по поводу отупления недоумения и деградации, тут как писал Ломоносов о сохранении энергии «Но как все перемены, в натуре случающиеся, такого суть состояния, что сколько чего у одного тела отнимется, столько присовокупится к другому, так, ежели где убудет несколько материи, то умножится в другом месте, сколько часов положит кто на бдение, столько же сну отнимет. Этот всеобщий естественный закон простирается и в самые правила движения; ибо тело, движущее своею силою другое, столько же оныя у себя теряет, сколько сообщает другому, которое от него движение получает».
Никто не деградирует, скорее наоборот, прост "мыслетопливо"(по Дорофееву) тратится на другие вещи и эти перемены можно даже назвать развитием.
И не удивительно
Если просто отдавать написание кода на аутсорс ИИ, то очевидно, что в итоге все перестают понимать, как это работает.
Если ИИ не знает, что у вас есть кластер и Redis, то как он напишет правильный код? Что его попросили, то он и сделал. Как двое из ларца.)
Я пока не дорос до агентской разработки, чаще общаюсь с ИИ в чатах. И пока он мне не объяснит каждую непонятную строку, я не отстану.) А если ещё и параллельно самому думать, то можно быстро прийти к лаконичному решению, которое понимаешь. Плюс получить похвалу от ИИ за свою проницательность.
Может это не самый быстрый способ писать код, но точно быстрее, чем разбираться с нуля без ИИ, и ускоряет процесс обучения.
Странно. У меня ровно наоборот. ИИ позволяет попробовать несколько подходов к одной задаче. Например, прогоняю ретро данные за месяц и смотрю, какой подход даёт лучшие результаты. С тестами по аналогии. Можно взять эталонные кейсы с прода, на которых ловили не тривиалтные баги или для которых пилили отдельные фичи. Пример из статьи это классический тест на отвяжись, коих большинство. ИИ здесь ни при чём.
Пример с кешированием какой-то глупый и странный.
Тут не ллм виновата, а тот кто принял решение о кешировании на уровне процесса. Если это джун — то а)кто пустил джуна принимать архитектурные решения б)не проверил за ним. Если это его начальник — а он не имел понимания о том что процессов несколько?
ЛЛМки действительно могут иной раз подсунуть что-то неочевидное в коде, которое дропает производительность, а ты это пропускаешь, потому что уже не думаешь над каждой строчкой, как если бы ты их писал сам. Но вот конкретно этот пример — совсем не в тему. Оно же буквально звучит как "ну мы понадеялись что декоратор как-то сам пошерит кеш между репликами". Это даже на первый взгляд не логично.
Спасибо за честный разбор. Очень откликается мысль про риск деградации инженерного мышления при безусловной автогенерации.
Но, возможно, многое зависит от архитектурной модели команды.
В нашей практике архитектура формируется не в PR и не в код-ревью, а заранее — через формализованные требования, ADR, описание транзакционных границ, SLA, идемпотентности, state machine и пр. Разработчики не придумывают модель данных «с нуля» — они реализуют в рамках уже согласованной архитектуры. При этом любой dev может поставить под сомнение решение, но дискуссия происходит на уровне документа, а не случайной генерации кода.
В такой модели AI становится инструментом ускорения реализации, а не источником архитектурных решений. Он не определяет границы процессов и не принимает системные решения — он помогает быстрее воплощать их.
Возможно, проблема не в автогенерации как таковой, а в отсутствии формализованного архитектурного центра. Там, где архитектура рождается из кода, AI действительно может размыть мышление. Там, где архитектура описана и задокументирована, он скорее снижает рутину.
Интересно было бы услышать, как меняется картина в командах с сильной архитектурной формализацией.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подсказка вместо мышления: как автогенерация кода меняет junior и middle за один год