Comments 19
Что делать джунам (или с джунами) вообще не понятно. Да, та часть, которая имеет задатки критического мышления (единицы на самом деле) будут использовать ИИ для обучения. Остальные - для получения быстрого результата, и соответственно развиваться не смогут. И как они будут набираться опыта совершенно не ясно. Интересно посмотреть во что это выльется лет через 10.
Вообще я часто вижу в рассуждениях про LLM странное суждение, у вас оно тоже проскочило (сразу проше простить, если не так понял) - "мы попросили выбрать лучшее решение, и оно потом оказалось не верным, потому что ..." и дальше следует тезис, который можно свести к одному - не верно поставленная задача, в вашем случае вы не задали параметр роста данных. LLM-ка должна быть частью команды, и соответственно вопросы ей надо ставить как части команды. Не "найди лучшее решение", а "найди какие решения есть, покажи плюсы и минусы каждого", и потом команда разбирает каждый (параллельно ища свои). Причём LLM должна работать с теме же вводными, что и команды, но плюс надо помнить, что LLM очень плохо умеет додумывать задачу. Если вы ей говорите, что вам нужно решение для обработки N данных, она найдёт именно такое решение, не задаваясь вопросом, а что будет потом. Если относиться к ней, как к джуну с феноменальной памятью, это станет понятнее такой подход, как мне кажется.
Но вообще мы живём в очень интересное время.
Что делать джунам (или с джунами) вообще не понятно. Да, та часть, которая имеет задатки критического мышления (единицы на самом деле) будут использовать ИИ для обучения. Остальные - для получения быстрого результата, и соответственно развиваться не смогут. И как они будут набираться опыта совершенно не ясно. Интересно посмотреть во что это выльется лет через 10.
Я вот честно не вижу проблемы с джунами. И те, и те при разработке столкнутся с разного рода задачами, и опыта наберутся те, кому интересно разобраться в проблеме. Вопрос в количестве заинтересованных.
Поделюсь своим опытом: открыл для себя новое направление, работа с графикой и написание шейдеров на wgsl. И вот начал всё это дело с ИИ. Иногда просил что-то реализовать и объяснить, через неделю такого взаимодействия пропало желание двигаться дальше. 2-3 дня походил расстроенный, что это как-то неинтересно стало (хотя строил надежды). А потом в один прекрасный день сел, но уже без ИИ начал по новой. И о чудо, желание до сих пор не пропало) Но я думаю, кто-то спокойно может и с ИИ набираясь опыта, просто для меня отдельное удовольствие, если я прям сам напишу и разберусь.
В интересное и удивительное время, когда ответы на большинство вопросов можно получить по щелчку пальцев и не нужно слушать как модем шуршит. Действительно что делать бедным джунам? Им же надо, например, MSDN на совке искать на дисках. /s
Разобраться в существующей архитектуре обычно проще, чем придумать её самому. Найти слабые места в решении легче, чем предложить действительно хорошую альтернативу. Проверить чужую работу проще, чем сделать её с чистого листа.
Абсолютно так. Меня всегда изумляли комментарии под статьями о найме, что мол на собесе надо предлагать сделать ревью. Причем началось это, кажется, ещё до бума ллм - просто потому что лайв-кодинг народу не нравится, но что-то спрашивать надо. Найти ошибки, особенно когда ты знаешь, что они там есть - на порядок проще, чем написать хорошо с нуля.
В статье была шахматная аналогия - у меня тоже есть такая. В одном из обсуждений читерства гм Даниил Дубов сказал, что он обыграет чемпиона мира, если у него будет подсказка вида "в этой позиции есть выигрышное решение". То есть даже не нужен конкретный ход, просто четкое указание - вот сейчас остановись и думай, решение есть, его только нужно найти.
к нам на собеседование пришел джун и с порога заявил, что не читает книги. вообще. На вопрос как он собирается читать код - ответить не смог.
Все же уметь читать чужой код (и не всегда он чистый и хороший) надо уметь. И мне кажется, что это важнее, чем писать свой. Писать свой код легко (ну, гм, хороший код уже не так легко), а вот прочитать простыню чужого в поисках бага - это тоже уметь надо.
мне тоже как-то странным показалось, что нет опыта выбора. Такое впечатление, что модель предлагала решение, команда его принимала и шла дальше. Обычно ведь модель настраивают так, чтобы она предлагала варианты решения, обозначала свой выбор и показывала аргументы за и против. И на основе всего этого команда принимает решение, которое может совпадать, а может и не совпадать с предложенным моделью. А затем это решение фиксируется в истории проекта. И тогда видно, почему когда-то решили так, а не иначе.
Замысел автора: Написать статью полезную, красиво написанную и прославляющюю ИИ, но без технических подробностей и с долей критики в “неумение” своих оценок предложенных решений?
P.S. Предлагаю такие статьи по содержанию отмечать, к примеру, тегом “Философия ИИ”. :)
Почему в ответах нет "нет"? Просто "нет", без всяких оговорок?
"за него" - чтобы стать "сильным инженером" - нужно иметь опыт. А опыт вы не получите если за вас кто-то или что-то принимает решение.
Строго говоря это серьёзная проблема с использованием ИИ с точки зрения пользователя ИИ/разработчика использующего ИИ: вы не получаете опыт при работе, вам не приходится исследовать, и ваши знания не растут. Не удивлюсь если это в будущем вызовет кризис профессии, и зависимость от ИИ в разработке.
Компании создаются для того, чтобы приносить прибыль. Рост компетенций добавляет прибыль, но не является основной целью.
Команды, привыкшие получать деньги из тумбочки, реально думают, что таким образом они приносят кому-то пользу, делая overingenerинг на старте. Вроятность того, что проект упёрся бы конкретную векторную базу на первых этапах стремится к нулю, а денег на все эти “анализы” и размышление не шибко быстрыми умами потрачено уйма. Сейчас на много быстрее взять работаютщий прототип, обвесить тестами вдоль и поперёк вход / выход и переписывать на что угодно и это будет дешевле и правильней.
Какая трогательная история. Жаль, что ...
Я пришел в комментарии посмотреть, что кто-нибудь сказал, что на КДПВ взятие черной пешки на d6 это ошибка.
Слона, а не пешки. Но всё равно ошибка, да.
В этом и смысл: вы же можете понять это краткосрочное действие, почему оно было сделано и даже объяснить его. Другое дело, что что это действие не является лучшим долгосрочным решением с точки зрения "инженера шахматных дел".
Я надеялся, что аналогия была понятна.
Хотел вообще минус за КДПВ влепить, но судя по комменту, ошибка намеренная, значит нельзя так делать. Спасибо, что защитили автора :)
вырастут ли вместе с этим проектом мои программисты как инженеры?
Какое удивительно разное айти. Моё начальство не думает о росте, оно просто берёт то, что уже есть. Как музыкант на концерте. Концерт — не место для изучения новых приёмов, там играешь то, что уже умеешь наилучшим образом, который можешь показать на тот момент. А обучаться — ну, дома.
Получается, у вас есть бюджеты на переписывание того, что и так уже работает? У нас обычно так: если в будущем что-то упадёт или найдётся затык, тогда и будем думать.
У нас тоже нет бесконечного бюджета, но я стараюсь думать в первую очередь о команде и это, конечно же, выливается в бесконечное противостояние - потому что бизнес думает о другом (что понятно). Стараюсь находить какие-то компромиссы и отстаивать интересы своих ребят, насколько это возможно (увы, получается не всегда).
Поколение «Approve»: почему я заставил команду переписать проект, который уже работал