Ponytail: reglas para que tu agente escriba menos código

Qué es Ponytail

Ponytail es un conjunto de reglas que hace que un agente de programación basado en IA escriba menos código. El proyecto se describe en una línea: «Hace que tu agente de IA piense como el desarrollador sénior más perezoso de la sala. El mejor código es el código que nunca escribiste». Tiene licencia MIT. No incluye un entorno de ejecución propio y no ejecuta nada. Es texto que se incorpora a las instrucciones del agente. Se distribuye como una skill para los hosts que cargan skills y como archivos de reglas simples para los hosts que no las cargan.

El repositorio es DietrichGebert/ponytail. Se creó el 12 de junio de 2026 y superó las 90,000 estrellas el 1 de agosto de 2026. El 1 de agosto de 2026, la versión etiquetada más reciente era v4.8.4, publicada el 29 de junio de 2026, y la página de releases mostraba diez tags entre el 14 y el 29 de junio. El desarrollo no se ha ralentizado: el 17 de octubre de 2026, la release más reciente es v5.3.2, publicada a última hora del 16 de octubre, la tercera release de ese día después de v5.3.0 y v5.3.1. Antes se publicó v5.2.0 el 13 de octubre, cinco días después de que aparecieran v5.0.0 y v5.1.0 el 8 de octubre. El repositorio muestra más de 165,000 estrellas. Un proyecto que avanza a ese ritmo habrá cambiado cuando leas esto, así que fija un tag antes de construir nada sobre él.

La idea antes de la herramienta: detenerse en el primer peldaño que encaje

El núcleo de Ponytail es una escala de decisiones. El agente la recorre antes de escribir nada y se detiene en el primer peldaño que encaje.

1. ¿Es necesario que esto exista? Es YAGNI (no lo vas a necesitar). Si la respuesta es no, omítelo.
2. ¿Ya existe en este código base? Reutiliza el helper o el patrón que ya está presente.
3. ¿La biblioteca estándar lo resuelve? Úsala.
4. ¿Una funcionalidad nativa de la plataforma lo cubre? Úsala.
5. ¿Una dependencia ya instalada lo resuelve? Úsala.
6. ¿Puede ser una sola línea? Haz que sea una sola línea.
7. Solo entonces, escribe el código mínimo que funcione.

Esta es la escala tal como está escrita en v4.8.4, y los números de los peldaños del resto de este artículo siguen ese orden. La rama main actual combina los peldaños 3 y 4 en uno: "¿Biblioteca estándar o funcionalidad de la plataforma? Úsala, salvo que el proyecto tenga una propia", y añade que "un componente propio supera a un widget nativo", por lo que tiene seis peldaños. El orden es el mismo.

El resultado depende del orden, no de un peldaño concreto. Si se pide a un agente un selector de fecha, escribirá un selector de fecha, porque eso es lo que se le ha pedido. La escala hace que compruebe qué existe antes de construir nada: el peldaño 2 pregunta si el repositorio ya tiene un componente para ello, y el peldaño 4 indica que el navegador ya tiene <input type="date">. Las notas del benchmark actual del proyecto muestran exactamente este caso: un selector de fecha que ocupaba 335 líneas sin la regla pasó a ocupar 10 líneas con Ponytail 5, porque el agente reutilizó el componente Input propio del repositorio con type="date" y dejó que el navegador proporcionara el calendario. Un selector de color se redujo menos, de 135 líneas a 26. El peldaño 2 es el que falla silenciosamente, porque un agente que no puede ver el helper que ya existe escribirá sin problemas un segundo, y esa es la brecha que un mapa consultable de tu código base pretende cerrar.

Aquí, perezoso no significa descuidado, y el conjunto de reglas lo indica directamente. Su lista de aspectos en los que "nunca hay que ser perezoso" incluye comprender el problema antes de decidir, validar las entradas en los límites de confianza, gestionar los errores para evitar la pérdida de datos, la seguridad, la accesibilidad y todo lo que se haya solicitado explícitamente. También pide una comprobación ejecutable pequeña por cada parte de lógica no trivial. La regla limita la invención. No limita la corrección.

