Qodo: KI-Code-Review prüft Pull Requests jetzt gegen verlinkte Spezifikationen

Code gegen die Spezifikation prüfen, nicht nur den Diff

Qodo beschreibt ein bekanntes Problem: Ein Pull Request kann korrekt aussehen und trotzdem eine entscheidende Anforderung übersehen. Der Code kompiliert, die Tests laufen durch, und die Implementierung entspricht den Akzeptanzkriterien des Tickets. Doch das Ticket verweist womöglich auf eine Spezifikation, etwa in Confluence, die eine Anforderung enthält, um die sich die Implementierung nie gekümmert hat.

Um diese Lücke zu finden, muss ein menschlicher Reviewer dem Link folgen, die Spezifikation lesen und die Anforderung mit dem Code abgleichen. Laut Qodo kann das Tool das nun selbst übernehmen. Verweist ein Pull Request auf ein Ticket, liest Qodo die dort verlinkte Spezifikation und prüft den Code dagegen.

Das Unternehmen fasst den Unterschied so zusammen: „Diff review catches broken code. Spec review catches code that runs fine and still does the wrong thing.“ (Ein Diff-Review findet fehlerhaften Code. Ein Spec-Review findet Code, der einwandfrei läuft und trotzdem das Falsche tut.)

Ein Beispiel: die fehlende Autorisierungsprüfung

Qodo führt einen typischen Ablauf vor. Ein Entwickler eröffnet einen Pull Request, der eine Massenoperation zum Aktualisieren von Kundendatensätzen hinzufügt, und verlinkt in der Beschreibung das Jira-Ticket. Das Ticket verweist auf eine Confluence-Seite mit der API-Spezifikation. Diese schreibt vor, dass jede Anfrage prüfen muss, ob der authentifizierte Nutzer zu dem Konto gehört, dem die Datensätze zugeordnet sind, bevor sie aktualisiert werden.

Qodo folgt dem Link vom Ticket zur Spezifikation und gleicht die Codeänderungen mit deren Anforderungen ab. Anschließend meldet das Tool die fehlende Autorisierungsprüfung auf Kontoebene als Sicherheitsproblem. Ohne diese Prüfung könnte ein Nutzer die Daten eines anderen Kunden verändern. In diesem Beispiel stand die Anforderung in der Spezifikation, aber weder im Ticket noch im Code.

Zu den unterstützten Quellen für Spezifikationen zählen Asana, Confluence, Notion, ServiceNow und JSM Assets.

Warum Spezifikationen mit Coding-Agenten wichtiger werden

Qodo bringt die Funktion mit der Rückkehr der spezifikationsgetriebenen Entwicklung in Verbindung, die nach Darstellung des Unternehmens durch KI-Coding-Agenten wieder aufgekommen ist. Bei diesem Ansatz schreiben Teams zuerst die Spezifikation, und Tools wie Kiro machen daraus einen Plan, Aufgaben und Code. Die Spezifikation wird zum Vertrag zwischen dem, was das Team beabsichtigt, und dem, was der Agent baut.

Dieser Vertrag trägt laut Qodo nur, wenn jemand den Code dagegen prüft. Agenten können abdriften: Sie überspringen einen Randfall, vereinfachen eine Einschränkung oder bauen auf Basis der Ticket-Zusammenfassung statt der vollständigen Anforderung. Für Teams, die in Kiro aus Spezifikationen entwickeln, verweist Qodo auf seine Qodo Kiro Power, die das Qodo-Review in diesen Workflow einbindet.

Was das für Teams bedeutet

Qodo weist darauf hin, dass Teams selten alle Anforderungen an einem Ort bündeln. Ein Ticket beschreibt die Aufgabe, ein verlinktes Dokument erläutert die Architektur, und eine weitere Seite legt systemweite Rahmenbedingungen fest. Ein Entwickler verlinkt womöglich das richtige Ticket, ohne jedes ergänzende Dokument in die Beschreibung des Pull Requests zu übernehmen, sodass der Reviewer den Kontext mühsam selbst rekonstruieren muss.

Indem es den Links folgt, kann Qodo nach eigenen Angaben eine ausgelassene Einschränkung, ein fehlendes Verhalten oder eine Entscheidung aufdecken, die dem dokumentierten Design widerspricht. Die Reviewer bewerten weiterhin jeden Befund und entscheiden, was zu tun ist. Außerdem müssten Teams Anforderungen nicht doppelt pflegen, so das Unternehmen: Detaillierte Spezifikationen bleiben im Dokumentationstool, die Tickets verweisen lediglich darauf.

Das Ziel ist laut Qodo, Anforderungslücken schon im Pull Request zu erkennen, wo Teams noch darauf reagieren können.