Ponytail, la skill para ahorrar tokens como si fueras senior

Le pides a tu agente un selector de fechas para un formulario.

Te instala flatpickr, te escribe un componente envoltorio, te añade una hoja de estilos y, de regalo, te abre un debate sobre zonas horarias.

Treinta líneas y una dependencia para elegir un día en un calendario.

Ponytail mete en tu agente de IA al programador sénior que ya viste alguna vez: coleta, gafas ovaladas, lleva en la empresa más tiempo que el control de versiones. Le enseñas cincuenta líneas, no dice nada, y las reemplaza por una:

<!-- ponytail: el navegador ya tiene uno -->
<input type="date">

Es una skill open source creada por Dietrich Gebert que se instala en Claude Code, Codex, Cursor y más de una docena de agentes. Su tesis cabe en una frase: el mejor código es el que nunca escribes.

Esto es lo que vas a encontrar aquí:

• Qué es Ponytail y por qué la sobreingeniería de los agentes es un problema medible
• La escalera de decisión con la que elige qué NO construir
• Ejemplos reales de antes y después, con código
• Dónde Ponytail se niega a recortar (seguridad, validación, accesibilidad)
• Los comandos, los niveles de intensidad y la instalación en cada agente
• En qué se diferencia de Caveman, la otra skill de moda
• Qué dicen sus benchmarks de verdad, con todas las letras pequeñas

Qué es Ponytail y qué problema resuelve ¶

Ponytail es una skill que fuerza a tu agente de IA a entregar la solución más corta que de verdad funciona. Antes de escribir una línea, el agente se pregunta si esa línea hace falta.

El problema que ataca tiene nombre y datos. La deuda técnica es la frustración número uno de los developers, por encima de los stacks complejos y los despliegues, según la Stack Overflow Developer Survey de 2024 y 2025. Y con la IA esto se amplifica: si el 41% del código global ya sale de un modelo, según las Vibe Coding Statistics 2026 de Second Talent, también se multiplica la basura que ese modelo genera por defecto.

Porque los agentes tienen un sesgo claro. Pídele a un asistente que valide un email y te devuelve una clase EmailValidator, un wrapper de conveniencia y una expresión regular que, encima, rechaza direcciones válidas. Pídele un endpoint que devuelva un usuario por su id y te monta cinco ficheros: controller, service, repository, schema y una excepción personalizada. Para envolver una consulta a base de datos.

💡 Los modelos no escriben de más por maldad. Escriben de más porque su entrenamiento premia las respuestas completas, elaboradas y “profesionales”. Ponytail invierte ese incentivo: premia el diff más corto que pasa la prueba.

No es un problema exclusivo de los modelos pequeños. En la presentación de Sonnet 4.6, una de las mejoras que más destacaron los que tuvieron acceso anticipado fue justo esta: es menos propenso a la sobreingeniería y “no se pasa de listo” añadiendo cosas que nadie pidió. Que un laboratorio venda esto como avance te dice cuánto duele el problema contrario.

La escalera de pereza con la que decide qué no escribir ¶

El corazón de Ponytail es una escalera de seis peldaños. El agente sube por ella y se detiene en el primer peldaño que aguanta el peso.

1. ¿Esto necesita existir?
   Si la necesidad es especulativa, se salta y lo dice en una línea (esto es YAGNI puro).
2. ¿Lo cubre la librería estándar?
   Si la stdlib ya lo hace, se usa la stdlib.
3. ¿Hay una función nativa de la plataforma?
   <input type="date"> antes que una librería de calendarios, CSS antes que JavaScript, una restricción de base de datos antes que código de aplicación.
4. ¿Lo resuelve una dependencia ya instalada?
   Se reutiliza. Nunca se añade una dependencia nueva para lo que resuelven unas pocas líneas.
5. ¿Cabe en una línea?
   Una línea.
6. Solo entonces: el mínimo código que funciona.

La gracia está en el matiz que trae el propio archivo de la skill: la escalera es un reflejo, no un proyecto de investigación. Si dos peldaños valen, coges el más alto y sigues. La primera solución perezosa que funciona es la correcta. No quieres un agente que se quede diez minutos meditando sobre qué no construir, porque ahí pierdes el tiempo que ganaste.

Hay además una regla afilada para los empates: entre dos opciones de la stdlib del mismo tamaño, se elige la que es correcta en los casos límite. Pereza significa escribir menos código, no elegir el algoritmo más endeble.

Antes y después: tres ejemplos con código ¶

