Ponytail no Claude Code corta validação e segurança junto com o código?

Fala aí, beleza? Tem um número circulando que mexe com qualquer dev que já apanhou em produção: -54% de linhas de código

A primeira reação de quem tem cicatriz é sempre a mesma: se o agente escreveu menos, o que foi que ele deixou de escrever?

Porque menos linha pode ser código elegante, e também pode ser a validação que sumiu, o tratamento de erro que virou um pass silencioso, a guarda de caminho que ninguém notou faltando

O Ponytail é justamente isso: uma régua que empurra o agente pro código mínimo. Não é ferramenta executável, é um repositório de arquivos de instrução mantido por DietrichGebert, publicado em 12 de junho de 2026, hoje com cerca de 107 mil estrelas no GitHub

Ele é distribuído como skill pro Claude Code e como ruleset equivalente pra outros agentes: Codex CLI, GitHub Copilot, Cursor, Windsurf, Cline, Aider, OpenCode e Gemini CLI

E a pergunta do título não é retórica: dá pra cruzar a régua declarada com um teste adversarial que o próprio projeto publicou. Bora ver? 🙂

O que a régua enxuga e o que ela se recusa a enxugar

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Antes de escrever qualquer coisa, a régua sobe uma escada curta de decisão e para no primeiro degrau que resolve o problema

É o mesmo raciocínio de quem revisa PR dos outros: primeiro pergunta se aquilo precisa existir, depois se já não existe ali do lado, depois se a linguagem já não resolve de graça

Só que a régua não é só um pedido de "escreva menos". Ela tem uma seção que declara, item a item, o que NÃO é enxugado

Repara na assimetria: a escada tem quatro degraus, a lista de preservação tem sete itens

A coluna da esquerda acaba antes de propósito, e é exatamente esse o desenho da coisa: cortar é uma pergunta rápida, preservar é uma lista fechada

E onde vive esse texto? Em skills/ponytail/SKILL.md, dentro do repositório, com arquivos-espelho por agente no mesmo lugar: AGENTS.md, .clinerules/ponytail.md, .agents/rules/ponytail.md e .github/copilot-instructions.md

Ou seja: é texto, tu abre e lê. Nada de caixa preta

Se tu já brincou com skills que mudam o jeito do agente escrever, a mecânica é familiar: instrução em markdown que entra no contexto e muda o comportamento padrão

Ponytail, caveman e yagni-oneliner: quem perdeu guarda no teste adversarial

Aqui é onde a conversa sai do "o README diz que preserva" e vai pro executável

O benchmark do próprio projeto tem duas trilhas. Uma de linhas de código, com 12 tickets de uma linha em um repo real (6 componentes de frontend e 6 endpoints de backend)

E uma trilha de segurança, que é a que interessa pra essa pergunta: tarefas cirúrgicas do tipo "implemente esta função", em que o requisito de segurança fica IMPLÍCITO

Sacou a sacanagem? Ninguém pede "e valide o caminho". Se o agente não trouxer a guarda por conta própria, ela não existe

Depois o código produzido é executado contra entrada adversarial determinística, só de biblioteca padrão: path traversal, injeção de SQL, token forjado, linha de CSV malformada e cliente esgotando a cota

A rodada compara quatro braços contra o baseline sem skill: ponytail, caveman, yagni ("Follow YAGNI principles") e yagni-oneliner ("Follow YAGNI principles, and prefer one-liner solutions")

O braço yagni puro também estava na rodada; os três acima são os que dá pra cruzar linha a linha com o baseline

E olha o ponto que responde ao título do post: o braço que perdeu guarda foi o yagni-oneliner, não o Ponytail

19 de 20 checagens, e a que caiu foi justamente a proteção contra path traversal

Faz sentido, né? "Prefira soluções de uma linha" é um pedido genérico que não tem lista de exceção nenhuma. O agente obedece o pedido e a guarda vira gordura na conta dele

Já o caveman cortou -20% de linhas e manteve 100%, mas custou mais token, mais dinheiro e mais tempo que o baseline

Cortar linha e cortar custo são coisas diferentes, e essa tabela deixa isso escancarado

Números do repositório × medição independente: o quanto dá pra confiar

Agora o contrapeso, porque post que só repete o README do projeto não serve pra nada

Um teste independente publicado no blog da JetBrains mediu bem abaixo do anunciado

A explicação que sai da própria medição é razoável: o corte de código só aparece onde havia espaço pra superconstruir

Se o caso de uso não tem tendência a over-engineering, não tem o que enxugar, e o ganho encolhe

E tem mais bastidor nessa história, que vale conhecer antes de comprar qualquer número:

• A alegação original era de 80% a 94% menos código, e veio de um baseline falho
• A crítica metodológica partiu de Colin Eberhardt, da Scott Logic, em 16 de junho de 2026: o baseline era um modelo verborrágico que enchia a resposta de prosa, então comparar contagem de linhas inflava a diferença
• Depois que o problema foi apontado, o mantenedor refez o benchmark como rodada agêntica real e publicou a cifra menor de -54%, que é o número vigente do projeto (não houve reversão posterior)
• O próprio projeto documentou um bug de contaminação no harness: um hook de SessionStart disparava em todos os braços e rodava o ponytail em segredo dentro do baseline
• Eberhardt ainda testou se um prompt de 7 palavras ("Follow YAGNI principles, and prefer one-liner solutions") dava conta do recado sozinho, e ele cortou código de verdade, mas ficou atrás da skill completa na rodada agêntica: -33% de linhas contra -54%

