Ponytail: como fazer o agente escrever menos código
Veja como o Ponytail orienta agentes de codificação a escolher a menor mudança funcional, o que os benchmarks mostram e como aplicar a regra hoje.
O que é o Ponytail
Ponytail é um conjunto de regras que faz um agente de codificação com IA escrever menos código. O projeto se descreve em uma linha: "Faz seu agente de IA pensar como o desenvolvedor sênior mais preguiçoso da equipe. O melhor código é aquele que você nunca escreveu." Ele usa a licença MIT. Não tem runtime próprio, e nada nele é executado. É texto inserido nas instruções do agente, empacotado como uma skill para hosts que carregam skills e como arquivos de regras simples para hosts que não carregam skills.
O repositório é DietrichGebert/ponytail. Ele foi criado em 12 June 2026 e ultrapassou 90,000 stars em 1 August 2026. A versão mais recente marcada em 1 August 2026 é v4.8.4, publicada em 29 June 2026, e a página de releases lista dez tags somente entre 14 e 29 June. Um projeto que avança nesse ritmo terá mudado quando você ler isto. Portanto, fixe uma tag antes de criar qualquer coisa sobre ele.
A ideia antes da ferramenta: pare no primeiro degrau que funcionar
O princípio central do Ponytail é uma escada de decisões. O agente sobe por ela antes de escrever qualquer coisa e para no primeiro degrau que funcionar.
- Isso precisa existir? Este é o princípio YAGNI (você não vai precisar disso). Se a resposta for não, ignore.
- Isso já existe nesta base de código? Reutilize o helper ou o padrão que já existe.
- A biblioteca padrão faz isso? Use-a.
- Um recurso nativo da plataforma resolve isso? Use-o.
- Uma dependência já instalada resolve isso? Use-a.
- Pode ser uma linha? Faça em uma linha.
- Só então, escreva o código mínimo que funcione.
A ordem é o que produz o resultado, não um degrau específico. Um agente solicitado a criar um seletor de data escreverá um seletor de data, porque foi isso que ele recebeu como instrução. A escada faz o agente verificar primeiro o degrau 4, e o degrau 4 informa que o navegador já tem <input type="date">. As próprias notas de benchmark do projeto registram exatamente este caso: um seletor de data que chegou a 404 linhas sem a regra ficou com 23 linhas com ela, porque o agente usou o input nativo em vez de criar um componente. Um seletor de cores caiu de 287 linhas para 23 pelo mesmo motivo.
Ser preguiçoso aqui não significa ser descuidado, e o ruleset afirma isso diretamente. A lista do que nunca deve ser tratado com preguiça inclui entender o problema antes de decidir, validar entradas nos limites de confiança, tratar erros para evitar perda de dados, segurança, acessibilidade e tudo o que foi solicitado explicitamente. Ela também pede uma verificação pequena e executável para cada parte de lógica não trivial. A regra reduz a invenção. Ela não reduz a correção.
O que o repositório realmente fornece
AGENTS.md, o conjunto de regras sempre ativo, que concentra toda a ideia em um arquivo que você consegue ler em cinco minutos.skills/ponytail/SKILL.md, a definição da skill, com uma indicação de argumento delite,fullouultra.- Arquivos de regras em diretórios específicos de editores, como
.cursor/rules/e.windsurf/rules/, para hosts que leem regras, mas não carregam skills. hooks/,benchmarks/,examples/escripts/.
O argumento de intensidade altera o quanto a regra é aplicada. lite cria o que você solicitou e apresenta uma opção mais permissiva em uma linha. full é o padrão e aplica a sequência de níveis. ultra é a configuração extremista do YAGNI: prefere remover a adicionar e questiona o próprio requisito.
Hosts compatíveis com skills também recebem comandos de barra. /ponytail define o nível, /ponytail-review verifica um diff em busca de engenharia excessiva, /ponytail-audit verifica um repositório inteiro, /ponytail-debt reúne os atalhos que você adiou e /ponytail-gain exibe o quadro de resultados do benchmark. Hosts que leem apenas arquivos de regras recebem o conjunto de regras sem comandos.
Para ler o código-fonte antes de confiar nele, clone a tag em vez da branch:
git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.gitNo Claude Code, o projeto documenta uma instalação de plugin. Estas duas linhas estão documentadas em 1 August 2026:
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytailO caminho do plugin segue a branch padrão em vez de uma tag. Por isso, as instruções que orientam seu agente podem mudar entre as sessões. Essa é a troca aceita pela conveniência de um comando de atualização.
Por que um agente econômico é mais barato em um VPS
O diff que um agente escreve não sai da conversa. Na próxima interação, o modelo o lê novamente como contexto, junto com todos os arquivos que abriu para produzi-lo. Portanto, uma alteração de 500 linhas afeta todas as interações seguintes, não apenas a interação que a produziu. É por isso que uma refatoração descontrolada faz um agente parecer mais lento e menos capaz à medida que a sessão avança: a janela se enche com a própria saída do agente, reduzindo o espaço disponível para o código que realmente importa. Manter isso sob controle é o assunto de gerenciar a janela de contexto de um agente de programação.
Os tokens são cobrados tanto na entrada quanto na saída. Portanto, um diff com metade do tamanho custa menos duas vezes: uma vez quando é escrito e novamente em cada interação que o relê. Se você acompanha a cobrança em uma configuração auto-hospedada, o arquivo de instruções é uma alavanca que não custa nada usar. Controlar quanto um agente de IA custa começa pelo volume da saída, e como um agente de programação gasta seus tokens explica por que a releitura importa mais do que as pessoas esperam.
Uma pessoa ainda precisa ler o diff. Uma alteração de 400 linhas que deveria ter 20 linhas consome a atenção de quem faz a revisão, e a atenção é o recurso que se esgota primeiro. Ninguém revisa o quarto diff longo do dia com o mesmo cuidado dedicado ao primeiro. Portanto, construir mais do que o necessário não apenas desperdiça tempo. Isso reduz silenciosamente a qualidade da revisão que deveria detectar os erros.
Em um servidor, os riscos são maiores, porque o agente costuma executar sem supervisão. Um agente trabalhando em uma sessão do tmux ou em um temporizador tem horas para desenvolver uma decisão ruim antes que você a veja. Esse é o risco prático de executar um agente de programação em um VPS, e é por isso que as pessoas que trabalham com engenharia de loops dedicam tanto cuidado às instruções permanentes, em vez de se concentrarem em prompts individuais. Uma regra no arquivo sempre ativo se aplica à interação 200. Uma regra digitada no chat se aplica à interação 3.
Novas dependências são o outro custo silencioso. A regra 5 diz para usar o que já está instalado. Cada pacote que um agente adiciona por iniciativa própria é algo que você terá de atualizar e corrigir depois, além de acabar incluído em toda imagem de contêiner criada a partir desse repositório.
O que os próprios números de benchmark do Ponytail mostram
O projeto publica dois conjuntos de resultados, e eles divergem bastante. Ambos são números publicados pelo próprio projeto. Nenhum deles é um teste independente.
The data behind this chart
[
{
"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
}
]A coluna de execução única vem de um modelo básico respondendo a um pequeno conjunto de prompts, com e sem a regra, calculada como a mediana de execuções repetidas realizadas em 13 e 17 June 2026. A coluna agêntica vem de uma sessão headless do Claude Code editando o full-stack-fastapi-template de tiangolo, um repositório real de FastAPI e React, para doze tickets de funcionalidades, com quatro execuções em cada um no Haiku 4.5. A avaliação usa o git diff deixado ao final.
Leia a segunda coluna. O resultado agêntico representa 54 por cento menos linhas de código, 20 por cento menos custo e 27 por cento menos tempo de execução, contra 93 por cento e 74 por cento para essas mesmas medidas na configuração de execução única. O README explica honestamente o motivo: a linha de base de execução única é um modelo básico que "responde com várias opções e comentários", algo fácil de superar. Quando a comparação é feita com um agente real executando trabalho real, o ganho diminui. Ele também continua sendo real, o que é a informação mais útil.
Há uma ressalva do próprio projeto, e ela determina se isso será útil para você. A economia é maior quando existe uma tendência real a implementar mais do que o necessário e fica próxima de zero em código que já era mínimo. Doze tickets em um único repositório Python e TypeScript não permitem prever o comportamento no seu repositório. Se esse número for importante para você, execute a comparação nos seus próprios tickets, com e sem a regra, e conte as linhas você mesmo.
O padrão que você pode copiar hoje sem instalar nada
A sequência é texto, portanto você não precisa do plugin para usar a ideia. Cole um bloco como este no arquivo de instruções que seu agente já lê, seja ele AGENTS.md, CLAUDE.md ou o arquivo de regras do seu 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.Essa última regra merece ser analisada separadamente. A convenção do Ponytail é um comentário identificado pelo nome da ferramenta:
# ponytail: global lock, per-account locks if throughput mattersO comentário representa duas linhas de trabalho e resolve uma questão que, de outra forma, consumiria um ciclo de revisão. Ele informa ao próximo leitor que a versão simples foi uma decisão e identifica a condição em que essa decisão deixa de ser válida. Sem ele, o revisor não consegue distinguir um atalho considerado de algo que o agente esqueceu, então precisa perguntar.
O local onde você coloca o bloco é tão importante quanto o que ele diz. Um arquivo que o agente carrega em cada execução orienta todas as execuções, inclusive aquelas que você não está acompanhando. Essa diferença é o tema de escrever um AGENTS.md que seu agente realmente segue, e é por isso que esse padrão deve ficar em um arquivo versionado, não no histórico do seu shell.
Quando a regra deixa de ser adequada
A hierarquia foi ajustada para trabalhar em uma base de código existente, na qual a reutilização geralmente está disponível e costuma ser adequada. Ela se aplica mal a um projeto greenfield, porque o nível 2 não tem nada para reutilizar e o nível 5 não tem nada instalado. Por isso, o agente sempre acaba no nível 7. Ela também se aplica mal quando você realmente quer a abstração. Se você está prestes a adicionar o quarto chamador do mesmo bloco copiado, a opção de usar o "diff mais curto" entrega uma quinta cópia.
O nível ultra vai questionar seus requisitos. Essa é a finalidade do nível, e isso representa um custo real quando você já tomou a decisão e quer que o trabalho seja executado. Use full para o trabalho comum e recorra a ultra quando suspeitar que a solicitação de recurso é o problema.
Nenhum bloco de instruções evita uma interpretação incorreta do problema. O primeiro item do próprio conjunto de regras é entender o código antes de decidir. Essa é a parte cara e a parte que o texto não pode fazer por você. Um diff mínimo na função errada continua sendo a correção errada. Agora, é uma correção errada pequena e fácil de aprovar.
O resumo honesto é que Ponytail é um prompt cuidadosamente escrito, bem distribuído e acompanhado de números. Nada nele exige o plugin. O que o projeto oferece é o fato de alguém ter escrito a lista corretamente, testado a lista em um repositório real e publicado o método junto com o resultado.
FAQ
O Ponytail funciona com agentes diferentes do Claude Code?
Sim. Ele é distribuído como uma skill para hosts que carregam skills, uma lista que inclui Claude Code, Codex, OpenCode, Gemini e vários outros mencionados no README. Editores que leem arquivos de regras, mas não carregam skills, como Cursor, Windsurf, Cline e Copilot, usam o ruleset sempre ativo do diretório de regras correspondente e não recebem comandos de barra. O texto é o mesmo nos dois casos. A diferença real é saber se o host mantém esse texto no contexto em cada interação ou apenas quando uma skill é acionada.
Um agente preguiçoso pode ignorar testes, validação ou segurança?
Não, e o ruleset afirma isso diretamente. A lista "nunca seja preguiçoso com" inclui a validação de entrada nos limites de confiança, o tratamento de erros que evita perda de dados, a segurança e a acessibilidade. Ela também pede uma verificação pequena e executável para cada parte da lógica não trivial. A regra remove estruturas inventadas: abstrações que ninguém solicitou e dependências de que ninguém precisava. Se o agente começar a remover testes depois da instalação, a causa é outra instrução na sua própria configuração com prioridade maior que esta. Nesse caso, leia o arquivo que o agente carrega por último.
Os números publicados de velocidade e custo são confiáveis?
Eles são as próprias medições do projeto, publicadas junto com o método usado, e devem ser interpretados dessa forma. Os números de execução única fazem uma comparação com um modelo básico que responde com opções e comentários. O próprio README indica que essa é uma referência fraca. Os números agentic vêm de uma sessão headless do Claude Code em um repositório FastAPI e React, com doze tickets e quatro execuções de cada um, usando Haiku 4.5. São números válidos para essa configuração. Eles não são uma previsão para a sua base de código, porque o projeto também informa que a economia cai para perto de zero em código que já era mínimo.
Preciso instalar alguma coisa para obter o benefício?
Não. A ladder é texto, e colar um bloco equivalente no arquivo de instruções que o agente já lê produz a maior parte do efeito. O plugin fornece o texto mantido, os níveis de intensidade, os comandos de revisão e um caminho de atualização. Testar primeiro o bloco copiado é a resposta do rung 1 à pergunta sobre se a instalação precisa existir.
Como impedir que um agente não supervisionado faça trabalho excessivo durante a noite?
Coloque a regra no arquivo de instruções sempre ativo, e não em uma mensagem de chat. Assim, ela será aplicada na interação 200 de uma execução longa, e não apenas na interação 3. Depois, limite o impacto separadamente: forneça ao agente um checkout que ele possa danificar, em vez da sua única cópia, e exija uma revisão humana do diff antes de qualquer merge. Uma regra de diff mínimo reduz o volume que você precisa ler. Ela não decide o que será incorporado, e não deve decidir.