Ponytail: l'agente AI che scrive meno codice

Che cos'è Ponytail

Ponytail è un insieme di regole che induce un agente AI per la programmazione a scrivere meno codice. Il progetto si descrive con una frase: "Induce il tuo agente AI a ragionare come lo sviluppatore senior più pigro della stanza. Il codice migliore è quello che non hai mai scritto." È distribuito con licenza MIT. Non include un proprio runtime e non esegue nulla. È testo che viene inserito nelle istruzioni dell'agente, distribuito come skill per gli host che caricano le skill e come semplici file di regole per gli host che non lo fanno.

Il repository è DietrichGebert/ponytail. È stato creato il 12 giugno 2026 e ha superato 90,000 stelle entro il 1 agosto 2026. Il 1 agosto 2026, l'ultima release contrassegnata era v4.8.4, pubblicata il 29 giugno 2026, e la pagina delle release elencava dieci tag tra il 14 e il 29 giugno. Il progetto non ha rallentato: il 17 ottobre 2026 l'ultima release è v5.3.2, pubblicata in tarda serata il 16 ottobre, la terza release di quel giorno dopo v5.3.0 e v5.3.1. Prima erano arrivate v5.2.0 il 13 ottobre, cinque giorni dopo la pubblicazione di v5.0.0 e v5.1.0, entrambe l'8 ottobre; il repository mostra inoltre più di 165,000 stelle. Un progetto che procede a questo ritmo sarà cambiato quando leggerai queste informazioni. Fissa quindi un tag prima di basarci sopra qualsiasi attività di sviluppo.

L’idea prima dello strumento: fermarsi al primo gradino valido

Il nucleo di Ponytail è una scala decisionale. L’agente la percorre prima di scrivere qualsiasi cosa e si ferma al primo gradino valido.

1. È davvero necessario che esista? Questo è YAGNI (non ne avrai bisogno). Se la risposta è no, saltalo.
2. Esiste già in questa codebase? Riutilizza l’helper o il pattern già presente.
3. La libreria standard lo gestisce? Usala.
4. Una funzionalità nativa della piattaforma lo copre? Usala.
5. Una dipendenza già installata risolve il problema? Usala.
6. Può essere una riga? Rendilo una riga.
7. Solo a questo punto, scrivi il minimo codice funzionante.

Questa è la scala così come è definita in v4.8.4, e i numeri dei gradini nel resto di questo articolo seguono questa numerazione. Il branch main attuale unisce i gradini 3 e 4 in uno solo, «Libreria standard o funzionalità della piattaforma? Usala, salvo che il progetto ne abbia una propria», e aggiunge che «un componente del progetto prevale su un widget nativo», quindi i gradini sono sei. L’ordine è lo stesso.

È l’ordine a fare la differenza, non un singolo gradino. Se si chiede a un agente un selettore di date, l’agente scriverà un selettore di date, perché è questo che gli è stato chiesto di fare. La scala gli impone di verificare che cosa esiste già prima di creare qualcosa: il gradino 2 chiede se il repository contiene già un componente adatto, mentre il gradino 4 osserva che il browser dispone già di <input type="date">. Le note del benchmark attuale del progetto riportano esattamente questo caso: un selettore di date che, senza la regola, era arrivato a 335 righe, con Ponytail 5 è arrivato a 10 righe, perché l’agente ha riutilizzato il componente Input del repository con type="date" e ha lasciato al browser la gestione del calendario. Un selettore di colori si è ridotto meno, passando da 135 righe a 26. Il gradino 2 è quello che fallisce senza produrre segnali evidenti, perché un agente che non riesce a vedere l’helper già disponibile scriverà senza esitazione un secondo helper; è proprio questa lacuna che una mappa interrogabile della codebase intende colmare.

Qui «pigro» non significa negligente, e il ruleset lo dichiara esplicitamente. L’elenco di ciò su cui «non essere mai pigri» comprende la comprensione del problema prima di decidere, la convalida degli input ai confini di attendibilità, la gestione degli errori che impedisce la perdita di dati, la sicurezza, l’accessibilità e tutto ciò che è stato richiesto esplicitamente. Chiede inoltre un piccolo controllo eseguibile per ogni componente di logica non banale. La regola limita le invenzioni. Non limita la correttezza.

