Ponytail: el agente senior que escribe menos código

Qué es Ponytail

Ponytail es un conjunto de reglas que hace que un agente de programación con 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, empaquetado como una habilidad para los hosts que cargan habilidades 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. La versión etiquetada más reciente del 1 de agosto de 2026 es v4.8.4, publicada el 29 de junio de 2026, y la página de versiones muestra diez etiquetas sólo entre el 14 y el 29 de junio. Un proyecto que avanza a ese ritmo habrá cambiado cuando lea esto, así que fije una etiqueta antes de construir algo sobre él.

La idea antes que la herramienta: deténgase en el primer nivel que funcione

El núcleo de Ponytail es una escala de decisión. El agente la recorre antes de escribir nada y se detiene en el primer nivel que funcione.

1. ¿Es necesario que exista? Esto es YAGNI (no lo va a necesitar). Si la respuesta es no, omítalo.
2. ¿Ya existe en este código base? Reutilice el helper o el patrón que ya esté presente.
3. ¿La biblioteca estándar lo hace? Úsela.
4. ¿Una función nativa de la plataforma lo cubre? Úsela.
5. ¿Una dependencia ya instalada resuelve el problema? Úsela.
6. ¿Puede escribirse en una línea? Escríbalo en una línea.
7. Sólo entonces, escriba el código mínimo que funcione.

El resultado depende del orden, no de un nivel concreto. Un agente al que se le pide un selector de fechas escribirá un selector de fechas, porque eso es lo que se le indicó. La escala le obliga a comprobar primero el nivel 4, y el nivel 4 indica que el navegador ya dispone de <input type="date">. Las notas de referencia del propio proyecto documentan exactamente este caso: un selector de fechas que ocupaba 404 líneas sin esta regla pasó a ocupar 23 líneas con ella, porque el agente recurrió al campo nativo en lugar de crear un componente. Un selector de colores pasó de 287 líneas a 23 por el mismo motivo.

Ser perezoso en este contexto no significa ser 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, mantener la seguridad y la accesibilidad, y cualquier requisito que se haya solicitado expresamente. 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é publica realmente el repositorio

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

El argumento de intensidad cambia la fuerza con la que se aplica la regla. lite implementa lo que se solicitó y menciona en una línea una opción más flexible. full es el valor predeterminado y aplica la escala. ultra es la configuración extrema de YAGNI: prefiere eliminar antes que añadir y cuestiona incluso el requisito.

Los hosts compatibles con habilidades también reciben comandos de barra. /ponytail establece el nivel, /ponytail-review comprueba si un diff tiene complejidad innecesaria, /ponytail-audit comprueba un repositorio completo, /ponytail-debt recopila los atajos que aplazó y /ponytail-gain muestra la tabla de resultados de la evaluación comparativa. Los hosts que sólo leen archivos de reglas reciben el conjunto de reglas sin comandos.

Para leer el código fuente antes de confiar en él, clone el tag en lugar de la rama:

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, y estas dos líneas corresponden a la documentación del 1 August 2026:

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

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

Por qué un agente poco ambicioso cuesta menos en un VPS

El diff que escribe un agente no desaparece de la conversación. En el turno siguiente, el modelo vuelve a leerlo como parte del contexto, junto con cada archivo que abrió para generarlo. Por tanto, un cambio de 500 líneas afecta a todos los turnos posteriores de la sesión, no sólo al turno en que se generó. Por eso una refactorización descontrolada hace que el agente parezca más lento y menos preciso 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 problema bajo control.

Los tokens se facturan tanto al introducirlos como al generarlos. Por tanto, un diff que ocupa la mitad cuesta menos dos veces: una al escribirlo y otra en cada turno que lo vuelve a leer. Si controla el coste en una instalación autohospedada, el archivo de instrucciones es una palanca que no cuesta nada utilizar. Controlar el coste de un agente de IA empieza por el volumen de salida, y cómo consume sus tokens un agente de programación explica por qué la relectura importa más de lo que se suele esperar.

Una persona sigue teniendo que leer el diff. Un cambio de 400 líneas que debería haber sido de 20 líneas consume la atención del revisor, 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 más de lo necesario no sólo desperdicia 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 puede pasar horas desarrollando una decisión incorrecta antes de que usted la detecte. Ese es el riesgo práctico de ejecutar un agente de programación en un VPS, y por eso quienes practican ingeniería de bucle dedican tanta atención a las instrucciones permanentes en lugar de centrarse en cada prompt individual. Una regla del archivo que siempre está activo se aplica al turno 200. Una regla escrita en el chat se aplica al turno 3.

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

Lo que muestran las propias cifras de referencia de Ponytail