La teoría se entiende mejor con las cicatrices. Estos son ejemplos sacados del propio repositorio.

El primero es el del email. Tarea: “valida una dirección de correo en Python”. La versión sin Ponytail monta una clase con su patrón compilado y su wrapper. La versión con Ponytail asume una verdad incómoda:

# ponytail: suficiente; la validación real es enviar el correo
"@" in email and "." in email.split("@")[-1]

¿Te parece poco serio? Lo es, y a propósito. Ninguna expresión regular valida de verdad un email; solo lo hace un intento de entrega. Para eso están los correos de confirmación. Si aun así quieres rigor, la librería estándar lo trae con email.utils.parseaddr. Veintisiete líneas convertidas en una.

El segundo es el endpoint de usuario. Cinco ficheros y tres clases reducidos a nueve líneas. Pero fíjate en lo que NO se borra:

# ponytail: fuera las capas; el response schema se queda, marca qué sale de la API
class UserOut(BaseModel):
    id: int
    name: str
    email: str

@app.get("/users/{user_id}", response_model=UserOut)
def get_user(user_id: int, db: Session = Depends(get_db)):
    user = db.get(User, user_id)
    if not user:
        raise HTTPException(404)
    return user

El repository, el service y la excepción eran ceremonia. El response_model, no: define qué campos abandonan la API. Devolver el modelo crudo del ORM filtraría todas las columnas, incluidas las que nunca quisiste exponer. Esa es la frontera que Ponytail respeta, y enlaza con un error común que ya vimos al hablar de skills para construir APIs con Node y TypeScript: no todos los proyectos necesitan DDD. A veces un controlador y poco más es todo lo que hace falta.

El tercero es el más doloroso para el orgullo. Tarea: “ordena este array de números”. Sin la skill, el agente te escribe un quicksort a mano, con sus tres arrays por nivel de recursión y su desbordamiento de pila en entradas grandes. Con la skill:

// ponytail: esto ya existe
numbers.sort((a, b) => a - b)

Veinticuatro líneas a una. Cada runtime trae un sort afinado por gente cuyo trabajo entero es ordenar. Úsalo.

🔑 Cada atajo que toma Ponytail queda marcado con un comentario ponytail:. No es un atajo escondido bajo la alfombra: es una decisión firmada. Y cuando el atajo tiene un techo conocido (un lock global, un escaneo O(n²)), el comentario nombra ese techo y la vía de salida.

Lazy no significa negligente ¶

Aquí es donde Ponytail se separa de “haz chapuzas más rápido”. La pereza tiene fronteras explícitas que la skill nunca cruza.

No se recorta nunca la validación en las fronteras de confianza, el manejo de errores que evita pérdida de datos, la seguridad, ni la accesibilidad. Si el usuario pidió algo de forma expresa, se construye y no se vuelve a discutir.

Hay un detalle que demuestra que quien escribió esto ha tocado hardware: el mundo físico nunca es el ideal del papel. Un reloj deriva, un sensor lee desviado, un PCA9685 va un poco adelantado. Ponytail deja la perilla de calibración aunque sea “más código”, porque el modelo mínimo no puede ver lo que solo el cacharro real sabe.

Y luego está la regla de oro, la que separa a Ponytail de un generador de one-liners frágiles: el código perezoso sin su comprobación está sin terminar. Toda lógica no trivial (una rama, un bucle, un parser, una ruta de dinero o de seguridad) deja detrás una comprobación ejecutable: el assert más pequeño que falla si la lógica se rompe. Sin frameworks, sin fixtures, sin suites por función. Los one-liners triviales no necesitan test, porque YAGNI también aplica a los tests.

Esto conecta con algo que Dax Raad, creador de OpenCode, dejó claro sobre la calidad del código y la IA: el 95% de las “chapuzas que ya arreglaremos después” no son trade-offs deliberados, son falta de oficio disfrazada de pragmatismo. Ponytail no te da permiso para el atajo tonto. Te da permiso para el atajo informado.

Los cuatro comandos que vienen con la skill ¶

Ponytail no es solo el modo perezoso. A diferencia de los plugins de Claude Code que añaden funcionalidades concretas, aquí instalas una filosofía con cuatro comandos para distintos momentos del ciclo de trabajo. Necesitan un agente con soporte de skills (Claude Code, Codex, OpenCode, Gemini, pi).

• /ponytail-review
  Revisa el diff actual buscando solo sobreingeniería y te devuelve una lista de cosas que borrar, una línea por hallazgo.
