Measuring the sloppiness of code

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

Автор экспериментально тестировал метрики: оценка кода самими LLM — нестабильна и часто случайна; ручная проверка неприменима в масштабе; изменение числа строк (LOC) — простая, но хрупкая метрика, подверженная закону Гудхарта. Два новых показателя из SlopCodeBench — на основе анализа AST и структурных паттернов — лучше разделяют «LLM-грязь» от устаревшего кода. Они выявляют избыточную связанность функций и низкую когезию, но всё ещё опираются на ручные хэристики. В итоге, даже при прогрессе в автоматизации, человеческая интуиция остаётся неотъемлемой частью оценки качества кода.

Комментарии (236)

Измерение «грязи» кода требует учета глобальных архитектурных свойств — разделения обязанностей, слоистой архитектуры и четких интерфейсов — а не только локальных метрик. Человеческий опыт и управление ментальной моделью команды остаются критически важными, даже при использовании LLM: если AI становится основным автором кода, человеческое понимание теряется через «потерянный» канал коммуникации. Метрики вроде циклической сложности и LCOM известны давно, но их эффективность для LLM не изучена, и их применение требует осторожности из-за риска Goodhart's law. Изменение числа строк кода (LOC) как метрика работает в практике, но теряет смысл при оптимизации под неё. Тесты, которые не проверяют ничего (например, всегда возвращают True), не обнаруживаются статическим анализом или покрытием, но выявляются mutation testing — это важный, но игнорируемый индикатор грязи. Сложность, вводимая LLM, может превышать их способность к управлению — неизвестно, есть ли предел, при котором модели теряют контроль над собственной сложностью. Для оценки качества кода следует использовать комбинацию метрик (циклическая сложность, churn, авторство) и анализировать их динамику во времени, а не только статические значения. Использование LLM как судьи в оценке кода (harness evals) перспективно при правильном проектировании метрик и контекста. Оптимизация под минимальное количество LOC, проходящее тесты, не гарантирует чистоту кода и может усугубить проблему без учета архитектурной целостности. Для улучшения качества кода, генерируемого LLM, необходима обратная связь на основе качественных репозиториев и комплексных метрик, а не только на корректность выполнения задач. Споры: - Код «решен» LLM? Работающий код ≠ поддерживаемый, особенно в сложных системах. - AI-генерируемый код — эволюция существующего «мусора» или его объем превышает человеческие возможности управления? - Стоимость токенов делает AI-генерацию экономически нецелесообразной? Или это временный этап? - Один участник отметил, что его репозиторий, написанный агентами, показал более низкую «verbose» метрику, чем у людей — что противоречит ожиданиям. Качество кода не измеряется только техническими метриками — ключевой индикатор — способность команды понимать и поддерживать систему, что требует коммуникации, а не автоматизации.