Qué incluye realmente el repositorio

• AGENTS.md, el conjunto de reglas siempre activo, que resume toda la idea en un archivo que puedes leer en cinco minutos.
• skills/ponytail/SKILL.md, la definición de la skill, con una indicación de argumento de lite, full, ultra o off.
• Archivos de reglas en directorios específicos de cada editor, como .cursor/rules/ y .windsurf/rules/, para los hosts que leen reglas pero no cargan skills.
• hooks/, benchmarks/, examples/ y scripts/.

El argumento de intensidad cambia cuánto presionan las reglas. lite crea lo que has pedido y menciona una opción más perezosa en una línea. full es el valor predeterminado y aplica la escala. ultra es la configuración extremista de YAGNI: prefiere eliminar antes que añadir y cuestiona incluso el requisito.

Los hosts compatibles con skills también obtienen comandos slash. /ponytail establece el nivel, /ponytail-review comprueba si un diff tiene ingeniería innecesaria, /ponytail-audit comprueba un repositorio completo, /ponytail-debt recopila los atajos que pospusiste y /ponytail-gain muestra la tabla de resultados del benchmark. Los hosts que sólo leen archivos de reglas reciben el conjunto de reglas sin comandos. Desde v5.3.0, publicada el 16 de octubre de 2026, Claude Code también muestra una banda sobre el prompt con el coste de la tarea, la reutilización de código y el estado de las pruebas. Requiere Claude Code 2.1.290 o posterior. No aparece en el panel de chat de VS Code, en sesiones cloud ni en claude -p, y /ponytail band off la oculta. Desde v5.3.2, /ponytail band import lee una vez tus sesiones anteriores de Claude Code y las añade al panel con su coste, el tiempo del agente y los tokens, para que puedas compararlas con las sesiones ejecutadas con la regla.

Para leer el código fuente antes de confiar en él, clona el tag en lugar de la rama. Este es el tag del que procede la escala anterior. Sustituye v5.3.2 por el último tag del 17 de octubre de 2026 para leer el texto actual:

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

En Claude Code, el proyecto documenta en su lugar la instalación de un plugin. Estas dos líneas corresponden a la documentación disponible el 17 de octubre de 2026:

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

La ruta del plugin sigue la rama predeterminada en lugar de un tag. Por tanto, las instrucciones que guían al agente pueden cambiar entre sesiones sin que lo adviertas. Ese es el coste que aceptas a cambio de la comodidad de un comando de actualización.

Por qué un agente perezoso es más barato en un VPS

El diff que escribe un agente no sale de la conversación. En el siguiente turno, el modelo lo vuelve a leer como contexto, junto con cada archivo que abrió para generarlo. Por tanto, un cambio de 500 líneas penaliza todos los turnos posteriores de la sesión hasta que la compactación sustituye los turnos antiguos por un resumen, no sólo el turno que lo generó. Por eso una refactorización descontrolada hace que el agente parezca más lento y menos capaz a medida que avanza la sesión: la ventana se llena con la salida del propio agente y queda menos espacio para el código real. Gestionar la ventana de contexto de un agente de programación trata precisamente de mantener este aspecto bajo control.

Los tokens se facturan tanto al introducirlos como al generarlos. Por eso, un diff que ocupa la mitad cuesta menos dos veces: cuando se escribe y de nuevo en cada turno que lo vuelve a leer. Que ese ahorro se refleje en la factura depende de cómo pague, porque una suscripción Pro o Max absorbe los tokens adicionales sólo hasta sus límites de uso. Después, los créditos de uso que se hayan habilitado se cobran por separado. En cambio, la facturación de la API por token cobra cada uno de ellos. Si controla el coste en una instalación autohospedada, el archivo de instrucciones es una palanca que no cuesta nada utilizar. Controlar cuánto le cuesta un agente de IA empieza por el volumen de salida, y cómo gasta sus tokens un agente de programación explica por qué la relectura importa más de lo que suele esperarse.

