Ponytail: l’agente senior che scrive meno codice

Che cos'è Ponytail

Ponytail è un insieme di regole che induce un agente di coding basato sull'IA a scrivere meno codice. Il progetto si descrive con una sola frase: «Induce il tuo agente IA a ragionare come lo sviluppatore senior più pigro della stanza. Il codice migliore è quello che non hai mai scritto». È distribuito con licenza MIT. Non dispone di un proprio runtime e al suo interno non viene eseguito nulla. È testo 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 le supportano.

Il repository è DietrichGebert/ponytail. È stato creato il 12 giugno 2026 e ha superato 90,000 stelle entro il 1 agosto 2026. L'ultima release contrassegnata disponibile il 1 agosto 2026 è v4.8.4, pubblicata il 29 giugno 2026; la pagina delle release elenca dieci tag soltanto tra il 14 e il 29 giugno. Un progetto che evolve a questo ritmo sarà probabilmente cambiato quando leggerai queste informazioni. Imposta quindi un tag preciso prima di costruirci sopra qualsiasi componente.

L’idea prima dello strumento: fermarsi al primo livello applicabile

Il principio alla base di Ponytail è una sequenza decisionale. L’agente la percorre prima di scrivere qualsiasi cosa e si ferma al primo livello applicabile.

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

È l’ordine a fare la differenza, non un singolo livello. Se chiedi a un agente di creare un date picker, scriverà un date picker, perché è quello che gli hai chiesto di fare. La sequenza lo obbliga a controllare prima il livello 4, che indica che il browser dispone già di <input type="date">. Le note del benchmark del progetto riportano esattamente questo caso: un date picker che senza questa regola raggiungeva 404 righe si è ridotto a 23 righe applicandola, perché l’agente ha usato l’input nativo invece di creare un componente. Per lo stesso motivo, un colour picker è passato da 287 righe a 23. Il livello 2 è quello che fallisce senza segnali evidenti, perché un agente che non riesce a vedere l’helper già disponibile scriverà senza problemi un secondo helper. È proprio questa lacuna che una mappa interrogabile del tuo codebase mira a colmare.

In questo contesto, essere pigri non significa lavorare senza attenzione, e il ruleset lo dichiara esplicitamente. L’elenco di ciò su cui non bisogna mai essere pigri comprende la comprensione del problema prima di decidere, la validazione degli input ai confini di attendibilità, la gestione degli errori per prevenire la perdita di dati, la sicurezza, l’accessibilità e tutto ciò che è stato richiesto esplicitamente. Il ruleset richiede inoltre un piccolo controllo eseguibile per ogni componente di logica non banale. La regola limita ciò che viene inventato. Non limita la correttezza.

Cosa include realmente il repository

• AGENTS.md, il ruleset sempre attivo, che raccoglie l’intera idea 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 o ultra.
• File delle regole nelle directory specifiche dell’editor, ad esempio .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 quanto rigorosamente viene applicata la regola. lite implementa ciò che hai richiesto e indica in una riga un’opzione meno rigorosa. full è l’impostazione predefinita e applica la progressione. ultra è l’impostazione più radicalmente orientata a YAGNI: preferisce rimuovere anziché aggiungere e mette in discussione anche il requisito.

Gli host che supportano le skill ricevono anche i comandi slash. /ponytail imposta il livello, /ponytail-review controlla un diff per individuare l’over-engineering, /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.

Per leggere il codice sorgente prima di considerarlo attendibile, clona il tag invece del branch:

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

Claude Code documenta invece l’installazione di un plugin; le due righe seguenti sono quelle documentate al 1 agosto 2026:

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

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

Perché un agente poco incline ad agire costa meno su un VPS

Il diff prodotto da un agente non esce dalla conversazione. Nel turno successivo diventa contesto che il modello deve rileggere, insieme a ogni file aperto per generarlo. Una modifica di 500 righe grava quindi su ogni turno successivo della sessione, non solo su quello in cui è stata prodotta. Per questo un refactoring fuori controllo fa sembrare l'agente più lento e meno efficace man mano che la sessione prosegue: la finestra di contesto si riempie dell'output dell'agente e resta meno spazio per il codice effettivo. Gestire questo aspetto è l'obiettivo di gestire la finestra di contesto di un agente di coding.

