Ponytail: cómo enseñarle a un agente de IA a escribir menos código

Pídele a un agente de IA un selector de fecha y es común que agregue una dependencia nueva o construya un calendario a mano: unos cientos de líneas que a partir de ese momento son tuyas. Pídeselo a un desarrollador senior y primero revisa lo que ya existe. El repositorio tiene un componente Input y todos los navegadores traen un selector de fecha nativo, así que la respuesta son unas diez líneas.

Ponytail es un plugin de código abierto, con licencia MIT y escrito por Dietrich Gebert, que intenta que el agente se comporte como la segunda persona. Es un conjunto de instrucciones más algunos hooks de ciclo de vida, y funciona en Claude Code, Codex y una larga lista de otros agentes. Lo usamos en nuestros propios repositorios. Aquí explicamos qué hace, cómo configurarlo y un cambio al que nos llevó en este mismo sitio.

1. La idea: flojera con la solución, no con el cambio

El plugin se describe como el "modo senior perezoso". La flojera apunta a una sola cosa: cuánto código nuevo necesita la solución. No es permiso para saltarse trabajo. La instrucción lo dice directamente: termina cada parte que la tarea necesita, incluidos los llamadores, las pruebas y los fixtures que tu cambio rompa.

En la práctica eso se convierte en una escalera corta de decisiones. Antes de escribir nada, el agente la baja y se detiene en el primer peldaño que resuelve el problema por completo.

1. ¿Tiene que existir? Se omiten las funciones, opciones y flexibilidad que nadie pidió, y se mencionan en una línea para que puedas pedirlas.
2. ¿Ya está en este código? Un helper, un componente, un servicio o un patrón, usado como lo usa el código de alrededor.
3. ¿Lo resuelve la biblioteca estándar o la plataforma? Salvo que el proyecto tenga su propia versión: en ese caso gana el componente de la casa.
4. ¿Hay una dependencia ya instalada que lo haga? Úsala. Nunca se agrega una dependencia nueva por unas cuantas líneas.
5. ¿Cabe en una línea que se entienda a la primera? Entonces una línea. Una línea que hay que descifrar no cuenta.
6. Si no, el mínimo código que funcione, más una prueba pequeña si tiene lógica de verdad.

Igual de importante es la lista de lo que nunca recorta: la validación en los límites de confianza, el manejo de errores que evita pérdida de datos, la seguridad, la accesibilidad y cualquier cosa que hayas pedido de forma explícita. Un diff más corto que se salta alguna de ellas no es el cambio correcto más pequeño. Es simplemente un cambio equivocado.

2. Instalación

En Claude Code es un plugin de su propio marketplace:

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

Codex usa el mismo repositorio con codex plugin marketplace add DietrichGebert/ponytail. Para agentes sin sistema de plugins, el repositorio incluye un AGENTS.md que puedes copiar al proyecto, además de archivos de reglas para Cursor, Windsurf, Cline, Copilot y otros. El autor pide instalarlo solo desde DietrichGebert/ponytail en GitHub o @dietrichgebert/ponytail en npm, y aclara que nunca distribuye archivos .exe ni .dll. Vale la pena revisarlo en cualquier herramienta que vaya a ejecutarse dentro de tu editor.

3. Niveles y comandos

Una vez instalado queda activo toda la sesión hasta que escribes "stop ponytail" o "normal mode". Tiene tres niveles:

• lite construye lo que pediste y menciona la opción más pequeña en una línea, para que tú decidas.
• full es el nivel por defecto y aplica la escalera de arriba.
• ultra además cuestiona la petición y objeta cualquier parte que la necesidad no justifique.

Los comandos son reportes de una sola vez que no modifican nada:

/ponytail full          # cambiar de nivel: lite | full | ultra
/ponytail-review        # revisar un cambio: correcto, seguro, aguanta carga, probado, sin sobra
/ponytail-audit         # las mismas preguntas sobre todo el repositorio
/ponytail-debt          # lista cada comentario "shortcut:" como un registro de deuda
/ponytail-gain          # las cifras del benchmark publicado

El comando de deuda es lo que más nos gusta. Cuando el agente toma un atajo con un límite conocido, tiene que dejar un comentario con una forma fija, shortcut: <el límite>, <cuándo mejorarlo>. /ponytail-debt los junta todos, así que un aplazamiento deliberado no se vuelve permanente sin que nadie lo note.

4. Un ejemplo real: nuestra propia factura de Railway

