Prüfe die Absicht, lass die Maschinen den Rest erledigen

Agent-Pull-Requests kommen in größerer Zahl, wirken selbstbewusst, und du kannst den Autor hinterher nicht fragen "was hast du dir dabei gedacht?". Erste Forschung zeigt allmählich, was das in der Praxis bedeutet.

Eine Studie zu 7.156 Agent-PRs ergab, dass die Art der Aufgabe mehr zählt als der Agent, der sie geschrieben hat: "documentation tasks achieve 82.1% acceptance compared to 66.1% for new features." Kein Agent gewann in jeder Kategorie. [2] Eine zweite Studie untersuchte 654 abgelehnte Agent-PRs und fand sieben Ablehnungsmuster, die nur bei Agent-PRs auftreten — und dass "a large proportion of rejected PRs (67.9%) lack explicit reviewer feedback." [1] Mit anderen Worten: Meistens sagt niemand dem Agenten warum.

Beide Studien nutzen denselben öffentlichen Datensatz von Agent-PRs (AIDev) und wurden beide im Februar 2026 veröffentlicht; Agenten haben sich seitdem weiterentwickelt — lies die Zahlen als Richtung, nicht als Rangliste.

Alles, was eine Maschine prüfen kann, sollte nie einen Menschen erreichen: Formatierung, Typen, Lint, Komplexität, Tests. Jedes davon gehört früher in die Kette — beim Edit des Agenten, beim Commit, in der CI. Wie du das aufsetzt, zeigen wir in unserem Guide zu sofortigem Feedback für Coding-Agenten.

Googles Guide zu Code-Reviews gilt weiterhin für Agenten: Der Reviewer schaut auf Design, Funktionalität, Komplexität, Tests, Namensgebung und Kommentare — die Dinge, die eine Codebasis über die Zeit gesünder machen. [3] Der Unterschied bei Agenten ist, dass der mechanische Teil dieser Liste fast vollständig automatisiert werden kann.

"Fertig, alle Tests bestehen" ist eine Behauptung. Verlange stattdessen Beweise. Füge jeder Story eine Übergabezeile hinzu, die den Agenten bittet, "summarize changed files, checks run, failures encountered, and any remaining risk." [8] Cursors Cloud Agents können dem Pull Request außerdem Screenshots, Videos und Log-Referenzen anhängen, sodass du sehen kannst, dass die Änderung funktioniert, ohne den Branch auszuchecken. [7]

## What changed
- auth/login-form.tsx — locked-account message + reset link
- auth/login-form.test.tsx — new test for the locked case

## Checks run
- npm run typecheck ✔
- npm test -- auth ✔ (14 passed)

## Failures hit
- First run broke the signup error style; fixed by reusing ErrorBanner.

## Remaining risk
- Copy not reviewed by product. Lockout threshold unchanged (non-goal).

Lass den Agenten nicht seine eigene Arbeit bewerten. Ein automatischer Reviewer in einem frischen Kontext erkennt Dinge, für die der Autor blind ist. Die Claude-Code-Doku beschreibt ein Schreiber/Reviewer-Muster: "A fresh context improves code review since Claude won't be biased toward code it just wrote." [4] Cursor Bugbot "analyzes PR diffs and leaves comments with explanations and fix suggestions" [5], und GitHub Copilot code review macht dasselbe auf GitHub. [6] Claude Code im Web kann noch einen Schritt weiter gehen und Pull Requests automatisch reparieren: Es beobachtet einen PR und reagiert auf CI-Fehler und Review-Kommentare — ein gutes Beispiel dafür, Befunde an den Agenten zurückzuschicken. [9]

Es gibt eine Kehrseite, und dieselbe Doku spricht sie offen an:

"A reviewer prompted to find gaps will usually report some, even when the work is sound, because that is what it was asked to do. Chasing every finding leads to over-engineering." [4]

Handle also nur bei Befunden, die Korrektheit oder die genannten Anforderungen betreffen. Alles andere ist optional.

Erinnere dich an die 67,9 %: Die meisten abgelehnten Agent-PRs tragen keinen expliziten Grund. [1] Wenn du einen PR ablehnst oder Änderungen verlangst, sag warum — im PR oder in der Story. "Falsch" lehrt nichts. "Das sollte das bestehende ErrorBanner wiederverwenden, siehe signup-form.tsx" behebt diesen Durchlauf und den nächsten. Wenn dasselbe Feedback immer wieder auftaucht, gehört es in eure gemeinsamen Konventionen, nicht in einen weiteren Kommentar.

Das Argument dieses Guides ist, dass Review in Schichten ablaufen sollte: zuerst Maschinen, dann ein unabhängiger Reviewer, zuletzt du — gemessen an der Story. Aerunit deckt die mittlere Schicht und den Maßstab ab. Wenn ein Agent einen Pull Request öffnet, prüft Aerunit ihn automatisch und kann die Befunde an dieselbe Agenten-Session zurückschicken, damit der PR, den du öffnest, bereits eine Runde durchlaufen hat.

Der Maßstab ist die Story selbst: Aerunits Story-Writer schlägt Linear-Issues mit Umfang, Akzeptanzkriterien und Non-Goals vor, sodass du gegen ein benanntes Ziel prüfst. Und Team-Konventionen, die du sonst in Review-Kommentaren wiederholen würdest, leben einmal in geteiltem Kontext und Skills und fließen in jede Story und jeden Lauf ein.