Claude et Ralph : Deux Approches pour Construire un DatePicker Complexe Activé par l'IA dans le Développement Produit

L'histoire du DatePicker dans cet article n'est importante non pas pour elle-même, mais comme modèle d'un choix que presque toute équipe produit envisage aujourd'hui : demander à un réseau de neurones de faire rapidement un brouillon d'une interface fonctionnelle, ou d'abord construire un système où l'IA écrira du code dans des règles préétablies. En utilisant un composant de calendrier accessible pour React comme exemple, les auteurs montrent que le débat ne porte pas sur quel modèle est plus intelligent, mais sur qui gère la complexité dans le processus — l'ingénieur ou le hasard. Les auteurs appellent le premier chemin AI-drafting.

La logique est simple : prenez une requête détaillée basée sur les recommandations WAI-ARIA APG et donnez-la à un modèle comme Claude. Le résultat est un DatePicker presque prêt qui résout vraiment la majorité du problème au départ. Mais alors émergent des problèmes rarement visibles dans cette belle première réponse.

L'adhésion aveugle à la spécification peut entrer en conflit avec le comportement réel des lecteurs d'écran, des gestionnaires comme onBlur et onClick commencent à diverger l'un de l'autre et causent des défaillances visuelles, et des ajustements subtils d'accessibilité — par exemple, le mode aria-live pour annoncer les changements — sont impossibles à deviner sans test en direct. Au final, l'équipe obtient non pas tant une architecture finie qu'un brouillon réussi, qu'il faut ensuite stabiliser manuellement. Le deuxième chemin est l'ingénierie systématique.

Ici, l'IA ne reçoit pas une tâche du style « fais un DatePicker », mais est placée dans une boucle de production rigoureusement conçue. Les auteurs ont utilisé un agent autonome basé sur Ralph reposant sur codex cli et un petit modèle, mais l'élément clé n'était pas le modèle, mais l'environnement. L'agent recevait un PRD avec des exigences fixes, un ensemble de tâches atomiques dans tasks.

json et des règles système qui interdisaient de s'écarter de l'architecture cible. Les conditions obligatoires incluaient une API en lecture seule, une navigation complète au clavier et un balisage ARIA correct. Après chaque étape, le code passait par une boucle de vérification externe : des tests unitaires et des vérifications a11y via Vitest et Playwright, la construction Vite et le contrôle de type TypeScript.

Tant que la tâche actuelle ne passait pas la vérification, l'agent ne pouvait pas avancer. Ce système change non seulement la discipline de développement, mais aussi la forme du code lui-même. Au lieu d'un composant monolithique, une structure à trois couches émerge progressivement : un noyau pur avec des dates et une logique de saisie, une couche UI séparée de composants maximalement simples et une couche de liaison qui gère l'état et l'interaction.

Cela coûte plus cher au départ : vous devez écrire des exigences, décomposer le travail, configurer un vérificateur et dépenser plus de jetons. Mais le coût des changements diminue avec le temps. Si vous devez ajouter une nouvelle fonction ou corriger un algorithme, les modifications sont apportées à une couche spécifique, non dispersées dans tout le composant.

Cependant, les auteurs montrent honnêtement que même une bonne architecture ne protège pas automatiquement : un petit changement dans le calcul des semaines a provoqué une défaillance en cascade, nous rappelant que des contrats explicites et une validation automatique sont nécessaires entre les couches. L'observation la plus utile de l'article concerne les types d'erreurs. En mode AI-drafting, les défauts principaux vivent aux coutures : événements, état, rendu, accessibilité, intégration de plusieurs morceaux de code apparemment corrects.

Ceux-ci sont difficiles à détecter à l'avance, et le débogage nécessite souvent de garder le composant entier en tête à la fois. Dans l'approche systématique, les erreurs se déplacent plus souvent vers le niveau des fonctions et modules individuels. Si le calendrier traite incorrectement février lors d'une année bissextile, l'équipe cherche le problème non dans l'interface entière, mais dans une fonction pure qui peut être rapidement isolée avec un test et corrigée sans effets secondaires.

Cela conduit à une conclusion pratique : le brouillon rapide convient bien aux MVP, prototypes, hackathons et utilitaires à usage unique où la vitesse prime sur le support à long terme. L'approche systématique est justifiée là où un composant deviendra partie d'un design system, du cœur du produit ou d'un projet de longue durée. Qu'est-ce que cela signifie en pratique : l'IA est déjà capable d'accélérer drastiquement la création d'interfaces, mais la principale bifurcation ne réside pas entre les modèles, mais entre les modes de travail de l'équipe.

Si le coût d'une erreur est faible, vous pouvez viser la vitesse et accepter les retouches manuelles. Si un composant vivra longtemps et d'autres développeurs en dépendront, il est judicieux d'investir dans les exigences, les tests, les contrats et un processus qui limite la liberté de l'agent. L'étape suivante la plus réaliste est un hybride : concevoir le système selon les règles de l'ingénierie et confier aux réseaux de neurones des tâches routinières bien formalisées dans ces limites.