Este sitio es una app de Next.js en Railway, con una base de datos Postgres pequeña para el blog. En octubre el uso del proyecto iba en $5.28 USD en lo que llevaba el periodo de facturación, y $5.12 de eso era memoria. El CPU estaba casi en cero. El servicio de Postgres promediaba 54 MB. El servicio web promediaba 0.99 GB en siete días, lo que equivale a unos $10 USD al mes solo de memoria con la tarifa de Railway de $0.000231 por GB por minuto.

Ya habíamos intentado arreglarlo en septiembre. El diagnóstico fue que next/image volvía a codificar cada variante de imagen una vez por minuto, y la solución fue de ajuste: una caché de 30 días, un solo hilo de libvips, MALLOC_ARENA_MAX=2 y un tope al heap. Ayudó, bajó el promedio de unos 1.25 GB a 0.99 GB, pero cada uno de esos ajustes era código agregado para conservar un componente que nunca habíamos cuestionado.

El primer peldaño hace la pregunta que nos habíamos saltado: ¿tiene que existir el optimizador en tiempo de ejecución? Contamos lo que estaba optimizando. Todas las imágenes del sitio salen de /public. Eran 47 archivos WebP, ninguno de más de 1440 píxeles de ancho y 2.2 MB en total, más seis PNG que sí se usaban. Nada de eso necesita volver a codificarse en el servidor, en cada despliegue, con una biblioteca nativa que se queda con su memoria.

El cambio fue borrar. Los ajustes salieron de next.config.ts y entró una sola opción:

images: {
  // Add new images to /public as WebP sized for their largest display.
  // shortcut: no srcset, so phones get the desktop-sized file; turn the
  // optimizer back on if /public gains large photos.
  unoptimized: true,
},

Los seis PNG se convirtieron a WebP una sola vez, en una laptop, con el sharp que ya estaba instalado. El logo era un PNG de 6345 píxeles de ancho y 164 KB que se dibuja a 30 píxeles de alto. Como WebP de 96 píxeles de alto pesa 10 KB. El ícono de la app pasó de 281 KB a 6 KB, y las cuatro capturas de la app de unos 180 KB cada una a unos 40 KB. Los visitantes descargan menos que con el optimizador.

Después compilamos el sitio y recorrimos las 274 páginas de su sitemap. El proceso del servidor quedó en 173 MB en reposo y 197 MB después del recorrido, frente a un pico de 344 MB en la misma prueba con el optimizador ajustado. Hay dos advertencias. Esas cifras se midieron en local, no en Railway, y una ejecución local no reproduce el asignador de memoria de Linux que causó el problema. La cifra de producción es la que lo confirma, y la revisaremos después del despliegue. Aun a 250 MB, la memoria del servicio web cuesta unos $2.50 USD al mes.

5. Lo que nos costó

Ponytail le pide al agente que termine cada trabajo diciendo qué omitió, así que aquí va lo nuestro. Sin el optimizador no hay srcset, así que un teléfono descarga la misma captura de 1440 píxeles que una computadora. Con nuestras imágenes eso son entre 11 y 141 KB, y lo aceptamos. Si el sitio empieza a publicar fotografía pesada, el comentario del atajo dice exactamente cuándo volver a activarlo. Las imágenes nuevas ahora tienen que agregarse como WebP del tamaño correcto, una regla para personas en lugar de una opción en el código.

6. Lo que dice el benchmark, y lo que no

El proyecto publica un benchmark con agentes: Claude Code sin interfaz en 39 tareas, cinco ejecuciones cada una, contra el mismo agente sin la instrucción. Las tareas incluyen tickets de funcionalidad en un repositorio de FastAPI y React, corrección de bugs y casos de seguridad y privacidad. Frente a esa base reporta 53% menos líneas de código, 45% menos tokens de salida, 26% menos costo y 41% menos tiempo. Las verificaciones ocultas de corrección y seguridad pasaron en 97%, contra 96%, y se escribió una prueba donde la lógica la necesitaba en 98% de los casos, contra 68%.

Son promedios de tareas de otra persona. El autor también lo cuida: /ponytail-gain se niega a inventar un ahorro por repositorio, porque la versión que nunca se escribió no tiene un número de líneas. Léelo como lo leemos nosotros. Es una instrucción que empuja al agente hacia la pregunta que haría un revisor senior. No reemplaza a ese revisor, y no reemplaza medir el resultado, que fue la parte de este ejemplo que importó.