Ponytail con 169.651 estrellas: una regla de 2.721 bytes y el ahorro del 26% que se queda en 1,7% cuando alguien ejecuta el código

Ponytail es un archivo markdown. Lo dice el propio proyecto, en una sección titulada The prompt: «Ponytail is one prompt: skills/ponytail/SKILL.md. The compact version, for agents that read a rules file, is AGENTS.md. Everything else in this repo loads that prompt into different agents.»

Son 2.721 bytes de AGENTS.md. Alrededor: 214 archivos, 12.066.966 bytes y 169.651 estrellas en GitHub. La proporción es de 4.435 a 1.

Este artículo va sobre el número que se cita —53% menos código, 41% más rápido, 26% más barato, 45% menos tokens— y sobre qué aparece cuando abres la tabla por tareas que hay detrás y la ordenas según qué tareas tienen una comprobación de corrección. Dos estadísticos míos reproducen el titular del proyecto hasta el decimal, así que la tabla es la que ellos usaron. Ordenada de otra manera, dice algo que el titular no dice.

Las mediciones de este artículo se tomaron el 21 de octubre de 2026 desde la API REST de GitHub, raw.githubusercontent.com, una ejecución de npm test sobre un clon limpio y renders con Playwright de ponytail.dev y del blog de JetBrains AI. Los números del proyecto son suyos; mi desglose de su tabla es mío.

Qué es el artefacto, en realidad

Empecemos por la forma del repositorio, porque «169.651 estrellas» y «un archivo markdown» son ambas ciertas y describen cosas muy distintas.

Dos detalles merecen una pausa. El archivo de texto más grande del repositorio no es el producto: es el corpus de tareas del benchmark, benchmarks/agentic/tasks.py, con 1.544 líneas. Y el archivo no-imagen más pesado es hooks/band/logo.ts: tres líneas y 49.871 bytes, una única cadena de trazado SVG para el logo de la barra de estado, redondeada a unidades enteras con el comentario «invisible at board sizes». Ese archivo solo es 18,3 veces la regla que hace el trabajo.

La regla además está duplicada. Cinco archivos son idénticos byte a byte (md5 a7bdf895…), 2.623 bytes cada uno: .agents/rules/ponytail.md, .clinerules/ponytail.md, .qoder/rules/ponytail.md, .windsurf/rules/ponytail.md, .github/copilot-instructions.md. Otros dos llevan el mismo cuerpo con otro front matter (.cursor/rules/ponytail.mdc, 2.748 bytes; .kiro/steering/ponytail.md, 2.688). Es deliberado y está vigilado: node scripts/check-rule-copies.js termina con código 0 y el mensaje «Rule copies match AGENTS.md; 10 rule invariants present in SKILL.md and AGENTS.md», y node scripts/check-versions.js sale 0 con «All 7 version files pinned at 5.3.2». Las dos comprobaciones pasan en un clon limpio, y npm test da 143 de 143 más 30 de 30 en la extensión de pi.

Un aviso sobre esa ejecución, porque importa para quien intente reproducirla: sin pandas instalado, un test falla —csv: correct pandas one-liner passes— con una aserción desnuda false !== true. La dependencia está documentada en benchmarks/README.md y en CONTRIBUTING.md, pero no en package.json, así que npm test en una máquina con solo Node reporta un fallo que parece un defecto y no lo es. Con pandas en el PATH, pasa.

La ingeniería es real. Simplemente no es la regla. La banda —el HUD de la barra de estado que llegó en 5.3— son 1.676 líneas en seis archivos (board.ts 560, register.tsx 487, metrics.ts 317, ponytail-band-import.js 274), el 14,2% de todo el código, para una función que el propio README limita a «Claude Code 2.1.290 o posterior, en la terminal o en la app de escritorio. No se muestra en el panel de chat de VS Code, ni en sesiones en la nube, ni en claude -p».

Cómo se calcula el titular

