shadcn/improve est un dépôt open source au fonctionnement simple : plutôt qu’utiliser le modèle d’IA le plus cher pour écrire directement du code, on l’utilise pour réfléchir. Il audite un dépôt, détecte des améliorations concrètes, les priorise et génère des plans techniques détaillés qu’un autre agent plus économique ou un développeur humain peut ensuite exécuter.
Cette approche répond à un problème concret que les équipes de développement découvrent en utilisant des agents IA : le coût, le bruit et le manque de contrôle. Un agent peut écrire du code, certes, mais il peut aussi trop toucher, casser des tests, s’écarter du périmètre ou consommer beaucoup de tokens pour des tâches peu intelligentes. shadcn/improve sépare l’analyse de l’exécution, ce qui change la façon d’allouer les ressources IA.
Open source, gratuit, format Markdown
shadcn/improve est publié sous licence MIT. N’importe quel développeur peut l’installer, l’examiner, l’adapter ou l’intégrer dans ses flux sans dépendre d’une plateforme propriétaire. L’installation se fait en une commande : npx skills add shadcn/improve. Le projet fonctionne avec des agents compatibles avec le format Agent Skills.
Les plans générés sont des fichiers Markdown standard, stockés dans un dossier plans/. Un autre agent, un développeur ou un outil interne peut les lire facilement. Ce n’est pas un détail mineur : plutôt que créer un format fermé, shadcn/improve génère une documentation qui s’intègre dans la culture de développement existante, pull requests, issues, revues et checklists.
| Caractéristique | Avantage pour le développeur |
|---|---|
| Dépôt ouvert | Auditable, modifiable et compréhensible |
| Licence MIT | Usage personnel, professionnel et commercial |
| Installation avec npx | Processus simple sans configuration complexe |
| Plans en Markdown | Format portable, lisible et versionnable |
| Ne modifie pas le code | Réduit les risques lors de l’audit |
| Compatible d’autres agents | Flexibilité dans le flux de travail |
| Publication en issues | Intégration facile dans GitHub Issues |
Le modèle coûteux pense, le modèle économique exécute
L’idée centrale : séparer deux phases que beaucoup d’outils mélangent. L’audit exige une compréhension approfondie. Le modèle doit analyser le dépôt, saisir l’architecture, détecter les conventions, examiner les zones sensibles et décider ce qui vaut la peine d’être corrigé. Cette étape justifie un modèle puissant.
L’exécution est différente. Si le plan est bien rédigé, mettre en œuvre une correction concrète devient une tâche plus mécanique : modifier un fichier, supprimer une duplication, ajouter un test, ajuster une migration. Un modèle plus économique, ou même un développeur junior guidé par des instructions claires, peut s’en charger. C’est exactement ce que démontre EAGLE 3.1 : l’optimisation IA ne passe pas seulement par plus de GPU, mais par des approches algorithmiques qui réduisent les coûts d’inférence.
| Phase | Qui devrait la réaliser | Raison |
|---|---|---|
| Lecture et cartographie | Modèle puissant | Compréhension globale requise |
| Identification des problèmes | Modèle puissant | Jugement technique nécessaire |
| Priorisation | Modèle puissant ou lead technique | Arbitrage impact/effort |
| Rédaction des plans | Modèle puissant | La qualité du plan détermine la fiabilité de l’exécution |
| Implémentation | Modèle économique ou humain | Tâche guidée et vérifiable |
| Vérification des différences | Modèle puissant ou senior | Contrôle final de la portée |
Ce mode opératoire réduit les coûts. Plutôt que laisser un modèle cher faire, essayer, échouer et consommer des tokens pour des tâches répétitives, on lui confie uniquement ce qui a de la valeur : la réflexion. L’exécution passe dans des instructions précises.
Plans autosuffisants pour éviter l’improvisation
shadcn/improve ne se contente pas de dire « améliore la performance de cette fonction ». Chaque plan inclut assez de contexte pour qu’un exécuteur, même sans avoir vu l’audit original, puisse travailler efficacement.
Cela comprend les chemins précis des fichiers, des extraits du code actuel, les conventions du dépôt, les commandes de vérification, les sorties attendues, les critères d’achèvement et les conditions d’arrêt. Ces conditions sont cruciales : si la réalité du code ne correspond pas au plan, l’agent s’arrête et signale la divergence plutôt qu’improviser.
| Éléments du plan | Pourquoi c’est important |
|---|---|
| Chemins exacts | Évite les recherches inutiles |
| Extraits de code | Contexte sans dépendance aux sessions précédentes |
| Commandes test/lint/build | Succès vérifiable |
| Sorties attendues | Réduit l’ambiguïté |
| Critères d’achèvement | Définit quand une tâche est terminée |
| Limites de périmètre | Évite les changements latéraux |
| Conditions d’arrêt | Empêche un modèle faible d’inventer des solutions |
| Commit de référence | Détecte si le plan devient obsolète |
Ce type de conception fonctionne particulièrement bien avec des modèles moins puissants. Un agent moins capable échoue davantage quand il décide seul. Avec un plan à étapes concrètes, des limites claires et des tests vérifiables, le risque de déviation diminue nettement.
Audits avec preuves tirées du dépôt
shadcn/improve ne produit pas de recommandations génériques. Son audit couvre la correction, la sécurité, la performance, les tests, la dette technique, les dépendances, l’expérience développeur et la documentation. Chaque constat s’appuie sur des preuves tirées du code, avec des références précises aux fichiers et lignes concernées.
Cela réduit un problème fréquent des agents IA en développement : les faux positifs. Beaucoup de modèles signalent trop de risques théoriques ou proposent des améliorations inadaptées au projet. Ici, le processus oblige à examiner les constats avant de les transformer en plans. Ce qui n’est pas un problème réel est rejeté et noté pour ne pas réapparaître lors de la prochaine exécution.
| Catégorie d’audit | Exemples de constats utiles |
|---|---|
| Correction | Cas limites, erreurs logiques, validations incomplètes |
| Sécurité | Risques avec preuve dans le code |
| Performance | Algorithmes coûteux, requêtes répétées, boucles inutiles |
| Tests | Zones critiques sans couverture |
| Dette technique | Duplications, abstractions fragillisées, TODOs anciens |
| Dépendances | Migrations en attente ou paquets problématiques |
| Expérience développeur | Commandes confuses, mauvaise documentation d’environnement |
| Documentation | Guides obsolètes ou incomplets |
Les résultats sont présentés sous forme d’une liste priorisée selon l’impact, l’effort et la confiance. L’utilisateur choisit quels constats transformer en plans. L’IA propose, l’équipe décide. Ce contrôle humain reste dans la boucle.
Utile pour les équipes, pas seulement les tests individuels
La valeur principale de shadcn/improve apparaît avec des équipes qui ont des codebases actives. Un monorepo volumineux, une application avec de la dette technique accumulée ou un produit multi-modules bénéficient d’un outil qui transforme des constats dispersés en plans révisables.
La commande /improve branch limite l’audit aux changements de la branche courante, ce qui permet de détecter les problèmes avant de solliciter une revue humaine. Pour les équipes qui utilisent déjà GitHub Issues, l’option --issues publie directement les plans sous forme de tâches.
| Cas d’usage | Comment shadcn/improve aide |
|---|---|
| Audit initial | Identifie et priorise les problèmes |
| Revue avant PR | Analyse les changements spécifiques |
| Réduction dette technique | Transforme constats en plans exploitables |
| Sécurité | Concentre la revue sur les risques concrets |
| Performance | Cible les goulets avec preuve à l’appui |
| Backlog technique | Publie des plans en tant qu’issues |
| Agents moins coûteux | Donne des instructions claires et vérifiables |
| Revue de plans | Critique et améliore des spécifications antérieures |
La commande /improve reconcile est aussi utile que l’audit initial : elle vérifie quels plans restent valides, lesquels sont bloqués, lesquels ont été résolus par d’autres moyens et lesquels doivent être mis à jour suite aux changements du dépôt. Dans un contexte réel, le backlog technique évolue vite.
Moins de code à la volée, plus de processus
Beaucoup de développeurs demandent simplement à un agent de faire des changements importants, puis acceptent le résultat si ça semble fonctionner. Cette approche convient pour des prototypes, pas pour un logiciel maintenu par des équipes avec des tests, de la sécurité et des conventions.
shadcn/improve propose une alternative plus structurée. Elle n’enlève pas la rapidité des agents, mais l’encadre : on audite, on priorise, on planifie, on exécute dans un environnement isolé, puis le décideur humain tranche avant de fusionner. Les évolutions récentes dans les modèles de génération comme DiffusionGemma montrent que l’architecture des LLM eux-mêmes change pour gagner en maîtrise et en prévisibilité, ce qui s’aligne avec l’approche de shadcn/improve.
Ce modèle suit une tendance qui se confirme en développement IA : de meilleurs résultats viennent de flux où chaque modèle a une fonction précise. Le modèle cher agit comme architecte. Le modèle économique exécute. Les tests jouent le rôle de juge automatique. Le développeur garde la décision finale.
Une idée simple dans un dépôt open source
shadcn/improve ne promet pas de remplacer une équipe d’ingénierie. Au contraire : il part du principe que l’équipe existe, que le code compte et que le contrôle humain est non négociable. Sa valeur est de réduire le chaos généré par l’IA dans le développement, en produisant des plans clairs, lisibles, discutables, exécutables et vérifiables.
Sa nature open source et gratuite rend la démarche particulièrement accessible. Chaque équipe peut l’essayer sans s’engager dans une plateforme propriétaire. Si ça correspond, on l’intègre. Sinon, les plans restent en Markdown et l’apprentissage demeure. L’IA pour programmer n’a pas besoin de plus de magie, mais de meilleurs processus. shadcn/improve va dans cette direction.
FAQ
Qu’est-ce que shadcn/improve ?
C’est une Agent Skill open source sous licence MIT qui audite un dépôt, détecte des améliorations et génère des plans de mise en œuvre en Markdown, exécutables par d’autres agents ou développeurs.
Pourquoi utiliser un gros modèle pour l’audit et un petit pour l’exécution ?
L’audit exige de comprendre l’architecture et de juger ce qui vaut la peine d’être corrigé. L’exécution suit des instructions précises, une tâche où un modèle moins puissant suffit. Ce partage réduit significativement les coûts en tokens.
shadcn/improve modifie-t-il directement le code ?
Non. Il écrit des plans dans le dossier plans/. L’implémentation peut être confiée à un autre agent dans un environnement isolé, mais la fusion reste à la charge de l’utilisateur.
Quel problème résout-il face aux autres agents de code ?
Il limite l’improvisation et les coûts. Il confie au modèle capable ce qui a le plus de valeur (analyser et planifier), puis laisse des agents moins chers exécuter des tâches bien définies avec des vérifications intégrées.
