Vue d’ensemble des personas

Les personas sont l’un des concepts les plus puissants de CodeCourier. Une persona est une configuration d’agent IA nommée et réutilisable qui définit exactement comment un agent se comporte lorsqu’il participe à un workflow run ou à une session de sandbox. Chaque persona spécifie l’outil CLI à utiliser, le modèle, le niveau d’effort de réflexion, des instructions personnalisées, les skills disponibles, les commands et scripts injectés, et optionnellement un document de contexte lié. En créant des personas conçues pour un usage précis, vous passez d’un prompting ad-hoc à une approche systématique et reproductible du développement assisté par IA.

Pourquoi les personas sont importantes

Sans personas, chaque workflow run démarre d’une page blanche. Vous devriez spécifier manuellement le modèle, écrire des system prompts et configurer les outils à chaque fois. Les personas résolvent ce problème en encapsulant toutes ces décisions dans une identité réutilisable à laquelle on peut faire référence par son nom dans tout le projet.

Prenons un scénario réel : votre équipe a un standard de code qui exige une type safety rigoureuse, privilégie les patterns fonctionnels et exécute toujours ESLint avant de commit. Plutôt que de répéter ces instructions dans chaque prompt, vous créez une persona “Senior TypeScript Designer” avec ces règles intégrées dans ses instructions. Chaque workflow qui utilise cette persona hérite automatiquement du même comportement.

Types de personas

Chaque persona a un type qui détermine son rôle au sein d’un pipeline de workflow. CodeCourier définit dix types de personas, chacun conçu pour une étape spécifique du processus de développement :

Designer

L’agent de codage principal. Les designers reçoivent un task prompt et l’implémentent directement dans l’environnement sandbox. Ils écrivent du code, créent des fichiers, installent des dépendances et produisent le livrable réel. La plupart des workflows commencent par une étape designer.

Checker

Un agent de review basé sur un verdict qui évalue la sortie du designer. Les checkers examinent les changements de code, exécutent des tests si configuré, et produisent un verdict pass/fail avec du feedback. Lorsqu’un checker rejette le travail, le designer peut reboucler et itérer sur la base du feedback, créant une boucle design-check qui améliore automatiquement la qualité.

Optimizer

Un agent spécialisé axé sur le refactoring et l’amélioration des performances. Les optimizers prennent du code existant et l’améliorent sans changer sa fonctionnalité. Ils recherchent des opportunités de réduire la duplication, d’améliorer la lisibilité, d’optimiser la taille du bundle et d’appliquer les best practices.

Prompter

Un agent de prompt engineering qui transforme des instructions vagues et informelles en prompts clairs et structurés avec des critères d’acceptation explicites. Exécuter un prompter avant une étape designer peut considérablement améliorer la qualité de l’implémentation résultante en garantissant que le designer reçoit des instructions non ambiguës.

Investigator

Un agent de recherche qui analyse en profondeur la codebase pour comprendre un problème ou une demande de fonctionnalité avant que toute implémentation ne commence. Les investigators explorent les structures de fichiers, lisent le code existant, tracent les dépendances et produisent un résumé des constats que les agents suivants peuvent utiliser comme contexte.

Planner

Un agent d’architecture qui analyse les codebases et crée des évaluations structurées. Le planner examine la codebase, identifie les problèmes et les tâches, et produit des résultats exploitables qui peuvent être exécutés étape par étape. Ce type alimente les issue sessions dédiées de CodeCourier.

Deep-Dive

Un agent d’analyse intensive conçu pour des problèmes complexes et multidimensionnels qui nécessitent une compréhension approfondie de la codebase. Le type deep-dive est similaire à l’investigator mais plus approfondi dans sa portée - il est généralement déployé pour des analyses architecturales, des investigations de cause racine s’étendant sur de nombreux sous-systèmes, ou des préoccupations transversales où un scan superficiel manquerait des dépendances critiques. Les sessions deep-dive s’exécutent généralement plus longtemps et avec un effort de réflexion plus élevé que les sessions investigator standard.

Reviewer

Un agent de code review spécialisé axé sur la sécurité, la maintenabilité et les design patterns. Le reviewer diffère du checker de façon fondamentale : il ne produit pas de verdicts pass/fail. Il produit à la place un feedback de review détaillé et nuancé - observations, suggestions, préoccupations et félicitations - sur lequel un humain ou un agent suivant peut agir. Utilisez le type reviewer lorsque vous voulez un feedback qualitatif riche plutôt qu’un gate binaire.

