KI-generierten Code mit Difftastic reviewen

KI-Coding-Tools bündeln häufig eine echte Logikänderung mit einer vollständigen Neuformatierung in einem einzigen Commit, und ein zeilenbasiertes git diff lässt die eine verhaltensändernde Zeile in einem Meer aus Rot und Grün verschwinden. Difftastic ist ein strukturelles Diff-Tool, das Code in Syntaxbäume parst und diese Bäume anstelle des Textes vergleicht – reine Neuformatierungen, Umbrüche und Whitespace-Änderungen werden dabei als keine Änderung gewertet und nur die Bearbeitungen, die das Verhalten tatsächlich beeinflussen, bleiben sichtbar. Dieser Artikel erläutert, was Difftastic ist, wie es in Git eingebunden wird und wie ein konkreter Workflow für das Review von Agent-Commits aussieht.

Das Problem: KI-Diffs verbergen die entscheidende Zeile

Agents und Assistenten wie Cursor, GitHub Copilot und Claude Code formatieren häufig eine ganze Funktion neu – oder umbrechen einen langen Aufruf über mehrere Zeilen – und kombinieren dies im selben Commit mit der Änderung einer einzigen Bedingung. Ein zeilenorientiertes Diff kann den Unterschied nicht erkennen: Es markiert jede berührte Zeile als geändert. Das Ergebnis ist eine Wand aus Rot und Grün, in der die eine Bearbeitung, die das Laufzeitverhalten verändert, irgendwo dazwischen versteckt ist. Das Review von KI-generiertem Code ist genau die Situation, in der das Signal-Rausch-Verhältnis am meisten zählt – denn die Neuformatierung ist maschinell erzeugter Lärm, während die Verhaltensänderung das ist, wofür man beim Merge verantwortlich ist.

Was ist Difftastic?

Difftastic ist ein strukturelles Diff-Tool, das Dateien anhand ihrer Syntax statt ihres Textes vergleicht. Es parst jede Version mit tree-sitter, erstellt einen abstrakten Syntaxbaum und vergleicht die Bäume. Die praktische Konsequenz: Wenn Code so umformatiert wird, dass er sich nun über mehrere Zeilen erstreckt, zeigt Difftastic nur die tatsächlichen Änderungen an, und ein verschobener oder umbenannter Block wird als Verschiebung gemeldet – nicht als Löschen und Neu-Hinzufügen.

Difftastic ist in Rust geschrieben, wurde von Wilfred Hughes entwickelt und ist Open Source unter der MIT-Lizenz. Es unterstützt über 30 Programmiersprachen durch tree-sitter-Parser – nicht die „50+”, die in manchen Rezensionen behauptet werden. Bei einer nicht erkannten Dateiendung fällt es graceful auf ein zeilenorientiertes Diff mit Wort-Highlighting zurück, sodass bei nicht unterstützten Sprachen nichts abbricht.

Difftastic installieren und in Git einbinden

Das difft-Binary lässt sich über einen Paketmanager oder cargo installieren und anschließend als externes Git-Diff registrieren:

# macOS
brew install difftastic

# Rust-Toolchain (benötigt Rust 1.85+ ab Version 0.69)
cargo install difftastic

Für einen einmaligen Einsatz kann die Konfiguration inline übergeben werden, ohne dauerhaft etwas zu ändern:

git -c diff.external=difft diff
git -c diff.external=difft show --ext-diff

Um Difftastic als Standard festzulegen, wird folgendes in ~/.gitconfig eingetragen – direkt aus dem Handbuch:

[diff]
    external = difft

Damit verwendet git diff Difftastic; andere Unterbefehle benötigen dann nur noch das Flag --ext-diff, z. B. git show --ext-diff und git log -p --ext-diff. Die empfohlene Konfiguration hat sich in Difftastic 0.61 (Oktober 2024) geändert – wer einen älteren Blog-Snippet kopiert, sollte ihn durch die aktuelle Version aus dem Handbuch ersetzen. Die Inline-Ausgabe ist der zweispaltigen Standardansicht vorzuziehen; sie lässt sich mit --display inline aktivieren:

