Hacker News Digest

В мае прошлого года лучший результат на SlopCodeBench составлял 14,8% строгого прохождения у gpt-5.5, а теперь лидер — gpt-6 astra с 16,3%. Строгий показатель означает, что модель прошла все тесты чекпоинта, не сломав при этом ранее работавшее поведение. У протестированных моделей — Opus 5.5, Fable 5.1, SOL 6 и 6.1, Astra и GLM 5.3 — строгий результат лежит в диапазоне 12,2–16,3%, тогда как менее строгий «core pass rate» достигает 65,8–74,0%. В этот раз прогон охватил 36 задач и 196 чекпоинтов на каждую настройку, что позволяет сравнивать результаты с официальными данными исследования, чего нельзя было делать на прежних подвыборках из трёх и шести задач.

Отдельный контринтуитивный вывод: средний уровень усилий оказался лучше максимального. XHigh стоит в 2,11–4,22 раза дороже Medium, но Opus 5.5 на среднем усилии показал результат лучше, чем на XHigh. По качеству кода Fable отличается наименьшей средней сложностью — 3,57 при 8967 вызываемых объектах, а GPT-6 SOL Medium — наибольшей, 11,70 при 1083 объектах. Фильтрация служебных файлов _work у Opus Medium убрала 45 файлов и 41 265 строк, снизив долю «слопа» до 92,90%, но первое место по этому показателю сохранилось.

Главный вывод: агенты гораздо чаще правильно реализуют основное поведение, чем сохраняют всё протестированное при изменении требований. Прогресс с 14,8% до 16,3% за май—сентябрь есть, но он скромнее, чем принято подавать.

Обсуждение показывает, что Astra генерирует компактный, но часто нечитаемый код, который пользователи решают проблемой форматирования; большинство участников предпочитают средний уровень усилий из‐за лучшего соотношения цены и качества, однако есть разногласия по поводу преимуществ xhigh и отсутствие тестов на уровнях high/max, а также критика текущих метрик slop и запросы на открытие исходных выводов.

• Многие отмечают, что у Astra часто отсутствуют переносы строк, из‐за чего генерируемый код выглядит как «code golf» и трудно читается.

• Совет: Рекомендуют сразу прогонять вывод Astra через автоформаттер (например Prettier) или использовать параграф‐ориентированное форматирование, чтобы восстановить читаемость.

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

• Для большинства задач средний уровень усилий (medium) даёт лучшее соотношение цены и качества по сравнению с xhigh, где прирост точности не покрывает рост стоимости.

• Спор: Некоторые считают, что xhigh не хуже medium и даже показывает лучшие строгие показатели, тогда как другие указывают, что разница в 15 % находится в шуме и незначительна.

• Слепок кода часто объясняется избыточным «защитным» программированием LLM, которое требует человеческого вмешательства для упрощения и удаления лишних проверок.

• Совет: Предлагается измерять не только процент прохождения, а сначала гарантировать проход через harness, а затем оценивать стоимость и читаемость результата.

• Отсутствие публичных «raw» выводов затрудняет воспроизводимость benchmark'а и проверку заявленных метрик.

• Спор: Некоторые требуют включения уровней high и max в тестирование, полагая, что их исключение искажает общую картину производительности моделей.

• Метрика «slop», основанная на разнице кода, считается «размытой» и может не отражать реальную поддерживаемость и производительность.

Astra writes well (which is why I often like to work with it over Claude), but it tends to produce code golf that's borderline unreadable, like completely omitting line breaks. I thought I had something funky with my config, but it seems to be a known issue. — @throwaway219450

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

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

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

Новый долгосрочный тест SlopCodeBench проверяет, как модель поддерживает качество кода при постепенном раскрытии требований, а не когда всё задание объявлено сразу. Каждый вызов состоит из нескольких контрольных точек, которые появляются по мере развития задачи, делая benchmark «не насыщенным» и измеряя способность модели адаптировать и рефакторить код в реальном времени. Эта методика остаётся «не насыщенной» – модель не знает полной задачи сразу, а получает её частями, имитируя развитие проекта. В работе показано, что даже самые крупные текущие модели, такие как GPT‑5.4 и Opus 4.6, получают лишь 11 % и 17 % строгих проходов, тогда как Opus 5, запущенный на небольшом подмножестве, достигает 24 % – небольшое, но заметное улучшение.

В набор входят database_migration ( пять проверок: ck1‑создание таблиц, ck2‑модификации данных, ck3‑внешние ключи, ck4‑откат, ck5‑зависимости) и dynamic_config_service_api ( четыре проверки: ck1‑REST‑служба с версиями, ck2‑реестр схем, ck3‑рабочий процесс с обзорами, ck4‑политика‑ограничения). Для анализа используют ck6‑ck8: stats, lint, dot, cone, truth‑table, equiv, opt, проверяющие метрики, валидацию и оптимизацию схем. Пять проверок в первой задаче и четыре во второй, позволяют оценить как локальные, так и системные аспекты поддержки кода.

Opus 5 — улучшение над Opus 4.8, не революционное, но полезное для сокращения токенов и ускорения работы. Споры: Снижение строк кода не всегда улучшает качество — важен баланс между сложностью и читаемостью. Увеличение числа функций и вызовов не всегда плохо: может повышать читаемость и тестируемость. Советы: Модели следует обучать принципам поддержания качества кода и снижения сложности через системы подсказок, проверок, рефакторинга, semi-lights-off и adversarial prompting. Для оценки использовать метрики: сложность кода, количество функций, p50, p95, deterministic scores, анализ state space. Бенчмарки, включая SlopCodeBench, полезны, но требуют новых методов и инструментов. Участники согласны: разработка таких методов — ключевая задача для улучшения моделей программирования.