LLM стали почти идеальными в генерации кода, но это не конец истории. То, что код формально корректен, не означает, что он не вводит ненужные абстракции, не создает дубликаты или просто не принимает плохие решения в целом. Это не революционное наблюдение; большинство людей, которые занимались вайб-кодингом проекта, поняли, что каждая дополнительная функция иногда может привести к взрывному росту строк кода (LOC). Это приводит к потере человеческой субъектности, потому что в проектах, добавляющих миллионы LOC в месяц, людям трудно успевать. Некоторые могут сказать, что это вообще не проблема, потому что они доверяют своим агентам справиться с этим. У меня для вас плохие новости: агенты тоже не могут справиться с небрежностью.

Имея физическое образование, я всегда подходил к решению проблем экспериментально/количественно. Когда я начал работать в Earendil с задачей выяснить, как измерить небрежность кода, моим естественным инстинктом было сначала углубиться в литературу, а затем проверить, что делают другие компании. Честно говоря, за исключением нескольких проницательных исследовательских работ, я был разочарован тем, насколько «основанной на ощущениях» кажется отрасль в данный момент. В своих исследованиях и в X я постоянно подвергался бомбардировке сообщениями вроде «Сквозные агенты для кодирования», «ИИ, который не просто предлагает код — он его поставляет» или «Оценка на человеческом уровне без затрат человеческого уровня». В которых, как и во всех хороших историях, есть доля правды. LLM способны писать почти идеально корректный код. Это связано с масштабируемостью и проверяемостью кода. Довольно просто позволить LLM генерировать код, а затем проверить этот код скрытыми тестами, что дает четкий сигнал вознаграждения. В резком контрасте с этим проверка «небрежности» этого кода часто требует человеческой интуиции и вкуса, и в целом это чрезвычайно сложная задача.

Я думаю, лучший способ проиллюстрировать, почему это так, — пройтись по возможным способам измерения небрежности. ИИ в роли судьи: это, вероятно, самый распространенный способ оценки качества кода в отрасли, и, по моим наблюдениям, он редко работает. Самый наивный способ сделать это, а именно спросить модели, насколько хорош код по шкале от 1 до 10, по сути эквивалентен генератору случайных чисел. Более сложный подход, а именно попытка дать модели-судье два решения A и B, а затем позволить ей решить, какое из них предпочтительнее, имеет недостаток: модель меняет свои предпочтения, когда вы переименовываете решения. Я здесь немного шучу, и с более крупными моделями эффект не так выражен, но основной момент остается. Просить LLM судить код, который они пишут, не заменяет надлежащую оценку. Хотя есть некоторые интересные подходы с рубриками или написанием тестов LLM, они все еще далеки от того, чтобы действительно избавиться от небрежности.

Люди судят ИИ: если мы проигнорируем тот факт, что существует огромное разнообразие в качестве программных инженеров, это было бы лучшим решением для обеспечения того, чтобы код оставался читаемым для человека. С недостатком: это не масштабируется для обучения ИИ или проведения крупных бенчмарков с несколькими поставщиками моделей и инструментами. Самый простой метод: в моих исследованиях и тестах простое измерение изменения количества LOC оказалось на удивление эффективной метрикой небрежности, с ироничной оговоркой, что если мы начнем оптимизировать под нее, она перестанет быть значимой мерой. Следующие две меры были представлены мне статьей Slop Code Bench, и казались многообещающими, поскольку они могли довольно хорошо отделить унаследованные кодовые базы от LLM-небрежности. Многословность: пытается измерить количество дублированных и ненужных многословных строк. Эрозия: пытается измерить, какая часть массы кодовой базы сосредоточена в нескольких больших и сложных функциях.

Ключевые сущности: Компании: Earendil