Lore: Git Commit Messages als strukturiertes Wissensprotokoll für KI‑Coding‑Agenten

KI-Coding-Agenten können einen Patch erklären, ohne zu wissen, warum das Team die naheliegende Alternative vor drei Monaten verworfen hat. Der Diff bleibt im Repository. Die Entscheidung dahinter verschwindet oft im Chat, im Ticket oder im Kopf eines Entwicklers. Das arXiv-Paper „Lore“ schlägt vor, diesen Kontext als strukturierte Git-Trailers an Commit-Messages zu hängen. Das ist kein fertiger Standard und kein getestetes Wundermittel. Als kleine Betriebsregel für kritische Änderungen ist die Idee trotzdem interessant.

Das Problem hinter dem sauberen Diff

Stell dir eine Änderung an einer Authentifizierung vor. Ein Agent ersetzt einen Cache, prüft mehrere Bibliotheken und entscheidet sich gegen eine neue Abhängigkeit, weil das Deployment in einer abgeschotteten Umgebung läuft. Im Commit steht dann vielleicht nur: „fix: cache session lookup“.

Beim nächsten Umbau sieht niemand mehr, welche Randbedingungen galten, welche Alternative bereits gescheitert ist oder ab welchem Lastprofil die Entscheidung neu bewertet werden sollte. Das Paper nennt diesen verlorenen Kontext Decision Shadow.¹

Für mich ist das der nützliche Teil der Idee: Nicht jeder Commit braucht eine Abhandlung. Architektur-, Sicherheits- und Migrationsentscheidungen brauchen aber mehr als einen griffigen Titel. Sonst muss jeder neue Agent dieselbe Recherche wiederholen oder trifft eine alte Fehlentscheidung erneut.

Lore ist ein Vorschlag, kein fertiges Werkzeug

Das Paper schlägt vor, vorhandene Git-Trailers für diesen Kontext zu nutzen. Trailers sind Key-Value-Zeilen in Commit-Messages, etwa Co-authored-by oder Signed-off-by.² Statt eines neuen Speichersystems könnten Teams eigene Felder definieren:

Lore-Constraints: keine neue Laufzeitabhängigkeit; Daten müssen in der EU bleiben
Lore-Alternatives: In-Memory-Cache verworfen, weil mehrere Pods bedient werden
Lore-Agent-Directives: Bei mehr als 10.000 aktiven Konten Sharding prüfen
Lore-Verified-By: menschliches Review vor Merge

Das ist eine Protokollskizze aus dem Paper, keine Aussage darüber, dass ein verbreitetes Paket namens lore diese Daten bereits zuverlässig verarbeitet. Genau diese Unterscheidung ist wichtig. Wer die Methode einführt, sollte zuerst mit Git und den vorhandenen Review-Abläufen arbeiten, statt ein weiteres Tool zu versprechen.

Ein praktischer Startpunkt kann beispielsweise eine Suche in Commit-Messages sein:

git log --format='%H%n%B%n---' --grep='Lore-Constraints:'

Das ersetzt keine gute Abfrageoberfläche. Es zeigt aber, ob die Informationen überhaupt geschrieben werden und ob sie für das Team einen Mehrwert liefern.

Ein kleiner Pilot statt eines neuen Rituals

Der Ansatz passt am ehesten zu Änderungen, bei denen später jemand wissen muss, warum eine Option ausgeschlossen wurde. Dazu gehören Datenmigrationen, Berechtigungen, Architekturgrenzen und Leistungsentscheidungen. Für reine Formatierungen oder einen Tippfehler wären zusätzliche Trailers bloß Ballast.

Ein sinnvoller Pilot beginnt mit zwei Feldern: Constraints und Alternatives. Bei jedem kritischen Commit beantwortet das Team knapp drei Fragen:

• Welche Grenze durfte die Änderung nicht verletzen?
• Welche realistische Alternative wurde verworfen – und warum?
• Unter welcher Bedingung sollte diese Entscheidung erneut geprüft werden?

Mehr braucht es am Anfang nicht. Die Felder können in ein Commit-Template aufgenommen werden; ob sie verpflichtend sind, sollte vom Risikoprofil des Projekts abhängen. Ein Security-Fix verlangt andere Dokumentation als eine Änderung am Frontend.

KI-Agenten können dabei helfen, die Angaben vorzuschlagen. Sie sollten sie aber nicht als Wahrheit in die Historie schreiben. Der Wert eines solchen Records hängt daran, dass jemand die Begründung prüft, ergänzt oder streicht. Sonst konserviert das Repository nur plausibel klingenden Unsinn.

Die Grenzen bleiben real

Git-Trailers lösen kein Wissensmanagement-Problem von allein. Lange Listen machen Commit-Messages schwer lesbar. Historische Commits bleiben weiterhin ohne Kontext. Und ein Team, das Entscheidungen nicht diskutiert, wird sie auch nicht plötzlich sorgfältig dokumentieren, nur weil ein Feld im Template steht.

Auch der Vergleich mit Knowledge Graphs, ADRs oder Agent-Memory-Systemen sollte nicht zu einer falschen Alternative werden. Ein ADR kann für eine große Architekturentscheidung sinnvoller sein. Ein Trailer eignet sich eher für den unmittelbaren Grund einer konkreten Änderung. Beides kann nebeneinander existieren.

Fazit: Kontext dort speichern, wo die Änderung lebt

Lore liefert keinen Beweis, dass strukturierte Commit-Messages den Decision Shadow zuverlässig schließen. Das Paper macht aber eine richtige Beobachtung: Mit mehr KI-Unterstützung steigt die Gefahr, dass begründete Entscheidungen zu bloßen Codezuständen werden.

Die Mindestregel wäre deshalb nicht „alle Commits mit Lore versehen“. Sie lautet: Bei Änderungen mit Sicherheits-, Architektur- oder Betriebsfolgen gehört eine knappe, überprüfte Begründung in das Repository – dort, wo der nächste Mensch oder Agent sie tatsächlich findet.

Footnotes

1. Lore: Repurposing Git Commit Messages as a Structured Knowledge Protocol for AI Coding Agents – arXiv:2603.15566v1, März 2026. https://arxiv.org/abs/2603.15566 ↩

2. Git Trailers – Git-Dokumentation zu Trailer-Zeilen in Commit-Messages. https://git-scm.com/docs/git-interpret-trailers ↩