Lass deinen Coding-Agent nicht seine eigenen Hausaufgaben benoten
mit Filip HricGeplant 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.

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.
Mehr dazu in der Datenschutzerklärung.
Projektquelle
Arbeits-Repository
Hier findest du Prompts, Instructions und Beispiele aus dem gezeigten Modernisierungs-Workflow.
Repository öffnenTimestamps der Session
- 00:00Einführung
- 01:38Begrüßung von Filip Hric
- 02:47Filips Weg von QA zu DevRel
- 05:38Was Qodo ist: Code-Governance und Qualität
- 08:15Warum KI-Code-Review zählt, wenn alle mehr Code ausliefern
- 18:13Code-Generierung vs. Code-Verifikation
- 26:10Regeln, die geladen, aber nicht durchgesetzt sind
- 28:29Demo: Qodo-Review auf Filips Java-Raumbuchungs-PR
- 35:05Ein Skill-Insight-Finding: vier Meetings erzeugen fünf Buchungen
- 39:02Finding-Kategorien und Blast Radius
- 43:42Sollten wir den Code noch lesen?
- 50:56Lernen mit KI und der Aufstieg der Generalisten
- 57:59Shift Left: Review vor dem PR
- 1:03:04Qodos Agentic Toolbox: MCP, CLI und Skills
- 1:07:12Demo: ein Linear-Ticket prüfen, bevor es umgesetzt wird
- 1:11:54Dashboard, Integrationen und Regelverwaltung
- 1:22:08Einstieg: Repos verbinden und die Software-Map
- 1:30:16Regeln im großen Maßstab und der Rule Miner
- 1:36:11Indizierte Branches und warum es keinen Fix-Button gibt
- 1:41:13Review Resolver, Preise und Abschluss
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.

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.
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.
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.
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 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.
Nützliche Links
- Introducing Qodo's Agentic Toolbox, der Launch-Post mit allen Skills
- Feature-Seite der Qodo Agentic Toolbox, mit Installationsanleitung für Claude Code, Codex und Kiro
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.