Wenn KI den Code schreibt, sollte dann auch die Session Teil des Commits sein?

(github.com/mandel-macaque)

26 Punkte von GN⁺ 2026-03-03 | 4 Kommentare | Auf WhatsApp teilen

git-memento ist ein Erweiterungstool, das von KI erzeugte Code-Sessions automatisch in Git-Commits dokumentiert und den zu jedem Commit gehörenden KI-Dialog als git notes speichert
Beim Commit kann eine KI-Session-ID angegeben werden; Zusammenfassungen werden in refs/notes/commits, vollständige Gespräche in refs/notes/memento-full-audit getrennt gespeichert, um Nachvollziehbarkeit und Privatsphäre zugleich sicherzustellen
Unterstützt verschiedene KI-Anbieter wie Codex und Claude; bei der Erstellung von Zusammenfassungen können benutzerdefinierte Skills angewendet werden, um die Qualität der Commit-Notizen zu steuern
In GitHub Actions integriert und bietet automatische Kommentare zu Commit-Notizen, CI-Gate-Prüfungen sowie automatische Übernahme von Notizen beim Merge (merge-carry)
Unterstützt Windows/Mac/Linux. Ein Tool, das die Transparenz von KI-generiertem Code erhöht und in kollaborativen Umgebungen die Auditierbarkeit von KI-Beiträgen sicherstellt

Überblick über git-memento

git-memento ist ein Git-Erweiterungstool zur Erfassung von KI-Coding-Sessions auf Commit-Ebene
- Beim Commit werden die Dialoginhalte der KI-Session als Markdown-Notiz aufbereitet und gespeichert
- Zu jedem Commit bleiben Herkunft und Gesprächskontext der KI-Session erhalten, sodass sich der Entstehungsprozess des Codes nachvollziehen lässt
Standardmäßig wird Codex unterstützt, andere KI-Modelle wie Claude können ebenfalls konfiguriert werden
Veröffentlicht unter der MIT-Lizenz und verteilt als NativeAOT-basierte Einzeldatei

Wichtige Befehle und Funktionen

Mit git memento init wird die repository-spezifische Konfiguration initialisiert und die Information zum KI-Anbieter in .git/config gespeichert
Der Befehl git memento commit fügt zusammen mit dem Commit eine Session-Notiz hinzu
- Mit der Option --summary-skill werden Zusammenfassung und vollständige Session getrennt gespeichert
- Die Zusammenfassung wird in refs/notes/commits, das vollständige Protokoll in refs/notes/memento-full-audit abgelegt
git memento amend ermöglicht das Hinzufügen oder Bearbeiten einer neuen Session für einen bestehenden Commit
git memento audit prüft innerhalb eines Commit-Bereichs, ob Notizen fehlen und ob Metadaten gültig sind
git memento doctor überprüft Konfiguration, Notiz-Referenzen und den Status der Remote-Synchronisierung

Notizverwaltung und Synchronisierung

Mit git memento share-notes werden Notizen in ein Remote-Repository (origin usw.) gepusht
git memento notes-sync führt Remote-Notizen sicher zusammen und erstellt Backups
- Sowohl refs/notes/commits als auch refs/notes/memento-full-audit werden synchronisiert
git memento notes-carry überträgt Notizen nach Rebase oder Squash auf neue Commits
git memento notes-rewrite-setup aktiviert die Konfiguration für die automatische Übernahme von Notizen

GitHub-Actions-Integration

Das Repository enthält eine wiederverwendbare GitHub Action
- mode: comment — liest Commit-Notizen und erstellt automatisch Kommentare
- mode: gate — prüft in der CI-Phase, ob Notizen fehlen, und blockiert bei Fehlern den Build
- mode: merge-carry — überträgt beim Mergen eines PR Notizen auf den Merge-Commit
Jeder Modus ist in action.yml definiert; außerdem ist ein Artefakt für die Marketplace-Veröffentlichung (dist/note-comment-renderer.js) enthalten
PRs mit dem Label ignore-notes überspringen die Gate-Prüfung und hinterlassen den Kommentar „Notes ignored“

Notizformat und Versionsverwaltung

Notizen werden im Format git notes add -f -m "" gespeichert
Für die Unterstützung mehrerer Sessions werden Versions-Tags(``) und Abschnittstrenner verwendet
Benutzernachrichten werden mit dem Git-Benutzernamen, KI-Antworten mit dem Namen des Anbieters gekennzeichnet
Bestehende Notizen mit nur einer Session werden bei Bedarf automatisch aktualisiert, um die Kompatibilität zu erhalten

4 Kommentare