Cosa contiene realmente il repository

• AGENTS.md, il ruleset sempre attivo, che racchiude l'idea completa in un unico file leggibile in cinque minuti.
• skills/ponytail/SKILL.md, la definizione della skill, con un suggerimento per l'argomento pari a lite, full, ultra o off.
• I file delle regole nelle directory specifiche dell'editor, come .cursor/rules/ e .windsurf/rules/, per gli host che leggono le regole ma non caricano le skill.
• hooks/, benchmarks/, examples/ e scripts/.

L'argomento relativo all'intensità modifica il livello di rigore con cui la regola viene applicata. lite realizza ciò che hai richiesto e indica in una riga un'opzione più permissiva. full è l'impostazione predefinita e applica la sequenza di livelli. ultra è l'impostazione estremista di YAGNI: preferisce eliminare invece di aggiungere e mette in discussione anche il requisito stesso.

Gli host che supportano le skill ricevono anche i comandi slash. /ponytail imposta il livello, /ponytail-review controlla un diff per individuare un'architettura eccessivamente complessa, /ponytail-audit controlla un intero repository, /ponytail-debt raccoglie le scorciatoie che hai rimandato e /ponytail-gain stampa il riepilogo dei punteggi del benchmark. Gli host che leggono soltanto i file delle regole ricevono il ruleset senza comandi. A partire da v5.3.0, rilasciato il 16 October 2026, anche Claude Code mostra una fascia sopra il prompt con il costo dell'attività, il riutilizzo del codice e lo stato dei test. Richiede Claude Code 2.1.290 o versione successiva, non viene visualizzata nel pannello della chat di VS Code, nelle sessioni cloud o in claude -p, e /ponytail band off la nasconde. A partire da v5.3.2, /ponytail band import legge una volta le sessioni precedenti di Claude Code e le aggiunge alla scheda con il relativo costo, il tempo dell'agente e il numero di token, così puoi confrontarle con le sessioni eseguite applicando la regola.

Per leggere il codice sorgente prima di considerarlo affidabile, clona il tag invece del branch. È il tag da cui proviene la sequenza di livelli descritta sopra; sostituiscilo con v5.3.2, l'ultima versione disponibile il 17 October 2026, per leggere il testo corrente:

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

In Claude Code il progetto documenta invece l'installazione di un plugin; queste due righe corrispondono alla documentazione del 17 October 2026:

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

Il percorso del plugin segue il branch predefinito invece di un tag. Di conseguenza, le istruzioni che guidano l'agente possono cambiare tra una sessione e l'altra senza che tu lo rilevi. Questo è il compromesso accettato in cambio della comodità di un comando di aggiornamento.

Perché un agente poco propenso a fare lavoro inutile costa meno su un VPS

La differenza che un agente scrive non esce dalla conversazione. Nel turno successivo fa parte del contesto che il modello legge di nuovo, insieme a ogni file che ha aperto per produrla. Una modifica di 500 righe pesa quindi su tutti i turni successivi della sessione, finché la compattazione non sostituisce i turni precedenti con un riepilogo, non soltanto sul turno che l’ha prodotta. Per questo un refactoring fuori controllo fa sembrare l’agente più lento e meno efficace man mano che la sessione prosegue: la finestra si riempie dell’output dell’agente stesso, quindi diminuisce lo spazio disponibile per il codice effettivo. Gestire questo aspetto è l’intero argomento di gestione della finestra di contesto di un agente di coding.