Las cifras salen de benchmarks/results/2026-10-07-agentic.md: 39 tareas, tres brazos (sin skill, Ponytail v4.13, Ponytail 5), 5 repeticiones cada una, 585 sesiones headless de Claude Code con Opus 5.5, CLI 2.1.288, y Bash desactivado en todos los brazos para medir solo lo que el agente escribe. El aislamiento se describe con honestidad, incluido un fallo confesado: «An earlier version of the harness ran some tasks inside the Ponytail repo. Claude Code then showed the model the repo’s recent commit messages. That is fixed.»

El estadístico está enunciado con precisión: «For each task I take the median of the 5 runs, divide arm by baseline, and report the geometric mean of those ratios over the tasks, with a 95% bootstrap interval». Así que −53% no es una media, ni una mediana, ni un total. Es una media geométrica de 39 cocientes por tarea.

Lo recalculé desde la tabla por tareas del final del mismo documento:

• media geométrica de los cocientes de líneas: 47,4% de la base, es decir −52,6%, su −53%
• media geométrica de los cocientes de coste: 74,1% de la base, es decir −25,9%, su −26%

Esa coincidencia es el punto. La tabla publicada y el titular publicado son los mismos datos, y la tabla lleva una variable más que el titular no lleva: qué tarea tiene una comprobación oculta que ejecuta de verdad el código entregado.

La misma tabla, ordenada por nivel

Dieciocho de las 39 tareas son «surgical tasks with hidden checks»: arreglos de bugs, devoluciones, SQL con entrada no confiable, path traversal, tokens falsificados, rate limiting, un caso de privacidad, renombrados. Las otras 21 son 12 tickets de funcionalidad sobre una plantilla fija de FastAPI + React, 3 ejemplos abiertos y 6 peticiones de «hazme una app pequeña». El documento dice de estas 21: «Their ‘pass’ only means the code was delivered or compiles, so I do not count them as a quality result».

Sumando la columna de coste de las 18 con comprobación, y de las 21 sin ella:

El −26% anunciado se concentra casi por completo en el nivel que no tiene señal de corrección ejecutada. En el nivel que sí la tiene, el ahorro es de menos de dos centavos por cesta de tareas, y no es uniforme: 8 de esas 18 salieron más caras.

Las ocho están en el nivel con comprobación. Ninguna de las 21 tareas sin comprobación se encareció. Eso no es un reparto aleatorio; es la forma del efecto. En un arreglo de tres a veinte líneas no hay nada que sobre-construir, así que no hay nada que ahorrar, y la regla inyectada más el «one small test or assert self-check» obligatorio son pura suma. En tmpl-fe-datepicker —el ejemplo estrella, 335 líneas de calendario hecho a mano sustituidas por 10 que reutilizan el componente Input del propio repo— el ahorro es de $0,427 a $0,099.

El resto de estadísticos se comporta igual cuando se mira tarea a tarea en lugar de media geométrica:

Nada de esto está escondido. El documento dice con claridad: «Less code did not cost correctness or safety. It did not add any either: the three arms are level». Las comprobaciones ocultas pasan 86/90, 86/90 y 87/90: 95,6%, 95,6%, 96,7%. Lo que el documento no hace es poner precio a los dos niveles por separado, y la distancia entre ellos es la diferencia entre adoptar esto por coste o adoptarlo por estilo.

Una prueba independiente de 80 tareas, y la tabla que no la cita

El 28 de julio, JetBrains publicó la tercera parte de una serie que pasa distintos skills públicos de «ahorro de tokens» por el mismo arnés emparejado. Es la prueba externa más rigurosa que he encontrado de Ponytail, y sus números son más pequeños que cualquier cosa que haya en el repositorio.

Montaje: 80 tareas emparejadas de SkillsBench, sandboxes Docker de Harbor 0.18 con verificadores, claude-sonnet-5 en esfuerzo medio, Claude Code 2.1.201 headless, Ponytail v4.8.4, 251 ensayos facturados por USD 246,09. Generaron el texto inyectado llamando al propio hooks/ponytail-instructions.js del proyecto en lugar de parafrasearlo, y auditaron cada ensayo para confirmar que la regla llegó al modelo: 100% de los ensayos con tratamiento, 0% de las bases.

