Passer au contenu principal
La chose la plus importante à garder à l’esprit lorsque vous donnez des instructions à Devin, c’est d’être aussi précis que possible. Tout comme vous fourniriez un cahier des charges détaillé lorsque vous demandez à un collègue d’écrire du code, vous devriez faire de même avec Devin. Ce guide vous aidera à structurer vos instructions/prompts pour utiliser Devin efficacement. Pour des approches plus générales sur la manière de travailler efficacement avec des agents de codage, consultez également notre guide Coding Agents 101.

​
Comment rédiger des prompts efficaces

Voici un exemple de prompt qui illustre une consigne bien formulée :
Dans le dépôt Devin, je souhaite que vous créiez un outil qui surveille l’utilisation de la RAM et du CPU des machines distantes sur lesquelles Devin s’exécute. Pour ce faire, veuillez effectuer les tâches suivantes :
  • Créer une tâche en arrière-plan qui se lance automatiquement lorsque devin.rs démarre.
  • Cette tâche doit ouvrir une connexion à toutes les machines distantes forkées utilisées dans cette session Devin et surveiller leur utilisation de la RAM et du CPU.
  • Si l’utilisation dépasse 80 % de la ressource disponible, émettre un nouveau type d’événement Devin pour le signaler (consultez la façon dont nous utilisons Kafka).
  • Concevoir l’architecture de manière intelligente afin de ne pas bloquer les autres opérations. Vous devez comprendre comment tous les conteneurs des sous-agents Devin interagissent entre eux.

​
Pourquoi cela fonctionne bien

Fournit un contexte utile

  • Détail : Précise le dépôt Devin et l’objectif plus large (surveiller l’utilisation des ressources).
  • Avantage : Devin connaît clairement le périmètre et le domaine.

Donne des instructions pas à pas

  • Détail : Des tâches comme create a background task et emit an event at 80% usage.
  • Avantage : Décompose le travail en parties logiques.

Définit des critères de réussite clairs

  • Détail : Définit la « réussite » comme l’émission d’un événement spécifique à 80 % d’utilisation.
  • Avantage : Devin sait exactement ce qu’il doit accomplir.

Fait référence aux patterns et au code existants

  • Détail : Mentionne Kafka et les interactions avec les conteneurs.
  • Avantage : Encourage la réutilisation de code ou d’approches de conception établis.

​
Bonnes pratiques : à faire et à éviter

À faire : donner des directives claires
  • Pourquoi : Devin peut se retrouver bloqué sans chemin clair ou face à trop d’interprétations possibles.
  • Comment :
    • Prendre pour Devin les décisions et arbitrages importants.
    • Proposer des choix de conception précis et des stratégies de mise en œuvre.
    • Définir un périmètre, des limites et des critères de réussite clairs.
  • Exemple : “Optimize the getOrderDetails query in orderService.js by adding a composite index on the order_id and product_id columns in the order_items table. Refactor the query to replace the existing correlated subquery with a JOIN to the products table for fetching product details.”
À ne pas faire : laisser les décisions ouvertes
  • Pourquoi : Des consignes vagues peuvent amener Devin à implémenter des solutions qui ne correspondent pas à vos besoins réels.
  • Comment :
    • Évitez de formuler des demandes qui amènent Devin à prendre des décisions de conception ou d’implémentation importantes sans orientation, ce qui peut conduire à des résultats inattendus.
  • Exemple : À ne pas faire : “Improve our database’s performance.”
À faire : choisir des tâches pour lesquelles Devin est particulièrement adapté
  • Pourquoi :
    • Maximiser les résultats : En attribuant à Devin des tâches qui correspondent à ses capacités, vous obtenez les meilleurs résultats pour le moindre effort et le moins d’ACUs consommés.
  • Comment :
    • Lisez ce guide : Quand utiliser Devin
    • Fournissez des exemples, des modules, des ressources et des modèles que Devin peut suivre.
      • Partagez des liens directs vers des sites de documentation pour que Devin puisse lire des détails comme les corps de requêtes d’API et des fonctionnalités qu’il ne connaît peut-être pas.
      • Partagez des noms de fichiers précis que vous voulez que Devin examine et dont il s’inspire.
    • Connectez des intégrations MCP pour donner à Devin accès à des designs Figma, des bases de données, des outils de monitoring, etc.
    • Exemple : À faire : “Refactoriser la gestion d’état dans le composant Header pour utiliser le hook useReducer de React afin d’améliorer la scalabilité et la maintenabilité. Veillez à ce que toute la fonctionnalité existante soit préservée et ajoutez des tests unitaires pour couvrir la nouvelle logique d’état.”
    • Exemple : À faire : “Utiliser authTemplate.rs comme référence pour conserver une gestion des erreurs cohérente.”
    • Exemple : À faire : “Consulter la documentation officielle de Sequelize sur https://sequelize.org/docs/v6/getting-started/ pour les étapes de migration.”
