Answering Sessions

Nachdem eine Issue Session Ihre Codebasis gescannt und eine Liste von Issues erzeugt hat, hält sie auch die Fragen fest, die sie aus dem Code allein nicht beantworten konnte, sowie die Annahmen, die sie ohne explizite Anleitung getroffen hat. Eine Answering Session ist der nächste Schritt: eine KI-gestützte Session, in der ein Answering Agent diese Fragen prüft, verfeinert und strukturierte Annahmen mit Confidence-Werten produziert, die Sie vor Beginn der Umsetzung überprüfen und freigeben.

Das Ergebnis ist ein Satz freigegebener, vom Menschen überprüfter Antworten, die als Kontext in Workflow-Runs einfließen, wenn die resultierenden Issues ausgeführt werden - so erhält der umsetzende Agent von Anfang an das richtige Verständnis von Anforderungen, Umfang und Architektur.

Warum Answering Sessions wichtig sind

Issue Sessions sind bewusst breit angelegt - der Scanning- Agent legt alles offen, was er findet, ohne notwendigerweise den vollen Kontext zu Absicht, Einschränkungen oder Prioritäten zu haben. Das führt zu reichhaltigen Issue-Listen, lässt aber auch offene Fragen zurück:

• “Soll dieser Security-Fix in allen Umgebungen oder nur in der Produktion angewendet werden?”
• “Ist das N+1-Query-Muster hier absichtlich, weil auf einer höheren Schicht gecacht wird?”
• “Muss dieses Refactoring die Rückwärtskompatibilität zur v1-API wahren?”

Ohne Antworten auf diese Fragen muss der umsetzende Agent eigene Annahmen treffen - die falsch sein können. Die Answering Session bietet einen strukturierten Weg, diese Unklarheiten vor der Umsetzung aufzulösen, und reduziert so das Risiko, dass KI-Agents Fixes liefern, die technisch korrekt, aber kontextuell falsch sind.

Konfiguration des Answering Agents

Bevor Sie eine Answering Session starten, konfigurieren Sie den Answering Agent auf der Answering-Setup-Seite unter /p/{projectId}/answering-setup. Diese Konfiguration wird von allen Answering Sessions im Projekt geteilt:

Eine Answering Session starten

Status von Answering Sessions

Kategorien von Session-Fragen

Der Answering Agent klassifiziert jede Frage in eine von sechs Kategorien, um Ihnen die Priorisierung der Überprüfung zu erleichtern:

Sie können die Review-Liste nach Kategorie filtern, um zuerst die kritischsten Fragen anzugehen. Architektur- und Anforderungsfragen haben typischerweise den größten Einfluss auf die Umsetzungs- qualität.

Review-Status von Session-Fragen

Jede Session-Frage hat einen reviewStatus, der verfolgt, wo sie sich im menschlichen Review-Prozess befindet:

Datenmodell

Answering Sessions werden in der Datenbank durch zwei Tabellen- typen abgebildet: answeringSessions und 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
}

Wie freigegebene Annahmen die Umsetzung verbessern

Wenn ein Workflow-Run ein Issue ausführt, dem eine Answering Session zugeordnet ist, werden die freigegebenen und korrigierten Annahmen als strukturierter Kontext formatiert und dem Run-Prompt vorangestellt. Der umsetzende Agent erhält also nicht nur “behebe diesen Bug”, sondern auch:

• Klargestellte Anforderungen: welches Verhalten erwartet wird und welche Edge Cases im Scope sind.
• Architektonische Leitlinien: welchen Mustern zu folgen ist, welche Abstraktionen zu verwenden sind und welche Grenzen nicht überschritten werden dürfen.
• Prioritätskontext: welche Aspekte des Fixes am wichtigsten und welche optional sind.
• Bewusstsein für Abhängigkeiten: welche anderen Systeme oder Bibliotheken betroffen sind und welche Einschränkungen sie mitbringen.

Dieser zusätzliche Kontext senkt die Wahrscheinlichkeit, dass der umsetzende Agent selbst falsche Annahmen trifft - eine der häufigsten Ursachen minderwertiger KI-Umsetzung.

Learnings aus Answering Sessions

Abgelehnte (und korrigierte) Session-Fragen sind als Lerninputs besonders wertvoll. Wenn der Answering Agent eine falsche Annahme getroffen hat und Sie sie korrigiert haben, lehrt diese Korrektur das System Einschränkungen, Vorlieben oder Muster Ihres Projekts, die aus der Codebasis allein nicht erkennbar waren.

Wird eine Session-Frage mit einer learningId verknüpft, bedeutet das, dass die Korrektur in einen Learning-Datensatz kompiliert wurde, der in zukünftige Sessions eingespeist wird - damit der Answering Agent (und andere an Learnings gebundene Agents) künftig seltener dieselbe falsche Annahme treffen.

Nächste Schritte