Por que o Ponytail devolve um input nativo quando você pede um date picker?

Você pede um date picker e o agente devolve 23 linhas, não uma biblioteca

Fala aí, beleza? Esse é o comportamento mais fácil de enxergar do Ponytail, um ruleset open source que não ensina o agente a programar melhor, ele muda a ORDEM em que o agente decide o que fazer antes de escrever a primeira linha

E o resultado aparece justo nos widgets de interface, onde o modelo adora construir do zero uma coisa que o navegador já entrega de graça 🙂

O que é o Ponytail e como funciona a escada de decisão

O Ponytail é um projeto open source hospedado no GitHub sob o usuário DietrichGebert, no repositório DietrichGebert/ponytail, licenciado sob MIT (Copyright (c) 2026 DietrichGebert)

A descrição do próprio projeto é a melhor definição possível: um ruleset que faz o agente de código pensar como o dev sênior mais preguiçoso da sala

E preguiça aqui não é gíria solta, é uma escada de decisão bem literal, em que o agente para no primeiro degrau que resolve o problema:

• isso precisa existir? (se não precisa, corta por YAGNI)
• já existe neste repositório? (reusa)
• a stdlib resolve? (usa)
• existe recurso nativo da plataforma? (usa)
• alguma dependência já instalada resolve? (usa)
• dá em uma linha? (faz em uma linha)
• só então escreve o mínimo que funciona

Formação Recomendada

Formação Claude Code

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

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Se você já pensou sobre o que é uma skill no Claude, a lógica é a mesma família: não é um prompt mágico, é uma instrução que muda o critério de escolha do agente

Aqui tem um detalhe que muita gente pula: a escada roda DEPOIS de o agente entender o problema, nunca no lugar disso

Ele lê o código que a mudança toca e traça o fluxo real antes de escolher em qual degrau vai parar

A regra do projeto diz isso com todas as letras: preguiçoso na solução, nunca na leitura

Date picker e color picker: o que muda com e sem a skill

Bora ver os números do benchmark do próprio projeto, que é onde o padrão fica escancarado:

O caso do color picker é quase cômico: 287 linhas viram 23 porque o agente simplesmente passa a usar um input nativo em vez de montar um componente inteiro

O README ainda resume o caso do date picker de outro jeito, como troca de dependência por recurso do navegador: de 1 dependência + 30 linhas para 0 dependências + 1 linha

Atenção pra não misturar as duas coisas: essa frase de resumo e a linha do benchmark são apresentações diferentes do mesmo caso, com contagens que não batem entre si

Eu não sei qual recorte exato o resumo está contando, então o número que eu uso como referência aqui é o do benchmark: 404 para 23

Que "recurso nativo" é esse? No caso da data, é o elemento <input type="date">, documentado no MDN, que existe como recurso do navegador e não depende de biblioteca nenhuma

Outra coisa que vale saber: esses comparativos não são exemplos escritos à mão pra vender o peixe

Os arquivos da pasta examples são saída real do modelo, verbatim das rodadas de benchmark, com a mesma tarefa respondida pelo mesmo modelo sem a skill e com a skill

O do date picker vive em examples/date-picker.md, e dá pra ler os dois lados lado a lado

Onde esse padrão rende e onde ele não deve rodar

Onde rende muito: widget de UI que a plataforma já entrega pronto

Data, cor, esse tipo de coisa que o navegador resolve com um atributo e que a IA insiste em reconstruir com estado, teclado, formatação e por aí vai

Onde NÃO rende: o próprio projeto avisa que o ganho é perto de zero onde o código já é mínimo, tipo um CRUD de backend que já está irredutível

Se não tem gordura, não tem o que cortar, simples assim

E tem o limite mais importante, que a regra declara explicitamente: a preguiça não vale para itens de risco

Validação em fronteira de confiança, tratamento de perda de dados, segurança e acessibilidade nunca entram no corte

Ou seja, não é "escreve menos em tudo", é "para de super-construir onde super-construir não paga nada"

Como instalar o Ponytail no Claude Code e ver o comportamento

A instalação em si é por plugin e são dois comandos, os outros dois passos da lista são conferência pra você não cair na pegadinha do node:

1. Adicione o marketplace do projeto

/plugin marketplace add DietrichGebert/ponytail

2. Instale o plugin

/plugin install ponytail@ponytail

3. Garanta que o node está no PATH

O plugin do Claude Code roda dois hooks de ciclo de vida em Node.js

O erro comum deste passo: sem node no PATH, as skills continuam funcionando normalmente, mas a ativação sempre ligada fica silenciosa

É o pior tipo de erro, o que não reclama… você acha que está ativo e não está

4. Peça uma tarefa de interface e observe em qual degrau ele parou

Um date picker é o teste mais direto: ou ele instala uma dependência, ou ele te devolve o input nativo

O que apareceu quando rodei a auditoria no meu projeto

Instalei o Ponytail num projeto Claude Code que já estava em andamento, e essa foi a primeira surpresa boa: não precisa de projeto do zero