Una persona sigue leyendo el diff. Un cambio de 400 líneas que debería haber ocupado 20 líneas consume la atención de quien revisa, y la atención es el recurso que se agota primero. Nadie revisa el cuarto diff largo del día con el mismo cuidado que el primero. Por tanto, construir de más no sólo hace perder tiempo. También reduce de forma silenciosa la calidad de la revisión que debe detectar los errores.

En un servidor, las consecuencias son distintas, porque el agente suele ejecutarse sin supervisión. Un agente que trabaja en una sesión de tmux o mediante un temporizador tiene horas para desarrollar una mala decisión antes de que usted la vea. Ese es el riesgo práctico de ejecutar un agente de programación en un VPS, y por eso quienes practican ingeniería en bucle dedican tanta atención a las instrucciones permanentes y no sólo a los prompts individuales. Una regla del archivo que se carga siempre se aplica al turno 200. Una regla escrita en el chat se aplica al turno 3. También se aplica a la segunda sesión que inicie en el mismo equipo, porque esa sesión lee el archivo confirmado, pero no hereda nada de lo que escribió en la primera, incluso cuando las dos sesiones pueden enviarse mensajes.

Las dependencias nuevas son el otro coste silencioso. El nivel 5 indica que se debe usar lo que ya está instalado. Cada paquete que un agente añade por iniciativa propia es algo que tendrá que actualizar más adelante y que acabará incluido en cada imagen de contenedor que genere a partir de ese repositorio.

Qué indican los propios números del benchmark de Ponytail

El proyecto ha publicado dos tipos de resultados y difieren mucho entre sí. Ambos son cifras publicadas por el propio proyecto. Ninguna procede de una prueba independiente.

[
  {
    "label": "Lines of code",
    "v4_13_pct": 48,
    "v5_pct": 53
  },
  {
    "label": "Cost per run",
    "v4_13_pct": 16,
    "v5_pct": 26
  },
  {
    "label": "Wall clock time",
    "v4_13_pct": 38,
    "v5_pct": 41
  }
]

El gráfico corresponde al benchmark agéntico actual del proyecto, fechado el 7 de octubre de 2026. Se ejecutaron sesiones de Claude Code 2.1.288 sin interfaz, con Opus 5.5 y el nivel de esfuerzo predeterminado, sobre 39 tareas, con cinco ejecuciones por tarea y por configuración: 585 sesiones en total entre sin skill, Ponytail v4.13.0 y Ponytail 5. Doce de las tareas son tickets de funcionalidades de full-stack-fastapi-template, el repositorio real de FastAPI y React de tiangolo, evaluados según el git diff resultante. Las demás son 18 tareas quirúrgicas con comprobaciones ocultas, seis solicitudes de aplicaciones pequeñas y tres solicitudes de «muéstrame un ejemplo». Bash estaba desactivado en todas las configuraciones. Los tokens de salida disminuyeron un 45 por ciento con Ponytail 5.

