Hört auf, aus dem Gedächtnis über Code zu streiten

7 Min. Lesezeit

Der Code hat sich geändert. Das Argument nicht.

Software ist besonders gut darin, diese falschen Argumente hervorzubringen, weil die Sache, über die diskutiert wird, unsichtbar ist. Sie können nicht einfach durch den Raum blicken und sehen, ob die Integrationslogik jetzt besser ist als im letzten Monat. Sie müssen den Code öffnen. Die Tests ausführen. Das Verhalten nachverfolgen. Die meisten Menschen ziehen es vor, ihr Gedächtnis zu schützen, anstatt ihr Modell zu aktualisieren.

Das ist das eigentliche Problem.

Ich habe das bei Integrations-Klebe-Code gesehen, der von einem halb-technischen Entwickler mit Claude Code und einem Tool zum Schreiben von Spezifikationen erstellt wurde. Die erste Version funktionierte irgendwie, in der Art, wie ein Stuhl mit drei Beinen irgendwie funktioniert, bis man sich zu schnell hinsetzt. Dann kam jemand, entwirrte das Chaos, fügte Hunderte von Tests hinzu, entfernte die Markdown-Dateien, die die KI immer wieder in Richtung veralteter Annahmen lenkten, und machte das System wesentlich vertrauenswürdiger.

Und dennoch kreiste die Konversation weiterhin um die alte Codebasis.

Nicht um den Code im Repository. Den Code im Kopf von jemandem.

Erinnerung ist billig. Nachsehen ist Arbeit.

Menschen argumentieren normalerweise nicht aus dem Gedächtnis, weil sie böswillig sind. Sie tun es, weil das Gedächtnis schnell, sozial bequem und schmeichelhaft ist.

Sich den Gegenstand der Arbeit anzusehen, ist langsamer. Es kann offenbaren, dass Ihre Meinung veraltet ist. Es kann beweisen, dass die Person, die Sie abgetan haben, das System tatsächlich verbessert hat. Es kann Sie zwingen, einen Satz zu sagen, den viele Profis hassen: “Ich habe von einer älteren Version gesprochen.”

Das Gedächtnis lässt Sie all das vermeiden.

In der Softwareentwicklung wird dies noch schlimmer, weil das Objekt selbst weich ist. Ein Vertriebsleiter, der über eine kaputte Lieferung streitet, kann zumindest auf die fehlende Kiste zeigen. Ein Entwickler, Produktmanager, Gründer oder angrenzender Experte, der über einen Integrationsfluss streitet, zeigt normalerweise auf eine interne Simulation. Ein erinnerter Stacktrace. Ein erinnerter Fehler. Eine erinnerte architektonische Beschwerde. Ein erinnerter Eindruck von vor drei Wochen, der sich zu Gewissheit verfestigt hat.

Je unsichtbarer die Arbeit, desto einfacher ist es, sie zu mythologisieren.

Das ist ein Grund, warum die unsichtbare Natur von Software so viel Management-Theater verursacht. Menschen füllen die Lücke der Sichtbarkeit mit Narrativen. Sobald sich das Narrativ verhärtet hat, fühlt sich Beweismaterial wie ein persönlicher Angriff an.

KI hat den ersten Entwurf billig gemacht, nicht die Wahrheit automatisch

KI-Programmierwerkzeuge haben dieses Muster häufiger gemacht, nicht seltener.

Jetzt kann ein Semi-Entwickler an einem Wochenende Integrations-Klebe-Code erstellen. Schön. Das kann nützlich sein. Der erste Entwurf von Software war schon immer der einfachste Moment, um Leute zu beeindrucken, die sie nicht warten müssen.

Dann holt einen die Realität ein.

Der Arbeitsablauf, der das System tatsächlich verbessert, ist auf genau die richtige Weise langweilig: Das Verhalten charakterisieren, Tests hinzufügen, irreführende Gerüste entfernen, die Feedback-Schleife verengen und jede zukünftige Änderung durch ausführbare Prüfungen zwingen. Dort beginnt die wirkliche Arbeit. Nicht in dem Moment, in dem die KI Dateien ausspuckt. In dem Moment, in dem jemand einen Haufen plausiblen Outputs in ein System verwandelt, dem ein anderer Mensch vertrauen kann.

Deshalb schlagen Tests Anweisungen für KI-Programmier-Agenten. Ein Stapel von Markdown-Dateien, die dem Modell sagen, wie die Welt funktionieren soll, ist fragil. Ein paar hundert Tests, die zeigen, was das System tatsächlich tun muss, sind schwerer wegzudiskutieren.

Oder zumindest sollte es so sein.

In der Praxis verteidigen Menschen oft weiterhin die Markdown-Fiktion, weil diese Fiktion das ist, woran sie sich erinnern. Die gelöschten .md-Dateien bleiben für sie realer als die erfolgreich durchlaufende Testsuite. Das klingt absurd, bis man sich daran erinnert, dass Organisationen voll von Leuten sind, die Dokumentation mit Wahrheit und Pläne mit Beweisen verwechseln.

Defensive Argumente drehen sich meist um Status

Sobald jemand öffentlich erklärt hat, wie sich der Code verhält, kann sich eine spätere Korrektur demütigend anfühlen. Wenn sich das System unter ihren Füßen verändert hat, haben sie nun zwei Möglichkeiten.

Sie können den aktuellen Zustand inspizieren und ihr Modell aktualisieren.

Oder sie können weiterreden, als ob das alte Modell noch gälte, und jede Korrektur in eine Debatte verwandeln.

