WissenClaude Code & Vibe Coding
Claude Code Änderungen prüfen vor dem Commit, wie du nichts Kaputtes übernimmst
Ein Agent, der Code schreibt, ist kein Grund, den Diff ungelesen zu committen. Der Workflow, mit dem du vor jedem Commit wirklich weißt, was sich geändert hat.
Ein Handwerker, der eine Rechnung unterschreibt, ohne die Arbeit vorher angesehen zu haben, würde niemandem einfallen. Bei Code aus einem KI-Agenten passiert genau das ständig: die Änderung wirkt fertig, die Zusammenfassung klingt überzeugend, also wird committet, ohne den eigentlichen Diff zu lesen.
Kurz gesagt
Claude Code Änderungen vor dem Commit zu prüfen heißt, den Diff zu lesen statt der Zusammenfassung zu vertrauen, eine automatisierte Prüfung mit /code-review laufen zu lassen und die Tests wirklich auszuführen statt sie nur zu überfliegen. Erst wenn diese drei Schritte durch sind, ist der Commit sinnvoll. Wer direkt committet, verlässt sich auf den Ton der Antwort statt auf eine echte Prüfung, das führt zu kaputten Änderungen im Hauptzweig.
Warum "klingt fertig" kein Prüfschritt ist
Ein Agent beschreibt eine erledigte Aufgabe fast immer positiv, das liegt an der Art, wie Sprachmodelle Text erzeugen, nicht an einer bewussten Täuschung. Die Zusammenfassung "ich habe X geändert und Y funktioniert jetzt" ersetzt aber keinen Blick auf den echten Diff. Genau dort steckt der Unterschied zwischen einer Änderung, die harmlos aussieht, und einer, die eine Zeile enthält, die niemand angefragt hat.
Die eingebauten Werkzeuge
Claude Code bringt für genau diesen Zweck zwei Befehle mit. /diff öffnet eine interaktive Ansicht der noch nicht committeten Änderungen und zeigt auch, was einzelne Antworten im Verlauf jeweils verändert haben. /code-review, auch aufrufbar als /review, lässt eine zusätzliche, unabhängige Prüfung über genau diesen Diff laufen und meldet Befunde zu Korrektheit sowie zu unnötiger Komplexität. Ein Effort-Level von low bis max steuert dabei, wie gründlich geprüft wird, mit dem Zusatz --comment landen Befunde direkt als Kommentare in einem Pull Request, mit --fix werden sie als ungestagte Änderungen im Arbeitsverzeichnis angewendet, committet ist dadurch noch nichts.
Ein Workflow, der wirklich schützt
Die vier Schritte oben in der Übersicht sind bewusst keine Formalität, sondern eine Reihenfolge, bei der jeder Schritt etwas prüft, das der vorherige nicht abdeckt: der Diff zeigt, was sich geändert hat, das Review bewertet die Änderung inhaltlich, und der Testlauf beweist, dass sie tatsächlich funktioniert. Fehlt einer der drei, bleibt eine Lücke. Wichtig dabei: Permissions verhindern, dass eine riskante Aktion ohne Rückfrage passiert, sie ersetzen aber keine inhaltliche Prüfung, ob die Änderung richtig ist. Und falls trotzdem etwas durchrutscht, hilft im Zweifel ein Blick auf die Backup-Strategie für den Fall, dass eine Datei verschwunden ist.
Ich denke, der eigentliche Denkfehler ist, Review als etwas zu behandeln, das man bei einem Agenten überspringen kann, weil er ja schon "geprüft" wirkt. Ein Mensch, der Code schreibt, bekommt auch nicht automatisch Vertrauen ohne Review, nur weil er es eilig hatte. Für einen Agenten gilt derselbe Maßstab, eher strenger, weil er nie zögert, bevor er eine Antwort gibt.
Quellen: Code Review (Claude Code Docs) · Code review, Claude Academy
Häufige Fragen
Was ist der Unterschied zwischen /diff und /code-review?
/diff zeigt dir die geänderten Zeilen zum Selbstlesen. /code-review lässt zusätzlich eine automatisierte Prüfung über genau diesen Diff laufen und meldet Befunde zu Korrektheit und Code-Qualität.
Ändert --fix meinen Code automatisch, ohne dass ich zustimme?
Die gefundenen Probleme landen als ungestagte Änderungen im Arbeitsverzeichnis. Du siehst sie, bevor irgendetwas committet wird, und kannst sie einzeln annehmen oder verwerfen.
Reicht ein Review, wenn die Tests schon grün sind?
Nein. Grüne Tests zeigen nur, dass das Verhalten stimmt, das die Tests auch tatsächlich prüfen. Ein Review deckt zusätzlich Dinge ab, die kein Test erfasst, etwa unnötige Komplexität oder eine unsichere Stelle im Code.
Muss ich das bei jeder kleinen Änderung machen?
Bei einer Ein-Zeilen-Korrektur ist das übertrieben. Der Workflow lohnt sich, sobald eine Änderung Logik, externe Daten oder etwas Kundenrelevantes berührt.
Willst du das bei dir umsetzen?
In der Community zeige ich, was bei mir hält. Im Erstgespräch schauen wir uns dein Vorhaben konkret an.