Skip to content
Zum Inhalt springen

Lass deinen Coding-Agent nicht seine eigenen Hausaufgaben benoten

mit Filip Hric

Geplant war eine Punktetafel: Claude Code baut ein Feature, Qodo reviewt es, jedes Finding bekommt ein Urteil. Gezählt haben wir nie. Stattdessen hat mir Filip Hric von Qodo gezeigt, dass Qodo weniger ein Pull-Request-Reviewer ist als eine Kontextschicht für Coding-Agents. Eine, die ein Ticket prüfen kann, bevor es Code gibt.

Veröffentlicht: 8. Oktober 2026Lesezeit: 7 Min. Lesezeit
Lass deinen Coding-Agent nicht seine eigenen Hausaufgaben benoten

YouTube

Lass deinen Coding-Agent nicht seine eigenen Hausaufgaben benoten

YouTube-Video laden

Dieses Video wird von YouTube eingebettet und erst nach Ihrer Einwilligung geladen. Beim Laden können personenbezogene Daten an YouTube oder Google übermittelt und Cookies gesetzt werden.

Auf YouTube öffnen

Mehr dazu in der Datenschutzerklärung.

Projektquelle

Arbeits-Repository

Hier findest du Prompts, Instructions und Beispiele aus dem gezeigten Modernisierungs-Workflow.

Repository öffnen
Timestamps der Session

Qodo ist kein PR-Bot. Ich hatte eine weitere KI erwartet, die über einen Pull Request schaut. Gesehen habe ich eine Kontextschicht für Coding-Agents.

Filip Hric

Co-Speaker

Filip Hric

DevRel Engineer bei Qodo

Filip kam über Psychologie und Testen in die IT: manuelle QA bei Slido, dann Testautomatisierung und DevRel. Er lebt in der Slowakei mit vier Kindern und Muffin, einem Berner-Sennenhund-Welpen, der den Stream verschlafen hat.

Der Reviewer, der das Protokoll gelesen hat

Die meisten Reviewer lesen den Diff ohne Vorwissen. Qodo hat das Protokoll gelesen. Bevor es einen Pull Request kommentiert, hat es die ganze Codebase indiziert, jeden Branch, frühere PR-Entscheidungen und die Commit-Historie. Es kann Jira- oder Linear-Tickets einbeziehen, Doku aus Notion oder Confluence und Slack.

Dieser ganze Kontext liegt in Qodos Cloud. Reviews und Toolbox sprechen mit Qodos Dienst, und dort indiziert Qodo deinen Code. Laut Qodo trainiert es keine Modelle mit deinem Code. Single-Tenant-Betrieb, On-Prem und eigene Modell-Schlüssel gibt es nur im Enterprise-Plan, für Teams ab 30 Personen. Für manche Firmen ist das Gespräch damit beendet, bevor es beginnt.

Deshalb reichen seine Findings über den Diff hinaus. Filip zeigte an jedem Review ein Blast-Radius-Tag. Qodo meldet auch Probleme über Repository-Grenzen hinweg, etwa eine Änderung, die einen Login-Service in einem anderen Repository bricht, mit Link auf die genaue Zeile.

Ich kenne dieses Problem. Filips Szenario, ab 08:15: 200 Entwickler mit je einem Coding-Agent schreiben 10- bis 50-mal mehr Code. Vierzig PRs am Tag statt zwei oder drei. Seine Frage: Wer traut sich da noch, auf Merge zu klicken? Meine Kollegen brauchen eine bis fünf Stunden pro Review-Runde. Für vierzig PRs reicht das nicht.

Kleiner macht Qodo diesen Stapel allerdings nicht. Filips Demo-PR fügte rund 500 Zeilen hinzu, und Qodo antwortete mit 19 Findings. Für einen Lead mit vierzig PRs am Tag heißt das: neunzehn Findings pro PR sind mehr Lesestoff, nicht weniger. Einig waren wir uns, dass Relevanz alles entscheidet: Ist das Signal nicht scharf, scrollen Entwickler daran vorbei.

