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énario | Enjeu 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 échelle | Tall & Deep |
| Confier à Devin des tâches simples et bien définies | Très fiable et efficace | Wide & Shallow |
Étroit & profond vs. 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.
Plus chaque tranche est simple, plus le projet global est fiable.
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.
Une slice doit être la plus petite unité atomique du projet.
| Exemples de slices |
|---|
| Fichier |
| Notebook |
| Module |
| Exigence | Détails |
|---|
| Limite de temps | Chaque slice doit nécessiter moins de 90 minutes de travail d’ingénierie manuel. |
| Vérification | Doit 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.
| Exigence | Description |
|---|
| Isolation | Chaque segment doit être indépendant et rétrocompatible. |
| Exécution parallèle | Utilisez le parallélisme de Devin pour exécuter les segments simultanément. |
| Revue humaine | Une fois chaque segment terminé, il doit être soumis à une revue par un humain avant d’être fusionné dans main. |
Considérations de passage à l’échelle
| Principe | Description |
|---|
| Fiabilité au niveau du slice | Devin est optimisé pour une fiabilité maximale au niveau de chaque slice individuel. |
| Considération de passage à l’échelle | Lors du passage à l’échelle à des milliers de slices, maintenir une fiabilité élevée est essentiel. |
| Impact des erreurs | Même un faible taux d’erreur peut se cumuler lorsqu’on exécute à grande échelle. |
Bonnes pratiques pour la définition des tâches
| Exigence | Description |
|---|
| Détails des étapes clairs | Fournissez des instructions explicites pour chaque sous-tâche. |
| Référence de bout en bout | Un guide détaillé ou une vidéo aide à garantir la cohérence. |
| Exemples avant/après | Proposez plusieurs exemples de code avant/après (paires entrée/sortie). |
| Accès aux dépendances | Assurez-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