Der Aufstieg des Programmierens und das Ende der architektonischen Absicht

Als Staff Engineers und Principal Architects haben die meisten von uns Jahre damit verbracht, über die langfristige Systemstabilität nachzudenken. Wir berücksichtigen die Geschäftsziele und die Strategie des Unternehmens, die Anhäufung von technischer Schuld und das Betriebsrisiko. Für uns geht es nicht darum, ob das Programm heute funktioniert, sondern ob der Entwickler, der es in drei Jahren übernimmt, verstehen kann, was damit beabsichtigt war und warum. Das ist es, was eine Codebasis wartbar macht – und nicht nur funktionsfähig.

KI-Codierungsassistenten untergraben das. Ein Großteil der aktuellen Diskussion konzentriert sich auf Geschwindigkeit und darauf, Entwicklern zu ermöglichen, mit weniger Zeitaufwand mehr zu erreichen. Doch während immer mehr Tools ins Spiel kommen, verlieren wir das Verständnis für die Absicht des Entwicklers. Wir werden zwar technisch schneller, erzeugen aber eine neue Art von technischer Schuld – die nur nicht wie technische Schuld aussieht. Sie sieht aus wie sauberer, gut strukturierter, funktionierender Code, hinter dem jedoch kein menschliches Denken steckt.

Die Anatomie von „Dark Code“

Kernaussage: Die automatisierte Codegenerierung verschleiert den Verlust der Entwicklerabsicht. Saubere Repositorien häufen Altlasten doppelt so schnell an wie früher.

Der lokale KI-Entwicklungszyklus wirkt oberflächlich betrachtet produktiv. Ein Entwickler öffnet seinen Editor, markiert einen Code-Block und gibt dem Modell die Anweisung: „Refactoriere diesen Authentifizierungs-Handler, damit er den Token-Austausch bei Multi-Tenant-Umgebungen unterstützt.“ Das Modell liefert einen 200-Zeilen-Diff zurück. Der Entwickler überfliegt ihn, führt einen lokalen Test durch, committet mit einer Nachricht wie „Auth für Multi-Tenant refactoriere“ und pusht in den Branch.

Auf dem Papier ist die Aufgabe erledigt. In der Praxis hat das Repository jedoch gerade eine Altlast geerbt.

Die Versionskontrolle hat das „Was“ erfasst: den rohen Diff der neu generierten Zeilen. Über das „Warum“ hat sie nichts festgehalten. Die Eingabeaufforderung, der Kontext, auf dessen Grundlage das Modell arbeitete, die Logikpfade, die es ausgewertet und verworfen hat, die strukturellen Annahmen, die in der Ausgabe enthalten waren – all das ist verschwunden, als die Editor-Sitzung geschlossen wurde.

Stell dir denselben Authentifizierungs-Handler vor, der sechs Monate später um 2 Uhr morgens aufgrund einer Token-Konfiguration in einem Randfall ausfällt, mit der niemand gerechnet hat. Ein leitender Entwickler führt „git blame“ aus. Er findet keine Entwurfsentscheidung. Stattdessen findet er ein Artefakt, das auf die Wahl eines bestimmten Agenten zurückzuführen ist. Es gibt keine Commit-Meldung, die die Überlegungen erklärt, keinen PR-Kommentar, der die Abwägungen festhält, keine Möglichkeit, nachzuvollziehen, worauf das Modell abzielte, als es diese bestimmte Struktur wählte. Der Kontext ist verloren, weil er nie irgendwo festgehalten wurde, der über die Sitzung hinaus Bestand hatte, in der er entstanden ist.

Wir haben schon immer technische Schulden angehäuft. Aber jetzt häufen wir sie schneller an – und in einer Form, die schwerer abzubauen ist, weil der Kontext fehlt.

Der Zusammenbruch der Git-Urheberschaft

Kernaussage: Wenn ein Entwickler einen Diff überprüft und zusammenführt, dessen Entstehungsgeschichte er nicht nachvollziehen kann, wird er für Entscheidungen verantwortlich gemacht, die er gar nicht getroffen hat.

Git basierte auf einer grundlegenden Annahme: Der Name bei einem Commit steht für den Kopf, der die Änderung geplant hat. Diese Verbindung ist still und leise zusammengebrochen.

Entwickler, die lokale KI-Tools nutzen, sind von Autoren zu Redakteuren maschinengenerierter Texte geworden. Dieser Wandel hat Konsequenzen, die nicht gleichmäßig verteilt sind. Der Entwickler, der das Modell angesteuert hat, macht weiter. Der reviewer ist derjenige, der mit dem Diff zurückbleibt.

Ein Staff Engineer, der einen komplexen Pull-Request mit mehreren Dateien überprüft, wird nun aufgefordert, architektonische Entscheidungen abzusegnen (z. B. ein bestimmtes Datenbank-Sperrmuster, einen bestimmten Ansatz für verschachtelte asynchrone Aufrufe), ohne zu wissen, ob diese Entscheidungen bewusst getroffen wurden oder ob es sich um die beste Vermutung des Modells handelt – basierend auf einem Kontextfenster, das der reviewer noch nie gesehen hat. Das Modell steht für Fragen nicht zur Verfügung. Der Entwickler, der die Eingabeaufforderung ausgeführt hat, versteht möglicherweise selbst nicht ganz, warum die Ausgabe so aussieht, wie sie aussieht.