O projeto já estava começado e mesmo assim ele identificou o que dava pra melhorar

Preferi deixar valendo só no projeto em que eu estava trabalhando, e não valendo em tudo, pra saber exatamente o que está ativo e evitar que uma regra de outro contexto vaze pra um projeto sem relação

Aí pedi a auditoria em português e ele varreu 21 arquivos

Tome cuidado com a grafia: na primeira tentativa eu escrevi o nome errado e simplesmente não foi identificado, só funcionou depois de corrigir 😛

O ponto que mais me pegou foi que a verificação não aplica mudança nenhuma

Ela lista o que dá pra melhorar e a decisão de aplicar fica com você, o que eu achei MUITO mais saudável do que sair mexendo sozinho

E adivinha qual foi o item de maior corte da lista?

Um date picker customizado que eu mesmo tinha construído, com a sugestão de trocar por um input nativo de data, e a estimativa da auditoria era de 219 linhas a menos

A justificativa apresentada foi que o input nativo já entrega teclado, bloqueio de datas e acessibilidade sem código próprio

Pra aplicar, eu só conversei direto com o Claude Code, sem chamar nada do plugin de novo, e o date picker customizado virou input simples

Aí veio a diferença que eu não vou disfarçar: o resumo depois da troca marcou menos 330 linhas, bem mais que os 219 estimados antes

Não vou inventar explicação pra essa diferença, um número é a estimativa de antes de mexer e o outro é o que o resumo mostrou depois de mexer, só isso

Outro apontamento foi um event factory com padrões strategy e registry, cerca de 195 linhas para cinco categorias fixas com cálculo de preço trivial, com a sugestão de virar um union type, um record e uma função

Aqui vai o conselho que eu acho mais importante do post: converse com a IA antes de aceitar cada sugestão

Às vezes a complexidade foi uma decisão consciente e vale manter… no caso do event factory, a conclusão foi que não valia mesmo

Depois eu mandei corrigir tudo seguindo as boas práticas do plugin: aproximadamente 690 linhas e 4 arquivos a menos, e o build continuou passando

E esse total não é a soma desses dois itens que eu contei aqui: a correção completa passou pela lista inteira da auditoria, que tinha varrido os 21 arquivos, e o date picker e o event factory eram só os dois casos mais gordos

Ressalva honesta: o projeto que usei era um exemplo simples, não um projeto real e complexo

No vídeo abaixo eu mostro essa auditoria rodando e a troca do date picker acontecendo na tela:

Os números do Ponytail merecem confiança?

Aqui é onde eu preciso ser honesto com você, porque a história tem uma reviravolta

Os números atuais divulgados pelo projeto são: cerca de 54% menos código em média, cerca de 20% mais barato e 27% mais rápido

Esses números vêm do benchmark agêntico atual, com 12 tarefas de feature, com e sem a skill, n=4, no modelo claude-haiku-4-5-20251001, via Claude Code 2.1.177 em modo headless, sobre um repositório real com FastAPI e React

Mas nem sempre foi esse número. A alegação original era de 80% a 94% menos código

E ela foi contestada na issue #126 do repositório, "Benchmark issues – baseline scores are ~7 times better", por Colin Eberhardt, CTO da Scott Logic

O que ele mostrou é fino demais: o baseline estava sendo medido pela prosa e pelos exemplos alternativos que o modelo devolvia, não só pelo código

Adicionar UMA linha ao prompt do baseline, pedindo só um exemplo e nenhum comentário, derrubou a média do baseline de 108 para 16 linhas

Depois da crítica, o mantenedor refez o benchmark contra um baseline agêntico justo e publicou publicamente o número menor, esse 54% que consta hoje

Isso, pra mim, conta a favor do projeto e não contra

Tem mais: um teste independente da JetBrains mediu ganhos menores que os divulgados, em 80 tarefas pareadas deu 15% menos código, 10,3% menos custo e 11% menos tempo

E o próprio projeto declara que os 94% são teto por tarefa, atingido só onde o agente super-constrói, com ganho perto de zero onde o código já é mínimo

Quando o assunto é número vindo de IA, essa desconfiança saudável vale sempre, é o mesmo motivo pelo qual eu insisto em conferir conta que a IA entrega antes de repassar pra alguém

Conclusão

O que fica de valor aqui nem depende de instalar nada: perguntar pelo recurso nativo ANTES de instalar dependência é um hábito que economiza código pra sempre

O Ponytail só transforma esse hábito em regra pro agente, e o caso do date picker é a demonstração mais limpa disso, de 404 linhas pra 23 porque o navegador já fazia o trabalho

Se quiser testar sem fé cega: instala, manda auditar UM arquivo que você já suspeita que está inchado e compara o diff antes de aceitar qualquer coisa

O pior cenário é você descobrir que estava certo e não tinha gordura… o melhor é sair com centenas de linhas a menos e o build passando 😀

até o próximo post!