I token vengono fatturati sia in ingresso sia in uscita. Una differenza grande la metà costa quindi il doppio: una volta quando viene scritta e poi a ogni turno in cui viene riletta. Il risparmio effettivo in fattura dipende dal modello di pagamento, perché un abbonamento Pro o Max assorbe i token aggiuntivi solo entro i propri limiti di utilizzo; oltre tali limiti, i crediti per l’utilizzo attivati dall’utente vengono addebitati separatamente. Con la fatturazione API per token, invece, viene addebitato ogni token. Se controlli i costi su un’installazione self-hosted, il file delle istruzioni è una leva che non costa nulla. Controllare quanto ti costa un agente AI inizia dal volume dell’output, mentre come un agente di coding spende i propri token spiega perché la rilettura incide più di quanto ci si aspetti.

La differenza viene comunque letta da una persona. Una modifica di 400 righe che avrebbe dovuto essere di 20 righe richiede l’attenzione del revisore, e l’attenzione è la risorsa che si esaurisce per prima. Nessuno esamina la quarta differenza lunga della giornata con la stessa cura riservata alla prima. Costruire più del necessario, quindi, non fa solo perdere tempo. Riduce silenziosamente la qualità della revisione che dovrebbe individuare gli errori.

Su un server la situazione cambia, perché spesso l’agente opera senza supervisione. Un agente che lavora in una sessione tmux o tramite un timer può passare ore a sviluppare una decisione errata prima che tu la veda. Questo è il rischio concreto di eseguire un agente di coding su un VPS, ed è il motivo per cui chi pratica l’ingegneria a ciclo continuo dedica tanta attenzione alle istruzioni permanenti, invece che ai singoli prompt. Una regola nel file sempre attivo si applica al turno 200. Una regola digitata nella chat si applica al turno 3. La stessa regola si applica anche alla seconda sessione avviata sullo stesso server: questa legge il file sottoposto a commit, ma non eredita nulla di ciò che hai digitato nella prima, anche quando le due sessioni possono scambiarsi messaggi.

Le nuove dipendenze sono l’altro costo silenzioso. Il livello 5 dice di usare ciò che è già installato. Ogni pacchetto che un agente aggiunge di propria iniziativa è qualcosa che dovrai aggiornare in seguito e che finirà in ogni immagine container che costruisci da quel repository.

Cosa dicono i benchmark pubblicati da Ponytail

Il progetto ha pubblicato due tipi di risultati, che differiscono ampiamente tra loro. Entrambi sono dati pubblicati dal progetto. Nessuno dei due deriva da un test indipendente.

[
  {
    "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
  }
]

Il grafico mostra l'attuale benchmark agentico del progetto, datato 7 ottobre 2026. Sessioni headless di Claude Code 2.1.288 su Opus 5.5, con il livello di effort predefinito, hanno eseguito 39 attività, con cinque esecuzioni per attività e configurazione: 585 sessioni in totale tra no skill, Ponytail v4.13.0 e Ponytail 5. Dodici attività sono feature ticket nel repository full-stack-fastapi-template di tiangolo, un repository reale basato su FastAPI e React; la valutazione si basa sul git diff risultante. Le altre comprendono 18 attività chirurgiche con controlli nascosti, sei richieste per piccole applicazioni e tre richieste "mostrami un esempio". Bash era disabilitato in tutte le configurazioni. Con Ponytail 5, il numero di token generati è diminuito del 45 percento.

Confronta questo risultato con i dati relativi a una singola esecuzione pubblicati dal progetto nel giugno 2026. Erano ottenuti da un modello senza agente che rispondeva a cinque richieste comuni, con e senza la regola, e riportavano le mediane di esecuzioni ripetute. Indicavano dal 80 al 94 percento di codice in meno tra Haiku, Sonnet e Opus, mentre la verifica dei costi del 17 giugno 2026 indicava per Haiku una riduzione del 63 percento. L'attuale risultato agentico per Ponytail 5 è 53 percento di righe di codice in meno, 26 percento di costo in meno e 41 percento di tempo trascorso in meno. Il progetto ha corretto rapidamente il dato relativo a una singola esecuzione. In v4.8.4, il 29 giugno 2026, il README riportava già nel titolo il risultato agentico, "~54% less code (up to 94%)", con una nota secondo cui l'intervallo precedente dall'80 al 94 percento era "il limite massimo per attività, non la media"; inoltre, aveva spostato i dati relativi alla singola esecuzione in una sezione compressa intitolata "Older single-shot numbers". Quella sezione spiegava chiaramente il motivo della differenza: il baseline della singola esecuzione è un modello senza agente che "riempie la risposta con prosa e opzioni", un obiettivo facile da superare. Se il confronto avviene con un agente reale che esegue attività reali, il vantaggio si riduce. Rimane comunque concreto, ed è il dato più utile. Quella esecuzione agentica di giugno, con dodici ticket su Haiku 4.5 e quattro esecuzioni per ciascuno, aveva prodotto un risultato vicino a quello attuale: il 54 percento di righe in meno. Il README attuale non riporta più i dati della singola esecuzione.

