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.

Implémentation d’une fonctionnalité à partir d’un design

“Implémentez la page de tarification à partir de ce fichier Figma : https://figma.com/file/abc123/Pricing-Page. Concentrez-vous sur le frame « Pricing Section ». Utilisez notre configuration Tailwind dans tailwind.config.ts pour les couleurs et les espacements. Réutilisez les composants Card et Button existants depuis src/components/ui/. Après l’implémentation, lancez le serveur de développement et prenez des captures d’écran aux largeurs desktop (1440px) et mobile (375px). N’ouvrez pas de PR tant qu’elle ne correspond pas au design.”
Pourquoi est-ce bien ? Référence le fichier Figma spécifique, nomme le frame exact, s’appuie sur le design system du projet et sur les composants existants, et indique à Devin de vérifier visuellement son travail avant d’ouvrir une PR. Avec le Figma MCP connecté, Devin peut lire directement les design tokens depuis le fichier.

Enquête sur un bug en production

“Les utilisateurs signalent des erreurs 500 sur la page de paiement. Utilisez le Sentry MCP pour récupérer les dernières stack traces pour le projet payments-api. Vérifiez la base de données pour tout problème de données lié. Identifiez la cause principale, corrigez-la et ajoutez un test de non-régression. Ajoutez le lien vers le ticket Sentry dans la description de la PR.”
Pourquoi est-ce bien ? Oriente Devin vers les bons outils (intégrations MCP), fournit un chemin d’investigation clair et définit le livrable attendu (correctif + test de non-régression + PR).

​
Mauvais

Revue de code trop ouverte

« Trouve les problèmes dans notre base de code et corrige-les »
Pourquoi est-ce mauvais ? La demande est trop vague et ouverte. Il n’y a aucun critère de réussite et aucun moyen pour Devin de savoir quand il a terminé.À la place : Utilisez Devin Review pour une revue de code automatisée sur des pull requests (PR) spécifiques, ou donnez à Devin une tâche ciblée, par exemple : « Trouve et corrige toutes les utilisations de l’API obsolète oldLogger dans src/services/. »

Demandes visuelles purement subjectives

« Rends la landing page plus attrayante »
Pourquoi est-ce mauvais ? « Plus attrayante » est subjectif et Devin n’a aucun critère à viser. Devin peut créer des interfaces utilisateur fonctionnelles et implémenter des designs à partir de spécifications, mais il ne peut pas prendre seul de décisions esthétiques.À la place : Fournissez un design Figma, un site de référence ou des modifications précises : « Augmente la taille de police de la section hero à 48 px, ajoute un padding de 32 px et utilise la couleur indigo-500 de notre configuration Tailwind. »

Projets très complexes et vagues

« Crée une nouvelle architecture de microservices pour notre application. »
Pourquoi est-ce mauvais ? C’est une tâche très vaste et non structurée. Elle nécessite de nombreuses décisions d’architecture, des arbitrages et un contexte qui ne figurent pas dans la demande.À la place, décomposez-la :
  1. Utilisez Ask Devin pour analyser votre base de code et cartographier les dépendances
  2. Demandez à Devin de proposer des architectures spécifiques avec leurs avantages et inconvénients
  3. Créez des sessions distinctes pour implémenter chaque service — exécutez-les en parallèle avec les batch sessions