wedding 2026-03-03

Bei privaten Projekten exportiere ich die Session, committe sie und bei öffentlichen Projekten committe ich sie nur dann, wenn ich entscheide, dass eine Zusammenfassungsdatei unbedingt nötig ist.
Letztlich gibt es darin auch personenbezogene Daten … und je nach Tool sind pro Session leicht mehr als 10 MB zusammen, daher fühlt es sich nicht richtig an, das einfach so hochzuladen.

roxie 2026-03-28

Aber wir leben doch in einer Zeit, in der Speicherplatz so günstig ist wie nie zuvor!

GN⁺ 2026-03-03

Hacker-News-Kommentare

Wenn ich mit AI Code schreibe, beginne ich mit einer Datei project.md
Darin beschreibe ich das gewünschte Ergebnis und lasse die AI auf dieser Grundlage plan.md schreiben
Danach überarbeite ich plan.md mehrfach, bis der gewünschte Plan steht, und erstelle dann eine detaillierte Todo-Liste, die ich ans Ende von plan.md anhänge
Wenn ich vollständig zufrieden bin, weise ich die AI an, die Todos auszuführen, ohne weitere Rückfragen bis zum Ende durchzuarbeiten
Zum Schluss committe ich project.md, plan.md und den gesamten Code
So wird plan.md zu einer Art reproduzierbarem Artefakt, auf dessen Basis ein späteres, leistungsfähigeres Modell Änderungen vornehmen oder Fehler finden kann
- Ich mache etwas Ähnliches, teile es aber in drei Dokumente auf — design, plan, debug
  Design wird pro Feature geschrieben und hält offene Fragen ausdrücklich fest
  Plan verwalte ich in der Struktur plan/[feature]/phase-N-[description].md, und wenn ich an Build- oder Laufzeitgrenzen stoße, halte ich an
  In der Debug-Phase formuliere ich Hypothesen zu möglichen Ursachen, prüfe sie mit Logging/Tracing und behebe dann den Fehler
  Mit dieser Methode hatte ich sowohl bei neuen Projekten als auch bei Legacy-Code fast eine Erfolgsquote von 100 %
  Der Nachteil ist, dass sich zu viele Markdown-Dateien ansammeln, aber die Historie ist für spätere Änderungen so nützlich, dass ich es bisher nicht automatisiert habe
- Das klingt nach einem spec-basierten Ansatz
  GitHub spec-kit könnte einen Blick wert sein
- Die „brainstorming“-Funktion von obra/superpowers ist fast genau derselbe Workflow. Wirklich großartig, wenn man es ausprobiert
- Früher habe ich Beads so verwendet und danach GuardRails gebaut
  Wenn man das Modell Marktanalysen und Vorschlagsprüfungen iterativ durchführen lässt, entwirft es gewissermaßen Prompts in einer Sprache, die es selbst verstehen kann
  Kürzlich habe ich erfahren, dass XML das Verhalten von Claude beeinflusst, und denke deshalb die Struktur von GuardRails erneut durch
  Link zum Einführungspost
- Ich nutze eine ähnliche Struktur, habe aber zusätzlich eine Datei „context“
  Wenn der Plan fertig ist, erstelle ich „context.md“, damit ich später darauf zurückgreifen kann, falls ich einen falschen Plan zurückrollen muss
  Ich musste das bisher noch nie tatsächlich verwenden, aber konzeptionell ist es nützlich
  Ich bin mir nur unsicher, wo solche Dateien abgelegt werden sollten, deshalb sind sie noch nicht im Repo
  Mich würde interessieren, wo ihr solche aufgabenbezogenen md-Dateien speichert
Meiner Meinung nach ist das dieselbe Frage wie: „Soll man jede Zeile committen?“
Entscheidend ist letztlich, für wen die Aufzeichnung gedacht ist
Die meisten Sessions enthalten viel Rauschen, viele Fehlversuche und unnötige Informationen
Wichtig ist das Ergebnis der Session, nicht der Prozess selbst
Ein anfängliches spec oder der erste Prompt haben allerdings Wert. Es ist sinnvoll, das zusammenzufassen und in einer Commit-Message oder einer Markdown-Datei festzuhalten
- Für Menschen sind solche Sessions komplex und laut, aber für zukünftige AI könnten diese Informationen nützlich sein
  Frühere Sessions könnten als Lernkontext dienen, um aktuelle Arbeit fortzuführen
  Besonders hilfreich kann das sein, um die Grenzen des Modells zu verstehen und Stellen zu finden, an denen der Code von der Absicht des Nutzers abweicht
  Letztlich halte ich es für wichtig, alle menschlichen Eingaben aufzuzeichnen, damit Open-Source-Modelle besser werden können