difft old.js new.js --display inline

Warum ist Difftastic beim Review von KI-Code überlegen?

Strukturelles Diffing konzentriert sich auf geänderte Syntaxknoten und eliminiert das Rauschen durch nicht wesentliche Bearbeitungen. Am deutlichsten zeigt sich das beim klassischen Fall: Neuformatierung plus ein neues Argument. Angenommen, ein Agent nimmt eine einzeilige Funktionssignatur und umbrecht sie – weil sie nun das Zeilenlängenlimit überschreitet – über mehrere Zeilen, und fügt dabei ein Argument hinzu:

// vorher
function createUser(name, email) {}

// nachher
function createUser(
  name,
  email,
  role,
) {}

Ein zeilenbasiertes Diff hebt den gesamten Block hervor, weil sich jede Zeile textuell verändert hat. Difftastic hebt nur das neue Argument role hervor – die einzige Bearbeitung, die das Verhalten ändert. Genau diese Art von subtiler Ergänzung kann einem Reviewer entgehen, der ein verrauschtes Diff nur überfliegt. Dieselbe Logik gilt für Extraktionen: Wenn ein Agent einen Block in eine neue Hilfsfunktion auslagert, kennzeichnet Difftastic den neuen Funktionsnamen als hinzugefügt, anstatt Wrapper und Rumpf als ein verworrenes Löschen-plus-Hinzufügen darzustellen.

Ein Commit-Review-Workflow für Agent-Output

Um nur die semantischen Änderungen eines Agents zu sehen, wird der genaue Commit gezielt angesteuert:

git show <agent-commit> --ext-diff
# oder den gesamten Branch reviewen
git log -p --ext-diff main..agent-branch

Dabei sollte auf drei Dinge geachtet werden: Ergänzungen und Entfernungen, die Difftastic tatsächlich als Änderungen kennzeichnet; Blöcke, die als Verschiebungen oder Umbenennungen statt als Umschreibungen gemeldet werden; und alle Hunks, die auf ein einfaches zeilenbasiertes Diff zurückfallen – das ist das Signal, dass Difftastic auf eine nicht erkannte Dateiendung oder einen Parse-Fehler gestoßen ist. Standardmäßig fällt Difftastic bei Parse-Fehlern auf ein zeilenorientiertes Diff zurück – eine konservative Entscheidung, damit es nie behauptet, zwei syntaktisch unterschiedliche Dateien seien identisch. Das ist relevant für KI-Output mitten in einem Refactoring, der möglicherweise nicht sauber geparst werden kann. Die Toleranz lässt sich mit export DFT_PARSE_ERROR_LIMIT=20 erhöhen, wenn eine nahezu valide Datei unnötigerweise zurückfällt.

Für die Automatisierung kann Difftastic prüfen, ob zwei Dateien denselben AST haben, ohne ein Diff zu rendern:

difft --check-only --exit-code before.js after.js

Der Exit-Code wird auf 0 gesetzt, wenn keine syntaktischen Änderungen vorliegen, und auf 1, wenn welche vorhanden sind – ein schnelles Gate für einen Pre-Merge-Hook oder einen CI-Schritt, der die Frage beantwortet: „Hat der Agent das Verhalten geändert oder nur neu formatiert?”

Einschränkungen und die Kombination mit delta

Die Trade-offs sollten ehrlich bewertet werden. Difftastic skaliert bei Dateien mit vielen Änderungen vergleichsweise schlecht und kann viel Arbeitsspeicher beanspruchen. Es sollte daher als Review-Tool für spezifische Commits betrachtet werden, nicht als vollständiger Ersatz für git diff. Die zweispaltige Darstellung ist in der Regel gut, kann aber gelegentlich verwirren. Da es ein externes Diff-Tool und kein Git-Pager ist, wird es weder im GitHub-PR-Tab „Files” noch in den meisten IDE-Diff-Ansichten gerendert – es ist ein lokales CLI-Tool.

