shadcn/improve Hits 10K Stars: A Strong Model Plans, Cheaper Ones Edit the Code

Paying for the smartest model to rename a variable across forty files is like asking the chief architect to haul bricks. The shadcn/improve repository proposes splitting the roles: the expensive model thinks, the cheap ones do the work.

What we know about the project

shadcn/improve reached the daily top of GitHub Trending: +333 stars in a day and 10,415 in total. Its author is shadcn, known for the shadcn/ui library, which explains part of the interest. The description fits on one line: use the most capable model to audit a codebase and write plans that cheaper models will carry out.

An important caveat. The source contains only this description and the statistics. The repository's language is not stated, and we have not seen the README. Which specific commands, plan formats and agents are supported is unknown, and we will not speculate. We examine the pattern itself, not a particular implementation.

How it works, by example

Imagine a project where 40 components use an outdated way of handling forms. The strong model reads the entire codebase once: it finds repetitions, notices non-obvious dependencies and produces a task list. For example: "in file A, replace the old hook with the new one, update the test, don't touch file B." Each item is self-contained and does not require knowing the others.

Next, each item goes to a cheap model. It does not need to understand the architecture of the whole project: it has a narrow task, clear boundaries and a clear definition of done. It is harder to go wrong under such conditions, and a single pass costs many times less than the same amount of work done by a flagship.

The logic is simple. The expensive part of the work is understanding and choosing what exactly to change. Execution from a ready recipe is mechanical. Many teams already do this by hand: they ask a flagship model to write a plan in markdown and feed it to a simpler model. Judging by the description, shadcn/improve tries to turn this trick into a repeatable process, so you don't have to rebuild it from scratch in every project.

What to do with this

Even without installing the repository, you can test the idea on your own code:

• Take one module and ask a strong model to write a refactoring plan without changing a single line of code.
• Demand atomic items: one file or one check, and an explicit "done" condition.
• Make tests, the linter and type checking the judge, not the model itself.
• Do the math: compare the cost of the plan plus execution with a full run on the flagship.

Limitations

Stars measure interest, not proof of quality. 333 in a day show that the idea struck a chord, but not that the tool is reliable on real codebases.

The approach itself has weak spots. An error in the plan multiplies across all executions: if the audit is wrong, the cheap models will diligently do the wrong thing. A large codebase can't always fit entirely into the strong model's context, which means the audit has to be split into parts, and you must make sure the parts don't contradict each other. And plan items that depend on each other do not split well into parallel tasks.

The main takeaway for practice doesn't depend on this repository's fate: separate "deciding what to change" from "changing it." The first is expensive and rarely needed; the second is cheap and needed often. Keep an eye on shadcn/improve, but for now treat it as a notable bid for a good pattern, not as a production-ready tool.