De 10.205 líneas se pasó a 8.756. El resultado de coste es el firme —más barato en 46 tareas, más caro en 34— con el matiz de sus autores: «a bootstrap interval on the median just touches zero», así que «roughly 10% cheaper on this workload» se sostiene y «ponytail saves you 10%» no.

Dos hallazgos de ese artículo importan más que los porcentajes.

Primero, el skill no se activa solo. JetBrains instaló SKILL.md de la forma obvia y dejó que Claude Code decidiera: «Across all ten sessions it self-activated zero times. Not rarely. Never». El método de instalación decide si obtienes algo: lo que inyecta la regla es el hook SessionStart del plugin, y una copia suelta del skill lo más probable es que mida cero.

Segundo, su agrupación reproduce el corte por niveles que yo encontré, desde otra dirección. Ordenando por cuánto código escribió la base: las tareas que casi no necesitaban código (26 tareas) se movieron 0,0%; los trabajos pequeños de 20–99 líneas (21 tareas) −11,9%; los medianos de 100–299 (24 tareas) −20,9%; las construcciones de 300+ líneas (9 tareas) −31,2%. Ellos mismos advierten su método: «we chose these thresholds after seeing the data, and grouping by the baseline’s own output can stretch a gradient like this on its own».

El benchmarks/README.md del proyecto mantiene una tabla de «Independent benchmarks» con dos entradas, ambas de junio: una de ~44% menos código en 24 tareas, otra con salida más ajustada pero mayor coste de proceso. Busqué JetBrains en todo el repositorio: tres apariciones en el markdown, las tres describiendo el host Junie, más dos cadenas JetBrains Mono en board.ts. La prueba de julio no se cita en ningún sitio. El contrapeso es que este proyecto tiene una costumbre poco común de autocorregirse, así que la lectura más probable es retraso de mantenimiento —la entrada más nueva de esa tabla es cinco semanas y tres versiones mayores anterior a la prueba— y no selección. Pero una tabla cuyo propósito declarado es la transparencia no debería ser el único lugar donde falta el cuarto dato.

La promesa sobre los tests, y la fila que va debajo

El segundo titular es que «98% of risky logic ships with a test», frente al 68% sin skill. Es cierto, y viene con la fila que lo completa:

Leídas juntas, las dos últimas filas describen un intercambio de cantidad por profundidad: el skill escribe tests muchas más veces, y cada test individual es más débil cazando un bug inyectado que el test que escribe un modelo sin ayuda cuando se molesta en escribirlo. El documento lo dice sin suavizar: «No skill writes the most thorough single tests, but often writes none».

La última fila es la que yo pondría en la portada si quisiera que el proyecto se tomara en serio. En tareas que no necesitaban test, el skill escribió uno igualmente el 45% de las veces, frente al 36%. En un proyecto cuya premisa entera es el mejor código es el código que nunca escribiste, eso es la regla fallando en sus propios términos, en su propia tabla, y el autor lo deja ahí.

El resultado del juez de respuestas está citado de forma más selectiva en el README. El repositorio dice: «in a blind comparison, Ponytail 5’s replies beat the previous Ponytail’s 110 to 67». La tabla de origen tiene una segunda fila que el README no menciona: contra el modelo sin ningún skill, Ponytail 5 perdió 82 a 106 (p=0,09), y sobre diffs idénticos 99 a 118 (p=0,22). «Sin diferencia significativa» es el resumen del propio documento; «cierta inclinación hacia las respuestas más largas sin skill» es su propio comentario.

La historia del número

Ponytail ya ha publicado cinco reducciones titulares, y la secuencia informa más que cualquier cifra suelta.

