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 maximiser l’utilité de Devin. 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.

​
Exemple de prompt

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.
Essayez le bouton d’amélioration du prompt lorsque vous créez une session (cliquez sur le cercle d’avertissement jaune pour afficher les retours)
Bouton d'amélioration du prompt

​
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 confiant à 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. Demander à Devin d’exécuter des tâches très éloignées de ses capacités actuelles peut souvent conduire à de mauvais résultats.
  • Comment :
    • Lisez ce guide : Quand utiliser Devin
    • Surtout pour les tâches avancées, 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.
    • 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 : Attribuer des tâches en dehors des compétences clés de Devin
  • Pourquoi : Attribuer des tâches qui nécessitent des connaissances métier avancées ou des décisions de conception majeures sans accompagnement suffisant peut entraîner de l’inefficacité et un gaspillage d’ACUs.
  • Comment :
    • Évitez les tâches qui exigent une contribution créative importante ou une réflexion stratégique de haut niveau sans instructions ni références claires.
    • Évitez les tâches qui nécessitent de fortes capacités visuelles, par exemple implémenter des maquettes Figma, car même si Devin peut voir les pages web, il n’a pas une vision parfaite.
    • Évitez de demander à Devin de créer des applications mobiles puisqu’il n’a pas accès à un téléphone et ne peut pas facilement tester son travail.
  • Exemple : À ne pas faire : “Créer un nouveau système d’authentification pour mon site web à partir de zéro.”
  • Exemple : À ne pas faire : “Transformer cette maquette Figma en composant React.”
  • Exemple : À ne pas faire : “Construire une application d’achat propulsée par l’IA.”
À faire : collaborer en accomplissant des tâches partielles
  • Pourquoi : Parfois, il est plus rapide pour vous de terminer les 20 % restants d’une tâche.
  • Comment :
    • Laissez Devin gérer la majorité de l’implémentation, puis affinez le résultat.
    • Utilisez Devin pour accélérer les parties du workflow qui sont répétitives, pendant que vous vous concentrez sur les aspects les plus critiques.
  • Exemple : À faire : « Génère le code de base initial pour le nouvel endpoint d’API, puis je l’intégrerai au système d’authentification existant. »
À ne pas faire : compter uniquement sur Devin pour des projets complexes de bout en bout
  • Pourquoi : Trop compter sur Devin pour des tâches qui nécessitent une compréhension fine ou une résolution de problèmes créative peut entraîner des retards et des résultats sous-optimaux.
  • Comment :
    • Évitez de confier à Devin des tâches dont vous savez qu’elles demanderont une intervention humaine significative pour être menées efficacement à bien.
  • Exemple : À ne pas faire : « Développe toute l’infrastructure backend pour notre nouvelle fonctionnalité d’IA générative. »
À 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.
  • 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.”
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.

​
Conclusion

Définissez les tâches avec suffisamment de structure et de clarté pour obtenir des résultats fiables et satisfaisants.