Compare esto con las cifras de una sola ejecución que el proyecto publicó en junio de 2026. Se obtuvieron con un modelo sin agente que respondió a cinco solicitudes habituales con y sin las reglas, y se informaron como medianas de varias ejecuciones. Mostraban entre un 80 y un 94 por ciento menos de código en Haiku, Sonnet y Opus, y la verificación de costes fechada el 17 de junio de 2026 situaba a Haiku en un 63 por ciento menos. El resultado agéntico actual de Ponytail 5 es 53 por ciento menos líneas de código, 26 por ciento menos coste y 41 por ciento menos tiempo de ejecución. El proyecto corrigió rápidamente la cifra de una sola ejecución. Para v4.8.4, el 29 de junio de 2026, el README ya destacaba el resultado agéntico, «~54% menos código (hasta un 94%)», con una nota que aclaraba que el 80 al 94 por ciento anterior era «el máximo por tarea, no el promedio», y había trasladado las cifras de una sola ejecución a una sección contraída titulada «Cifras anteriores de una sola ejecución». Esa sección explicaba por qué existe la diferencia: la referencia de una sola ejecución es un modelo sin agente que «rellena su respuesta con prosa y opciones», algo fácil de superar. Si se compara con un agente real que realiza trabajo real, la ventaja se reduce. También sigue siendo real, que es el dato más útil. Esa ejecución agéntica de junio, con doce tickets sobre Haiku 4.5 y cuatro ejecuciones por ticket, quedó cerca de la cifra actual, con un 54 por ciento menos de líneas, y el README actual ya no incluye las cifras de una sola ejecución.

El propio proyecto incluye una salvedad, y es la que determina si esto le resulta útil. El ahorro es mayor cuando existe una tendencia real a construir más de lo necesario y casi nulo cuando el código ya era mínimo. La tabla por tarea de octubre lo confirma: varias tareas quirúrgicas terminaron con el mismo número de líneas en las tres configuraciones. Treinta y nueve tareas sobre un modelo y un host, con Bash desactivado, no permiten predecir el comportamiento en su repositorio. Si la cifra es importante para usted, ejecute la comparación con sus propios tickets, con y sin la regla, y cuente las líneas usted mismo.

El patrón que puede copiar hoy sin instalar nada

La escala es texto, por lo que no necesita el plugin para aplicar la idea. Pegue un bloque como este en el archivo de instrucciones que su agente ya lee, ya sea AGENTS.md, CLAUDE.md o el archivo de reglas de su editor.

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

La última regla merece analizarse por separado. La convención de Ponytail en sus versiones actuales es un comentario etiquetado con shortcut: que indica el límite y cuándo actualizarlo (las versiones de junio, incluida v4.8.4, lo etiquetaban con ponytail: en su lugar):

# shortcut: global lock, per-account locks if throughput matters

El comentario requiere dos líneas de trabajo y resuelve una cuestión que, de otro modo, consumiría otro ciclo de revisión. Informa al siguiente lector de que la versión sencilla fue una decisión y especifica la condición en la que esa decisión deja de ser válida. Sin él, un revisor no puede distinguir un atajo deliberado de algo que el agente olvidó, así que tiene que preguntar.

La ubicación del bloque importa tanto como su contenido. Un archivo que el agente carga en cada ejecución influye en todas las ejecuciones, incluidas las que no está supervisando. Esa diferencia es el tema de escribir un AGENTS.md que el agente realmente siga, y es la razón por la que este patrón debe estar en un archivo versionado, no en el historial de su shell. En un monorepo debe estar en más de un archivo versionado, porque un AGENTS.md por paquete mantiene breves las reglas de cada directorio en lugar de obligar al agente a leer las convenciones de todo el árbol en cada ejecución. La ubicación no es una garantía, sin embargo, y conviene saber por qué un agente pasa por alto una regla que ya ha cargado antes de concluir que la escala necesita una redacción más estricta.

Dónde deja de ser válida la regla

La escalera está ajustada para trabajar en una base de código existente, donde normalmente hay reutilización disponible y suele ser correcta. Encaja peor en un proyecto greenfield, porque el nivel 2 no tiene nada que reutilizar y el nivel 5 no tiene nada instalado. El agente aún puede detenerse en el nivel 1, la biblioteca estándar, una función de la plataforma o una línea de código, pero desaparecen dos de las salidas más económicas y, por tanto, más tareas terminan requiriendo código nuevo. También encaja mal cuando realmente se necesita la abstracción. Si está a punto de añadir el cuarto llamador del mismo bloque copiado, el «diff más corto» le entrega una quinta copia.

