Поколение «Approve»: почему я заставил команду переписать проект, который уже работал

[Freeman_RU]

Что делать джунам (или с джунами) вообще не понятно. Да, та часть, которая имеет задатки критического мышления (единицы на самом деле) будут использовать ИИ для обучения. Остальные - для получения быстрого результата, и соответственно развиваться не смогут. И как они будут набираться опыта совершенно не ясно. Интересно посмотреть во что это выльется лет через 10.

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

Но вообще мы живём в очень интересное время.

[AngryEvilCookie]

В интересное и удивительное время, когда ответы на большинство вопросов можно получить по щелчку пальцев и не нужно слушать как модем шуршит. Действительно что делать бедным джунам? Им же надо, например, MSDN на совке искать на дисках. /s

[dom1n1k]

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

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

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

[AppCrafter]

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

[forthuse]

Замысел автора: Написать статью полезную, красиво написанную и прославляющюю ИИ, но без технических подробностей и с долей критики в “неумение” своих оценок предложенных решений?

P.S. Предлагаю такие статьи по содержанию отмечать, к примеру, тегом “Философия ИИ”. :)

[Krypt]

Почему в ответах нет "нет"? Просто "нет", без всяких оговорок?

"за него" - чтобы стать "сильным инженером" - нужно иметь опыт. А опыт вы не получите если за вас кто-то или что-то принимает решение.

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