shadcn/improve atteint 10 000 étoiles : le modèle puissant planifie, les modèles économiques modifient le code

Payer le modèle le plus intelligent pour renommer une variable dans quarante fichiers, c'est comme demander à l'architecte en chef de porter des briques. Le dépôt shadcn/improve propose de séparer les rôles : le modèle coûteux réfléchit, les modèles économiques travaillent.

Ce que l'on sait du projet

shadcn/improve est entré dans le top quotidien de GitHub Trending : +333 étoiles en une journée et 10 415 au total. L'auteur est shadcn, connu pour la bibliothèque shadcn/ui, ce qui explique une partie de l'intérêt. La description tient en une ligne : utiliser le modèle le plus capable pour auditer la base de code et rédiger des plans que des modèles moins chers exécuteront.

Une réserve importante. La source ne contient que cette description et les statistiques. Le langage du dépôt n'est pas indiqué, et nous n'avons pas vu le README. On ignore quelles commandes, quels formats de plan et quels agents sont pris en charge, et nous ne comblerons pas les blancs par des suppositions. Nous analysons le schéma lui-même, pas une implémentation précise.

Comment ça marche, sur un exemple

Imaginez un projet où 40 composants utilisent une ancienne manière de gérer les formulaires. Le modèle puissant lit une fois tout le code : il repère les répétitions, remarque des dépendances peu évidentes et produit une liste de tâches. Par exemple : « dans le fichier A, remplacer l'ancien hook par le nouveau, mettre à jour le test, ne pas toucher au fichier B ». Chaque point est autonome et n'exige pas de connaître les autres.

Ensuite, chaque point est confié à un modèle économique. Il n'a pas besoin de comprendre l'architecture de tout le projet : il a une tâche étroite, des limites claires et un critère d'achèvement net. Dans ces conditions, il est plus difficile de se tromper, et un passage coûte plusieurs fois moins cher que le même volume de travail réalisé par le modèle phare.

La logique est simple. La partie coûteuse du travail, c'est comprendre et choisir ce qu'il faut changer. L'exécution proprement dite, à partir d'une recette toute prête, est mécanique. Beaucoup d'équipes le font déjà à la main : elles demandent au modèle phare un plan en markdown et le donnent à un modèle plus modeste. D'après la description, shadcn/improve cherche à transformer cette astuce en processus reproductible, pour ne pas avoir à le reconstruire dans chaque projet.

Que faire de tout cela

Même sans installer le dépôt, vous pouvez tester l'idée sur votre code :

• Prenez un module et demandez au modèle puissant un plan de refactorisation sans modifier la moindre ligne de code.
• Exigez des points atomiques : un fichier ou une vérification, avec une condition explicite de « terminé ».
• Prenez les tests, le linter et le typage pour juges, et non le modèle lui-même.
• Faites le calcul : comparez le coût du plan plus de l'exécution avec un passage complet du modèle phare.

Limites

Les étoiles mesurent l'intérêt, pas la qualité. Les 333 en une journée montrent que l'idée a séduit, mais pas que l'outil est fiable sur de vraies bases de code.

L'approche elle-même a des points faibles. Une erreur dans le plan se multiplie sur toutes les exécutions : si l'audit s'est trompé, les modèles économiques feront consciencieusement le mauvais travail. Une grande base de code ne tiendra pas toujours entièrement dans le contexte du modèle puissant ; il faudra donc découper l'audit en parties et veiller à ce qu'elles ne se contredisent pas. Enfin, les points du plan qui dépendent les uns des autres se répartissent mal en tâches parallèles.

La principale conclusion pratique ne dépend pas du sort de ce dépôt : séparez « décider quoi changer » de « changer ». Le premier est coûteux et rarement nécessaire, le second est bon marché et fréquemment nécessaire. Suivez shadcn/improve, mais pour l'instant considérez-le comme une proposition notable pour un bon schéma, et non comme un outil prêt pour la production.