El mejor código es el que no escribís: Ponytail y la filosofía del dev más vago
Lo conocés. Cola de caballo larga, anteojos ovalados, lleva más tiempo en la empresa que el propio sistema de control de versiones. Le mostrás cincuenta líneas de código; las mira, no dice nada, y las reemplaza por una.
El 12 de junio alguien metió a ese tipo adentro del agente de IA. Y en cuatro días el repo pasó de cero a más de 20.000 stars.
Ponytail no es otro agente, ni otro MCP, ni otro modelo. Es un ruleset: un conjunto de instrucciones que cargás en tu agente de coding para que deje de escribir código como un junior tratando de justificar su sueldo, y empiece a escribirlo como un senior al que ya lo despertaron a las 3 de la mañana una vez de más por la genialidad ajena.
El problema que ataca ponytail
Le pedís a tu agente un date picker. Instala flatpickr, escribe un componente wrapper, agrega una hoja de estilos y abre una discusión sobre zonas horarias. Cuatro archivos donde el browser ya te da <input type="date">.
Este es el comportamiento por defecto de casi todos los agentes de coding: ante un pedido, producen. Más código, más abstracciones, más dependencias, como si el volumen fuera la prueba del trabajo. Al autor de ponytail lo cansó ver a su agente escribir 500 líneas para un problema de 5, y construyó el antídoto.
La filosofía entra en una línea, y está impresa en el repo: el mejor código es el que nunca escribiste.
Cómo funciona: la escalera
El corazón de ponytail es una escalera de escalado. Antes de escribir cualquier código, el agente tiene que frenar en el primer escalón que aguante:
- ¿Esto necesita existir? → No: salteálo (YAGNI)
- ¿La stdlib lo hace? → Usála
- ¿Hay un feature nativo de la plataforma? → Usálo (
<input type="date">en vez de una librería, CSS en vez de JS, un constraint de DB en vez de lógica de aplicación) - ¿Una dependencia ya instalada lo resuelve? → Usála, sin agregar una nueva para lo que se soluciona con unas pocas líneas
- ¿Puede ser una línea? → Que sea una línea
- Recién ahí: escribí el mínimo código que funcione
La escalera, en palabras del autor, es un reflejo y no un proyecto de investigación. El agente no se queda trabado debatiendo: entrega la versión vaga y cuestiona el pedido complejo en la misma respuesta.
Vago, no negligente
Acá está la distinción que evita que ponytail sea un tiro en el pie. “Vago” significa menos código, no código más endeble. Hay cosas que nunca van al banquillo: la validación en los límites de confianza (trust boundaries), el manejo de pérdida de datos, la seguridad y la accesibilidad. Entre dos opciones de stdlib del mismo tamaño, la regla es elegir la que está correcta en los edge cases: la vagancia nunca es excusa para el algoritmo más débil.
Y cuando el agente toma un atajo, lo marca: un comentario ponytail: en el código nombra la simplificación intencional. Si ese atajo tiene un techo conocido —un lock global, un scan O(n²), una heurística ingenua— el comentario nombra el techo y el camino de upgrade. No te quedás con deuda escondida; te quedás con deuda etiquetada.
Funciona con lo que ya usás
Ponytail no te pide que cambies de agente. Es deliberadamente agnóstico al modelo y al host, y viene en dos formatos:
- Como plugin (con activación always-on y comandos
/ponytail) para Claude Code, Codex —incluida la app de escritorio—, Gemini CLI, OpenCode y GitHub Copilot CLI. - Como archivo de reglas que copiás en la ruta correspondiente para Cursor, Windsurf, Cline, GitHub Copilot (editor), Aider y Kiro.
Tiene cuatro niveles de intensidad: lite, full (el default), ultra (para cuando, en palabras del autor, el codebase te ofendió personalmente) y off. Los cambiás en plena sesión.
Lo que dicen los números (y quién los dice)
El repo publica sus propios benchmarks: entre 80% y 94% menos código, entre 47% y 77% menos costo, y de 3 a 6 veces más rápido que un agente sin ruleset, en todos los modelos probados. Vale ser claro acá: son cifras autorreportadas por el proyecto, no validación independiente. Para crédito del autor, el benchmark es reproducible —corre sobre promptfoo y el método junto con los números crudos están en el repo—, pero hasta que alguien externo los reproduzca, tomálos por lo que son: las mediciones del autor sobre su propia herramienta.
La señal que sí es independiente es la adopción: más de 20.000 stars en cuatro días, y un release v4.6.0 que ya incluye contribuciones de afuera del proyecto, entre ellas la de un ingeniero de GitHub Copilot que sumó el Copilot CLI como host de plugins. Una herramienta que hace menos se volvió más completa al pasar por más manos.
Dónde no encaja
Ponytail está pensado para trabajar arriba de algo que ya existe: apalancarse en la stdlib, en features nativos, en dependencias instaladas. En un proyecto greenfield de verdad, donde todavía no hay nada que reutilizar y necesitás sentar arquitectura fundacional, la escalera te da menos apalancamiento: los primeros escalones asumen que hay una plataforma debajo en la que apoyarse. Tampoco es lo que querés si tu tarea realmente requiere construir una abstracción robusta desde cero, aunque ponytail, con razón, te haría justificar primero que de verdad la necesitás.
Para el día a día en el que vivimos la mayoría —mantener, extender, arreglar codebases reales— ahí es exactamente donde el dev más vago de la sala se gana el sueldo.