Viele wählen die zweite Option, weil sie kurzfristig den Status schützt.

Hier wird das Gespräch schnell dumm. Eine Person spricht über das Repository, wie es jetzt existiert. Die andere spricht über ein erinnertes Repository, eine alte Prompt-Kette, einen früheren Fehler-Modus oder ein Design, an das sie sich emotional gebunden haben. Beide denken, sie diskutieren über dasselbe Objekt. Tun sie aber nicht.

Dann beginnt der übliche Unsinn.

• “Dieses Modul ist immer noch fehleranfällig.” Nein, es war einmal fehleranfällig.
• “Die KI braucht diese Spec-Dateien.” Nein, diese Dateien haben den Output vergiftet.
• “Das Verhalten ist wahrscheinlich immer noch kaputt.” Wahrscheinlich ist das, was Leute sagen, bevor sie sich weigern, die Tests auszuführen.

Nichts davon dreht sich wirklich um Code. Es geht um Selbstschutz.

Das macht es nicht harmlos. Es verlangsamt Entscheidungen, vergiftet die Zusammenarbeit und verwandelt geradlinige Verifizierung in eine Miniatur-politische Krise.

Die bessere Frage ist immer: Was tut es jetzt?

Es gibt einen sauberen Ausweg aus dieser Falle, und er ist viel weniger glamourös als das Argumentieren.

Stellen Sie bessere Fragen.

Nicht: “War diese Integration nicht unzuverlässig?”

Fragen Sie: Was tut sie jetzt?

Nicht: “Brauchte die KI diese Anforderungsdatei nicht?”

Fragen Sie: Was hat sich nach dem Entfernen geändert?

Nicht: “Ich erinnere mich, dass dieser Fluss abgebrochen ist, als das Upstream-System ein Timeout hatte.”

Fragen Sie: Gibt es einen Test für diesen Fall, und besteht er?

Diese Verschiebung ist wichtig, weil sie die Konversation zurück in Richtung beobachtbarer Realität zwingt. Sie offenbart auch, wer zusammenarbeitet und wer ein Erinnerungsartefakt verteidigt.

Aus demselben Grund war das Konzeptdokument ein Workaround. Beschreibungen altern schlecht. Ausführbare Beweise altern viel besser. Das Gleiche gilt für Argumente in einem Code-Review, einer Architektur-Diskussion oder einer Gründer-Entwickler-Debatte. Wenn Sie die Sache inspizieren können, dann inspizieren Sie die Sache. Hören Sie auf, über eine Beschreibung der Sache zu prozessieren.

Die Codebasis verdient Zeugen, keine Historiker

Softwareteams haben die schlechte Angewohnheit, selbstbewusste Erinnerungen zu belohnen. Jemand erinnert sich an einen Ausfall vor sechs Monaten und wird plötzlich zur Autorität für ein Subsystem, das er seitdem nicht mehr angerührt hat. Jemand erinnert sich an eine Entwurfs-Prompt-Datei und behandelt sie als permanente Architektur. Jemand erinnert sich an einen Prototyp und spricht noch lange darüber, nachdem eine andere Person die harte Arbeit erledigt hat, ihn in ein tatsächliches System zu verwandeln.

So bleiben Teams in veralteten Narrativen gefangen.

Was eine Codebasis braucht, sind keine weiteren Historiker. Sie braucht Zeugen.

Ein Zeuge prüft den aktuellen Branch. Liest den fehlschlagenden Test. Reproduziert das Verhalten. Schaut in die Protokolle. Aktualisiert seine Sichtweise, wenn sich die Fakten ändern.

Ein Historiker erzählt Ihnen, was das System einmal war, und schmuggelt diese Geschichte leise in die Gegenwart.

Beide Arten von Wissen sind wichtig. Nur eine sollte ein Argument über aktuelles Verhalten gewinnen.

Wenn das hart klingt, gut so. Zu viele technische Debatten sind in Wirklichkeit nur Erinnerungswettbewerbe, die sich als Expertise verkleiden.

Der professionelle Schachzug

Der professionelle Schachzug ist nicht, härter zu argumentieren. Er besteht darin, die Angriffsfläche zu verkleinern, in der die Erinnerung vorgeben kann, die Wahrheit zu sein.

• Stellen Sie Verhalten unter Tests.
• Löschen Sie irreführende Dokumente, wenn sie nicht mehr mit der Realität übereinstimmen.
• Behandeln Sie veraltete KI-Anweisungen als Fehler, nicht als heiliges Wissen.
• Bitten Sie die Leute, auf aktuelle Beweise hinzuweisen, nicht auf erinnertes Verhalten.
• Belohnen Sie schnelle Korrekturen mehr als sture Zuversicht.

Letzteres ist wichtiger, als die meisten Führungskräfte erkennen. Wenn die Aktualisierung Ihrer Ansicht Sie schwach aussehen lässt, werden sich die Leute an alte Geschichten klammern. Wenn die Aktualisierung Ihrer Ansicht Sie kompetent aussehen lässt, wird das Team schneller schlauer.

Vibe Coding ist keine Softwareentwicklung. Das gleiche Prinzip gilt sozial. Vibe-basierte Meinungen sind kein technisches Urteilsvermögen. Wenn das Artefakt verfügbar ist, sehen Sie sich das Artefakt an.

Der Code hat sich geändert. Die Tests haben sich geändert. Das Verhalten hat sich geändert.

Die erwachsene Reaktion ist, auch Ihre Meinung zu ändern.