• /ponytail-audit
  Lo mismo, pero a nivel de todo el repositorio en lugar del diff. Ordena los hallazgos del recorte más grande al más pequeño.
• /ponytail-debt
  Recolecta todos los comentarios ponytail: repartidos por el código y los reúne en un libro de deuda, para que “más tarde” no se convierta en “nunca”.
• /ponytail-help
  La tarjeta de referencia rápida de todo lo anterior.

El formato del review es lo que lo hace útil. Nada de “¿has considerado si todas estas reglas de validación son necesarias en esta etapa?”. En su lugar, algo que puedes ejecutar mentalmente al instante:

L12-38: stdlib: validador de 27 líneas. "@" in email, 1 línea.
L4: native: moment.js importado para un format. Intl.DateTimeFormat, 0 deps.
repo.py:L88: yagni: AbstractRepository con una implementación. Inlínealo.
net: -73 lines possible.

Cada hallazgo lleva una etiqueta (delete, stdlib, native, yagni, shrink), qué cortar y qué lo reemplaza. Y cierra con la única métrica que importa: cuántas líneas puedes borrar. Si no hay nada que recortar, dice “Lean already. Ship.” y se calla. Esa honestidad de no inventarse trabajo es, en sí misma, una forma de pereza bien entendida.

Los tres niveles de intensidad: lite, full y ultra ¶

Ponytail no es un interruptor de encendido y apagado. Tiene tres marchas, y por defecto arranca en la del medio.

⚠️ El nivel por defecto es full y se activa solo en cada sesión. Si quieres otro, lo fijas con la variable de entorno PONYTAIL_DEFAULT_MODE o en ~/.config/ponytail/config.json. La resolución es: variable de entorno > fichero de configuración > full.

La diferencia entre marchas es de actitud:

1. lite
   Construye lo que pediste, pero te nombra la alternativa más perezosa en una línea. Tú decides.
2. full
   La escalera aplicada en serio. Stdlib y nativo primero, el diff más corto, la explicación más corta. El valor por defecto.
3. ultra
   El extremista de YAGNI. Borrar antes que añadir. Te entrega el one-liner y, en la misma respuesta, cuestiona el resto del requisito. Existe, en palabras del repositorio, “para cuando la base de código te ha ofendido personalmente”.

El ejemplo de la caché lo ilustra bien. Ante “añade una caché para estas respuestas de la API”, el nivel lite te la añade y te susurra que functools.lru_cache lo cubre en una línea. El full pone el decorador y se salta la clase de caché. El ultra te dice que no pongas caché hasta que un profiler lo pida, porque una clase de TTL hecha a mano es una granja de bugs con tasa de aciertos.

Cómo se instala en cada agente ¶

👉 Si ya tienes claro el concepto, lo único que queda es meterlo en tu agente. Aquí es donde Ponytail brilla: nació para ser portable.

Instalación según tu herramienta ¶

Ponytail funciona en más de una docena de agentes, divididos en dos categorías. Los que soportan plugins o skills nativos obtienen la experiencia completa (activación por sesión, comandos, cambio de nivel). Los que solo leen ficheros de instrucciones obtienen las reglas siempre activas, pero sin comandos ni hooks.

En Claude Code son dos líneas:

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

Para Codex, GitHub Copilot CLI y Gemini CLI el patrón es equivalente, un comando de marketplace y otro de instalación:

# Codex
codex plugin marketplace add DietrichGebert/ponytail

# GitHub Copilot CLI
copilot plugin install ponytail@ponytail

# Gemini CLI
gemini extensions install https://github.com/DietrichGebert/ponytail

Un apunte de actualidad: Google está renombrando Gemini CLI a Antigravity CLI (el binario agy), y la misma extensión se instala allí. Hasta que la migración termine, alrededor del 18 de junio de 2026, gemini extensions install sigue valiendo.

Para OpenCode y el harness pi la instalación reutiliza los mismos hooks/ y skills/ del repositorio. Y hay un grupo de agentes que solo leen instrucciones (Cursor, Windsurf, Cline, Copilot en editor, Aider, Kiro): para ellos copias el fichero de reglas correspondiente desde el repositorio. La tabla completa de qué fichero va a qué agente está en la documentación de portabilidad del proyecto.

🛡️ Los plugins de Claude Code y Codex ejecutan dos hooks de Node.js. Necesitas node en tu PATH. Si no lo tienes, las skills siguen funcionando; lo único que se pierde es la activación automática, que se queda en silencio en vez de dar error en cada prompt.

