Ponytail-скилл для Claude Code: действительно ли экономит код и токены

JetBrains продолжает серию парных A/B-бенчмарков публичных «сберегателей токенов» для кодинг-агентов. Часть 1 — caveman-скилл (заявлено −65%, измерено −8,5%), часть 2 — rtk (заявлено −60–90%, измерено +7,6%). Теперь настала очередь ponytail-скилла для Claude Code: заявлено −54% кода, −22% токенов, −20% стоимости и −27% времени. Измерили −15% кода, −10,3% стоимости и −11% времени.

Важно другое: это первый инструмент в серии со статистически солидным сигналом экономии, а не штрафа. Качественной разницы не нашли, хотя ~80 пар могут исключить только крупные эффекты. Главный нюанс: срез кода проявляется там, где было место для перепроектирования (over-engineering).

Зачем это тестировали

Ponytail скроен так, чтобы агент писал меньше кода. Идея: сеньор, повидавший всё, заменит ваши пятьдесят строк одной. Вместо установки flatpickr и обёртки для datepicker он напишет <input type="date"> и пойдёт дальше.

Механически перед написанием чего-либо модель проходит лестницу вопросов: нужно ли это вообще? уже есть в кодовой базе? делает ли это стандартная библиотека? нативная фича платформы? установленная зависимость? можно ли в одну строку? И только потом — пиши минимум, который работает. Лестница идёт после понимания задачи, а не вместо него, а валидация, обработка ошибок, безопасность и доступность явно не входят в число сокращаемого.

Пример из собственного прогона. Обоих агентов попросили экспортировать three.js-сцену в OBJ для Blender; оба выдали файл, принятый верификатором. Разница — вокруг общей петли. Обычный агент строил объект-обёртку для поворота сцены и именовал каждый промежуточный шаг:

// без скилла — 10 операторов: повернуть сцену и записать файл
const exportRoot = new THREE.Group();
exportRoot.name = 'blender_export_root';
exportRoot.rotation.x = -Math.PI / 2;
exportRoot.add(root);
exportRoot.updateMatrixWorld(true);

const exporter = new OBJExporter();
const objString = exporter.parse(exportRoot);

const outputPath = '/root/output/object.obj';
fs.mkdirSync(path.dirname(outputPath), { recursive: true });
fs.writeFileSync(outputPath, objString);

// ponytail — та же работа, 5 операторов
root.rotation.x = -Math.PI / 2;
root.updateMatrixWorld(true);

const obj = new OBJExporter().parse(root);
fs.mkdirSync('/root/output', { recursive: true });
fs.writeFileSync('/root/output/object.obj', obj);

Ничем не пожертвовали: ponytail повернул уже существующий объект вместо родителя, пропустив лишний импорт. Десять операторов стали пятью, геометрия идентична. Эффект работает ровно как заявлено — на одном файле, на одной задаче.

Методика

• Harness: Harbor 0.18 — Docker-песочницы, верификаторы задач, парные прогоны.
• Агент: Claude Code 2.1.201, headless, bypassPermissions, одинаков в обеих руках.
• Модель: claude-sonnet-5 на medium reasoning.
• Бенчмарк: SkillsBench, 80 парных задач, автогрейд 0–1 с частичным зачётом.
• Рука A: стоковый Claude Code; рука B: ponytail v4.8.4 + инъекция правил.
• Объём: 251 платная попытка агента, USD 246,09.

Внедрённый текст руки B сгенерирован собственным hooks/ponytail-instructions.js скилла, а не пересказом — модель видела оригинальный набор правил. Каждая «с-ponytail» попытка аудировалась на предмет попадания правил в модель (100%), каждая базовая — на предмет отсутствия (0%). Это прямой потомок бага контаминации, который ponytail сам нашёл у себя в бенчмарке.

Находка 1 — скилл не самоактивируется

Скилл собран с расчётом, что модель сама решит его применить: описание просит использовать его на «любой кодинг-задаче — написание, добавление, рефакторинг, фикс, ревью, дизайн кода».

За десять сессий он самоактивировался ноль раз — не редко, а никогда. Это не баг ponytail, поэтому инструмент поставляется как плагин с SessionStart-хуком, внедряющим правила независимо от спроса. Но это значит, что способ установки решает, получите ли вы хоть что-то: скопируйте SKILL.md в папку со скиллами — и почти наверняка измерите ноль. Все числа ниже получены на руке, где правила реально внедрены.

Находка 2 — срез кода втрое меньше заявленного

По 80 парным задачам типичная задача теряет 15,4% кода; в сумме 10 205 строк стали 8 756. Небольшое, но реальное сокращение. Однако при p=0,088 это самая мягкая из ключевых цифр. И далека от −54%.

Понять разрыв: их −54% — среднее по двенадцати специально отобранным фичам; наше — медиана по 80 задачам, которые никто не подгонял. Среднее и медиана на перекошенных данных — разные вещи, и их собственный отчёт честно пишет: снижение «достигает −94%, где агент излишне строит, и около нуля, где код уже минимален».

Находка 3 — экономия концентрируется там, где было место перестроить

Разделите задачи по объёму кода, который написал базовый агент (ponytail не может выбирать свою корзину сам). На крупных построениях срез достигает −31%. На задачах, где обычный агент уже писал почти ничего, типичная задача двигалась на ноль — хотя суммарно в группе выросла (104 → 910 строк). Отсюда один сюрприз.