À ne pas faire : omettre de fournir du contexte pour les tâches complexes
  • Pourquoi : Même si Devin peut gérer un travail complexe, il donne les meilleurs résultats lorsque vous fournissez du contexte et des instructions claires.
  • Comment :
    • Pour les tâches nécessitant des connaissances métier, fournissez de la documentation, des exemples ou des références pertinents.
    • Pour les tâches visuelles, fournissez des fichiers Figma via le Figma MCP, des designs de référence ou des spécifications détaillées — Devin peut s’appuyer dessus, mais n’inventera pas lui‑même l’esthétique.
    • Pour les applications mobiles, gardez à l’esprit que Devin n’a pas accès à un émulateur de téléphone, donc fournissez des critères de test clairs.
  • Exemple : À ne pas faire : “Make the app look better” — fournissez plutôt des spécifications de design précises ou un fichier Figma.
  • Exemple : À ne pas faire : “Improve our database’s performance” — précisez plutôt quelles requêtes optimiser et quels indicateurs viser.
À faire : établir des contrôles clairs et fréquents
  • Pourquoi : des retours fréquents (de votre part et via les tests/contrôles/linters) permettent à Devin de corriger efficacement ses erreurs.
  • Comment :
    • Utilisez des tests (unitaires/d’intégration) pour confirmer la correction du résultat.
    • Conservez les validations de build, les contrôles de lint et l’analyse statique pour assurer la qualité du code.
    • Activez Devin Review avec Auto-Fix afin que Devin réponde automatiquement aux commentaires de revue et aux échecs de CI — ce qui crée une boucle fermée où les PR s’affinent jusqu’à atteindre une qualité prête à être fusionnée, sans que vous ayez à intervenir.
  • Exemple : À faire : “Run npm test after each iteration.”
  • Exemple : À faire : “Ensure the pipeline on CircleCI doesn’t fail.”
  • Exemple : À faire : “Pass ESLint/Prettier checks before pushing any commits.”
À ne pas faire : négliger de fournir des retours
  • Pourquoi : sans retours, Devin ne saura pas si ses solutions répondent à vos exigences.
  • Comment :
    • Évitez d’assigner des tâches sans préciser comment vous les évaluerez.
À faire : définir des points de contrôle clairs et des sous-tâches
  • Pourquoi : découper les tâches complexes en points de contrôle plus petits aide Devin à rester concentré et réduit les erreurs.
  • Comment :
    • Divisez les tâches en sous-tâches vérifiables et lancez une session Devin distincte pour chaque sous-tâche.
    • Définissez ce à quoi ressemble la réussite pour chaque sous-tâche et, si besoin, fixez des points de contrôle au sein de chaque sous-tâche.
    • Demandez à Devin de faire un compte rendu après avoir terminé chaque point de contrôle ou sous-tâche.
Exemples :
  • Exemple : À faire : “Lorsque vous travaillez avec le dataset, vérifiez qu’il contient au moins 500 lignes et les colonnes X, Y, Z.”
  • Exemple : À faire : “Lorsque vous modifiez l’API, confirmez que l’endpoint renvoie le statut 200 et inclut tous les champs requis.”
  • Exemple : À faire : “Lors de la mise à jour de l’UI, vérifiez que le composant s’affiche sans erreurs dans la console et correspond aux spécifications de design.”
À ne pas faire : ignorer les exigences de validation spécifiques
  • Pourquoi : sans étapes de validation définies, Devin ne peut pas terminer les tâches de manière fiable.
  • Comment :
    • Évitez les critères de réussite vagues.
    • Ne laissez pas les étapes de vérification implicites ou non définies.
  • Exemple : À ne pas faire : “Assurez-vous que ça fonctionne.”
Devin dispose d’un environnement de bureau complet — shell, IDE et navigateur. Dites à Devin de tester son propre travail avant d’ouvrir une pull request (PR) :
  • Lancer l’application : “Exécute npm run dev et vérifie que la nouvelle page s’affiche à l’URL /settings.”
  • Tests dans le navigateur : “Ouvre le navigateur, va sur la page de connexion et confirme que le flux OAuth se termine avec succès.”
  • Vérification visuelle : “Prends des captures d’écran aux largeurs desktop (1440 px) et mobile (375 px) et vérifie que la mise en page correspond au design.”
  • Enregistrement d’écran : “Enregistre-toi en train de tester le flux de paiement de bout en bout.”
Cela permet à Devin de faire la QA de ses changements de la même manière que vous le feriez — avant même que vous n’ayez besoin de regarder la PR.
Pour les tâches répétitives ou complexes, nous vous recommandons d’utiliser des playbooks et de les faire évoluer. Pour en savoir plus, consultez la section sur l’utilisation efficace des playbooks. Les playbooks sont des prompts réutilisables et partageables qui simplifient la délégation des tâches. Par exemple, si vous voulez que Devin traite des échecs récurrents de builds CI, créez un playbook qui inclut les étapes générales que Devin doit suivre à chaque fois.Pour un contexte persistant que Devin doit retenir d’une session à l’autre — comme des normes de code, des bugs courants et leurs correctifs, des workflows de déploiement ou la façon d’utiliser des outils internes — utilisez Knowledge. Les éléments Knowledge sont automatiquement rappelés lorsqu’ils sont pertinents, de sorte que vous n’avez pas besoin de répéter les mêmes consignes dans chaque prompt. Vous pouvez épingler Knowledge à des dépôts spécifiques ou l’appliquer globalement.
Playbooks vs. Knowledge : Utilisez les playbooks pour des procédures étape par étape liées à des tâches spécifiques. Utilisez Knowledge pour des conseils généraux, des conventions et du contexte qui s’appliquent de manière générale d’une session à l’autre.