Si ya has instalado plugins en Claude Code, el flujo te resultará familiar. La diferencia es que aquí instalas una filosofía, no una funcionalidad. Para ver cómo el equipo de Anthropic clasifica sus propias skills en 9 categorías temáticas, hay un catálogo completo del ecosistema.

Ponytail frente a Caveman: qué recorta cada una ¶

Si ya leíste sobre Caveman, la skill que recorta hasta un 75% los tokens de salida, la pregunta es inevitable: ¿no hacen lo mismo? No. Y el propio Ponytail lo aclara: “gobierna lo que construyes, no cómo hablas; combínalo con Caveman para prosa escueta”.

La distinción es limpia. Caveman comprime lo que el agente dice: fuera artículos, saludos y hedging, solo la sustancia. Ponytail comprime lo que el agente construye: fuera capas, dependencias y abstracciones que nadie pidió. Una ataca los tokens de la prosa; la otra, las líneas del código.

En los propios benchmarks del repositorio se ve la división de papeles. Caveman, al ser una skill de compresión de prosa, deja el código “normal” y se sitúa entre la línea base y Ponytail en tamaño de código; gana sobre todo en tokens de prosa. Ponytail gana en líneas de código por goleada. No compiten: se complementan. Una para la boca, otra para las manos.

Los números, con todas las letras pequeñas ¶

El titular del repositorio es contundente: 80-94% menos código, 47-77% más barato y 3-6 veces más rápido que un agente sin skill. Esos números son reales, pero merecen contexto, porque sin él se prestan a malinterpretación.

Lo que se midió: cinco tareas cotidianas (validador de email, debounce, suma de CSV, temporizador en React, rate limiter), tres modelos (Haiku, Sonnet, Opus), diez ejecuciones por celda, mediana reportada. La mejora en líneas de código frente a la base es enorme y consistente. Por ejemplo, en Haiku la base escribe una mediana de 518 líneas, Caveman 116 y Ponytail 39.

Ahora las letras pequeñas, que el propio repositorio no esconde:

• Los modelos probados son de la familia Claude. El propio benchmark admite que en modelos pequeños o locales (probaron Llama 3.2 vía Ollama) la escalera de decisión no se sigue de forma fiable y las ganancias se diluyen en el ruido.
• Las comprobaciones de React y FastAPI son estructurales, por palabras clave, no ejecutan el código. Solo email, debounce y CSV se ejecutan de verdad.
• El coste reflejado es de llamadas que reenvían la skill cada vez. En sesiones reales la skill se inyecta una vez y se cachea, así que la comparación de coste es orientativa.

Y aquí viene la parte que más me gustó, porque es la prueba de fuego de cualquier proyecto honesto. En el issue #65, un miembro de la comunidad reportó que Ponytail empeoraba la corrección del código en gpt-4.1-mini (10 de 15 con la skill frente a 15 de 15 sin ella). Una acusación seria para una skill que presume de no romper nada.

El autor investigó. ¿La conclusión? El culpable principal era el propio benchmark: el medidor de corrección no sabía leer código sin las comillas de bloque (algo más frecuente con el estilo escueto de Ponytail) y una de las tareas comprobaba un entregable que el prompt nunca pidió. Arreglados esos dos bugs, la caída no se reproduce: gpt-4.1-mini puntúa 100% con y sin la skill.

💡 Lo valioso no es que el problema fuera del medidor. Es lo que el autor hizo después: documentó un defecto real y pequeño que sí existe, y explicó por qué no lo arregló.

Ese defecto real merece nombrarse, porque es el límite honesto de toda esta filosofía. Bajo la presión de “usa la stdlib”, algunos modelos de OpenAI recurren a email.utils.parseaddr para validar emails. Pero parseaddr es un parser, no un validador: acepta basura como @missing-local.com. El autor probó ocho ediciones distintas del archivo de skill para forzar el 100% y todas puntuaron igual o peor, además de inflar las líneas de código. Así que no envió ninguna. Añadir texto que no mueve la aguja es justo el culto al cargo que Ponytail existe para evitar.

El dato tranquilizador: en los modelos Claude, su plataforma objetivo, la validación de email da 100% en Haiku, Sonnet y Opus. La ganancia de tamaño (la mitad del código) viene sin peaje de corrección en Claude. El resbalón es específico de OpenAI y está documentado.

Eso es, para mí, la mejor señal de calidad del proyecto. No la cifra del titular, sino la disposición a enseñar la herida.

Cuándo tiene sentido usarla y cuándo no ¶