I token vengono conteggiati sia in ingresso sia in uscita. Un diff grande la metà costa quindi due volte meno: una volta quando viene scritto e di nuovo a ogni turno in cui viene riletto. Il risparmio si riflette effettivamente sulla fattura in base al modello di pagamento, perché un abbonamento Pro o Max a tariffa fissa assorbe i token aggiuntivi, mentre la fatturazione API per token addebita ciascun token. Se controlli i costi di un'installazione self-hosted, il file delle istruzioni è una leva che non costa nulla. Controllare quanto costa un agente AI inizia dal volume dell'output, mentre come un agente di coding utilizza i token spiega perché la rilettura incide più di quanto ci si aspetti.

Il diff viene comunque letto da una persona. Una modifica di 400 righe che avrebbe dovuto contenerne 20 consuma l'attenzione di chi esegue la revisione, e l'attenzione è la risorsa che si esaurisce per prima. Nessuno esamina il quarto diff lungo della giornata con la stessa cura riservata al primo. Costruire più del necessario non fa quindi solo perdere tempo. Riduce gradualmente la qualità della revisione incaricata di individuare gli errori.

Su un server la situazione è diversa, perché spesso l'agente opera senza supervisione. Un agente attivo in una sessione tmux o eseguito tramite un timer ha ore per sviluppare una decisione errata prima che tu possa accorgertene. 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 host: questa legge il file versionato, 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 nascosto. Il livello 5 dice di usare ciò che è già installato. Ogni pacchetto aggiunto autonomamente da un agente è qualcosa che dovrai aggiornare in seguito e che finirà in ogni immagine container costruita da quel repository.

Cosa indicano i benchmark pubblicati da Ponytail

Il progetto pubblica due serie di risultati, che differiscono ampiamente. Entrambe riportano dati pubblicati dal progetto stesso. Nessuna delle due è un test indipendente.

