Ponytail lite, full, ultra ou off: qual nível usar em cada tarefa?

Você pediu um campo novo no formulário e recebeu uma factory, uma interface, um arquivo de tipos e três testes de mentira

Quem usa agente de código todo dia conhece a cena: o modelo não erra a tarefa, ele exagera nela

O Ponytail nasceu exatamente pra isso: é uma skill/ruleset de código mínimo pra agentes de IA, criada e mantida por DietrichGebert no GitHub, com uma descrição oficial que já entrega o espírito da coisa: "Makes your AI agent think like the laziest senior dev in the room"

O detalhe que quase ninguém explora é que ele não é liga/desliga: tem lite, full, ultra e off, e a troca é por comando, no meio da sessão

Então a pergunta do post é essa: qual nível serve pra qual tarefa? 🙂

O que o Ponytail faz antes de escrever qualquer linha

Antes de gerar código, o Ponytail aplica uma escada de decisão, sempre nesta ordem:

1. YAGNI: isso precisa existir?
2. biblioteca padrão
3. recurso nativo da plataforma
4. dependência já instalada
5. uma linha
6. o mínimo que funciona

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

Se você conhece aquela revisão de código do sênior que pergunta "por que isso é uma classe?" antes de olhar a lógica, é mais ou menos isso, só que aplicado antes do primeiro caractere

E não vale só pra código novo: a régua entra em escrever, adicionar, refatorar, corrigir, revisar ou desenhar código, e também na hora de escolher bibliotecas ou dependências

Esse último ponto é o que mais dói na prática, porque a dependência a mais é a decisão que ninguém revisa depois

Vale pra quem monta fluxo também, não só pra quem escreve backend: se você já montou um agente de suporte com n8n, sabe que metade do trabalho é resistir à vontade de adicionar mais um nó

E o que ele NUNCA corta?

Essa é a parte que separa régua de preguiça de verdade. Com a régua ligada, seja no lite, no full ou no ultra, o Ponytail não simplifica:

• entendimento do problema (ler e rastrear o fluxo real antes de escolher o degrau)
• validação de entrada em fronteiras de confiança
• tratamento de erro que evita perda de dados
• segurança
• acessibilidade
• qualquer coisa que você pediu explicitamente

Tem mais: pra lógica não trivial (um branch, um loop, um parser, um caminho de dinheiro ou de segurança) ele exige deixar UM check executável, seja um self-check com assert num demo()/__main__, seja um test_*.py pequeno

Um check. Não uma suíte

E pra situar: o repositório foi publicado em 12 de junho de 2026, ou seja, é projeto novo e ainda em movimento

Lite, full, ultra e off: a diferença em uma tabela

<table> <thead> <tr><th>Nível</th><th>Comportamento</th><th>Quem decide o corte</th><th>Quando faz sentido</th></tr> </thead> <tbody> <tr><td>lite</td><td>Constrói o que foi pedido e sinaliza a alternativa mais enxuta ao lado; só sugere mudança quando o excesso de engenharia é óbvio</td><td>Você</td><td>Quando você quer o aviso, mas não quer a régua mandando</td></tr> <tr><td>full (padrão)</td><td>Aplica a escada de decisão de forma estrita em cada geração de código</td><td>O agente, dentro da escada</td><td>Dia a dia, é o estado que vem ligado</td></tr> <tr><td>ultra</td><td>YAGNI levado ao extremo: entrega a solução de uma linha e questiona o resto do requisito na mesma resposta, preferindo deletar código a adicionar</td><td>O agente, e ele ainda devolve a pergunta</td><td>Quando o objetivo é encolher, não crescer</td></tr> <tr><td>off</td><td>Régua desligada</td><td>Ninguém, você recebe o que pediu</td><td>Quando contraproposta atrapalha</td></tr> </tbody> </table>

Lendo a tabela de cima pra baixo, o que muda não é só a intensidade: muda quem fica com a decisão

O lite te dá informação, o full te dá uma escolha já feita, e o ultra te dá uma escolha feita MAIS um questionamento do requisito que você escreveu 😀

Uma observação honesta antes de continuar: o repositório descreve o que cada nível faz, mas não publica uma tabela oficial de "use ultra pra X, lite pra Y". O mapeamento da próxima seção é raciocínio em cima do comportamento documentado, não recomendação do projeto

Qual nível para cada tipo de tarefa

Feature nova em base que você não domina: lite

Código de terceiros, projeto legado, aquele módulo que ninguém toca desde sempre

Aqui o problema não é o agente construir demais, é você não ter contexto pra julgar se o corte dele é seguro

O lite resolve isso pela mecânica: ele constrói o que foi pedido e coloca a alternativa enxuta do lado, como sugestão. A decisão continua sua

E como ele só abre a boca quando o excesso de engenharia é óbvio, você não fica lendo contraproposta a cada resposta

Escrever, corrigir e revisar no dia a dia: full

É o padrão, e padrão existe por um motivo

O full aplica a escada estrita em cada geração, então a pergunta "isso precisa existir?" acontece antes de você precisar fazê-la na revisão

Como a régua também cobre revisar e corrigir, ele age nos dois sentidos: segura o código novo e reclama do código velho quando você pede pra mexer nele

