Answering Sessions

Après qu’une Issue Session a scanné votre codebase et produit une liste d’issues, elle enregistre également les questions auxquelles elle n’a pas pu répondre à partir du seul code, ainsi que les hypothèses qu’elle a formulées en poursuivant sans directives explicites. Une Answering Session est l’étape suivante : une session pilotée par l’IA où un Answering Agent examine ces questions, les affine, et produit des hypothèses structurées avec des scores de confiance que vous examinez et approuvez avant le début de l’implémentation.

Le résultat est un ensemble de réponses approuvées, examinées par un humain, qui sont injectées comme contexte dans les workflow runs lorsque les issues résultantes sont exécutées - garantissant que l’agent qui implémente dispose dès le départ de la bonne compréhension des exigences, du périmètre et de l’architecture.

Pourquoi les Answering Sessions comptent

Les Issue Sessions sont délibérément larges - l’agent de scan fait remonter tout ce qu’il trouve sans avoir nécessairement le contexte complet sur l’intention, les contraintes ou les priorités. Cela produit des listes d’issues riches, mais laisse aussi des questions ouvertes :

• “Ce correctif de sécurité doit-il être appliqué à tous les environnements ou seulement à la production ?”
• “Le pattern de requête N+1 est-il intentionnel ici en raison d’un cache à une couche supérieure ?”
• “Ce refactoring doit-il maintenir la compatibilité ascendante avec l’API v1 ?”

Sans réponses à ces questions, l’agent qui implémente doit formuler ses propres hypothèses - qui peuvent être erronées. L’Answering Session vous offre un moyen structuré de résoudre ces incertitudes avant l’implémentation, réduisant considérablement le risque que les agents IA implémentent des corrections techniquement correctes mais contextuellement erronées.

Configurer l’Answering Agent

Avant de lancer une Answering Session, configurez l’Answering Agent depuis la page Answering Setup à l’adresse /p/{projectId}/answering-setup. Cette configuration est partagée par toutes les Answering Sessions du projet :

Lancer une Answering Session

Statuts des Answering Sessions

Catégories de questions de session

L’Answering Agent classe chaque question dans l’une des six catégories pour vous aider à prioriser votre examen :

Vous pouvez filtrer la liste d’examen par catégorie pour traiter d’abord les questions les plus critiques. Les questions d’architecture et d’exigences ont généralement l’impact le plus élevé sur la qualité de l’implémentation.

Statuts d’examen des questions de session

Chaque question de session possède un reviewStatus qui suit son état dans le flux d’examen humain :

Modèle de données

Les Answering Sessions sont représentées par deux types de tables dans la base de données : answeringSessions et sessionQuestions.

answeringSessions: {
  userId: Id<"users">;
  projectId: Id<"projects">;
  issueSessionId: Id<"issueSessions">;
  sandboxId?: string;

  // Lifecycle
  status: "active" | "completed" | "reviewing" | "archived" | "killed" | "cancelled";

  // Agent outputs
  questionsJson?: string;     // Raw questions JSON from the Issue Session, passed as input
  assumptionsJson?: string;   // Raw assumptions JSON from the Issue Session, passed as input
  prompt?: string;            // The prompt used for the Answering Agent
  error?: string;             // Error message if the session failed or was killed
}

Comment les hypothèses approuvées améliorent l’implémentation

Lorsqu’un workflow run exécute une issue associée à une Answering Session, les hypothèses approuvées et corrigées sont formatées comme un contexte structuré et ajoutées en préambule au prompt du run. L’agent qui implémente reçoit non seulement “corrige ce bug”, mais aussi :

• Des exigences clarifiées : quel comportement est attendu et quels cas limites sont dans le périmètre.
• Des orientations architecturales : quels patterns suivre, quelles abstractions utiliser, et quelles limites ne pas franchir.
• Un contexte de priorité : quels aspects de la correction sont les plus critiques et lesquels sont optionnels.
• Une connaissance des dépendances : quels autres systèmes ou bibliothèques sont impliqués et quelles contraintes ils imposent.

Ce contexte supplémentaire réduit la probabilité que l’agent qui implémente formule ses propres hypothèses incorrectes, ce qui est l’une des sources les plus courantes d’implémentation IA de faible qualité.

Learnings issus des Answering Sessions

Les questions de session refusées (et corrigées) sont particulièrement précieuses comme entrées de learning. Lorsque l’Answering Agent a formulé une hypothèse erronée et que vous l’avez corrigée, cette correction enseigne au système des contraintes, préférences ou patterns de votre projet qui n’étaient pas évidents à partir de la seule codebase.

Si une question de session est liée à un learningId, cela signifie que la correction a été compilée dans un enregistrement de learning qui sera injecté dans les sessions futures - de sorte que l’Answering Agent (et les autres agents liés aux learnings) sera moins susceptible de refaire la même hypothèse incorrecte à l’avenir.

Prochaines étapes