Der Agent soll seine Hausaufgaben nicht selbst benoten

Filips Hauptargument für einen eigenen Reviewer, bei 12:17:

Dieser Agent kann nicht einfach Claude Code sein, das Claude Code reviewt, oder? Oder Codex, das Codex reviewt. Klar findet er vielleicht etwas, aber ... sie haben womöglich denselben blinden Fleck.

— Filip Hric, DevRel Engineer bei Qodo

Ich habe leicht widersprochen. In einem meiner Projekte gibt es einen Skill „implementiere dieses Issue“ und einen getrennten Skill „reviewe diesen PR“. Eine frische Session mit demselben Modell findet trotzdem vieles, was die umsetzende Session übersehen hat. Filip sah darin eine Bestätigung. Er teilt KI-gestützte Arbeit in zwei Aufgaben, Code erzeugen und Code prüfen, und beides müssen getrennte Schritte sein, egal wer sie erledigt.

Einen zweiten Punkt habe ich mitgenommen. Ab 26:10 sagte er: Eine Regel im Kontext des Agenten ist noch keine durchgesetzte Regel. Jemand muss trotzdem prüfen.

Das Ticket prüfen, bevor es Code gibt

Mein Bild von Qodo änderte sich bei 57:59. Filip zeichnete die ganze Kette: Ticket, Plan, Coding-Agent, Review vor dem Commit, PR-Agent. Heute sitzt das Review ganz am Ende. Selbst wenn Qodos Review nur etwa zwei Minuten dauert, kommen die Findings erst nach dem PR. Er will dieselben Prüfungen früher: auf noch nicht committeten Änderungen, auf Plänen und auf Tickets.

100%
klassische Schleife: Findings erst nach dem PRTicketPlanCoding-AgentReview vordem CommitPR-AgentAgentic ToolboxSkills · MCP · CLI, auf Qodo-Kontext: Regeln, PR-Historie, Codebase-Graph, Tickets

Die Agentic Toolbox ist Qodos Weg dorthin. Sie besteht aus einem MCP-Server, einer CLI und einer Reihe von Skills. Qodos PR-Agent nutzt sie, und ein Coding-Agent kann dieselben Werkzeuge aufrufen, lange bevor es einen PR gibt. Der Agent muss sie aufrufen; von selbst unterbricht nichts.

Eine schlechte Beschreibung führt zu einem schlechten Plan, und der führt zu einem schlechten Agenten.

— Filip Hric, DevRel Engineer bei Qodo

Für seine Demo wollte Filip eine absichtlich fehlerhafte App. Das ging auf komische Weise nach hinten los: Mit eingeschaltetem Qodo-Plugin weigerte sich sein Agent, sie zu schreiben, bis er das Plugin abschaltete. Vor seiner nächsten Demo muss er daran denken, es wieder abzuschalten.

Qodos Codebase-Wisdom-Skill kann ein Ticket gegen die Regeln des Repositorys prüfen, bevor jemand Code schreibt. Ich schreibe meine Tickets schon mit einem Coding-Agent. Diesen Skill als letzten Schritt aufzurufen, ist nur ein kleiner Schritt von dem, was ich heute mache.

Regeln, die niemand aufgeschrieben hat

Jedes Team hat Konventionen, die nur in Köpfen existieren. Qodos Rule Miner, gezeigt ab 1:30:16, schlägt Regeln aus Mustern im Code vor, die nie dokumentiert wurden. Eine vorgeschlagene Regel gilt dann für ausgewählte Repositories oder die ganze Organisation und taucht in PR-Reviews und in der Toolbox auf.

Unsichtbare Regeln sichtbar machen ist eine gute Idee. Ob die gefundenen Regeln taugen, haben wir nicht getestet. Es geht auch andersherum. Auswertungen zeigen, welche Regeln alle ignorieren, sodass man sie abschwächen oder löschen kann.

Filip sagte auch voraus, wohin der Blast Radius führt. Um 42:28 meinte er, dass Änderungen mit kleinem Blast Radius irgendwann automatisch gemergt werden. Er stellte klar: Das ist seine eigene Vermutung, nicht Qodos Roadmap.

