La Boucle ShadCN Est La Meilleure Solution Pour Votre Interface Défaillante

ShadCN est l'une des bibliothèques d'interface les plus populaires, mais utiliser des agents IA pour construire avec peut causer des problèmes majeurs. Alors que les pages d'atterrissage simples fonctionnent bien, le développement de nouvelles applications ou fonctionnalités entraîne des ruptures qui affectent d'autres parties de l'application. Les agents IA testent leur code mais deviennent peu fiables avec des contextes volumineux. Il est donc nécessaire de trouver un moyen de garantir que les agents terminent le travail qui leur est confié sans abandonner prématurément.

La solution vient du concept de boucles agentiques, et Anthropic résout ce problème avec la boucle RALPH. Le créateur a d'abord échoué à implémenter RALPH, mais a réalisé que le problème venait du processus et non de la boucle elle-même. RALPH est un nouveau plugin publié par Anthropic basé sur une technique d'un tiers qu'ils ont implémentée en open source. La boucle utilise des hooks d'arrêt de Claude Code qui s'exécutent quand Claude arrête de produire une réponse, lui renvoyant son fichier de prompt initial pour améliorer itérativement son travail. L'agent ne sort de la boucle que lorsqu'il produit une 'promesse d'achèvement', qui peut être n'importe quel mot choisi (par exemple 'complete'), garantissant qu'il ne quitte pas simplement quand il le souhaite.

Après installation du plugin, trois commandes sont disponibles : la commande de boucle RALPH, une commande d'annulation et une commande d'aide. Dans la commande de boucle, il faut fournir le prompt transmis à l'agent de manière répétée. Pour éviter les boucles infinies lorsque l'agent reçoit une tâche impossible à résoudre, définir un nombre maximum d'itérations est une très bonne pratique. Le dépôt GitHub contient des meilleures pratiques pour les prompts à donner à la boucle RALPH. Cette vidéo se concentre spécifiquement sur les prompts liés au flux de travail d'interface qui sera démontré dans les sections suivantes.

Deux fonctionnalités seront implémentées : une palette de commandes pour rechercher dans l'application et exécuter des commandes, et une vue tableau dans la base de données similaire à Notion. Pour garantir que ces nouvelles fonctionnalités ne cassent pas d'autres parties de l'application, on commence par les tests en utilisant le développement piloté par les tests (TDD). Claude Code peut configurer la structure TDD automatiquement, créant un dossier de tests de bout en bout, un dossier de captures d'écran pour vérifier les problèmes d'interface et les tests correspondants. L'approche TDD signifie que les tests sont écrits avant le code, donc les tests initiaux échoueront toujours. Ensuite, on écrit la quantité minimale de code nécessaire pour passer ces tests, puis on refactorise et ajoute plus de fonctionnalités tout en s'assurant que les tests passent toujours.

Les tests sont automatisés et Playwright peut être importé pour la vérification visuelle, mais contrairement à ce qu'on pourrait penser, le MCP Playwright n'est pas utilisé pour vérifier de manière autonome via le navigateur. Avec le TDD, pour chaque comportement fonctionnel, des captures d'écran peuvent être prises. Par exemple, si le comportement fonctionnel est d'ajouter une carte, la capture d'écran montrerait une carte ajoutée au tableau. L'agent IA doit simplement regarder ces captures d'écran et s'assurer qu'il n'y a pas de problèmes dans la façon dont les composants ShadCN ont été implémentés. Ces fichiers de test garantissent que chaque fois que quelque chose de nouveau est ajouté ou pendant qu'une fonctionnalité est construite, toutes les exigences comportementales sont remplies, les captures d'écran servant purement à la vérification de l'interface.

Malgré l'existence du TDD, la boucle RALPH reste nécessaire car avec des tâches plus importantes et des fenêtres de contexte presque pleines, les modèles quittent brusquement leurs tâches et nécessitent une intervention humaine constante. Par conséquent, on peut avoir des tests écrits à l'avance pour tout type de fonction, puis utiliser la boucle pour indiquer à l'agent quoi faire afin qu'il puisse travailler de manière autonome. On lui dit quel flux de travail suivre et la condition pour produire la promesse d'achèvement. Dans ce cas, l'agent termine la tâche et sort de la boucle quand il passe les 25 tests uniques, garantissant un processus complètement autonome sans abandon prématuré.

En utilisant la commande slash RALPH, un prompt a été fourni pour construire itérativement la fonctionnalité de palette de commandes. Le prompt indiquait d'implémenter la fonctionnalité avec quelques exigences de base (bien que les exigences puissent aussi être trouvées dans les tests) et décrivait tout le flux de travail. Dans ce flux, l'agent devait commencer par exécuter les tests, sachant qu'ils échoueraient, puis implémenter les composants pour les faire passer. C'était tout l'objectif du processus. Pour une tâche beaucoup plus large, lorsque la fenêtre de contexte se remplit ou que Claude est confus, il quitterait automatiquement, mais ne produirait jamais la promesse d'achèvement. Sans promesse, le prompt serait renvoyé à nouveau et l'agent devrait tout recommencer, continuant itérativement jusqu'à la réussite.