La cifra del 80–94% sigue en el repositorio, en una tabla, con un aviso encima: «Read this number honestly (updated 2026-06-18). The gap above is single-shot, against a bare model that answers with several options plus commentary, so it counts prose, not just code, and overstates the win. #126 was right about that». El archivo de resultados de junio es más tajante: «The original 80–94% single-shot numbers were inflated by a chatty baseline, Colin was right. The honest number on real tickets is ‘huge where there’s bloat to cut, nothing where there isn’t, and not at the cost of safety.’».

Quiero ser justo con eso. Casi ningún proyecto de este género retira nada, y este retira en público, acredita al crítico por su nombre, confiesa un fallo de contaminación en su propio arnés y publica las filas incómodas. La frase de la conclusión de junio —«huge where there’s bloat to cut, nothing where there isn’t»— es exactamente el corte por niveles que produce mi recálculo y exactamente lo que encontraron los grupos de JetBrains. La información estaba en el repositorio desde el principio. Lo que viaja es la pancarta de cuatro números.

Distribución: dónde aterrizan de verdad 169.651 estrellas

Una estrella es un marcador. Una descarga es una decisión. Ponytail se distribuye por npm y por los marketplaces de plugins de GitHub, no por binarios adjuntos a releases:

La página de releases es un changelog, no un canal de entrega. Unas 102.000 instalaciones al mes frente a 169.651 estrellas es una proporción cercana a 0,6 descargas por estrella al mes, y npm cuenta CI y reinstalaciones, así que el número real de personas es menor. No es un escándalo —una regla de 2,7 KB está a un curl de distancia y los marketplaces de plugins se saltan npm por completo—, pero significa que el contador de estrellas y el de adopción no miden el mismo acontecimiento.

La distribución de contribuyentes es el patrón de un proyecto al que se le da estrella mucho más de lo que se le trabaja:

El volumen de commits cuenta lo mismo con un agujero en medio. Por mes: junio 155, julio 51, agosto 4, septiembre 14, octubre 139. La cronología de npm tiene el hueco equivalente: 4.8.4 el 29 de junio, después nada hasta 4.9.0 el 7 de agosto —treinta y nueve días—, y luego 13 versiones entre el 2 y el 16 de octubre, terminando en 5.3.2 cuatro días antes de mi medición. La v5.0.0 salió el 8 de octubre, un día después del archivo de benchmark que la justifica.

No es una crítica a un mantenedor en solitario que se toma un verano libre. Es la respuesta a una pregunta que se hacen los compradores: un proyecto con un agosto de cuatro commits y un octubre de 139 es un proyecto cuya hoja de ruta es el calendario de una persona. Tampoco hay semántica de versiones que leer: v1.0.0 y v4.0.0 se publicaron el primer día del repositorio.

La parte que es un negocio

El repositorio es MIT y la regla es gratis. Alrededor hay cuatro superficies comerciales:

• Un patrocinador. GreenPT ocupa el hueco del logo en el README.
• Merchandising. ponytail.dev/merch.html lista catorce artículos desde una pegatina de 3,49 € hasta una sudadera de 59,99 €, con el argumento «No slogans, no name. People who get it will ask».
• Una lista de espera. ponytail.dev/soon solo dice «He’s building something. Won’t say what. Won’t say when. Leave your email and you’ll get exactly one message the day it ships». Doble opt-in.
• Búsqueda de socio. ponytail.dev/stories pide a los lectores que «Connect us with a team that builds AI coding agents or developer tools, someone who picks the tools for a large engineering team, or a possible strategic partner», con contacto en chris@ponytail.dev. El dueño del repo y mantenedor en npm es dietrichgebert; la dirección de stories es otro nombre.

Esa es la secuencia habitual de una herramienta viral para desarrolladores: artefacto gratis, audiencia, merchandising, lista de correo y después algo de pago detrás de la lista. Nada de eso choca con la licencia MIT: el prompt sigue siendo bifurcable. Lo único que conviene anotar es que la frontera entre gratis y pago todavía no está dibujada, así que cualquier plan que dependa de que esta regla se quede exactamente como está hoy es un plan contra una hoja de ruta no anunciada.

