Answering Session

Dopo che una Issue Session ha scansionato la tua codebase e prodotto un elenco di issue, registra anche le domande a cui non è riuscita a rispondere basandosi solo sul codice e le assunzioni fatte procedendo senza indicazioni esplicite. Una Answering Sessionè il passo successivo: una session basata su IA in cui un Answering Agent esamina quelle domande, le raffina e produce assunzioni strutturate con punteggi di confidenza che esamini e approvi prima che inizi l’implementazione.

Il risultato è un insieme di risposte approvate, esaminate da un umano, che vengono iniettate come contesto nei workflow run quando vengono eseguite le issue risultanti - garantendo che l’agente che implementa abbia fin dall’inizio la giusta comprensione di requisiti, scope e architettura.

Perché le Answering Session contano

Le Issue Session sono deliberatamente ampie - l’agente di scansione fa emergere tutto ciò che trova senza avere necessariamente il contesto completo su intenzioni, vincoli o priorità. Questo produce elenchi di issue ricchi, ma lascia anche domande aperte:

• “Questa correzione di sicurezza deve essere applicata a tutti gli ambienti o solo alla produzione?”
• “Il pattern di query N+1 qui è intenzionale a causa della cache a un livello superiore?”
• “Questo refactoring deve mantenere la compatibilità all’indietro con l’API v1?”

Senza risposte a queste domande, l’agente che implementa deve fare le proprie assunzioni - che potrebbero essere sbagliate. La Answering Session ti offre un modo strutturato per risolvere queste incertezze prima dell’implementazione, riducendo drasticamente il rischio che gli agenti IA implementino correzioni tecnicamente corrette ma contestualmente sbagliate.

Configurare l’Answering Agent

Prima di avviare una Answering Session, configura l’Answering Agent dalla pagina Answering Setup all’indirizzo /p/{projectId}/answering-setup. Questa configurazione è condivisa da tutte le Answering Session del progetto:

Avviare una Answering Session

Stati delle Answering Session

Categorie delle domande di session

L’Answering Agent classifica ogni domanda in una delle sei categorie per aiutarti a dare priorità al tuo esame:

Puoi filtrare l’elenco di esame per categoria per affrontare prima le domande più critiche. Le domande di architettura e requisiti hanno tipicamente l’impatto maggiore sulla qualità dell’implementazione.

Stati di esame delle domande di session

Ogni domanda di session ha un reviewStatus che traccia dove si trova nel flusso di esame umano:

Modello dati

Le Answering Session sono rappresentate da due tipi di tabella nel database: answeringSessions e 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
}

Come le assunzioni approvate migliorano l’implementazione

Quando un workflow run esegue una issue associata a una Answering Session, le assunzioni approvate e corrette vengono formattate come contesto strutturato e anteposte al prompt del run. L’agente che implementa riceve non solo “correggi questo bug”, ma anche:

• Requisiti chiariti: quale comportamento è atteso e quali casi limite rientrano nello scope.
• Indicazioni architetturali: quali pattern seguire, quali astrazioni usare e quali confini non oltrepassare.
• Contesto di priorità: quali aspetti della correzione sono più critici e quali sono opzionali.
• Consapevolezza delle dipendenze: quali altri sistemi o librerie sono coinvolti e quali vincoli impongono.

Questo contesto aggiuntivo riduce la probabilità che l’agente che implementa faccia proprie assunzioni scorrette, una delle cause più comuni di implementazione IA di bassa qualità.

Learning dalle Answering Session

Le domande di session rifiutate (e corrette) sono particolarmente preziose come input per il learning. Quando l’Answering Agent ha fatto un’assunzione sbagliata e tu l’hai corretta, quella correzione insegna al sistema vincoli, preferenze o pattern del tuo progetto che non erano evidenti dalla sola codebase.

Se una domanda di session è collegata a un learningId, significa che la correzione è stata compilata in un record di learning che verrà iniettato nelle session future - così l’Answering Agent (e altri agenti collegati ai learning) avrà meno probabilità di fare la stessa assunzione sbagliata in futuro.

Prossimi passi