LLM пишут код почти идеально, но он вдвое более «замусоренный», чем человеческий
If coding is solved, what now?: Measuring the sloppiness of code
LLM достигли совершенства в генерации кода, но формальная корректность не гарантирует отсутствия лишних абстракций, дублирования и плохих решений. Автор из Earendil исследует метрики «замусоренности» кода: verbosity и erosion. Анализ показывает, что код агентов примерно вдвое более многословен и эродирован, чем код людей. В итеративных бенчмарках даже лучшие модели не проходят все тесты, что сигнализирует о накоплении ошибок.
Агенты не могут справиться с этим мусором. Придя из физики, я всегда применял экспериментальный и количественный подход к решению задач.
- dang
dang:
Всем: пожалуйста, не публикуйте шаблонные рефлекторные реакции на заголовки. Это покрывается следующим правилом, среди прочих, в https://news.ycombinator.com/newsguidelines.html:
"Пожалуйста, не выбирайте самую провокационную вещь в статье или посте, чтобы жаловаться на неё в ветке. Найдите что-то интересное, на что можно ответить вместо этого."
Я убрал провокационный момент из заголовка выше, но, пожалуйста, помните, что мы хотим рефлексивных комментариев, а не рефлекторных, в ветках HN.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor....
- dherman
dherman:
Очень рад видеть, что люди изучают количественные подходы, чтобы давать агентам обратную связь по качеству кода. Этот пост выглядит как хорошее начало!
Мой основной отзыв авторам был бы таким: самые важные проблемы небрежности — это глобальные свойства, а не локальные. По моему опыту, у агента, как и у человека, ограниченная ёмкость внимания, но если он сталкивается с локальной небрежностью, которая ему мешает, он может исправить её по мере необходимости. Проблемы технического долга, которые имеют значение, обычно являются глобальными проблемами, которые не так легко исправить: они требуют глобального анализа и глобального рефакторинга.
Я не знаю ответа, но думаю, что нам понадобятся способы измерения архитектурных свойств, таких как разделение ответственности, чёткое архитектурное расслоение, хорошо определённые интерфейсы и т.д.
- toddwprice
toddwprice:
Программирование решено, возможно, при неограниченных затратах токенов на frontier-модель. Ещё предстоит увидеть, будет ли это запредельно дорого навсегда. В моей компании мы выжимали максимум токенов, пока это было выгодно. Но когда нам пришлось перейти на корпоративный план Anthropic и начать платить за токен, дерьмо реально ударило в вентилятор. Теперь мы отступаем назад к разумным уровням затрат и обнаруживаем, что — угадайте что? — человеческая сила, возможно, просто более рентабельна. ИИ, конечно, огромный инструмент для использования, но всё ещё слишком дорогой, чтобы создавать циклы и позволять ему работать. Это изменится со временем, конечно, но предполагать, что проблема решена, — это чушь. Может быть, если мы решим проблему холодного синтеза, да. А до тех пор эволюция выигрывает войну с энтропией.
- justinmarsan
justinmarsan:
Достигнув тех же выводов, что и автор, я создал своего первого агента для архитектурного ревью, и именно так я узнал о метриках, стоящих за хорошими практиками, которым я следовал годами. LCOM, цикломатическая сложность, всё такое...
Так легко выкатить кучу кода, больше усилий следует вкладывать в то, чтобы код был правильным, с самоулучшающимися циклами обратной связи, включающими разработчиков, и специализированным инструментарием...
Но опять же, некоторое время назад всё было в prompt engineering, а теперь можно выразить свою идею расплывчато и получить более-менее работающий результат, так что это, вероятно, тоже будет быстро развиваться...
- FiberBundle
FiberBundle:
Кто-нибудь на самом деле знает, есть ли предел сложности, с которой LLM способны справляться в кодовой базе? Совершенно очевидно, что они не пишут код, пригодный для понимания людьми (и это будет становиться всё хуже и хуже по мере использования RL для обучения этих моделей), но если нет точки, в которой LLM также испытывают трудности из-за сложности, которую они вносят, тогда я не уверен, что это действительно имеет значение для большой части не критичного для безопасности программного обеспечения. Я очень надеюсь, что такая точка есть, потому что управление ими — это, как мне кажется, одна из последних компетенций, через которые я всё ещё могу приносить пользу, но есть ли на самом деле доказательства, что эти модели испытывают больше трудностей с плохо поддерживаемым кодом?
- drsopp
drsopp:
Закон Гудхарта здесь упоминается без обсуждения. Мы уверены, что оптимизация на минимум LOC, проходящих все необходимые тесты, порождает небрежный код? И: что такое небрежный код вообще? Если бы мы могли его определить, могли бы мы добавить определение в контекст и сказать LLM избегать его?
- conqrr
conqrr:
Программирование — это не просто программа, работающая в памяти, это также процесс распространения ментальной модели понимания среди команды.
Если люди всё больше отстраняются от программирования, то кто держит ментальную модель?
Если ИИ держит ментальную модель, то по определению человеческие промпты будут идти по каналу с потерями. Это верно и без ИИ. Качество программного обеспечения напрямую зависит от хороших разработчиков, которые переводят с языка бизнеса/PM на технические решения.
Так что программирование теперь решено? Оно уже было решено десятилетия назад.
- glouwbug
glouwbug:
Хорошая мера — это коммуникация. Если есть общее понимание, то происхождение не обязательно имеет значение.