El nivel ultra cuestionará sus requisitos. Para eso existe ese nivel, y supone un coste real cuando ya ha tomado la decisión y quiere que se complete el trabajo. Use full para el trabajo habitual y recurra a ultra cuando sospeche que el problema es la propia solicitud de funcionalidad.

Ningún bloque de instrucciones evita una interpretación incorrecta del problema. El primer elemento del propio conjunto de reglas consiste en entender el código antes de decidir, que es la parte costosa y la que el texto no puede hacer por usted. Un diff mínimo en la función equivocada sigue siendo una corrección equivocada, y ahora es una corrección equivocada pequeña que resulta fácil de aprobar.

El resumen honesto es que Ponytail es un prompt cuidadosamente redactado, bien distribuido y con números asociados. Nada de lo que contiene requiere el plugin. Lo que aporta el proyecto es que alguien redactó correctamente la lista, la probó con un repositorio real y publicó el método junto con el resultado.

FAQ

¿Ponytail funciona con agentes distintos de Claude Code?

Sí. Se distribuye como una skill para hosts que cargan skills. Entre ellos están Claude Code, Codex, OpenCode, Gemini y varios más indicados en el README. Los editores que leen archivos de reglas, pero no cargan skills, como Cursor, Windsurf, Cline y Copilot, usan el ruleset siempre activo del directorio de reglas correspondiente y no disponen de comandos slash. El texto es el mismo en ambos casos. La diferencia real es si el host mantiene ese texto en el contexto en cada turno o sólo cuando se activa una skill.

¿Un agente perezoso omitirá las pruebas, la validación o la seguridad?

No. El ruleset lo indica directamente. Su lista de aspectos en los que nunca debe ser perezoso incluye la validación de entradas en los límites de confianza, el manejo de errores que evita la pérdida de datos, la seguridad y la accesibilidad. También solicita una comprobación pequeña y ejecutable para cada parte de lógica no trivial. La regla elimina la estructura inventada: abstracciones que nadie solicitó y dependencias que nadie necesitaba. Si el agente empieza a omitir pruebas después de instalarla, la causa es otra instrucción de su propia configuración que tiene prioridad sobre esta. Lea el archivo que el agente carga en último lugar.

¿Son fiables las cifras publicadas de velocidad y coste?

Son mediciones del propio proyecto, publicadas junto con su método, y deben interpretarse como tales. Las cifras de una sola ejecución de junio de 2026 se compararon con un modelo básico que alargaba su respuesta con prosa y opciones. El propio README de ese momento lo señaló como una referencia débil. Las cifras agentic actuales proceden de sesiones de Claude Code sin interfaz en Opus 5.5: 39 tareas con cinco ejecuciones cada una, 12 de ellas tickets de funcionalidad en un único repositorio de FastAPI y React. Son cifras válidas para esa configuración. No son una previsión para su base de código, porque los propios resultados por tarea del proyecto muestran que el ahorro se aproxima a cero en código que ya era mínimo.

¿Tengo que instalar algo para obtener el beneficio?

No. La ladder es texto. Pegar un bloque equivalente en el archivo de instrucciones que su agente ya lee proporciona la mayor parte del efecto. El plugin ofrece el texto mantenido, los niveles de intensidad, los comandos de revisión y una vía de actualización. Probar primero el bloque copiado es la respuesta de rung 1 a la pregunta de si la instalación debe existir.

¿Cómo impido que un agente desatendido construya demasiado durante la noche?

Coloque la regla en el archivo de instrucciones siempre activo, no en un mensaje de chat. Así se aplicará en el turno 200 de una ejecución larga y no sólo en el turno 3. Después, limite los daños por separado: proporcione al agente un checkout que pueda estropear en lugar de su única copia y exija una revisión humana del diff antes de fusionar cualquier cambio. Una regla de diff mínimo reduce la cantidad que debe leer. No decide qué se integra, ni debería hacerlo.