Öffnen Sie ein Repository sechs Monate nach dem Release eines Features, und Sie können vieles rekonstruieren. Sie können die Architektur nachvollziehen, das Schema prüfen, die Tests lesen und genau sehen, welche Zeilen geändert wurden.
Was sich meist nicht rekonstruieren lässt, ist die Unterhaltung, die diese Zeilen notwendig gemacht hat.
Der Code wird Ihnen nicht sagen, dass eine Validierungsregel existiert, weil ein Kunde fehlerhaft formatierte Exporte sendet. Er wird nicht erklären, dass eine merkwürdige Retry-Policy doppelte Transaktionen in einem nachgelagerten System verhindert. Er wird nicht zeigen, dass die sauberere Oberfläche nach einem Accessibility-Test verworfen wurde oder dass eine Service-Grenze eher eine vertragliche Einschränkung als eine technische Präferenz widerspiegelt.
Git ist hervorragend darin, Code-Historie zu bewahren. Absicht bewahrt es nur dann, wenn ein Team diese Absicht bewusst festhält und mit der Implementierung verknüpft hält.
Diese Lücke war schon immer Teil des Software Engineerings. KI-Coding-Tools machen sie sichtbarer. Ein System kann jede Datei in einem Repository lesen, jedem Symbol folgen und einen technisch überzeugenden Patch erzeugen und trotzdem das falsche Problem lösen.
Das Problem ist nicht, dass der Code irreführend ist. Der Code beantwortet eine engere Frage.
Fünf Ebenen technischer Wahrheit
Die meisten bedeutenden Softwareänderungen hängen von fünf verschiedenen Ebenen der Evidenz ab.
- Absicht — Welches Ergebnis fordern Nutzer, Kunde oder Unternehmen? Das kann in einer Spezifikation, einem Ticket, einer Support-Unterhaltung oder einer Besprechungsnotiz stehen.
- Rahmenbedingungen — Was darf nicht kaputtgehen? Kompatibilitätszusagen, Sicherheitsgrenzen, Vorschriften, Verträge, Budgets und Fristen liegen oft außerhalb des Repositorys.
- Implementierung — Wie funktioniert das System heute? Code, Tests, Schemata, Abhängigkeiten und Deployment-Konfiguration bilden diese Ebene.
- Laufzeit-Evidenz — Was passiert im realen System? Logs, Traces, Metriken, Produktionsdaten und Incident-Reports können Annahmen widersprechen, die im Code plausibel wirken.
- Entscheidungshistorie — Warum wurde der aktuelle Ansatz gewählt? Pull Requests, Design-Diskussionen, verworfene Alternativen und frühere Incidents liefern die Antwort.
Im Repository ist die dritte Ebene am stärksten vertreten. Es enthält Teile der anderen, aber selten genug, um sie vollständig abzubilden.
Das ist wichtig, weil Softwarefehler oft an den Grenzen zwischen diesen Ebenen auftreten. Die Implementierung entspricht einer veralteten Spezifikation. Der Fix erfüllt das Ticket, verletzt aber eine operative Einschränkung. Die Tests bestehen, weil sie die Annahmen von gestern kodieren. Der Code ist in sich konsistent, während die Produktionsdaten einem Muster folgen, das niemand dokumentiert hat.
Ein lokal korrekter Patch kann trotzdem die falsche Änderung sein.
Was das Repository allein nicht beantworten kann
Stellen Sie sich einen Nutzer vor, der ein Dokument bearbeitet und anschließend nach dem aktualisierten Satz sucht, in den Ergebnissen aber nur die alte Version sieht. „Die Suche soll sofort aktualisiert werden“ klingt nach einer klaren Anforderung. Das Repository zeigt mehrere mögliche Ansatzpunkte, kann die richtige Lösung aber nicht aus eigener Kraft bestimmen.
| Frage | Wahrscheinliche Quelle |
|---|---|
| Welche Version des Dokuments ist maßgeblich? | Quelldokument und Revisionsverlauf |
| Wo bleibt der alte Text erhalten? | Synchronisierungsprotokolle, Extraktionsausgabe, Suchindex oder Cache |
| Was bedeutet „sofort“ für dieses Produkt? | Produktversprechen oder Serviceziel |
| Haben sich die Berechtigungen des Dokuments zusammen mit seinem Inhalt geändert? | Quellberechtigungen und Audit-Verlauf |
| Ist das veraltete Ergebnis auf einen Nutzer, eine Quelle oder eine Region beschränkt? | Request-Traces und Produktionsmetriken |
Der Suchcode kann erklären, wie Ergebnisse zurückgegeben werden. Er kann Ihnen nicht sagen, ob der eigentliche Fehler in einer Synchronisierungsverzögerung, veralteter Extraktion, Cache-Invalidierung, der Weitergabe von Berechtigungen oder in einer Erwartung liegt, die das Produkt nie definiert hat.
Diese Unterscheidung wird in ausgereiften Systemen noch wichtiger. Ein Feld, das veraltet aussieht, kann weiterhin einen Legacy-Client unterstützen. Ein Dienst, der wie ein Duplikat wirkt, kann Daten mit unterschiedlichen Berechtigungsanforderungen trennen. Eine scheinbar überflüssige Prüfung kann die einzige Spur im Code zu einem Produktionsvorfall sein, den das aktuelle Team nie erlebt hat.
Komplexität zu entfernen ist wertvoll. Geschichte zu entfernen, die nur wie Komplexität aussieht, ist teuer.
Mehr Kontext kann trotzdem zur falschen Antwort führen
Die naheliegende Lösung ist, der KI mehr Material zu geben: das gesamte Repository, jedes Ticket, jedes Dokument, jede Nachricht und jedes Log.
Das schafft Zugriff, nicht Verständnis.
Quellen können veraltet, widersprüchlich, spekulativ oder für unterschiedliche Zielgruppen geschrieben sein. Ein Brainstorming sollte nicht höher gewichtet werden als eine freigegebene Spezifikation. Eine sechs Monate alte Anforderung sollte nicht stillschweigend die Produktentscheidung von gestern außer Kraft setzen. Ein Produktionslog sollte mit dem Release, der Umgebung und dem Codepfad verknüpft sein, die es hervorgebracht haben. Eine Kundenanfrage sollte nicht als allgemeingültige Anforderung behandelt werden, ohne den Geltungsbereich zu prüfen.
Ein ernstzunehmendes Kontextsystem braucht daher mehr als Retrieval. Es braucht eine Möglichkeit, über Folgendes nachzudenken:
- Autorität: Welche Quelle darf die Anforderung festlegen?
- Aktualität: Welche Information ist aktuell, und was wurde ersetzt?
- Herkunft: Woher stammt jede Behauptung, Einschränkung oder Schlussfolgerung?
- Beziehungen: Welche Issue, welches Release, welcher Kunde, welcher Datensatz und welcher Codepfad gehören zusammen?
- Berechtigungen: Welche Quellen dürfen für diese Aufgabe verwendet und dieser Person gezeigt werden?
Kontext ist kein Haufen von Tokens. Er ist ein Graph mit Zeit, Autorität und Grenzen.
Mehr Kontext sollte mehr Belege liefern, nicht mehr Zuversicht ohne Belege.
Die eigentliche Arbeitseinheit ist die Änderung
Editoren und Coding-Tools sind um Dateien herum organisiert, weil Dateien das sind, was wir verändern. Engineering-Teams sind um Änderungen herum organisiert.
Eine Änderung beginnt mit einem Grund. Sie wird zu einer Anforderung, berührt Code und Daten, durchläuft ein Review, gelangt in die Produktion und erzeugt neue Belege. Wenn diese Phasen voneinander getrennt bleiben, beginnt jede künftige Aufgabe mit einer weiteren Runde Archäologie.
Ein KI-System, das an echter Software arbeitet, sollte diesem Lebenszyklus folgen.
Vor der Implementierung sollte es die Anfrage, die relevanten Einschränkungen und alle widersprüchlichen Quellen identifizieren. Es sollte wissen, ob es einen Fehler behebt, erwartetes Verhalten ändert oder einen neuen Vertrag einführt.
Während der Implementierung sollte es jede wesentliche Entscheidung mit Belegen verknüpfen. Warum dieses Modul? Warum diese Migrationsstrategie? Warum diesen Branch beibehalten? Die Erklärung sollte über den Chat hinaus Bestand haben, in dem der Code entstanden ist.
Nach der Implementierung sollte es Verifikationsergebnisse, Review-Entscheidungen und neu entdeckte Einschränkungen an die Änderung anhängen. Andernfalls muss die nächste Person – oder die nächste AI-Sitzung – sie erneut erschließen.
Das ist der Unterschied zwischen einem Tool, das ein Repository bearbeiten kann, und einem System, das an technischer Entwicklungsarbeit teilnehmen kann.
AI sollte Rekonstruktionsaufwand verringern, nicht Urteilsvermögen ersetzen
Besserer Kontext wird manchmal als Weg zur autonomen Softwareentwicklung dargestellt. Der unmittelbare Nutzen ist weniger spektakulär und hilfreicher: die Kosten zu senken, die Realität vor einer Änderung erst rekonstruieren zu müssen.
AI kann die ursprüngliche Anforderung direkt neben den relevanten Code stellen. Sie kann den Vorfall sichtbar machen, der eine ungewöhnliche Schutzmaßnahme erklärt. Sie kann eine fehlschlagende Metrik mit dem Release verknüpfen, das sie verändert hat. Sie kann zeigen, dass zwei maßgebliche Quellen einander widersprechen, bevor die Implementierung beginnt.
Diese Fähigkeiten beseitigen technisches Urteilsvermögen nicht. Sie sorgen dafür, dass es besser informiert ist.
Eine Person muss weiterhin entscheiden, welcher Trade-off akzeptabel ist, ob eine Anforderung vollständig ist und wie viel Risiko ein Release tragen kann. Das System sollte die Evidenz sichtbar und die Begründung nachvollziehbar machen. Es sollte Unsicherheit nicht hinter einem glatt wirkenden Patch verbergen.
Der Maßstab ist nicht: „Kann es Code generieren?“
Der Maßstab ist: „Kann es erklären, warum dies jetzt die richtige Änderung ist?“
Von repository-bewusst zu arbeitsbewusst
Coding-Assistenten wurden zuerst nützlich, indem sie die Datei verstanden, die vor der Entwicklerin oder dem Entwickler lag. Repository-Bewusstsein war der nächste große Schritt: verwandten Code finden, Symbolen folgen und Änderungen projektweit anwenden.
Der nächste Schritt ist ein Bewusstsein für die Arbeit rund um das Repository.
Das bedeutet, Code mit der Spezifikation zu verknüpfen, die ihn angefordert hat, mit der Unterhaltung, die ihn präzisiert hat, mit den Produktionsdaten, die ihn infrage gestellt haben, und mit der Entscheidung, an die man sich später erinnern sollte. Es bedeutet auch, Kontext auszuschließen, der irrelevant, veraltet oder außerhalb der Berechtigungen der Nutzerin oder des Nutzers liegt.
Während wir Dvina entwickeln, ist das eine der Ideen, zu denen wir immer wieder zurückkehren. Arbeit findet nicht innerhalb einer einzelnen Datei, Anwendung oder Unterhaltung statt. Bedeutung lebt in den Verbindungen zwischen ihnen und darin, wie sich diese Verbindungen im Laufe der Zeit verändern.
Das Repository bleibt essenziell. Es ist die ausführbare Quelle der Wahrheit für das Verhalten des Systems. Es ist nur nicht die vollständige Quelle der Wahrheit für Produktabsicht, operative Realität oder organisatorisches Gedächtnis.
Die ganze Geschichte verändert, was gebaut wird
Mit nur dem Code lautet die naheliegende Frage:
Welche Änderung passt zu diesem System?
Mit dem breiteren Kontext wird daraus die Frage:
Welche Änderung passt zu diesem System, zu dieser Anforderung, zu dieser Vorgeschichte und zu diesem Moment?
Diese zweite Frage macht Einschränkungen sichtbar, bevor sie zu Regressionen werden. Sie liefert Reviewer:innen die Begründung für die Implementierung. Sie hilft neuen Teammitgliedern zu verstehen, warum das System so aussieht, wie es aussieht. Sie gibt KI eine fundierte Rolle: nicht als Orakel im Editor, sondern als Mitwirkende, die über die gesamte Arbeit hinweg Belege zusammentragen kann.
Ihr Repo war nie die ganze Geschichte.
Die Chance besteht darin, Systeme zu bauen, die auch den Rest davon lesen können – und ihre Arbeit offenlegen.
