Sì, ponytail fa scrivere meno codice agli agenti AI — ma quasi tutto il merito è di YAGNI, un principio degli anni '90. L'ho verificato con 48 run indipendenti su Claude Code, due modelli e giudici ciechi: su un modello forte è quasi solo formattazione in meno, su uno economico evita over-engineering vero. Il mio -33% medio coincide con quello di un banale prompt «YAGNI» di sette parole.
ponytail è il fenomeno open-source del momento: 54.500 stelle su GitHub in pochi giorni, licenza MIT, e un'idea semplice. È un plugin comportamentale per agenti di coding — Claude Code, Codex, Cursor, Cline, Aider e altri 14 in tutto — che, prima di far scrivere una riga nuova, obbliga l'agente a salire una «scala della pigrizia»: serve davvero (YAGNI)? lo fa la standard library? una feature nativa? una dipendenza già installata? si fa in una riga? E solo allora scrivere il minimo. Non tocca il modello e non gira in locale: nel cuore è un file SKILL.md di un centinaio di righe.
La promessa che ha fatto il giro è forte: circa -54% di codice (fino al 94% negli scenari di over-engineering), -22% di token, -20% di costo, -27% di tempo, e «100% safe». Numeri auto-dichiarati. Mi sembrava il caso di verificarli in modo indipendente — non con un colpo fortunato, ma con un banco ripetibile e la varianza in chiaro. È lo stesso spirito con cui ho misurato quanto risparmia davvero Headroom invece di fidarmi della brochure.
La storia vera dietro il -54%
Vale la pena raccontarla, perché è più interessante del numero. La prima versione del benchmark di ponytail era single-shot — un prompt, una risposta, conta le righe — e dichiarava un taglio dell'80-94%. A giugno 2026 Colin Eberhardt, CTO di Scott Logic, l'ha smontata: quel vantaggio era in gran parte un artefatto del confronto, perché il modello «nudo» riempie la risposta di prosa e di opzioni alternative, gonfiando il conteggio. Eberhardt ha mostrato che bastava scrivere «Follow YAGNI principles» (tre parole) per quasi pareggiare ponytail, e che la versione di sette parole lo batteva, mantenendo il 100% di correttezza. Il suo verdetto: ponytail cavalca l'onda dell'hype più che innovare.
Qui arriva la parte che fa onore all'autore: invece di difendersi, ha
Quanto grande può essere un'AI in locale? Il limite della VRAM sui 16GB
Nei primi due articoli della serie abbiamo installato LM Studio e misurato quanto corre sul mio portatile RTX 5080 16GB. Poi, nel primo bonus, abbiamo visto quanto costa la *memoria* del modello — il contesto. Oggi il secondo dei tre bonus in cui spingo la scheda al limite lungo
usa sessioni agentiche reali (Claude Code headless su un vero repo FastAPI + React), git diff come metro, e — onestamente — include il prompt YAGNI di sette parole come braccio di controllo. È lì che nasce il -54% «buono»: su
Haiku 4.5
, n=4, dodici feature task. E ammette il caveat che conta: il taglio è enorme dove c'è una vera trappola di over-engineering (un date picker passa da 404 a 23 righe), e vicino a zero dove il codice è già minimale.
Due cose saltano all'occhio. Primo: il -54% è misurato su un modello economico e su task scelti pieni di trappole. Secondo: nello stesso benchmark, il prompt YAGNI di sette parole da solo fa -33%. Ponytail lo supera, ma il grosso del risparmio è l'idea YAGNI, non il plugin. Tienili a mente: il mio test indipendente ci ricasca esattamente sopra.
Come ho costruito il mio banco di prova
Quattro task piccoli ma scelti dove l'over-engineering si vede: sommare una colonna di un CSV, fare uno slugify, scrivere un debounce in JavaScript, aggiungere un flag --verbose a una mini CLI. Ognuno parte da uno stub identico in una cartella git isolata. Per ogni task ho confrontato due bracci: «baseline» (consegna nuda) e «ponytail» (stessa consegna col testo reale della scala della pigrizia anteposto). Stesso task, stesso modello, stessa partenza: l'unica variabile è il ruleset.
Tre ripetizioni per combinazione, due modelli — Claude Sonnet come agente «capace» e Claude Haiku come agente «economico» — per 48 generazioni totali. Le metriche non me le sono fatte raccontare: righe misurate con git diff, dipendenze rilevate dagli import, e un check di correttezza e un probe di sicurezza eseguiti per davvero su ogni soluzione. In più un giudice cieco indipendente (Claude Opus) ha valutato le coppie anonime sul grado di over-engineering. Un caveat di onestà: così provo il ruleset di ponytail, non il pacchetto completo coi suoi comandi /ponytail-review. Ma la leva che produce «meno codice» è proprio quel ruleset.
Modello forte: il -33% c'è, ma è quasi solo cosmesi
Sul modello capace la riduzione è netta e con varianza bassissima: -33% di righe scritte, -17% di LOC. Poi guardi il codice e capisci che non è quella la storia. Le trappole non sono scattate quasi mai: in nessuna delle 24 run qualcuno ha tirato dentro pandas per un CSV, lodash per un debounce o un framework di config per un flag. Lo slugify usa lo stesso identico algoritmo nei due bracci; il debounce pure. La differenza è quasi tutta commenti riga-per-riga e formattazione: il baseline spiega ogni passo, ponytail accorpa e taglia. Stessa correttezza (12 su 12 in entrambi), zero regressioni di sicurezza, zero dipendenze inutili.
Il giudice cieco conferma: nessuno dei due bracci è over-ingegnerizzato in senso vero (1,5 il baseline contro 1,0 ponytail, dove 1 è ideale), e ponytail è giudicato più pulito in 4 coppie su 6 e mai peggiore. Su un buon agente, insomma, la scala della pigrizia è un linter di stile gentile: utile, marginale.
Modello economico: qui le trappole scattano davvero
Su Haiku la musica cambia. La percentuale è la stessa (-33% di righe), ma i numeri assoluti sono molto più grandi, perché il baseline economico è più prolisso e variabile: sul CSV oscilla tra 13 e 26 righe a seconda della run, ponytail tra 5 e 16. Su quel task la riduzione tocca il -52,6% — praticamente il -54% del vendor, ritrovato in modo indipendente proprio dove lui lo misura: modello debole, task-trappola.
E qui l'over-engineering è reale. Due baseline su tre, per sommare una colonna, si sono messi a scrivere un parser CSV a mano. Lo stesso task, lo stesso stub, due mondi:
python
def sum_column(csv_text, column):
lines = csv_text.strip().split('\n')
if not lines:
return 0
headers = lines[0].split(',')
try:
col_index = headers.index(column)
except ValueError:
raise ValueError(f"Column '{column}' not found in CSV headers")
total = 0
for line in lines[1:]:
if line.strip():
values = line.split(',')
if col_index < len(values):
try:
total += float(values[col_index])
except ValueError:
pass
return total
python
import csv
from io import StringIO
def sum_column(csv_text, column):
reader = csv.DictReader(StringIO(csv_text))
return sum(float(row[column]) for row in reader)
Non è solo più lungo: è più fragile. Il giudice cieco ha bollato la versione fatta a mano come la più over-ingegnerizzata (3 contro 1), notando che il split(',') ingenuo si rompe sui campi tra virgolette — un bug che csv.DictReader non ha. Più codice, meno robustezza.
Dati: benchmark indipendente homelabz.cc — 48 run, baseline vs ponytail
La sicurezza, e perché eseguo il codice invece di crederci
La claim «100% safe» merita un test a sé, perché il timore ovvio è che «scrivi meno codice» significhi «salta la validazione». Sui miei task è successo il contrario. L'unica regressione di sicurezza di tutto il banco — 48 run — è venuta da un baseline, non da ponytail: su Haiku, una soluzione del CSV ha avvolto il parsing in un try/except: pass dall'aria difensiva che però inghiottiva proprio l'errore della colonna mancante, restituendo zero invece di sollevare. Il braccio ponytail, più corto, lasciava emergere l'errore. È coerente col benchmark del vendor, dove ponytail tiene la sicurezza su 20 task su 20 mentre il prompt YAGNI «nudo» ne sbaglia uno: è proprio lì che ponytail aggiunge qualcosa rispetto al semplice «sii pigro».
Verdetto onesto: è YAGNI confezionato bene (e non è un insulto)
Mettendo insieme i numeri esce un quadro chiaro. Il mio -33% medio coincide con il braccio «YAGNI in sette parole» del benchmark ufficiale e con la tesi di Eberhardt: ho misurato il ruleset, e il ruleset è essenzialmente YAGNI. Il -54% del vendor è vero ma stretto — modello Haiku, n=4, task pieni di trappole — e più alto del mio perché il suo mix ha più over-build, mentre il mio include task già minimali dove, come dice lui stesso, il guadagno è zero. Su un modello forte come Sonnet il vantaggio si riduce a cosmesi.
Questo non rende ponytail inutile, lo ridimensiona. Buona parte del beneficio la ottieni scrivendo «Follow YAGNI principles, prefer one-liners» nel tuo system prompt. Quello che ponytail aggiunge è confezionamento: la stessa disciplina applicata in modo coerente su 14 agenti diversi, un floor di sicurezza che il prompt nudo non garantisce, comandi di review, il tutto gratis, MIT, installabile in una riga. E va detto a favore dell'autore: ha rifatto un benchmark sbagliato dopo una critica pubblica, cosa rara. Se fai girare flotte di agenti su modelli piccoli per contenere i costi — la stessa logica del quale quantizzazione scaricare per stare nel budget — è lì che si ripaga, perché è lì che gli agenti strafanno.
In 48 run ponytail non ha mai peggiorato correttezza né sicurezza, non ha mai imposto dipendenze, ed è costato zero da provare: per un plugin del genere il rapporto rischio/beneficio resta ottimo, basta regolare le aspettative sul modello che usi. Se questo tipo di verifica indipendente ti piace, è lo stesso metodo con cui ho smontato l'idea che servano modelli enormi nel test su Gemma 3 270M: misurare, ripetere, mostrare la varianza, ed eseguire sempre il codice.
Domande frequenti
Che cos'è ponytail e come si installa?
È un plugin che fa scrivere meno codice agli agenti di coding (Claude Code, Codex, Cursor, Cline, Aider e altri) iniettando una «scala della pigrizia» basata su YAGNI nel loro contesto. Su Claude Code si aggiunge con /plugin marketplace add DietrichGebert/ponytail. Non è un modello e non gira in locale: è un ruleset comportamentale di un centinaio di righe, licenza MIT.
ponytail fa davvero scrivere il 54% di codice in meno?
Dipende dal modello e dai task. Il -54% del vendor è misurato su Claude Haiku 4.5, n=4, su task scelti pieni di trappole di over-engineering; sul codice già minimale il guadagno è vicino a zero. Nel mio test indipendente la media è -33% di righe, che sale a -52,6% proprio sul task-trappola con un modello economico, e scende a cosmesi su un modello forte.
Non basta scrivere «YAGNI» nel system prompt?
Quasi. Sia la critica di Scott Logic sia il braccio di controllo del benchmark ufficiale mostrano che un prompt YAGNI di sette parole ottiene gran parte del risultato (-33%), e il mio test lo conferma. Quello che ponytail aggiunge è disciplina coerente su molti agenti diversi e un floor di sicurezza migliore del prompt nudo (100% contro 95% sui task di sicurezza).
Conviene su un modello forte o su uno economico?
Soprattutto su quelli economici. Su un modello capace l'effetto è quasi solo formattazione e commenti in meno; su un modello piccolo e prolisso evita over-engineering reale, codice fragile fatto a mano e qualche bug. Se fai girare agenti su modelli piccoli per contenere i costi, è lì che rende di più.