[
  {
    "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 colonna single shot deriva da un modello senza agent che risponde a un piccolo insieme di prompt, con e senza la regola, usando le mediane di esecuzioni ripetute del 13 e 17 giugno 2026. La colonna agentic deriva da una sessione headless di Claude Code che modifica full-stack-fastapi-template di tiangolo, un repository reale con FastAPI e React, per dodici ticket di funzionalità, con quattro esecuzioni ciascuno su Haiku 4.5. La valutazione si basa sul git diff lasciato al termine.

Considera la seconda colonna. Il risultato agentic usa 54 percento di righe di codice in meno, ha un costo inferiore del 20 percento e richiede il 27 percento in meno di tempo reale, rispetto rispettivamente al 93 percento e al 74 percento dello scenario single shot. Il README spiega chiaramente il motivo: la baseline single shot è un modello senza agent che "risponde con diverse opzioni e commenti", quindi è facile da superare. Il vantaggio si riduce quando il confronto avviene con un agent reale che svolge attività reali. Il risultato resta comunque significativo, ed è questo il dato più utile.

Il progetto indica anche una limitazione, che determina se questa soluzione può esserti utile. Il risparmio è maggiore quando esiste un rischio concreto di implementazione eccessiva, mentre è quasi nullo per il codice che era già minimale. Dodici ticket in un singolo repository Python e TypeScript non consentono di prevedere i risultati sul tuo repository. Se questo dato è importante per te, esegui il confronto sui tuoi ticket, 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 usare l'idea. Incolla un blocco come questo nel file di istruzioni che il tuo agent legge già, che 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.

Quest'ultima regola merita di essere considerata separatamente. La convenzione di Ponytail consiste in un commento contrassegnato con il nome dello strumento:

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

Il commento richiede due righe di lavoro e risolve una domanda che altrimenti farebbe perdere un ciclo di revisione. Comunica al lettore successivo che la versione semplice è stata una scelta e indica la condizione oltre la quale tale scelta non è più valida. Senza questo commento, un revisore non può distinguere una semplificazione ponderata da qualcosa che l'agent ha dimenticato, quindi deve chiedere chiarimenti.

Dove inserisci il blocco è importante quanto il suo contenuto. Un file che l'agent carica a ogni esecuzione influenza ogni esecuzione, comprese quelle che non stai osservando. Questa differenza è il tema di scrivere un AGENTS.md che l'agent segua davvero, ed è il motivo per cui questo modello deve trovarsi in un file versionato, non nella cronologia della shell. In un monorepo deve trovarsi in più di un file versionato, perché un AGENTS.md per ogni package mantiene brevi le regole di ciascuna directory invece di costringere l'agent a leggere a ogni esecuzione le convenzioni dell'intero albero. La posizione, però, non è una garanzia: prima di concludere che la scala richiede una formulazione più vincolante, è utile capire perché un agent supera una regola che ha già caricato.

Quando la regola non è più corretta

La sequenza è pensata per il lavoro su funzionalità in una base di codice già esistente, dove il riutilizzo è generalmente possibile e corretto. Si adatta male a un progetto greenfield, perché il livello 2 non ha nulla da riutilizzare e al livello 5 non è installato nulla; di conseguenza, l’agente arriva ogni volta al livello 7. Si adatta male anche quando si vuole davvero introdurre un’astrazione. Se si sta per aggiungere il quarto utilizzatore dello stesso blocco copiato, il criterio del «diff più breve» produce una quinta copia.

Il livello ultra metterà in discussione i requisiti. È questo lo scopo del livello, ma rappresenta un costo reale quando la decisione è già stata presa e si vuole semplicemente eseguire il lavoro. Usare full per il lavoro ordinario e ricorrere a ultra quando si sospetta che il problema sia la richiesta di funzionalità.

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

La sintesi corretta è che Ponytail è un prompt scritto con attenzione, distribuito in modo efficace e corredato da numeri. Nulla al suo interno richiede il plugin. Il contributo del progetto consiste nell’aver scritto correttamente l’elenco, averlo verificato su un repository reale e aver 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, applicano il ruleset sempre attivo dalla directory delle regole corrispondente e non dispongono di comandi slash. Il testo è lo stesso in entrambi i casi. La differenza effettiva è quindi se l'host mantiene quel testo nel contesto a ogni turno oppure soltanto quando viene attivata una skill.

Un agente poco diligente può saltare test, convalida o controlli di sicurezza?

No, e il ruleset lo specifica chiaramente. L'elenco "never lazy about" include la convalida degli input ai confini di attendibilità, la gestione degli errori che previene la perdita di dati, la sicurezza e l'accessibilità. Inoltre richiede un controllo eseguibile e di dimensioni ridotte per ogni parte di logica non banale. La regola elimina le strutture inventate: astrazioni che nessuno ha richiesto e dipendenze che nessuno aveva bisogno di aggiungere. Se l'agente inizia a omettere i test dopo l'installazione, la causa è un'altra istruzione nella configurazione personale che ha precedenza su questa. Leggere quindi il file caricato per ultimo dall'agente.

I dati pubblicati su velocità e costi sono attendibili?

Sono misurazioni del progetto, pubblicate insieme al relativo metodo, e vanno interpretate in questo modo. I valori single shot sono confrontati con un modello senza agentic behavior che risponde con opzioni e commenti; lo stesso README lo indica come baseline debole. I valori agentic provengono da una sessione headless di Claude Code su un repository FastAPI e React, con dodici ticket e quattro esecuzioni ciascuno, usando Haiku 4.5. Sono dati attendibili per quella configurazione. Non costituiscono una previsione per il vostro codebase, perché il progetto specifica anche che il risparmio si avvicina a zero sul codice che era già minimale.

Devo installare qualcosa per ottenere il vantaggio?

No. La ladder è testo, e incollare un blocco equivalente nel file delle istruzioni già letto dall'agente produce la maggior parte dell'effetto. Il plugin fornisce il testo mantenuto, i livelli di intensità, i comandi di revisione e una procedura di aggiornamento. Provare prima il blocco copiato è la risposta di rung 1 alla domanda se l'installazione debba esistere affatto.

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

Inserire 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. Limitare poi separatamente i possibili danni: fornire all'agente un checkout che possa danneggiare invece dell'unica copia disponibile e richiedere una revisione umana del diff prima di qualsiasi merge. Una regola che impone un diff minimale riduce la quantità di modifiche da leggere. Non decide quali modifiche verranno applicate, e non dovrebbe farlo.