Die pragmatische Lösung ist, beide Tools zu verwenden: einen schnellen Text-Pager für die alltägliche Ansicht und Difftastic für komplexe, formatierungsintensive Diffs.

Delta und diff-so-fancy sind textbasiert; keines der beiden Tools führt AST-Diffing durch. Delta eignet sich als Standard-Pager, während Difftastic zum Einsatz kommt, wenn das Diff in Formatierungsrauschen untergeht.

Ein sauberes strukturelles Diff ist ein Pre-Merge-Filter: Es erkennt die verhaltensändernde Zeile, bevor ein Approve erteilt wird. Die Änderungen, die dennoch durchschlüpfen – die subtile Logikbearbeitung, die ein verrauschtes KI-Diff verborgen hat – sind genau die, die man nach dem Deployment rekonstruieren muss. Das Ansehen einer Session-Replay des fehlerhaften Verhaltens ist eine der direktesten Methoden, um diese Art von Regression aufzudecken. [diff] external = difft noch heute konfigurieren und den nächsten Agent-Commit mit git show <commit> --ext-diff reviewen – und nur noch lesen, was sich wirklich geändert hat.

FAQs

Was ist der Unterschied zwischen Difftastic und delta?

Difftastic ist ein strukturelles Diff-Tool, das Code mit tree-sitter parst und abstrakte Syntaxbäume vergleicht, sodass Neuformatierungen und Zeilenumbrüche als keine Änderung gewertet werden. Delta ist ein textbasierter, syntax-highlighted Pager, der weiterhin Zeilen vergleicht. Difftastic kann nicht als Git-Pager fungieren und funktioniert ausschließlich als externes Diff-Tool, während delta als Pager für die alltägliche Ansicht dient. Delta sollte als Standard verwendet werden, Difftastic hingegen für formatierungsintensive KI-Diffs.

Was passiert, wenn Difftastic auf eine Datei trifft, die es nicht parsen kann?

Difftastic fällt in zwei Fällen auf ein zeilenorientiertes Diff mit Wort-Highlighting zurück: bei einer nicht erkannten Dateiendung und bei Parse-Fehlern. Der Fallback bei Parse-Fehlern ist eine bewusst konservative Entscheidung, damit Difftastic nie behauptet, zwei syntaktisch unterschiedliche Dateien seien identisch. Das ist relevant für KI-Output mitten in einem Refactoring, der möglicherweise nicht sauber geparst werden kann. Die Toleranz lässt sich mit der Umgebungsvariable DFT_PARSE_ERROR_LIMIT erhöhen, wenn eine nahezu valide Datei unnötigerweise zurückfällt.

Kann Difftastic Diffs im GitHub-PR-Tab 'Files' anzeigen?

Nein. Difftastic ist ein lokales Kommandozeilentool, das als externes Diff-Tool von Git fungiert – nicht als Rendering-Schicht im GitHub-PR-Tab 'Files' oder in den meisten IDE-Diff-Ansichten. Es wird über Befehle wie git show mit dem Flag --ext-diff oder git log -p --ext-diff aufgerufen. Für einige Tools wie magit existieren Drittanbieter-Integrationen, aber die Unterstützung im PR-Tab und in IDEs ist begrenzt. Difftastic sollte daher als terminalbasierter Review-Schritt betrachtet werden.

Wie lässt sich prüfen, ob ein KI-Commit das Verhalten geändert oder nur neu formatiert hat?

difft mit den Flags --check-only und --exit-code auf zwei Versionen einer Datei ausführen. Difftastic prüft, ob die Dateien denselben abstrakten Syntaxbaum teilen, ohne ein Diff zu rendern, und setzt den Exit-Code auf 0, wenn keine syntaktischen Änderungen vorliegen, und auf 1, wenn welche vorhanden sind. Das ist deutlich schneller als ein vollständiges Diff und eignet sich als sauberes Gate für einen Pre-Merge-Hook oder einen CI-Schritt, der echte Verhaltensänderungen von reinen Neuformatierungen unterscheidet.