Il progetto segnala una precisazione, che determina se questo risultato sia utile nel tuo caso. Il risparmio è maggiore quando esiste un rischio concreto di implementare più del necessario, mentre è quasi nullo per il codice già minimale. La tabella per attività di ottobre lo conferma: in diverse attività chirurgiche, il numero di righe è risultato identico in tutte e tre le configurazioni. Trentotto attività su un solo modello e un solo host, con Bash disabilitato, non consentono di prevedere il comportamento nel tuo repository. Se questo dato è importante per te, esegui il confronto sulle tue attività, con e senza la regola, e conta personalmente le righe.

Il modello che puoi copiare oggi senza installare nulla

La scala è testo, quindi non ti serve il plugin per applicare l'idea. Incolla un blocco come questo nel file di istruzioni che il tuo agente legge già, sia AGENTS.md, CLAUDE.md oppure il file delle regole del tuo 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.

L'ultima regola merita di essere considerata separatamente. La convenzione di Ponytail nelle release attuali consiste in un commento contrassegnato da shortcut:, che indica il limite e quando eseguire l'upgrade (nelle release di giugno, inclusa v4.8.4, era invece contrassegnato da ponytail:):

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

Il commento richiede due righe di lavoro e risolve una domanda che altrimenti costerebbe un ciclo di revisione. Indica al lettore successivo che la versione semplice è stata una scelta consapevole e specifica la condizione che rende tale scelta non più valida. Senza questo commento, un revisore non può distinguere una semplificazione valutata da qualcosa che l'agente ha dimenticato, quindi deve chiedere chiarimenti.

Anche la posizione del blocco è importante quanto il suo contenuto. Un file che l'agente carica a ogni esecuzione influenza ogni esecuzione, comprese quelle che non stai controllando. Questa differenza è l'argomento di scrivere un AGENTS.md che l'agente segua davvero ed è il motivo per cui questo modello deve trovarsi in un file sottoposto a commit, non nella cronologia della shell. In un monorepo deve trovarsi in più di un file sottoposto a commit, perché un AGENTS.md per ogni pacchetto mantiene brevi le regole di ogni directory, invece di costringere l'agente a leggere a ogni esecuzione le convenzioni dell'intero albero. La posizione, però, non offre garanzie; prima di concludere che la scala richieda una formulazione più rigida, conviene capire perché un agente ignora una regola che ha già caricato.

Dove la regola non è più adatta

La scala è pensata per lavorare su una codebase esistente, dove il riuso è generalmente disponibile e generalmente corretto. Si adatta meno a un progetto greenfield, perché il gradino 2 non ha nulla da riutilizzare e il gradino 5 non ha nulla di installato. L’agente può comunque fermarsi al gradino 1, alla libreria standard, a una funzionalità della piattaforma o a una one-liner, ma vengono meno due delle uscite meno costose, quindi più attività arrivano alla scrittura di nuovo codice. Si adatta male anche al momento in cui si desidera davvero l’astrazione. Se stai per aggiungere il quarto chiamante dello stesso blocco copiato, il «diff più breve» ti consegna una quinta copia.

