Denkfehler sind Features, keine Bugs

Warum Erfahrung nicht vor kognitiven Verzerrungen schützt – und welche Sicherungen mir bei technischen und beruflichen Entscheidungen helfen.

Wenn Entwickler über Fehler sprechen, meinen sie meistens Fehler im Code, in der Architektur oder in einem Prozess. Für solche Fehler gibt es Tests, Logs, Reviews und reproduzierbare Beispiele.

Schwieriger sind die Fehler, die bereits entstehen, bevor ich eine Zeile Code schreibe: in meiner Wahrnehmung des Problems, in meinen Annahmen über die Ursache, in der Auswahl der Optionen und in der Einschätzung meiner eigenen Fähigkeiten.

Auch nach mehr als drei Jahrzehnten als Entwickler bin ich nicht frei davon. Erfahrung hilft mir, bestimmte Muster früher zu erkennen. Sie kann mich aber auch gefährlich sicher machen.

Das Ziel kann deshalb nicht sein, meine Denkfehler irgendwann vollständig loszuwerden. Das Ziel ist, Arbeitsweisen zu entwickeln, die ihre Folgen begrenzen.

Erfahrung schützt nicht vor Verzerrungen

Kognitive Verzerrungen werden oft so dargestellt, als seien sie kleine Defekte eines ansonsten rationalen Verstands. Man lernt Begriffe wie Bestätigungsfehler, Ankereffekt oder Sunk-Cost-Falle und hofft, dadurch etwas weniger irrational zu werden.

So einfach funktioniert es nicht.

Ich kann den Bestätigungsfehler erklären und trotzdem bei der Fehlersuche vor allem nach Hinweisen suchen, die meine erste Vermutung stützen. Ich kann die Sunk-Cost-Falle kennen und trotzdem an einer technischen Lösung festhalten, weil ich bereits drei Wochen in sie investiert habe. Ich kann seit Jahrzehnten Projekte planen und trotzdem unterschätzen, wie viel Zeit Integration, Tests und die letzten zwanzig Prozent kosten werden.

Das Wissen um eine Verzerrung hebt sie nicht auf. Manchmal liefert es mir nur ein anspruchsvolleres Vokabular, mit dem ich meine ursprüngliche Entscheidung nachträglich verteidigen kann.

Der Bestätigungsfehler beim Debugging

Der Ankereffekt bei Aufwandsschätzungen

Die Planungsillusion gehört zum Beruf

Die Sunk-Cost-Falle bei Architektur und eigenen Projekten

Der Status-quo-Bias in Legacy-Systemen

Verfügbarkeitsheuristik: Der letzte Unfall bestimmt die Architektur

Selbstüberschätzung und das Recht des Seniors

Der Not-invented-here-Effekt

Gruppendenken und höfliche Zustimmung

KI beseitigt meine Verzerrungen nicht

Coding Agents können alternative Lösungen vorschlagen, Gegenargumente formulieren und Code analysieren. Das kann helfen, meine eigene Perspektive zu erweitern. Aber auch ein Agent arbeitet mit dem Kontext, den ich ihm gebe.

Wenn ich meine falsche Annahme bereits in den Prompt einbaue, kann mir das System eine äußerst überzeugende Ausarbeitung genau dieser Annahme liefern. Wenn ich nach Argumenten für meine bevorzugte Architektur frage, werde ich Argumente dafür erhalten. Wenn ich ein Problem voreilig definiere, optimiert der Agent womöglich sehr effizient die falsche Lösung.

KI kann deshalb sowohl Korrektiv als auch Verstärker meiner Verzerrungen sein. Nützlich wird sie besonders dann, wenn ich sie ausdrücklich gegen meine erste Einschätzung arbeiten lasse:

Welche Annahmen übersehe ich?
Welche Alternativen gibt es?
Was spricht gegen diesen Ansatz?
Unter welchen Umständen würde diese Lösung scheitern?
Welche einfachere Erklärung passt ebenfalls zu den Beobachtungen?
Welche Teile meines Plans sind vermutlich zu optimistisch?

Auch dann liefert das System keine objektive Wahrheit. Aber es kann Reibung erzeugen – und Reibung ist oft genau das, was eine zu schnelle Gewissheit braucht.

Bei anderen erkenne ich Verzerrungen leichter

Bei Kollegen sehe ich selektive Wahrnehmung, Selbstüberschätzung und emotionales Festhalten meist erstaunlich deutlich. Bei mir selbst fühlen sich dieselben Prozesse anders an:

wie technische Erfahrung,
wie Intuition,
wie Pragmatismus,
wie Qualitätsanspruch,
wie Verantwortungsbewusstsein,
oder einfach wie gesunder Menschenverstand.

Das ist der Bias Blind Spot: die Neigung, Verzerrungen bei anderen zu erkennen und sich selbst für vergleichsweise objektiv zu halten.

Deshalb reicht Selbstbeobachtung allein nicht. Ich brauche Rückmeldungen, Reviews, Tests, Messwerte und Menschen, die mir widersprechen dürfen. Nicht weil andere automatisch recht haben. Sondern weil mein eigener Blickwinkel unvermeidlich begrenzt ist.

Gute Arbeit braucht Sicherungen

Ich werde meine Denkfehler nicht los. Deshalb versuche ich nicht, mich auf meine Rationalität zu verlassen, sondern kleine Sicherungen in meine Arbeit einzubauen:

Hypothesen aufschreiben, bevor ich mit der Fehlersuche beginne.
Aktiv nach widerlegenden Hinweisen suchen.
Aufwandsschätzungen mit ihren Annahmen dokumentieren.
Große Entscheidungen nach etwas Abstand noch einmal prüfen.
Vor einem weiteren Investment fragen, ob ich heute neu beginnen würde.
Bei Architekturentscheidungen Alternativen ausdrücklich benennen.
Messwerte von eindrücklichen Einzelfällen unterscheiden.
Unsicherheit sichtbar machen, statt sie mit Seniorität zu überdecken.
Andere bitten, gezielt nach Schwächen in meiner Lösung zu suchen.
KI nicht nur zur Bestätigung, sondern als Gegenposition einsetzen.

Keine dieser Methoden macht mich objektiv. Sie verringern nur die Wahrscheinlichkeit, dass eine unbemerkte Verzerrung allein das Steuer übernimmt.

Das Ziel ist nicht perfekte Rationalität

Softwareentwicklung findet unter Zeitdruck, mit unvollständigen Informationen, historischen Altlasten, sozialen Abhängigkeiten und begrenzter Aufmerksamkeit statt. Perfekte Rationalität wäre selbst unter idealen Bedingungen unrealistisch.

Professionelles Arbeiten bedeutet für mich deshalb nicht, immer richtigzuliegen. Es bedeutet, damit zu rechnen, dass ich mich täuschen kann. Es bedeutet, Entscheidungen so zu treffen, dass Fehler möglichst früh sichtbar und möglichst günstig korrigierbar werden. Und es bedeutet, eine einmal gefasste Überzeugung nicht mit der eigenen Identität zu verwechseln.

Ich werde meine Denkfehler als Entwickler nie los. Aber ich kann lernen, ihnen weniger unkontrolliert meine Projekte, meine Entscheidungen und mein Berufsleben zu überlassen.