Un detalle del README merece citarse por otro motivo: «Only install ponytail from DietrichGebert/ponytail on GitHub or @dietrichgebert/ponytail on npm. It never ships .exe or .dll files; a copy that does is not mine». Un proyecto que ya tiene que avisar sobre copias falsas, distribuido por catorce directorios de host, cuatro manifiestos en la raíz y los veinte marketplaces que promete su insignia, tiene una superficie de cadena de suministro que ningún markdown puede auditar. Si instalas skills para un equipo, esa frase es tu modelo de amenaza, no la tabla de benchmarks.

Lo que dijo Hacker News cuando importaba

169.651 estrellas y la mejor aparición en Hacker News es de 98 puntos y 17 comentarios, el 14 de junio, cuatro días después de crear el repositorio. Un segundo hilo en septiembre llegó a 33 puntos y 20 comentarios. Para un repositorio en este escalón de estrellas esa proporción es rara, y los comentarios son la parte útil:

• «I like how this repo has 159 files with 11635 LoC, and the load-bearing (!!!) part of it is a couple lines of natural language instructions»: la misma observación que mis recuentos de archivos, hecha en junio, cuando el repo tenía 55 archivos menos.
• «isn’t all this a little excessive for a few line long markdown file!? Why not just display the ‘skill’ itself with a few lines commenting on what it does/how it helps?»
• Un usuario de dos meses: «it is hit or miss. It’ll make actual high quality suggestions at times. But the thing it’s missing is the actual experience that makes its namesake persona. There’s no sense of nuance of context applied».
• «Concision begets perplexity»: la objeción de que optimizar por menos líneas hace más difícil ver los compromisos, que es el contraargumento honesto a toda la escalera.
• Y una acusación que reporto como afirmación y no repito como hallazgo: un comentarista sostuvo que las estrellas están «clearly manipulated with bots and fake accounts». No encontré ninguna prueba de eso y los números de crecimiento no la necesitan: un repo en GitHub Trending con cuatro insignias de Trendshift en su README puede llegar a seis cifras sin que nadie compre nada. Pero esas afirmaciones circulan, y la única respuesta duradera es el contador de descargas, no el de estrellas.

Hay además un pequeño ecosistema: «Show HN: Fleecevest – The Product Counterpart to Ponytail» (septiembre), «Show HN: Piggy – lazy senior dev mode for AI agents (80–94% less code)» (julio) y «My benchmark, it beat Ponytail on code, tokens, cost, and time» (agosto). Cuando tu idea genera clones y contra-benchmarks en semanas, la aportación es el formato, no la implementación, y el formato son cuatro kilobytes de inglés.

Qué haría yo en la práctica

1. Pon precio a tu propia mezcla de tareas antes de creerte ninguna de estas cifras. Cuenta los PR fusionados del último trimestre por tamaño de diff. Si la mayoría van de 3 a 50 líneas, el nivel con comprobación es tu realidad: espera alrededor de un 2% de coste, regresiones ocasionales del 10–30% en tareas sueltas, y cómpralo por la disciplina de revisión, no por la factura.
2. Verifica que la regla está en el contexto. No instalada: dentro. JetBrains obtuvo cero auto-activaciones en diez sesiones con SKILL.md suelto; el hook SessionStart del plugin es lo único que la inyecta de forma fiable. Abre la transcripción de una sesión terminada y busca una cadena distintiva de la regla, como el formato de comentario shortcut:. Si no está, has medido un placebo y vas a concluir que la herramienta no hace nada.
3. Haz pruebas de mutación a los tests que escribe. El 98% cuenta presencia. La fila del 69% frente al 77% cuenta qué caza un test. En tu propio dominio, invierte una comparación y un límite en un PR generado por el agente y mira si su test se pone en rojo.
4. Ejecuta las comprobaciones del proyecto antes de fiarte de su CI. node scripts/check-rule-copies.js y node scripts/check-versions.js pasan hoy, y npm test da 143/143, con pandas instalado. Sin él verás un fallo que parece un bug.
5. Lee el corte por niveles, no la pancarta. Si un proveedor de skills publica una tabla por tareas, suma las columnas según si la tarea tiene un verificador. Esa única operación dice más sobre dónde vive el efecto que cualquier porcentaje titular, y casi nadie la hace antes de adoptar.