Il livello ultra metterà in discussione i tuoi requisiti. È questo lo scopo del livello, e rappresenta un costo reale quando hai già preso la decisione e vuoi che il lavoro venga eseguito. Usa full per il lavoro ordinario e ricorri a ultra quando sospetti che il problema sia la richiesta di funzionalità.

Nessun blocco di istruzioni può proteggerti da un’interpretazione errata del problema. Il primo punto dello stesso ruleset consiste nel comprendere il codice prima di decidere: è la parte costosa e quella che il testo non può svolgere al posto tuo. Un diff minimo nella funzione sbagliata resta una correzione sbagliata, che ora è semplicemente una correzione sbagliata piccola e facile da approvare.

La sintesi onesta è che Ponytail è un prompt scritto con attenzione, distribuito in modo efficace e corredato di numeri. Nulla al suo interno richiede il plugin. Ciò che offre il progetto è che qualcuno ha scritto correttamente l’elenco, lo ha testato su un repository reale e ha pubblicato il metodo insieme al risultato.

FAQ

Ponytail funziona con agenti diversi da Claude Code?

Sì. Viene distribuito come skill per gli host che caricano le skill, tra cui Claude Code, Codex, OpenCode, Gemini e diversi altri elencati nel README. Gli editor che leggono i file delle regole ma non caricano le skill, come Cursor, Windsurf, Cline e Copilot, usano il ruleset sempre attivo dalla directory delle regole corrispondente e non dispongono dei comandi slash. Il testo è lo stesso in entrambi i casi. La differenza effettiva è se l'host mantiene quel testo nel contesto a ogni turno oppure soltanto quando viene attivata una skill.

Un agente pigro salterà i test, la validazione o i controlli di sicurezza?

No, e il ruleset lo dichiara direttamente. L'elenco "never lazy about" include la validazione degli input ai confini di attendibilità, la gestione degli errori che previene la perdita di dati, la sicurezza e l'accessibilità. Inoltre richiede un piccolo controllo eseguibile per ogni componente di logica non banale. La regola rimuove le strutture inventate: astrazioni che nessuno ha richiesto e dipendenze che nessuno deve usare. Se l'agente inizia a eliminare i test dopo l'installazione, la causa è un'altra istruzione nella configurazione che ha precedenza su questa. Leggete quindi il file caricato per ultimo dall'agente.

I valori pubblicati relativi a velocità e costi sono attendibili?

Sono misurazioni del progetto, pubblicate insieme al relativo metodo, e devono essere interpretate in questo senso. I dati del test singolo di June 2026 sono stati confrontati con un modello privo di regole che rendeva la risposta più lunga aggiungendo testo e opzioni. Il README dell'epoca indicava già questo modello come una baseline debole. I dati agentic attuali provengono da sessioni headless di Claude Code su Opus 5.5: 39 task con cinque esecuzioni ciascuno, di cui dodici feature ticket in un unico repository FastAPI e React. Sono numeri attendibili per quella configurazione. Non costituiscono una previsione per il vostro codebase, perché i risultati del progetto per singolo task mostrano che il risparmio tende a zero sul codice che era già minimale.

Devo installare qualcosa per ottenere il beneficio?

No. La ladder è testo, e incollare un blocco equivalente nel file delle istruzioni già letto dall'agente produce gran parte dell'effetto. Il plugin fornisce il testo aggiornato, i livelli di intensità, i comandi di revisione e un percorso di aggiornamento. Provare prima il blocco copiato è la risposta di rung 1 alla domanda se sia effettivamente necessaria l'installazione.

Come posso impedire a un agente non presidiato di costruire troppo durante la notte?

Inserite la regola nel file delle istruzioni sempre attive invece che in un messaggio della chat. In questo modo si applica al turno 200 di un'esecuzione lunga e non soltanto al turno 3. Limitate poi separatamente i danni: fornite all'agente un checkout che possa danneggiare invece dell'unica copia disponibile e richiedete una revisione umana del diff prima di qualsiasi merge. Una regola per diff minimi riduce la quantità di codice da leggere. Non decide quali modifiche entrano nel progetto, e non dovrebbe farlo.