Limpeza, refatoração e corte de dependência: ultra

Esse é o nível pra quando, nas palavras do próprio repositório, o codebase já ofendeu você pessoalmente

O ultra prefere deletar código a adicionar, entrega a solução de uma linha e ainda questiona o resto do requisito na mesma resposta

Em tarefa de crescimento isso vira briga, beleza? Mas em tarefa de encolhimento é exatamente o comportamento que você quer: alguém disposto a perguntar por que aquela dependência ainda está no package.json

Quando você quer só o que pediu: off

Tem hora que a contraproposta é ruído

Spike descartável, reprodução de bug, prova de conceito que vai morrer amanhã, ou aquele caso em que você JÁ decidiu a arquitetura e não quer discutir

Pra isso existe o off: a régua sai de cena e o agente entrega o que você pediu, sem alternativa enxuta do lado nem questionamento do requisito

Só não confunda desligar a régua com desligar o cuidado: sem nada filtrando a saída, a revisão do que chega volta a ser inteirinha sua

Como trocar de nível e fixar o padrão

1. Instale no Claude Code pelo marketplace de plugins. São dois comandos, na ordem:

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

O erro comum deste passo: rodar sem node no PATH. Os plugins de Claude Code e Codex rodam dois hooks de ciclo de vida em Node.js, então sem node as skills até funcionam, mas a ativação always-on não acontece automaticamente

2. Troque o nível dentro da sessão com o comando e o modo:

/ponytail lite
/ponytail full
/ponytail ultra
/ponytail off

O erro comum deste passo: achar que ficou. A troca por /ponytail seguido do modo tem escopo de sessão, acabou a sessão, voltou ao padrão

3. Cheque qual nível está ativo rodando o comando sem argumento:

/ponytail

Sem argumento ele REPORTA o nível ativo, não reseta nada. É a checagem mais barata que existe quando o agente começa a se comportar diferente do esperado

4. Fixe o padrão pra valer com o default:

/ponytail default lite

Ele grava no config, sobrevive a reinício e aceita apenas off, lite, full ou ultra. A resposta que confirma é PONYTAIL DEFAULT SET: new sessions start in, seguida do modo que você escolheu

5. Ou defina o padrão por fora, via variável de ambiente PONYTAIL_DEFAULT_MODE (lite/full/ultra/off) ou pelo campo defaultMode no arquivo de configuração, que fica em ~/.config/ponytail/config.json (%APPDATA%\ponytail\config.json no Windows):

{ "defaultMode": "full" }

O erro comum deste passo: configurar os dois e não entender quem ganhou. A ordem de precedência é env var, depois arquivo de config, depois full

6. Desligue por frase quando precisar. Dizer "stop ponytail" ou "normal mode" desliga, assim como /ponytail off. Pra retomar, é /ponytail

Veredito: comece no full e ajuste pelo atrito

Minha leitura: comece no full, porque é o padrão e é a calibragem que o projeto assume como certa

Desça pra lite quando a régua começar a apertar em cima de decisão que é sua, e suba pra ultra em tarefa cujo objetivo declarado é cortar

Sobre ganho, dá pra usar o benchmark oficial como termômetro, com uma ressalva importante: a média esconde os extremos

O número atual é de cerca de 54% menos código em média, chegando a 94% só onde o agente superconstrói e perto de zero onde o código já é mínimo, com aproximadamente 20% menos custo e 27% mais rápido

A metodologia foram 12 tarefas de feature rodadas no Claude Code sobre um repositório real de FastAPI e React, totalizando 48 execuções de teste. Em nenhuma delas o Ponytail sugeriu remover validação de entrada, tratamento de erro ou checagem de segurança, ou seja, 100% no quesito segurança

E tem um detalhe que merece crédito ao mantenedor: a alegação inicial era de 80% a 94% menos código, mas essa medição foi feita contra um modelo de chat puro. Um contribuidor apontou que o baseline era falho, o benchmark foi refeito com baseline agêntico justo e o número publicado ficou MENOR

Projeto que corrige o próprio benchmark pra baixo já ganha uns pontos comigo 😀

Agora a ressalva viva: existe uma issue aberta (#161) relatando que o Ponytail desliga sozinho quando o prompt contém por acaso a expressão "normal mode"

Tome cuidado com isso, porque o sintoma é silencioso: o agente simplesmente volta a superconstruir e você acha que a skill é fraca. É justamente por isso que o /ponytail sem argumento vira um hábito útil

Outra coisa que não dá pra afirmar: não encontrei benchmark medindo custo ou economia POR nível. Os 54%, 20% e 27% são do modo padrão, não de lite versus full versus ultra

Conclusão

O nível certo do Ponytail é aquele que você troca sem pensar duas vezes

Régua de código mínimo ajuda enquanto é ajuste fino, e atrapalha no minuto em que vira briga com o agente no meio da tarefa

Próximo passo prático, bem curtinho: instala, roda UMA tarefa real no full, confere o nível ativo com /ponytail e fixa o que sobrou com /ponytail default

Depois disso é só ir calibrando pelo atrito, que é o único sinal que não mente

até o próximo post! =)