Daraus ergeben sich zwei Dinge. Das erste ist ein Problem mit der Überprüfungsqualität: Unter dem Druck des Backlogs lautet die ehrliche Antwort auf die Frage „Verstehst du, warum dieses Programm so strukturiert ist?“ zunehmend „Nein“, aber die Zusammenführung findet trotzdem statt. Das zweite ist ein Problem der Verantwortlichkeit, mit dem sich die meisten Teams noch nicht vollständig auseinandergesetzt haben: Die Person, die auf „Zusammenführen“ klickt, ist operativ verantwortlich für die Folgen von Programmcode, den sie nicht entworfen hat und nicht vollständig nachvollziehen kann.

Was Rückverfolgbarkeit tatsächlich erfordert

Kernaussage: Die Lösung besteht nicht darin, den Einsatz von KI einzuschränken. Es geht darum, den Kontext zu erfassen, den die KI-Ausführung derzeit außer Acht lässt.

Die Versuchung ist groß, dies als ein Tooling-Problem zu behandeln, das sich mit Tooling-Maßnahmen beheben lässt: bessere Disziplin bei Commit-Meldungen, obligatorische PR-Vorlagen, KI-Code-Review-Ebenen. Diese Dinge helfen am Rande. Sie lösen das zugrunde liegende Problem nicht.

Das zugrunde liegende Problem ist, dass die KI-Schlussfolgerungen an einer Stelle stattfinden, die keine dauerhafte Aufzeichnung hinterlässt. Ein Modell, das im lokalen Editor eines Entwicklers läuft, verarbeitet den Kontext, trifft Entscheidungen und generiert eine Ausgabe – und dann ist der Kontext weg. Was in die Versionskontrolle eingecheckt wird, ist die Ausgabe. Alles, was dazu geführt hat, ist weg.

Die Teams, die beginnen, sich ernsthaft damit auseinanderzusetzen, überdenken, an welcher Stelle im Prozess die KI zum Einsatz kommt – nicht nur, wie sie funktioniert. Wenn der Kontext, aus dem ein Agent arbeitet, die Entscheidungen, die er trifft, und die menschliche Überprüfung dieser Entscheidungen alle als Teil derselben Aufzeichnung wie die Codeänderung selbst erfasst werden, hast du etwas, das du tatsächlich überprüfen kannst. Sechs Monate später, wenn etwas nicht mehr funktioniert, ist die Argumentationskette immer noch vorhanden.

Das ist eine andere Art von Infrastrukturanforderung, als die meisten Teams es gewohnt sind. Aber es ist der richtige Ansatz für das Problem. Wir haben kein Problem mit der Codequalität. Wir haben ein Problem mit der Erhaltung des Kontexts. Und es zu lösen bedeutet, die Argumentation hinter einer Codeänderung als Teil des technischen Artefakts zu behandeln – nicht als Nebenprodukt, das nach Ende der Sitzung verworfen wird.

Genau dieses Problem wollen wir mit Upsun Dispatch™ lösen: die gesamte Kette aus Kontext, Begründung und menschlicher Freigabe als Teil der technischen Dokumentation selbst zu erfassen – und nicht als etwas, das nachträglich nachgebildet wird.

• Neu hier? Lies die Einführung zu Upsun Dispatch
• Möchtest du bei der Entwicklung mithelfen? Bewirb dich für die Gründungsgruppe der Design-Partner

Häufig gestellte Fragen (FAQ)

Was genau ist „Dark Code“?

Das ist ein Programm, das kompiliert wird, die Überprüfung besteht und in die Produktivumgebung gelangt, ohne dass es eine nachvollziehbare Dokumentation darüber gibt, warum es so geschrieben wurde, wie es ist. Die architektonischen Entscheidungen sind für alle unsichtbar – außer für das Modell, das sie getroffen hat, und dieses Modell ist vielleicht schon längst verschwunden.

Warum reicht eine gute Commit-Meldung nicht aus, um „Dark Code“ zu vermeiden?

Eine Commit-Meldung gibt wieder, was ein Mensch als Zusammenfassung gewählt hat. Sie erfasst weder die Eingabeaufforderungen noch den Kontext oder die Argumentationskette, die eine KI zu bestimmten strukturellen Entscheidungen geführt hat. Ein Entwickler, der „Authentifizierung für Multi-Tenant refaktorisieren“ schreibt, fasst seine Interpretation des Ergebnisses zusammen, dokumentiert aber nicht den Prozess, der dazu geführt hat. Das sind zwei ganz unterschiedliche Dinge.

Verlangsamt Rückverfolgbarkeit die Entwickler nicht?

Nur, wenn man sie schlecht umsetzt. Das Ziel ist nicht, dass Entwickler jede KI-Interaktion manuell dokumentieren müssen. Es geht darum, diesen Kontext automatisch zu erfassen – genau dort, wo die KI tatsächlich arbeitet –, ohne den Arbeitsablauf des Entwicklers zu behindern.

Inwiefern hängt „Dark Code“ mit Compliance zusammen?

Standards wie ISO 27001 verlangen, dass man nachweisen kann, warum eine Änderung vorgenommen wurde, wer sie genehmigt hat und wie sie überprüft wurde. Code, der lokal von einem KI-Assistenten programmiert wird, ohne dass es eine gemeinsame Aufzeichnung des Kontexts oder der Genehmigung gibt, lässt sich bei einem Audit nur sehr schwer nachweisen. Das ist ein Risiko, das die meisten Teams noch nicht vollständig erfasst haben.