Sollten wir den Code noch lesen?

Bei 43:42 kamen wir zu der Frage, mit der ich am meisten ringe. Der Merge-Button lockt mich, wie er es vor KI nie getan hat. In einem Projekt kann ich den Next.js-Teil nicht richtig reviewen. Dieser Engpass drängt mich dazu, eine KI reviewen zu lassen und zu mergen.

Es fühlt sich fast unangenehm an, das zu sagen, aber vielleicht gibt es Situationen, in denen man den Code nicht lesen muss.

— Filip Hric, DevRel Engineer bei Qodo

Filip sagte, das hänge vom Kontext ab: Gesundheitswesen und Finanzen sind kein Startup. Zeile für Zeile lesen ist eine Form der Prüfung, die ein Agent genauso gut erledigen kann, und menschliche Aufmerksamkeit ist begrenzt. Live sagte ich, den Code nicht mehr zu lesen, sei nur eine Frage der Zeit. Einen Tag später bin ich hin- und hergerissen. Ich glaube an die Richtung, aber ich bin noch nicht bereit, damit aufzuhören.

Ab 50:56 ging es darum, was KI mit dem Lernen macht. Filip hört oft, KI lasse alle Gehirne verkümmern, und erlebt das Gegenteil. Bei mir ist es gemischt: Ich rechne damit, Java-Details zu verlieren, und habe Wissen über Deployment und GitHub Actions dazugewonnen. Was jetzt zählt: gute Fragen stellen und die Antworten wirklich lesen.

Kein Fix-Button

Qodo findet das Problem, erklärt es und schreibt sogar einen Prompt, den man in seinen Agenten kopieren kann. Code ändert es nicht. Auf meine Frage, warum es keinen Fix-Button gibt, bei 1:36:11, sagte Filip: Er erwartet, dass Agent-Schleifen das Beheben übernehmen und irgendwann auch den Klick auf Merge. Auch das ist seine Annahme, kein Versprechen.

Was kostet ein Review?

Filip hält sich aus dem Thema Preise heraus, und Qodo rechnet in Credits ab. Laut Qodos Preisseite kostet ein Credit 0,012 $, und 2.500 Credits reichen für etwa 18 Reviews im Monat. Das sind rund 1,67 $ für ein durchschnittliches Review, aber größere PRs kosten mehr, und ungenutzte Credits verfallen jeden Monat. Was eine Ticket-Prüfung oder eine Codebase-Wisdom-Abfrage kostet, steht dort nicht.

Das ist kein reines Qodo-Problem. KI-Werkzeuge verkaufen Tokens, Credits oder Coins, und selten weiß man, was man dafür bekommt. Man erfährt es aus der Rechnung. Bevor ich vierzig PRs am Tag durch eines davon schicke, will ich einen Preis pro Arbeitseinheit, nicht pro Währungseinheit.

Fazit

Am treffendsten beschreibt man Qodo als Kontextschicht für Coding-Agents. Es bringt Tickets, Historie und ungeschriebene Regeln zu dem Agenten, der gerade arbeitet, vom Ticket bis zum Pull Request. Der PR-Agent ist die sichtbarste Stelle.

Würde ich es morgen ausprobieren, finge ich klein an: Qodos PR-Agent auf unseren Pull Requests, mit einem Menschen als Absicherung, und mit einem Blick auf den Credit-Pool. Wenn das hält, ließe ich es allein laufen.

Kommentare

Kommentare optional von GitHub laden

Die Kommentarfunktion wird über Giscus und GitHub Discussions bereitgestellt. Sie wird erst nach Ihrer ausdrücklichen Einwilligung geladen. Beim Laden können personenbezogene Daten wie Ihre IP-Adresse und technische Metadaten an GitHub übermittelt sowie Cookies oder ähnliche Technologien gesetzt werden.

Bitte bestätigen Sie zuerst Ihre Einwilligung, bevor die Kommentare geladen werden.

Mehr dazu in der Datenschutzerklärung.