- Statt „ob man jede Zeile committet“ ist vielleicht die passendere Analogie, ob man alle Notizen und gescheiterten Versuche aufbewahren sollte
- In der Wissenschaft gibt es dieses Problem schon länger — die Reproduzierbarkeitskrise
  Dasselbe Ergebnis sollte auch dann herauskommen, wenn man die Anfangsbedingungen und das Rauschen mit einbezieht
  Sonst wird zukünftige Code-Wartung zu einem Ratespiel über die ursprüngliche Absicht
  Passender Artikel
- Für Organisationen, denen Transparenz wichtig ist, kann das für Audits wertvoll sein, aber realistisch gesehen: Wer liest solche langen Logs?
- Man muss nicht jede Session speichern, aber die Momente, in denen Anforderungen während der Detailarbeit konkret werden, sind wertvoll
Ich habe vor einer Woche eine ähnliche Idee vorgeschlagen (Link)
Es gab aber viel Widerspruch — AI-Projekte entstehen nicht aus einer einzelnen Eingabe, sondern in einem dialogischen Prozess und lassen sich daher schwer wie Quellcode als Artefakt behandeln
Trotzdem gibt es inzwischen so viele generierte Projekte auf Show HN, dass das Rauschen ein ernstes Problem geworden ist
Ganz ausschließen kann man sie nicht, aber im aktuellen Zustand sinkt mein Interesse
Ich überlege, wie die Community mit diesem Problem umgehen sollte
- Ich orientiere mich an Boris Tanes Methode, mit Claude Code zu arbeiten
  Ich committe research.md und plan.md und nutze sie als lebendiges Nachschlagewerk für Architektur und Features
  Ich stelle den Feature-Namen an den Anfang des Dateinamens, damit Claude relevante Entwürfe schnell laden kann
  Referenzblog
- Das Problem ist nicht fehlender Kontext, sondern dass die Hürde für Aufwand gesunken ist
  Projekte, die früher interessant gewesen wären, lassen sich jetzt zu leicht erstellen
  Menschen zum Lesen langer Session-Logs zu bringen, ist keine Lösung. Die Fähigkeit zum Zusammenfassen und Planen wird wichtiger
- Es wäre gut, wenn Codex die komplette Session als Markdown exportieren könnte
  Der eigentliche Wert von Vibe Coding liegt darin, den Prozess von Versuch und Scheitern zu sehen
- Ich überlege auch, zwei Projekte auf Show HN zu posten
  Interessanter als nur das Ergebnis ist es, wenn es den Entstehungsprozess und Erklärungen dazu gibt
  Deshalb fände ich neben [Show HN] auch eine Kategorie wie [Creations] sinnvoll
  Beispiel: eine einfache Chess-Engine wäre [Creations], eine Chess-Engine in 1k dagegen [Show HN]
  PerfBoard und Lerc sind Beispiele dafür
Eine Session ist nur ein Zwischenergebnis und muss nicht Teil des Endergebnisses sein
Wenn die Gründe für Code-Änderungen wichtig sind, sollte man sie in Commit-Messages oder Dokumentation festhalten
- Letztlich ist das ein Zusammenfassungsproblem
  Zum Zeitpunkt des Commits weiß man nicht, welche Fragen spätere Leser haben werden
  Deshalb speichere ich Sessions lieber und erzeuge später Zusammenfassungen anhand von Fragen
  Git AI verfolgt diesen Ansatz
  Heutige Engineers arbeiten so schnell, dass sie oft schon nach einer Woche nicht mehr wissen, warum sie etwas so gemacht haben
- Zumindest eine Zusammenfassung der Session ist notwendig
  Forschungsorientierte Prompts sollte man zusammenfassen, codegenerierende Prompts besser unverändert speichern
  So bleiben Reproduzierbarkeit und Reviewbarkeit erhalten
- Früher ließ ich LLMs nur die Commit-Message schreiben, aber inzwischen finde ich Versionsverwaltung für Plan-Dateien besser
  Der Plan bildet sogar den Fehlerbehebungsprozess ab und wird dadurch für die nächste Iteration zu einem nützlichen Dokument
- In meinem Fall ist das Repo selbst der Speicher des Agenten
  Verschiedene Repos schicken sich gegenseitig Nachrichten und verwalten so Feature-Requests
  Ich speichere sowohl die Originalgespräche als auch semantisch komprimierte Erinnerungen, um Spezifikationen und Anforderungen neu zu ordnen