Comme c'était une tâche plus petite, l'agent a pu tout implémenter d'un coup, écrire tous les composants et faire passer tous les tests. Après que les tests passent, le flux de travail lui indique de revoir toutes les captures d'écran de la palette de commandes. Ces captures d'écran prises à différentes étapes s'assurent que l'interface, que ce soit ShadCN ou toute autre bibliothèque de composants, est implémentée correctement sans problèmes mineurs. Après cette vérification, l'agent devait exécuter les tests à nouveau pour s'assurer qu'ils passaient toujours après les changements d'interface. Puisque tous les tests passaient et que les captures d'écran étaient revues, l'agent a produit la promesse d'achèvement, arrêtant la boucle. Un gros problème non remarqué dans cette fonctionnalité allait bientôt se révéler.

Le vrai problème est apparu lors de l'implémentation de la vue tableau avec le même prompt et flux de travail similaire. L'agent a complété toutes les exigences d'un coup, s'assurant que tous les tests passaient. Cependant, pendant ce processus, le nombre de tests réussis diminuait parfois car en changeant quelque chose, l'agent cassait autre chose, démontrant l'importance du TDD avec ses tests récursifs. Le principal problème est survenu après vérification de l'interface : bien que la plupart des choses étaient implémentées correctement, l'agent avait complètement manqué certaines erreurs d'interface évidentes. Ces erreurs apparaissaient même dans les captures d'écran que l'agent était censé vérifier, révélant un échec majeur du processus.

Après analyse de ce qui s'était réellement mal passé, le vrai problème identifié était un échec de processus, spécifiquement en termes de correction de l'interface. L'agent avait bien passé tous les tests parce qu'il était censé exécuter les fichiers de test encore et encore, mais il n'y avait pas de test spécifique pour l'interface autre que les captures d'écran. L'agent a jeté un coup d'œil à quelques-unes d'entre elles, ignorant même certaines erreurs d'interface qu'il avait vues. Certains fichiers de captures d'écran ont été complètement ignorés. Le principal problème était donc que l'agent a produit sa déclaration de promesse prématurément sans vérifier si l'interface était réellement corrigée, nécessitant une refonte complète du processus de vérification.

Après une session de brainstorming et consultation des meilleures pratiques du dépôt, des règles spécifiques et un changement de processus ont été proposés pour garantir que l'interface soit toujours correcte. Le changement principal concernait la vérification des captures d'écran, pas les tests qui continueraient à s'exécuter normalement. Le nouveau protocole ajoutait un simple préfixe à chaque image indiquant à Claude s'il avait lu la capture d'écran ou non. Lors de la première implémentation, l'agent ne lisait toujours pas toutes les images : il en lisait quelques-unes, écrivait 'vérifié' dessus et quittait tôt. Pour résoudre cela, l'agent a été encouragé à penser différemment : après avoir renommé toutes les captures d'écran, il ne devait pas encore produire la promesse, laissant la prochaine itération confirmer l'achèvement. Cela garantissait qu'au moins deux boucles s'exécuteraient.

Dans la prochaine vérification, Claude vérifie que tous les fichiers ont le préfixe 'vérifié', ce qui nécessitait de changer les tests et de séparer la vérification des images des tests fonctionnels. L'itération suivante s'assure que toutes les images ont des résultats vérifiés et si Claude en manque, il les regarde à nouveau et corrige la sortie. Avec ce changement, les petites erreurs d'interface ont finalement été corrigées et l'agent a pu implémenter toutes les fonctionnalités correctement. Lors de la boucle suivante, l'agent a exécuté les tests à nouveau, trouvé des erreurs, les a corrigées, et parce que tous les fichiers avaient le mot 'vérifié', il a exécuté un test final. Cette fois, la tâche s'est terminée en deux boucles avec toutes les erreurs d'interface majeures corrigées dans l'application.

Automata est présenté comme un service qui applique ces flux de travail IA avancés directement aux projets clients. Après avoir enseigné à des millions de personnes comment construire avec l'IA, l'équipe a commencé à implémenter ces flux de travail eux-mêmes et a découvert qu'ils pouvaient construire de meilleurs produits plus rapidement que jamais. Automata aide à donner vie aux idées, que ce soient des applications ou des sites web, servant de copilote technique pour ceux qui ont des idées mais pas d'équipe technique. Ils appliquent les mêmes flux de travail enseignés à des millions de personnes, transformant les concepts en véritables solutions fonctionnelles sans les tracas d'embaucher ou de gérer une équipe de développement. Les spectateurs peuvent les contacter à hello@automata.dev ou soutenir la chaîne via le bouton Super Thanks.