Custom

Un type libre pour les personas qui ne correspondent à aucune des catégories standard. Le type custom n’impose aucune attente structurelle sur le comportement de l’agent - il se comporte exactement comme le dictent ses instructions, ses skills et son contexte. Utilisez ce type pour des agents hautement spécialisés tels que des rédacteurs de documentation, des assistants de migration, des générateurs de changelog, ou tout autre rôle qui nécessite une flexibilité maximale sans se conformer à un archétype prédéfini.

Comment les personas se rapportent aux workflows

Les workflows dans CodeCourier sont des séquences d’étapes, et chaque étape peut être alimentée par une persona. Le type de workflow Persona Pipeline est spécifiquement conçu pour cela : vous sélectionnez une séquence de personas, et chacune s’exécute dans l’ordre au sein du même environnement sandbox. La sortie d’une persona devient le contexte de la suivante.

Par exemple, un persona pipeline pourrait ressembler à :

1. La persona Investigator analyse la codebase et documente l’architecture pertinente
2. La persona Prompter réécrit la demande de l’utilisateur en une spécification technique détaillée
3. La persona Designer implémente la fonctionnalité sur la base du prompt affiné
4. La persona Checker examine l’implémentation et approuve ou demande des changements
5. La persona Optimizer nettoie et refactorise le code final

Chaque étape de ce pipeline utilise une persona différente, potentiellement avec un modèle différent, des ensembles de skills différents, des commands et scripts injectés différents, et des instructions adaptées à son rôle.

Comment les personas se rapportent aux sandboxes

Lorsqu’un workflow run s’exécute, chaque étape de persona est assignée à une sandbox. La sandbox fournit un environnement cloud E2B isolé avec un système de fichiers Linux complet, un accès internet et des outils CLI installés. La configuration de la persona détermine quel outil CLI s’exécute dans la sandbox (Claude Code, OpenCode, Codex ou d’autres) et comment cet outil se comporte (modèle, instructions, skills, commands, scripts et contexte).

Les run steps dans la base de données suivent quelle persona a exécuté chaque étape, permettant des analyses par persona comme les taux de réussite, le nombre moyen d’itérations, les répartitions de coûts, les scores de qualité dans le temps, et les chronologies d’activité.

Capacités

Les personas peuvent être configurées avec :

• Sélection de l’outil CLI - Choisir entre Claude Code, OpenCode, Codex ou d’autres outils pris en charge
• Sélection du modèle - Choisir le modèle LLM spécifique (par ex., claude-opus-4-6, claude-sonnet-4-6)
• Effort de réflexion - Contrôler le niveau de reasoning appliqué par le modèle (low, medium, high, max)
• Instructions personnalisées - Texte libre qui façonne le comportement de l’agent
• Attribution de skills - Choisir les skills (packages de connaissance de domaine) disponibles
• Injection de commands - Sélectionner les shell commands et alias à injecter dans la sandbox
• Injection de scripts - Sélectionner les scripts exécutables à injecter dans la sandbox
• Liaison de contexte - Lier un document Context dont la version active est préfixée à la configuration de la sandbox
• Injection de learnings - Activer ou désactiver l’injection des learnings compilés issus des runs passés
• Bascule activer/désactiver - Désactiver temporairement une persona sans la supprimer

Les personas ne contrôlent pas les paramètres d’infrastructure de la sandbox comme la mémoire, le CPU ou le timeout - ceux-ci sont configurés au niveau du workflow ou du run.

Versioning des personas

Les personas prennent en charge un système de versioning intégré. Chaque fois que vous enregistrez des modifications significatives à la configuration ou aux instructions d’une persona, une nouvelle version est créée plutôt que d’écraser la précédente. Chaque enregistrement de version porte un numéro version, un parentPersonaId pointant vers la version précédente, et un flag isLatest indiquant s’il s’agit de la version actuellement active.

Cela signifie que vous pouvez itérer en toute sécurité sur les instructions d’une persona et toujours revenir à une version antérieure si un changement produit de moins bons résultats. L’historique des versions est visible depuis la page de détail de la persona, avec une vue diff pour comparer les versions côte à côte.

Étapes suivantes