Jede KI-Änderung ist ein echter Commit mit der anfordernden Person als Autor — mit Branches, Pull Requests und eurem eigenen GitHub-Repository.

KI-generierte Arbeit ist in XAIO normale Softwareentwicklung. Sie ist kein einzelner, undurchsichtiger Generierungsschritt, den man nur ganz annehmen oder ganz wegwerfen kann.

Jede Änderung ist ein Commit

Wenn der Agent einen Turn abschließt, wird das Ergebnis als gewöhnlicher Git-Commit gestaged, committet und gepusht. Als Autor des Commits steht die Entwicklerin oder der Entwickler, die oder der die Änderung angefordert hat; Committer ist XAIO. Historie, Blame und eure Review-Werkzeuge ordnen die Änderung damit der Person zu, nicht einem Werkzeug.

Weil es gewöhnliche Commits sind, funktioniert alles weiter, was ihr ohnehin tut: Diffs, Branches, Merges, Pull Requests, das Zurücknehmen einer einzelnen Änderung, Bisect zur Fehlersuche.

Eigenes Repository mitbringen

Ein Projekt lässt sich mit einem bestehenden GitHub-Repository verbinden. Eure Branch Protection, Pflicht-Reviews und CI-Pipelines gelten weiter — XAIO pusht in euren Prozess hinein, statt ihn zu ersetzen.

Zwei Personen, ein Repository

Git-Operationen an einem Projekt werden über die Server-Replicas hinweg mit einer gemeinsamen Sperre serialisiert. Zwei Operationen können also nicht gleichzeitig in dasselbe Repository schreiben und es halbfertig zurücklassen — der klassische Fall, den das verhindert, sind zwei Prozesse, die um den Index des Repositories konkurrieren.

Eine ehrliche Einschränkung: Die Sperre ist so gebaut, dass sie degradiert statt zu blockieren. Ist der Koordinationsdienst nicht erreichbar, läuft die Operation trotzdem — unserialisiert — und das Ereignis wird protokolliert. Das ist Absicht: Eine Sperre, die zum Single Point of Failure wird, ist schlimmer als das Rennen, das sie verhindert.

Was wir Teams empfehlen

Ein Branch beziehungsweise ein Arbeitsstrang pro Feature.
Über Pull Requests mergen, mit den Review-Regeln, die ihr schon habt.
Änderungen an AGENTS.md in denselben Pull Request wie den Code, für den sie gelten.
Pro Feature eine Person, die den Chat führt. Parallel über Features hinweg ist unproblematisch, parallel innerhalb eines Features ist teuer.

Der Agent kann die Historie lesen

Der Agent hat lesenden Zugriff auf die Versionshistorie des Projekts: das Commit-Log mit Filtern (Datei, Autor, Zeitraum, Commit-Message, Code-Suche), die Änderungen eines einzelnen Commits oder eines Bereichs, zeilengenaue Autorenschaft und die Branch-Liste mit ahead/behind gegenüber dem Basis-Branch. Das reicht, um ein Changelog zu erzeugen, eine Regression aufzuspüren oder die Frage „wer hat das geändert?" zu beantworten.

Lesend heißt lesend — kein Commit, kein Push, kein Checkout, kein Netzwerkzugriff aus diesen Werkzeugen.

Im Team ist die Code-Suche das nützlichste davon: Die Frage, welcher Commit eine bestimmte Zeile eingeführt hat, findet den Commit — und damit die Person, die man fragen kann.

Wer welche Nachricht geschrieben hat

In einem geteilten Projekt wird jede Chat-Nachricht mit der E-Mail-Adresse der absendenden Person gespeichert. Sie stammt aus der authentifizierten Sitzung, nicht vom Client, damit der Agent weiß, wer was angefordert hat. Die Adresse geht ausschließlich an den Agenten — der Chat selbst zeigt weiterhin Anzeigenamen. Verwendet wird das Git-Autorenformat, weshalb der Agent Chat-Absender mit Commit-Autoren abgleichen kann.