На семи задачах счётчик дал ноль строк обычному агенту и 51–230 строк ponytail. Из транскриптов: дело скорее в том, где жил код. Обычный агент скармливал решение в Python-интерпретатор heredoc'ом — результат получен, скрипта не осталось. Ponytail писал ту же логику в файл. Счётчик считает сохранённый файл кодом, а inline-heredoc мусором. Все семь файлов — обычные рабочие скрипты (edit.py, diff.py, build_model.py), а не тесты. Смещение небольшое и в обе стороны: ponytail только на 7 задачах сохранил код на диск (761 строка), обычный агент на 4 (567). Итог — около 190 строк из 10 205 против ponytail, меньше 2%.

Находка 4 — счёт падает, и на этот раз сигнал крепкий

Типичная задача стоит на 10,3% меньше с ponytail: p=0,004 по 80 парам, дешевле на 46 задачах, дороже на 34. Это самый сильный результат по стоимости в серии и первый, который является полноценной экономией, а не штрафом (rtk дал +7,6% — настолько же значимый, но «в неправильную сторону»). Каверман тоже выходил на ~10% дешевле после удаления одного ценового выброса, но это хрупкая цифра, держащаяся на одном исключении.

Честная оговорка: медиана −10,3%, но разброс такой, что bootstrap-интервал медианы едва касается нуля. «Примерно 10% дешевле на этом ворклоаде» обоснованно; «ponytail экономит вам 10%» — нет.

Что характерно, не сдвинулся «вход». Перечитывание собственной истории упало на 8,4%, свежие токены на 3,9% — оба не значимы. В части 2 серии выяснилось, что счёт агента доминирует именно перечитывание, поэтому скилл, сжимающий вывод команд, еле его трогал. Ponytail бьёт по другой стороне — по тому, что модель пишет, — и именно там сдвигались деньги.

Находка 5 — качественной разницы не видно

Очевидный страх про «пиши меньше» — удаление важного. Ponytail утверждает, что не трогает валидацию, обработку ошибок, безопасность и доступность.

Однако верификаторы SkillsBench ставят оценку за то, завершена ли задача. Это не набор тестов на безопасность, валидацию или доступность. Ниже ничего не проверяет, сохраняет ли ponytail защитный механизм — только выдержит ли работа проверку.

Распределение: девять задач чуть хуже, шесть чуть лучше, 65 идентичны — статистически неразличимо. Это нулевой результат, не чистая справка о здоровье: прогон не был задуман для доказательства эквивалентности, данные совместимы и с малой деградацией, и с малым улучшением. Но можно сказать, что нет очевидного режима отказа, когда «меньше пишешь» тихо ломает тесты.

Маленькая заметка об одержимости: набор правил просит помечать вынужденные упрощения комментарием ponytail: с именем потолка и планом апгрейда. За 80 попыток с заведомо присутствующим набором правил — это случилось один раз. Лестница выполняется, бумажки — нет.

Находка 6 — малые выборки обманули в обе стороны

Из-за маленького объёма серия не была бы неисправной: десятизадачный smoke-прогон сказал, что ponytail режет код на 3% и делает всё на 9,6% дороже, а средний результат задач обвалился с 0,51 до 0,31. Опубликуйте это — и получите совершенно неверную статью.

Вердикт

Ponytail работает. По 80 парным задачам он снижает типичный счёт на 10,3% и объём кода на 15%, без замеренной разницы качества. Это первый инструмент в серии, который явно сэкономил деньги. Установите его и забудьте — будет умеренно лучше.

Не ждите разрекламированные 54% везде. Бенчмарк ponytail построен на задачах с явными «ловушками» излишнего построения. Наши — нет. В наших прогонах код падал на 31% на крупных построениях и едва двигался на уже минимальных задачах. Чем больше агент перестраивает — тем больше срежет ponytail.

Есть инструмент, который экономит токены? Сообщите, какой, и прогоним его через тот же стандарт.

Методология и ловушки

• Никогда не верьте k=1. Эскалационная лестница: бесплатный аудит транскрипта, smoke из 10 задач, те же 10 при k=3, затем полные 80. Находка 6 показывает, что рассказал бы один smoke.
• Только парный анализ. Задача, упавшая в любой из рук, исключается из обеих. Знаковый тест для качества, медианы по задачам плюс Wilcoxon для всего остального — одна длинноконтекстная сессия может биллиться в 25 раз больше нормы и сломать среднее.
• Ключевые метрики зафиксированы до платных прогонов. Суммарные токены добавили после, когда выяснили, что именно рекламирует собственный run.py ponytail (сумма входа, кэша и выхода), так что сравнение чистой цифры по выходу с его −22% выглядело бы втрое лестнее.
• Что null-результат значит, а что нет. Проверка качества — это тест значимости, не эквивалентности. «Разница не обнаружена» — честное чтение.
• Измерение кода без workspace-diff. Бенчмарк считает git diff добавленные строки. Harbor не оставляет post-agent воркспейса, поэтому эквивалент восстанавливается из вызовов инструментов: Write, Edit и shell-heredoc'ов в файл, как non-blank non-comment строки ровно как loc.js ponytail. Это накопленные эмитированные строки, а не финальный размер. Heredoc'и в интерпретатор считаются утилит-анализом и исключаются.
• Происхождение. ponytail закреплён на коммите 16f2980 (v4.8.4, MIT).
• Чего это не даёт. SkillsBench — данные, анализ и ремонт; в нём мало front-end ловушек перепроектирования. Это честная проверка стоимости, скорости и качества, но консервативная — для среза кода.