Les cas d’usage stratégiques sont de grands projets à forte valeur pour l’entreprise qui peuvent être découpés en sous-tâches isolées et répétitives. Chaque découpe correspond au travail d’un Devin, et doit donc être simple (moins de 90 minutes de travail d’ingénierie humaine) et incrémentale.
En résumé — Exigences pour un cas d’usage Devin :
- Volume élevé de sous-tâches (découpes) répétitives
- Sous-tâches d’un niveau de difficulté équivalent à celui d’un ingénieur débutant
- Sous-tâches isolées pouvant être réalisées de manière incrémentale
- Sous-tâches avec une boucle de vérification objective
- (Recommandé) : Dépendances de projet minimales
Caractéristiques requises
Un cas d’usage stratégique optimal de Devin est large et peu profond, par opposition à étroit et profond.
Les fonctionnalités complexes, entièrement nouvelles (même répétitives) sont peu susceptibles d’être suffisamment fiables à grande échelle.
Un important backlog de changements horizontaux et simples (p. ex. des problèmes SonarQube) génère un retour sur investissement considérable lorsqu’il est étendu horizontalement à grande échelle.
Plus le périmètre est simple, plus le projet global est fiable.
Cas d’utilisation du découpage [IMPORTANT]
Les migrations, les refactorings, les modernisations et les backlogs de dette technique sont d’excellents cas d’utilisation. Par exemple, prenez une migration de code.
Fractionnez la migration en tranches isolées, où chaque tâche est prise en charge dans une session Devin distincte.
Un slice doit être la plus petite unité atomique du projet (fichier, notebook ou module) avec :
- Moins de 90 minutes de travail d’ingénierie réalisé par un humain
- Un moyen de vérifier les changements de code (tests, build, vérifications CI ou script de vérification personnalisé)
Chaque Devin doit savoir de manière objective s’il a réussi à accomplir sa tâche. Tant qu’il n’a pas terminé la vérification, il doit continuer à itérer en utilisant des traces de pile détaillées ou des journaux d’erreurs.
Chaque slice doit éviter d’avoir trop de dépendances ou de plateformes avec lesquelles interagir. Concentrez Devin sur les changements de code !
Chaque slice doit être isolé et incrémental. En tirant parti du parallélisme de Devin, effectuez la migration un slice à la fois. Après la revue humaine, fusionnez successivement chaque PR dans master.
Le modèle global pour un cas d’usage Devin :
Devin doit être aussi fiable que possible au niveau de chaque slice individuel, afin que, lors de la parallélisation sur des milliers de slices, nous maintenions une fiabilité élevée à l’échelle. Même une petite marge d’erreur peut entraîner de nombreux changements incorrects lorsqu’on passe à l’échelle.
- Des détails clairs pour chaque étape de chaque slice (un descriptif détaillé ou une vidéo du processus de bout en bout est très efficace)
- Plusieurs exemples de modifications de code avant/après (paires d’entrée/sortie)
- Accès donné à Devin à toutes les dépendances nécessaires dans chaque slice
Les tâches continues liées à la dette technique (par exemple, la revue de PR ou les tests de QA) sont également d’excellents cas d’usage, à condition qu’elles puissent être découpées en tranches.
Les migrations, modernisations et refactorisations sont d’excellents cas d’usage pour Devin lorsqu’elles sont incrémentales. Une migration qui nécessite la mise à niveau de l’intégralité du dépôt vers le nouveau système en une seule fois, plutôt que tranche par tranche, n’est pas recommandée.
Pour aller plus loin : Nubank Migration Case Study