Passer au contenu principal
Le choix du bon cas d’usage pour Devin est essentiel pour maximiser l’efficacité et le retour sur investissement (ROI). Vous trouverez ci-dessous les meilleures pratiques pour sélectionner un cas d’usage qui tire parti des points forts de Devin.

Meilleurs cas d’usage pour l’offre Enterprise

Critères d’un cas d’usage idéal
Projets importants, à forte valeur métier, pouvant être décomposés en sous-tâches isolées et répétitives.
Tâches nécessitant moins de 90 minutes de travail d’ingénierie effectué manuellement.
Tâches rétrocompatibles pouvant être validées et fusionnées indépendamment.

Exigences idéales pour Devin

Exigence
Volume important de sous-tâches répétitives (slices)
Tâches d’une complexité de niveau ingénieur junior
Tâches isolées et incrémentales
Sous-tâches objectives et vérifiables
(Recommandé) Dépendances minimales vis-à-vis du projet
Si votre tâche remplit la plupart ou la totalité de ces exigences, elle est idéale à confier à Devin.

Structurer le travail de Devin

Choisir le bon type de tâche est essentiel pour maximiser la fiabilité de Devin.
ScénarioEnjeu de fiabilitéType de tâche
Demander à Devin de créer des fonctionnalités entièrement nouvelles complexes (même si répétitives)Fiabilité plus faible à grande échelleTall & Deep
Confier à Devin des tâches simples et bien définiesTrès fiable et efficaceWide & Shallow

Étroit & profond vs. large & superficiel

Comparaison entre étroit-profond et large-superficiel
Un important backlog de tâches simples, faciles à mettre à l’échelle horizontalement (par exemple, la résolution de problèmes SonarQube) peut générer un retour sur investissement (ROI) significatif lorsqu’il est répliqué sur des milliers d’itérations. Diagramme de changements horizontaux
Plus chaque tranche est simple, plus le projet global est fiable.

Que découper

Excellents cas d’utilisation pour Devin :
  • Migrations
  • Refactorisations
  • Modernisations
  • Backlogs de dette technique
Par exemple, lors d’une migration de code, vous devez la découper en segments isolés, chacun géré par une session Devin distincte. Slicing use cases illustration

Vérification

Une slice doit être la plus petite unité atomique du projet.
Exemples de slices
Fichier
Notebook
Module
ExigenceDétails
Limite de tempsChaque slice doit nécessiter moins de 90 minutes de travail d’ingénierie manuel.
VérificationDoit inclure un moyen de valider les changements de code, par exemple :
- Exécuter les tests
- Compiler ou construire le code
- Lancer les vérifications CI
- Utiliser un script de vérification personnalisé
Devin doit disposer d’un mécanisme clair de vérification du succès ou de l’échec.
Évitez les tâches comportant des dépendances excessives ou des systèmes externes. Devin excelle sur les tâches de développement.
Schéma de rétrocompatibilité

Exécution parallèle

ExigenceDescription
IsolationChaque segment doit être indépendant et rétrocompatible.
Exécution parallèleUtilisez le parallélisme de Devin pour exécuter les segments simultanément.
Revue humaineUne fois chaque segment terminé, il doit être soumis à une revue par un humain avant d’être fusionné dans main.
Visualisation de l’exécution parallèle

Considérations de passage à l’échelle

Schéma global du modèle
PrincipeDescription
Fiabilité au niveau du sliceDevin est optimisé pour une fiabilité maximale au niveau de chaque slice individuel.
Considération de passage à l’échelleLors du passage à l’échelle à des milliers de slices, maintenir une fiabilité élevée est essentiel.
Impact des erreursMême un faible taux d’erreur peut se cumuler lorsqu’on exécute à grande échelle.

Bonnes pratiques pour la définition des tâches

ExigenceDescription
Détails des étapes clairsFournissez des instructions explicites pour chaque sous-tâche.
Référence de bout en boutUn guide détaillé ou une vidéo aide à garantir la cohérence.
Exemples avant/aprèsProposez plusieurs exemples de code avant/après (paires entrée/sortie).
Accès aux dépendancesAssurez-vous que Devin dispose de toutes les dépendances nécessaires pour la tâche.
Devin excelle sur les tâches récurrentes de dette technique (par exemple, revues de pull requests (PR), automatisation de la QA) lorsqu’elles sont correctement découpées et structurées.
Les migrations, modernisations et refactorings sont d’excellents cas d’usage si elles peuvent être abordées de manière incrémentale. Par exemple, une migration de l’ensemble du dépôt nécessitant tous les changements en une seule fois n’est pas recommandée.
Étude de cas : Étude de cas de migration Nubank