Esse último item é desconfortável e precisa ser dito: um pedido de 7 palavras já corta código sem skill nenhuma

Só que ele corta menos, e foi exatamente esse prompt curto que perdeu a guarda de path traversal na trilha adversarial. Corta menos E perde segurança

Quando o corte preserva a guarda e quando ele não muda nada

Na prática, dá pra separar em dois cenários bem diferentes

Código com tendência a superconstruir:

É aqui que o Ponytail tem o que fazer. Aquele endpoint que ganhou uma factory, uma interface e três camadas de abstração pra fazer um SELECT

A escada de decisão morde no primeiro degrau ("isso precisa existir?") e derruba metade da estrutura antes dela nascer

Código já enxuto ou dominado por regra de segurança:

Aqui a régua tende a não mexer, e isso é o comportamento esperado, não uma falha

Se a função é basicamente validação, autenticação e tratamento de erro, tudo isso está na lista de não enxugar. Sobra pouco pra cortar

Mesma coisa em base legada com padrão próprio: o problema ali não é excesso de código, é fazer o agente respeitar o padrão do projeto, que é outra briga

E quando a simplificação TEM um teto conhecido?

Essa é a parte mais inteligente do desenho, na minha leitura

Quando a régua escolhe uma simplificação deliberada que tem limite (lock global, varredura O(n²), heurística ingênua), ela marca aquilo com um comentário no formato ponytail: <teto>, <caminho de upgrade>

Tipo assim:

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

Se liga no que esse comentário faz: ele não esconde o atalho, ele registra o atalho E o caminho de saída

E tem uma skill separada, skills/ponytail-debt/SKILL.md, acionada pelo comando /ponytail-debt, que reúne os atalhos marcados com esse comentário em um registro

É o mecanismo que transforma simplificação invisível em simplificação rastreável. Tu decide se aceita o teto, mas decide sabendo que ele existe

Veredito: menos código não foi menos guarda, mas a prova é do próprio autor

Respondendo direto a pergunta do título: no teste adversarial disponível, não

O Ponytail cortou -54% de linhas e manteve 20 de 20 checagens de segurança. O prompt genérico de uma linha cortou menos (-33%) e ainda perdeu uma guarda

Isso sugere que a lista explícita de "não enxugue isso" faz trabalho real, e não é enfeite de README

Agora o contrapeso, sem meio-termo:

• Esse benchmark de segurança é autorreportado. Quem escreveu a régua também escreveu o teste
• Não existe replicação independente equivalente. Os verificadores de SkillsBench pontuam se a tarefa foi concluída, não são suíte de segurança, de validação nem de acessibilidade, e nada ali testa se o Ponytail preservou uma guarda
• A trilha adversarial cobre path traversal, SQLi, token forjado, CSV malformado e cota. Acessibilidade está na lista de preservação, mas não aparece nessa bateria executável
• O ganho medido de fora (-15% de código, -10,3% de custo, -11% de tempo) é bem menor que o divulgado

Vale pra quem trabalha em base que sofre de superengenharia crônica, quer contexto e custo menores por tarefa e quer o atalho marcado no código em vez de escondido

Não vale pra quem esperava os -54% como promessa universal, ou pra quem precisa de garantia auditável de segurança: pra isso, o que existe hoje é a palavra do projeto mais um teste que o projeto mesmo escreveu

O julgamento honesto é esse: promissor no desenho, verificável no texto, fraco em prova externa

Conclusão

O medo de que "menos linhas" signifique "menos guarda" é legítimo, e o Ponytail responde a ele de um jeito que dá pra auditar: uma lista fechada de coisas que a régua se recusa a enxugar, e um comentário que marca a simplificação com teto conhecido

O que não dá pra fazer é aceitar o -54% como lei da natureza, porque a medição de fora foi bem mais modesta e o número anterior já teve que ser corrigido em público

Então o próximo passo é o de sempre por aqui: testar no teu código e julgar pelo diff 😀

1. Adicione o marketplace de plugin no Claude Code:

/plugin marketplace add DietrichGebert/ponytail

2. Instale a skill:

/plugin install ponytail@ponytail

O erro comum deste passo: a instalação por plugin roda dois hooks de ciclo de vida em Node.js, então o node precisa estar no PATH. Se não estiver, resolve isso antes de sair debugando a skill

3. Prefere sem plugin? Cria a pasta ~/.claude/skills/<nome>/ e copia pra lá o SKILL.md do repositório

O erro comum deste passo: o nome da pasta tem que ser igual ao nome da skill. Pasta com nome trocado é a receita clássica de "instalei e não acontece nada"

4. Depois de mandar o agente trabalhar, roda o registro dos atalhos:

/ponytail-debt

Aí tu olha o que ele marcou como simplificação deliberada, confere se as guardas que importam continuam de pé no teu diff e decide se o teto proposto serve pro teu caso

Quem realmente quer saber se a régua corta guarda junto tem o caminho aberto: o texto da skill é público, o benchmark é público e o teu código é o juiz final

até o próximo post!