shadcn/improve chega a 10 mil estrelas: o modelo forte planeja, os baratos editam o código

Pagar pelo modelo mais inteligente para renomear uma variável em quarenta arquivos é como chamar o arquiteto-chefe para carregar tijolos. O repositório shadcn/improve propõe separar os papéis: o modelo caro pensa, os baratos trabalham.

O que se sabe sobre o projeto

O shadcn/improve entrou no top diário do GitHub Trending: +333 estrelas em um dia e 10 415 no total. O autor é shadcn, conhecido pela biblioteca shadcn/ui, e isso explica parte do interesse. A descrição cabe em uma linha: usar o modelo mais capaz para auditar a base de código e escrever planos que serão executados por modelos mais baratos.

Uma ressalva importante. A fonte contém apenas essa descrição e as estatísticas. A linguagem do repositório não é informada, e não vimos o README. Não se sabe quais comandos, formatos de plano e agentes são suportados, e não vamos especular. Analisamos o padrão em si, não uma implementação específica.

Como funciona, com um exemplo

Imagine um projeto em que 40 componentes usam uma forma obsoleta de lidar com formulários. O modelo forte lê o código inteiro uma vez: encontra repetições, percebe dependências pouco óbvias e entrega uma lista de tarefas. Por exemplo: «no arquivo A, trocar o hook antigo pelo novo, atualizar o teste e não mexer no arquivo B». Cada item é autossuficiente e não exige conhecer os demais.

Em seguida, cada item vai para um modelo barato. Ele não precisa entender a arquitetura de todo o projeto: tem uma tarefa restrita, limites claros e um critério objetivo de conclusão. Nessas condições é mais difícil errar, e uma passada custa várias vezes menos do que o mesmo volume de trabalho feito pelo modelo de ponta.

A lógica é simples. A parte cara do trabalho é entender e escolher o que exatamente mudar. A execução em si, a partir de uma receita pronta, é mecânica. Muitas equipes já fazem isso manualmente: pedem ao modelo de ponta um plano em markdown e o entregam a um modelo mais simples. Pela descrição, o shadcn/improve tenta transformar esse truque em um processo repetível, para que não seja preciso montá-lo do zero em cada projeto.

O que fazer com isso

Mesmo sem instalar o repositório, é possível testar a ideia no seu código:

• Pegue um módulo e peça ao modelo forte um plano de refatoração sem alterar uma única linha de código.
• Exija itens atômicos: um arquivo ou uma verificação, com uma condição explícita de «concluído».
• Use testes, linter e tipagem como juízes, e não o próprio modelo.
• Faça as contas: compare o custo do plano mais a execução com uma rodada completa feita pelo modelo de ponta.

Limitações

Estrelas medem interesse, não são prova de qualidade. As 333 em um dia mostram que a ideia chamou a atenção, mas não que a ferramenta seja confiável em bases de código reais.

A própria abordagem tem pontos fracos. Um erro no plano se multiplica por todas as execuções: se a auditoria errou, os modelos baratos farão o errado com muito capricho. Nem sempre será possível colocar uma base de código grande inteira no contexto do modelo forte, então a auditoria terá de ser dividida em partes, cuidando para que elas não se contradigam. E os itens do plano que dependem uns dos outros se dividem mal em tarefas paralelas.

A principal conclusão prática não depende do destino deste repositório: separe «decidir o que mudar» de «mudar». O primeiro é caro e necessário raramente; o segundo é barato e necessário com frequência. Acompanhe o shadcn/improve, mas por enquanto trate-o como uma aposta notável em um bom padrão, e não como uma ferramenta pronta para produção.