- Das Speichern von Sessions ist auch für Root-Cause-Analysen oder Postmortems nützlich
Session-Logs sind größtenteils Rauschen
Es ist eine Abfolge aus Fehlversuchen und Rücknahmen; sie neben Commits zu legen ist, als würde man den Browserverlauf speichern
Wichtig sind Commit-Messages, die Absicht und Randbedingungen festhalten
Wenn AI den Code geschrieben hat, ist der Kern nicht das Gespräch, sondern warum man genau so darum gebeten hat
Am Ende geht es vielleicht gar nicht um das Speichern der Session, sondern um die Gewohnheit, Commit-Messages zu vernachlässigen
Auch wenn ich AI nutze, halte ich an klassischen Design-Prozessen fest
Anforderungen → Use Cases → Klassendesign → Definition der Randbedingungen → Ausführung durch die AI
So bleibt das architektonische Urteilsvermögen beim Menschen, während AI die wiederholte Implementierung beschleunigt
Wenn man statt Session-Logs solche UML-/Constraint-Dokumente in den Commit aufnimmt, bleiben Absicht und Kontext klar erhalten
Ich finde, Entwickler im Jahr 2026 sollten eine solche würdevolle Form der Zusammenarbeit bewahren
Das ähnelt der Frage, ob man Commits squashen sollte oder nicht
Wer Squash bevorzugt, dem ist nur das Ergebnis wichtig und nicht der Prozess
Wer es anders sieht, möchte die ganze Reise dokumentieren
Mit AI-Sessions ist es genauso: Für das Debuggen des Denkprozesses sind sie nützlich, aber wer eine saubere Historie bevorzugt, muss sie nicht unbedingt sehen
Praktisch ist es am sinnvollsten, Sessions außerhalb des Repos getrennt zu verwalten
- Ich bin auch Team Squash, aber in einem System, das die interne Historie aufklappen kann, würde ich Sessions gern mitsehen
  Mercurial oder Fossil sollen dafür besser geeignet sein
- Ich halte diese Analogie für die treffendste
  Beim Vibe Coding zeigen eher die Prompts die Spuren des Denkens als der Code selbst
  Ob man sie in git ablegt, ist eine andere Frage, aber sie zugänglich zu machen, hat Wert
- Wenn die Entwicklung vom Menschen geführt wird, ist die Nutzung von AI nur ein Werkzeug
  Dann muss man den Prozess in Echtzeit nicht sehen
  Wenn der Code aber vollständig von AI geschrieben wurde, sollte man die Prompts offenlegen
Ich habe auch schon Sessions extrahiert
Dabei geht zwar ein Teil der Informationen verloren, aber Lesbarkeit und Zugänglichkeit werden deutlich besser
Ich finde, zumindest die zusammengefassten Prompts einer Session sollte man speichern
AI-Code-Review ist weniger streng als menschliches Review, und die Absicht steckt nur in den Prompts
Sonst wiederholt man dieselben Fehler immer wieder
Der Wert von Code-Review liegt im Lernen und Verbessern; da AI nicht lernt, muss die Aufzeichnung der Prompts diese Rolle übernehmen
Außerdem ist sie auch für die Bewertung von Prompt-Kompetenz oder für die Ausbildung von Juniors nötig
- Ich stimme aber nicht zu, dass das „selbstverständlich“ sei
  Wir nehmen auch keine Tastatureingaben, Menü-Klicks oder Debugging-Versuche in Commits auf
  Wenn man alle Gespräche speichert, entsteht viel zu viel Rauschen
  Realistisch ist eher, nur Dokumente mit Absichten und Annahmen zu behalten
- Übrigens würde mich interessieren, wie groß ihr eine Session überhaupt einschätzt
Das ist wie die Frage: „Soll man den Google-Suchverlauf in Commits aufnehmen?“ — für mich ganz klar nein
- Perfekte Analogie. Jedes Gedankenfragment zu protokollieren hat ein zu schlechtes Signal-Rausch-Verhältnis
  Besser ist es, nur Gründe, Annahmen und Alternativen in Zusammenfassung festzuhalten
- Wenn man Sessions archiviert, speichert man allerdings auch die Suchanfragen und Ergebnisse, die die AI verwendet hat, und das kann für den Projektkontext nützlich sein
- Niemand will wissen, wie oft jemand nach „div zentrieren“ gesucht hat
  Genauso unnötig sind Logs, in denen das Modell bei Kleinigkeiten festhängt
- Außerdem hat nicht jede Suche überhaupt mit dem Commit zu tun. Es könnten auch sensible Informationen enthalten sein