El proyecto publica dos conjuntos de resultados que difieren ampliamente entre sí. Ambos proceden de cifras publicadas por el propio proyecto. Ninguno es una prueba independiente.

[
  {
    "label": "Lines of code",
    "single_shot_pct": 93,
    "agentic_pct": 54
  },
  {
    "label": "Cost per run",
    "single_shot_pct": 63,
    "agentic_pct": 20
  },
  {
    "label": "Wall clock time",
    "single_shot_pct": 74,
    "agentic_pct": 27
  }
]

La columna de ejecución única procede de un modelo sin configuración adicional que responde a un conjunto pequeño de indicaciones con la regla y sin ella. Los valores son las medianas de varias ejecuciones realizadas los días 13 y 17 de junio de 2026. La columna agéntica procede de una sesión sin interfaz de Claude Code que modifica full-stack-fastapi-template de tiangolo, un repositorio real de FastAPI y React, para resolver doce tickets de funcionalidades, con cuatro ejecuciones en Haiku 4.5. La evaluación se basa en el git diff resultante.

Mire la segunda columna. El resultado agéntico representa 54 por ciento menos líneas de código, 20 por ciento menos coste y 27 por ciento menos tiempo de ejecución, frente a 93 por ciento y 74 por ciento para esas mismas medidas en la configuración de ejecución única. El README explica claramente el motivo: la referencia de ejecución única es un modelo sin configuración adicional que «responde con varias opciones y comentarios», algo fácil de superar. Cuando se compara con un agente real que realiza trabajo real, la ventaja se reduce. También sigue siendo una ventaja real, que es el dato más útil.

Hay una salvedad del propio proyecto, y es la que determina si esto le resulta útil. El ahorro es mayor cuando existe un riesgo real de implementar más de lo necesario y se acerca a cero en el código que ya era mínimo. Doce tickets en un único repositorio de Python y TypeScript no permiten predecir el comportamiento en su repositorio. Si esta cifra es importante para usted, ejecute la comparación con sus propios tickets, con la regla y sin ella, y cuente las líneas personalmente.

El patrón que puede copiar hoy sin instalar nada

La plantilla es texto, así 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 tratarse por separado. La convención de Ponytail consiste en un comentario etiquetado con el nombre de la herramienta:

# ponytail: 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, costaría otra ronda de revisión. Indica al siguiente lector 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 este comentario, un revisor no puede distinguir entre un atajo deliberado y algo que el agente olvidó, por lo que tiene que preguntar.

La ubicación del bloque es tan importante 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 cómo escribir un AGENTS.md que su agente siga realmente, y por eso este patrón debe estar en un archivo versionado en lugar de quedar en el historial del shell.

Cuando la regla deja de ser adecuada

La escala está ajustada para trabajar en una base de código existente, donde normalmente es posible reutilizar código y hacerlo suele ser correcto. Encaja mal en un proyecto nuevo, porque el nivel 2 no tiene nada que reutilizar y el nivel 5 no tiene nada instalado, de modo que el agente llega al nivel 7 cada vez. También encaja mal cuando realmente se necesita una abstracción. Si está a punto de añadir el cuarto uso del mismo bloque copiado, «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 ejecute el trabajo. Use full para el trabajo habitual y recurra a ultra cuando sospeche que la solicitud de funcionalidad es el problema.

Ningún bloque de instrucciones evita interpretar mal el problema. El primer elemento del propio conjunto de reglas consiste en comprender el código antes de decidir, y esa es la parte costosa que el texto no puede hacer por usted. Un diff mínimo en la función equivocada sigue siendo una corrección incorrecta, y ahora es una corrección incorrecta 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 esto 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 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 obtienen comandos de barra. 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 sobre 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 mayor prioridad. En ese caso, lea el archivo que el agente carga en último lugar.

¿Son fiables las cifras publicadas de velocidad y coste?

Son mediciones propias del proyecto, publicadas junto con su método, y deben interpretarse como tales. Las cifras de una sola ejecución comparan el resultado con un modelo básico que responde con opciones y comentarios. El propio README indica que es una referencia débil. Las cifras del agente se obtuvieron en una sesión de Claude Code sin interfaz gráfica, sobre un repositorio con FastAPI y React, doce tickets y cuatro ejecuciones por ticket, usando Haiku 4.5. Son cifras válidas para esa configuración. No son una previsión para su base de código, porque el proyecto también indica 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 escalera es texto, y 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 del nivel 1 a la pregunta de si la instalación debe existir.

¿Cómo impido que un agente sin supervisión construya demasiado durante la noche?

Coloque la regla en el archivo de instrucciones siempre activo en lugar de enviarla 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 el daño por separado: proporcione al agente un checkout que pueda modificar o 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 de cambios que debe leer. No decide qué se incorpora, ni debe hacerlo.