Ponytail no es para todo el mundo ni para todo momento. Brilla cuando trabajas con un agente capaz (Claude Haiku para arriba) y tu dolor es la sobreingeniería: prototipos, scripts internos, side projects, código que se acumula sin que nadie lo pida. También como red de seguridad en revisiones, con /ponytail-review cazando el exceso que se cuela en los pull requests.

Donde tendría cuidado: con modelos locales pequeños que no siguen bien la escalera, en bases de código donde la “complejidad” es en realidad un requisito de negocio mal comunicado, y en cualquier sitio donde confundir “menos código” con “menos rigor” tenga consecuencias. La skill se cuida de esto con sus fronteras, pero la última línea de defensa sigues siendo tú.

Porque al final el mensaje de fondo es el mismo de siempre, el que repetimos cada vez que sale una herramienta nueva: el agente propone, tú dispones. Ponytail es un sénior excelente metido en tu terminal. Pero hasta el mejor sénior necesita que alguien lea el diff antes de hacer merge.

¿Te animas a meterle la coleta a tu agente y ver cuánto código deja de escribir esta semana?

Preguntas frecuentes ¶

¿Qué es Ponytail?

Ponytail es una skill open source para agentes de IA que fuerza la solución más corta que funciona. Aplica una escalera de decisión (YAGNI, librería estándar, función nativa, dependencia existente, una línea) antes de escribir código nuevo. La creó Dietrich Gebert y se publica bajo licencia MIT.

¿En qué se diferencia de Caveman?

Caveman comprime la prosa que el agente escribe; Ponytail comprime el código que construye. Caveman ataca los tokens de salida, Ponytail ataca las líneas y las dependencias. Son complementarias y se pueden usar a la vez.

¿Ponytail rompe el código o lo hace menos correcto?

En los modelos Claude (Haiku, Sonnet, Opus) la corrección se mantiene al 100% en las validaciones probadas, según la auditoría de robustez del repositorio. Hay un resbalón documentado en validación de email en modelos de OpenAI, que el propio autor expone con honestidad.

¿Funciona con modelos locales pequeños?

No bien. El propio benchmark muestra que en modelos como Llama 3.2 la escalera de decisión no se sigue de forma fiable y las ganancias se pierden en el ruido. Necesita un nivel de seguimiento de instrucciones comparable a Claude Haiku o superior.

¿En qué agentes se instala?

En más de una docena: Claude Code, Codex, GitHub Copilot CLI, OpenCode, Gemini CLI (y la futura Antigravity), pi y OpenClaw con experiencia completa; Cursor, Windsurf, Cline, Kiro y Aider en modo solo instrucciones.

¿Qué hace el comando ponytail-review?

Revisa un diff buscando solo sobreingeniería y devuelve una lista de qué borrar, una línea por hallazgo, con etiquetas como stdlib, native o yagni. Cierra con el total de líneas que podrías eliminar. No aplica los cambios, solo los lista.

¿Cuáles son los niveles de intensidad?

Son tres: lite (construye lo pedido y nombra la alternativa perezosa), full (la escalera aplicada en serio, es el valor por defecto) y ultra (extremista de YAGNI, borra antes que añadir y cuestiona el requisito).

¿Necesita Node.js para funcionar?

Solo los plugins de Claude Code y Codex, para dos hooks de activación. Si no tienes node en el PATH, las skills siguen funcionando; lo único que se pierde es la activación automática al inicio de sesión.

¿Qué es un comentario ponytail: en el código?

Es la firma de un atajo deliberado. Cuando Ponytail simplifica algo, lo marca con // ponytail: ... para que se lea como intención, no como ignorancia. Si el atajo tiene un techo conocido, el comentario nombra ese techo y la vía de salida.

¿Cómo desactivo Ponytail?

Diciendo “stop ponytail” o “normal mode” en la conversación, o con /ponytail off. También puedes fijar el modo por defecto en off con la variable PONYTAIL_DEFAULT_MODE para que no se active solo al arrancar la sesión.

Fuentes ¶

• Ponytail en GitHub — repositorio oficial, README y documentación
• Benchmarks de Ponytail — metodología, resultados y auditoría de robustez
• Issue #65: ¿degrada Ponytail el rendimiento del modelo? — el hilo donde se discutió la corrección
• Documentación de portabilidad entre agentes — qué fichero va a cada agente
• Caveman, de Julius Brussee — la skill de compresión de prosa que sirve de contrapunto
• Stack Overflow Developer Survey — datos sobre deuda técnica y adopción de IA

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter