Orchestrez de nombreuses sessions Devin à l’aide d’un script Python déterministe : répartissez le travail, transmettez des résultats structurés entre les étapes et reprenez une exécution là où elle s’est arrêtée.
Les workflows dynamiques sont disponibles dans n’importe quelle session Devin : décrivez simplement le travail et demandez à Devin de l’exécuter sous forme de workflow.
Un workflow dynamique est un script Python déterministe qui orchestre une équipe d’agents Devin. Devin écrit et exécute le script, qui détermine quels agents s’exécutent, dans quel ordre et quelles instructions chacun reçoit, en utilisant les résultats structurés des agents précédents pour construire les prompts des suivants.Chaque appel à un agent est enregistré. Une exécution de workflow peut donc être observée pendant son déroulement et reprise en cas d’interruption : les agents ayant terminé restituent instantanément leurs résultats enregistrés, et seul le travail inachevé est de nouveau exécuté.Cela va plus loin que les Devins gérés, où la session de coordination lance et supervise manuellement les sessions enfants. Dans un workflow, l’orchestration est elle-même du code.
Demandez un workflow lorsque le travail présente une véritable structure :
Large répartition des tâches avec une étape de consolidation — environ cinq unités indépendantes ou plus (fichiers, modules, endpoints, tickets) nécessitant chacune une évaluation ou une vérification, puis une consolidation des résultats.
Un pipeline par étapes — les étapes ultérieures exploitent la sortie structurée des précédentes, par exemple audit → correctif → vérification.
Privilégiez une session simple (ou quelques Devins gérés) lorsque :
La modification est mécanique — un codemod, une correction automatique du linter ou un générateur l’effectue plus rapidement et plus fiablement que des agents.
Une ou deux sessions indépendantes suffisent, sans échange de données entre elles.
Le travail dépend étroitement d’un état partagé, ou est limité et séquentiel.
Vous décrivez la tâche et demandez un workflow ; Devin écrit le script.Migration — lancez un agent par unité sur sa propre branche, puis regroupez le tout :
Utilise un workflow pour migrer chaque job de jobs/ de l'ancien exécuteur cronvers notre nouvelle API de planification — un agent par job, chacun travaillantsur sa propre branche et exécutant les tests du job — puis fais la synthèse desjobs qui nécessitent une intervention manuelle
Recherche — recueillez des éléments de preuve en parallèle, puis faites-en la synthèse :
Utilise un workflow pour évaluer Postgres, DynamoDB et CockroachDB pour lenouveau service d'événements : un agent par option, qui la note au regard denos exigences de latence, de coût et d'exploitation, puis un agent final quicompare les éléments recueillis et en recommande une
Revue de code — un relecteur par fichier, puis une étape de fusion :
Utilise un workflow pour relire chaque fichier modifié sur cette branche auregard de CONTRIBUTING.md — un relecteur par fichier — puis fusionne lesconstats en une seule liste dédupliquée, classée par gravité
Audit de l’ensemble de la codebase — un pipeline en plusieurs étapes audit → correctif → vérification :
Utilise un workflow pour auditer chaque requête SQL du module de reportingafin d'y détecter les paginations manquantes et les patterns N+1, corrigechaque problème confirmé sur sa propre branche, et vérifie chaque correctifavec un EXPLAIN avant et après
Boucle — répétez jusqu’à ce qu’une vérification réussisse ou que la progression stagne :
Utilise un workflow pour faire passer au vert la suite de tests d'intégrationinstable : exécute-la, corrige ce qui a échoué, et recommence jusqu'à cequ'elle passe trois exécutions consécutives ou qu'un tour ne corrige plus riende nouveau
Devin écrit le script dans un fichier et lance l’exécution. Vous devez d’abord l’approuver, sauf si vous avez activé l’approbation automatique dans Settings → Preferences → Approbation automatique des workflows.
Le script s’exécute sur la machine de Devin. Les primitives de workflow sont injectées automatiquement — rien à installer ni à importer.
Chaque appel d’agent génère un agent et attend sa sortie structurée. Par défaut, cet agent est une session Devin indépendante sur sa propre VM.
La progression est transmise à la session. Le panneau des workflows affiche chaque phase, ses agents et leur statut en direct ; vous pouvez y ouvrir la session de n’importe quel agent.
Les résultats sont enregistrés sous un ID d’exécution, ce qui permet de reprendre l’exécution.
L’exécution se déroule en arrière-plan, de sorte que la session reste réactive — vous pouvez continuer à parler à Devin pendant son exécution, demander un récapitulatif de l’avancement ou lui demander d’arrêter l’exécution. L’arrêt annule le script et met en veille les sessions enfants restantes ; tout ce qui a déjà été enregistré peut être repris.
Le script est du Python standard. Devin l’écrit, mais il est utile d’en connaître la structure lorsque vous en examinez un :
Primitive
Rôle
register_workflow(meta)
Déclare le nom, la description et les phases du workflow. Doit être attendu avant le lancement de tout agent.
agent(prompt, phase=..., schema=...)
Exécute un agent et renvoie sa sortie structurée sous forme de dictionnaire.
pipeline(items, stage1, stage2, ...)
Exécute chaque élément indépendamment à travers les étapes — il n’y a pas de barrière entre les étapes : l’élément A peut donc être à l’étape 3 alors que l’élément B est encore à l’étape 1.
parallel([...])
Exécute des appelables asynchrones simultanément et attend qu’ils soient tous terminés. À utiliser uniquement lorsqu’une étape requiert réellement tous les résultats précédents, par exemple lors d’une fusion ou d’une déduplication.
log("message")
Écrit une ligne de progression visible tant que l’exécution est en cours.
Chaque appel à agent() reçoit un schéma JSON et renvoie un dictionnaire qui respecte ce schéma. Les constats d’une étape peuvent ainsi alimenter le prompt de l’étape suivante. Gardez les schémas petits et plats.
Un pipeline d’audit suivi de correctifs sur trois modules :
import asyncioimport jsonREPO = "github.com/acme/api"MODULES = ["auth", "billing", "search"]META = { "name": "error-handling-audit", "description": "Audit and fix error-handling bugs across api modules", "phases": [ {"title": "analyze", "detail": "audit each module for error-handling bugs"}, {"title": "fix", "detail": "fix confirmed issues and push a branch"}, ],}FINDINGS_SCHEMA = { "type": "object", "properties": { "module": {"type": "string"}, "issues": {"type": "array", "items": {"type": "string"}}, }, "required": ["module", "issues"],}FIX_SCHEMA = { "type": "object", "properties": {"branch": {"type": "string"}, "summary": {"type": "string"}}, "required": ["branch", "summary"],}async def analyze(module): return await agent( f"In {REPO}, audit the '{module}' module for error-handling bugs. " "Report each issue as a one-line string.", phase="analyze", schema=FINDINGS_SCHEMA, label=f"analyze-{module}", )async def fix(findings): if not findings["issues"]: return None return await agent( f"In {REPO}, fix these issues in the '{findings['module']}' module:\n" + json.dumps(findings["issues"], sort_keys=True) + "\nPush your work to a new git branch (do not open a PR) and " "report the branch name and a one-line summary.", phase="fix", schema=FIX_SCHEMA, label=f"fix-{findings['module']}", )async def main(): await register_workflow(META) results = await pipeline(MODULES, analyze, fix) for module, result in zip(MODULES, results): log(f"{module}: {result['branch'] if result else 'no fix needed/failed'}")asyncio.run(main())
Par défaut, chaque agent s’exécute sur sa propre VM, mais peut être épinglé à la machine de la session d’orchestration.
VM distincte (par défaut)
Une session Devin enfant complète disposant de sa propre machine, de ses clones de dépôt et de son environnement. Elle ne peut pas accéder aux fichiers de la session d’orchestration. Les transferts de code passent donc par des branches Git : chaque agent pousse une branche et en indique le nom, que les étapes ultérieures lisent dans la sortie structurée.
VM partagée
L’agent s’exécute sur la machine de la session d’orchestration et partage son arbre de travail, y compris les modifications non validées — aucun transfert Git n’est nécessaire. Utilisez cette option lorsque les agents doivent lire ou modifier l’arbre de travail actuel, ou lorsque le dépôt n’existe que sur cette machine.
Les agents sur VM partagée sont en concurrence avec la session pour le processeur, la mémoire et l’espace disque, et sont soumis à une limite de concurrence plus faible. Comme ils partagent un même arbre de travail sans isolation, les agents qui écrivent en parallèle doivent se voir attribuer des fichiers ou répertoires strictement distincts.Les agents peuvent également être épinglés à un mode Devin spécifique — par exemple, le mode Devin Lite, moins coûteux, pour la classification de chaque élément dans le cadre d’une répartition des tâches très large.
Lorsqu’une exécution reprend, le script de workflow est réexécuté depuis le début, et chaque appel d’agent est associé à un hash de son prompt, de son schéma et de ses paramètres d’exécution. Tout ce qui s’est déjà terminé est rejoué à partir de son résultat enregistré ; le reste est exécuté à nouveau dans de nouvelles sessions.Cela ne fonctionne que si le script effectue les mêmes appels à chaque fois. La logique du workflow et les prompts ne doivent pas dépendre de l’heure ou de la date actuelles, du hasard, des ID générés, des variables d’environnement, de l’état du système de fichiers ou des réponses du réseau. Tout ce qui nécessite d’inspecter le monde extérieur doit être placé dans un appel agent(), dont le reste du script consomme la sortie enregistrée.Deux conséquences à connaître :
Modifier un prompt réexécute cet agent et tout ce qui en dépend en aval, tandis que les agents précédents non modifiés sont toujours rejoués.
Une exécution ayant expiré ou été interrompue reprend là où elle s’était arrêtée lorsqu’elle est reprise avec son ID d’exécution. Le budget par défaut et maximal d’une exécution est de sept jours.
Si un agent échoue — parce que sa session s’est arrêtée ou qu’il n’a produit aucune sortie structurée valide — le script décide de la suite : ignorer l’élément, utiliser une valeur par défaut, réessayer ou faire échouer l’exécution. Une exécution reprise réessaie les agents ayant échoué dans de nouvelles sessions.
Chaque agent d’un workflow correspond à une session Devin. Une exécution peut donc consommer bien plus d’ACU que la même tâche effectuée dans une seule session. Avant d’appliquer un workflow à un repo entier, exécutez-le sur un sous-ensemble — un répertoire, trois modules, une question plus ciblée — et vérifiez l’utilisation des ACU des agents dans le panneau des workflows. Demander un mode moins coûteux pour les étapes à fort volume, telles que la classification élément par élément, permet également de maîtriser les coûts d’une large répartition des tâches.
Une fois qu’un workflow est opérationnel, vous pouvez le valider dans votre repo sous forme de skill : un fichier workflow.py accompagné d’un fichier SKILL.md décrivant quand l’utiliser. Devin le détectera et l’exécutera à nouveau pour de futures tâches, au lieu de créer un nouveau script. Demandez à Devin d’enregistrer un workflow ; il créera les fichiers nécessaires.