Conclusión

Ponytail es el caso más claro que he mirado de un efecto real, modesto y funcional envuelto en un número grande. La regla es buena: seis peldaños, un párrafo de disciplina de alcance, una lista explícita de lo que nunca se recorta y la costumbre de cerrar cada respuesta con lo que no se comprobó. La ingeniería alrededor es cuidadosa: comprobaciones de deriva que pasan, versiones fijadas que pasan, 143 tests, un arnés de benchmark que confiesa su propio fallo de contaminación y un autor que concedió en público que su primera cifra estaba inflada.

Y el número que viaja es el que mezcla 18 tareas comprobadas con 21 sin comprobar y reporta una única media geométrica. Sepáralas y el 26% se convierte en 1,7%, con ocho regresiones individuales, todas en el nivel donde alguien ejecutó el código de verdad. Una prueba independiente de 80 tareas aterrizó en −15,4% de código y −10,3% de coste, coincidió en la forma del efecto y encontró que el skill no se activa solo nunca.

Nada de eso lo convierte en una mala herramienta. Lo convierte en una herramienta que se adopta por disciplina de revisión y presencia de tests, a un coste prácticamente plano donde se mide la corrección y claramente menor donde el agente iba a sobre-construir de todas formas. El repositorio ya lo dice, en una línea, en un archivo de resultados de junio: huge where there’s bloat to cut, nothing where there isn’t. La pancarta simplemente nunca recibió la actualización.

FAQ

¿Ponytail es solo un prompt? Sí. skills/ponytail/SKILL.md son 3.496 bytes y AGENTS.md 2.721; el resto del repositorio de 12 MB son catorce directorios de host, cuatro manifiestos en la raíz, una extensión de pi, un arnés de benchmark, un juego de i18n y un HUD de barra de estado.

¿Funciona en Cursor, Copilot o Windsurf? Se instala, con los límites que el README declara: los adaptadores de solo instrucciones cargan la regla siempre activa sin los comandos de barra, y Cursor con hooks obtiene el cambio de nivel /ponytail «only, typed as a plain message». Todas las cifras publicadas se midieron en Claude Code.

¿Por qué desaparece el ahorro en tareas pequeñas? Porque no hay nada que recortar y sí algo que añadir. La regla se inyecta en cada sesión y exige un test donde hay lógica; en un arreglo de 3 a 20 líneas, esas adiciones pueden superar lo que ahorra la escalera. Ocho de las 18 tareas comprobadas cuestan entre un 3% y un 30% más.

¿Qué dice exactamente la prueba independiente? −15,4% de código (p=0,088, no significativo al 0,05), −10,3% de coste (p=0,004, sólido), −11% de tiempo, −7,5% de tokens (dentro del ruido) y ninguna diferencia de calidad detectable: 6 mejor, 9 peor, 65 igual.

¿Se envían mis datos a algún sitio? La regla no llama a nada. La banda escribe en ~/.config/ponytail/band/ y el tablero se describe como una página local con «no server and no network: inline CSS, inline SVG and a few lines of script». La página de privacidad del sitio dice lo contrario de lo habitual: «This website sets no cookies and uses no analytics, tracking or advertising services», con las fuentes servidas localmente; la lista de espera la gestiona Brevo como encargado del tratamiento en la UE con doble opt-in.

¿Debería instalarlo en mi equipo? Si quieres diffs más pequeños y más tests, sí: es MIT, 2,7 KB y reversible. No presupuestes el 26%. Presupuesta entre 0 y 10%, verifica la inyección y haz pruebas de mutación a dos tests generados antes de dejarlo acercarse a una rama de release.