Passer au contenu principal
Assurez-vous de lire Quand utiliser Devin et Bien instruire Devin pour plus de conseils essentiels.

Ajout d'un nouvel endpoint d'API

Bonne approche
“Crée un nouvel endpoint /users/stats qui renvoie un objet JSON avec le nombre d’utilisateurs et l’âge moyen à l’inscription. Utilise notre table users existante dans PostgreSQL. Réfère-toi à l’endpoint /orders/stats dans statsController.js pour voir comment nous structurons les réponses. Assure-toi que le nouvel endpoint soit couvert par la suite de tests StatsController.test.js.”
Pourquoi cela fonctionne :
  • Spécifie clairement la route et le format de réponse attendu
  • Fait référence à du code existant comme modèle
  • Définit la source de données (table users)
  • Inclut les exigences de couverture de tests


Mauvaise approche
“Ajoute un endpoint de statistiques utilisateurs.”
Pourquoi cela échoue :
  • Ne précise pas quelles statistiques inclure
  • Ne mentionne aucune source de données
  • Aucune référence aux modèles existants
  • Aucune exigence de tests

Fonctionnalité frontend pour afficher des données

Bonne approche
“Dans UserProfileComponent, ajoute un menu déroulant qui affiche une liste de rôles d’utilisateur (admin, editor, viewer). Utilise les styles de DropdownBase. Lorsqu’un rôle est sélectionné, appelle l’API existante pour définir le rôle de l’utilisateur. Valide en vérifiant que la sélection met à jour le rôle de l’utilisateur dans la base de données. Réfère-toi à ta Knowledge pour savoir comment tester correctement.”
Pourquoi cela fonctionne :
  • Nomme des composants spécifiques
  • Énumère précisément les rôles à inclure
  • Fait référence à un composant de style existant
  • Définit le flux d’interaction utilisateur
  • Inclut des étapes de validation


Mauvaise approche
“Rends la page de profil utilisateur plus conviviale. Ajoute un moyen de changer les rôles et de confirmer que ça fonctionne.”
Pourquoi cela échoue :
  • “Conviviale” est subjectif
  • Aucun composant d’interface spécifique mentionné
  • Flux d’interaction utilisateur peu clair
  • Critères de validation vagues

​
Autres exemples

​
Bon

Écriture de tests unitaires

“Ajoutez des tests Jest pour les méthodes d’AuthService : login et logout. Assurez-vous que la couverture de test pour ces deux fonctions est d’au moins 80 %. Utilisez UserService.test.js comme exemple. Après l’implémentation, exécutez npm test -- --coverage et vérifiez que le rapport de couverture indique >80 % pour les deux fonctions. Confirmez également que les tests réussissent avec des identifiants valides et invalides, et que logout efface correctement les données de session.”
Pourquoi est-ce bien ? Indicateur de réussite clair (80 % de couverture), références pour guider Devin (UserService.test.js) et périmètre bien défini avec des étapes de vérification spécifiques.

Migration ou refactorisation de code existant

“Migrez logger.js de JavaScript vers TypeScript. Nous avons déjà un tsconfig.json et une suite de tests LoggerTest.test.js pour la validation. Assurez-vous que la compilation se fait sans erreurs et veillez à ne pas modifier la configuration existante ! Après la migration, vérifiez en : 1) exécutant tsc pour confirmer l’absence d’erreurs de typage, 2) exécutant la suite de tests avec npm test LoggerTest.test.js pour garantir que tous les tests réussissent, et 3) vérifiant que tous les appels existants aux méthodes du logger dans l’ensemble du code fonctionnent toujours sans erreurs de typage.”
Pourquoi est-ce bien ? Il y a un modèle clair (tsconfig.json) et une suite de tests pour un retour immédiat, ainsi que des étapes spécifiques de compilation et de validation.

Mise à jour des API ou des requêtes de base de données

“Nous passons de pg à sequelize (voir https://sequelize.org/api/v6/identifiers). Veuillez mettre à jour les requêtes de UserModel pour utiliser les méthodes Sequelize. Référez-vous à OrderModel pour voir comment nous le faisons dans cette base de code. Après l’implémentation, vérifiez en : 1) exécutant npm run test:integration UserModel.test.js pour confirmer que tous les tests d’intégration réussissent, 2) confirmant que les performances des requêtes ne se sont pas dégradées en vérifiant le temps d’exécution sur un jeu de données de test de 1000 utilisateurs, et 3) validant que toutes les opérations CRUD maintiennent toujours l’intégrité des données en exécutant npm run test:e2e user-flows.test.js.”
Pourquoi est-ce bien ? Devin peut reproduire un modèle connu et il existe des références explicites (OrderModel.js). Un lien vers la documentation indique à Devin où se référer, et les étapes de vérification des performances et des fonctionnalités sont explicites, avec des commandes de test précises.

​
Mauvais

Revue de code sans cadre précis

“Identifier les problèmes dans notre codebase et les corriger”
Pourquoi est-ce mauvais ? La demande est trop vague et demande à Devin d’accomplir trop de tâches en une seule session. Devin peut se perdre au cours de longues sessions.

Tâches de conception visuelle

“Reproduire exactement ce qui est montré dans cette maquette Figma”
Pourquoi est-ce mauvais ? Il s’agit d’une demande visuelle subjective. Devin ne peut pas « voir » comme les humains et ne reproduira pas parfaitement les détails. Ce n’est pas un cas d’usage pour lequel il est optimisé.

Projets très complexes et vagues

“Concevoir une nouvelle architecture de microservices pour notre application.”
Pourquoi est-ce mauvais ? Il s’agit d’une tâche très vaste et non structurée, qui nécessite des décisions d’architecture et des compromis.À la place, décomposez les projets complexes en phases :
  1. Demandez à Devin d’analyser votre codebase
  2. Demandez à Devin de proposer des architectures spécifiques
  3. Créez des sessions distinctes pour implémenter chaque partie