Kritisches Denken im Zeitalter der AI

• Auch in einer Umgebung, in der AI Code, Entwürfe und Antworten erzeugt, ist kritisches Denken – also die Fähigkeit, die richtigen Fragen zu stellen und Annahmen zu hinterfragen – eine Schlüsselkompetenz, die über die Leistung von Engineers und Teams entscheidet
• Im gesamten Problemlösungsprozess sollten die sechs Fragen Who·What·Where·When·Why·How genutzt werden, um Menschen, Problem, Kontext, Timing, Ursachen und Vorgehensweise systematisch zu überprüfen
• Antworten von AI sollten wie ein von einem Praktikanten vorgeschlagener Entwurf als zu validierende Grundlage behandelt werden; die Verantwortung für tatsächliche Problemdefinition, Sammlung von Belegen, Kontextverständnis, Ursachenanalyse und Kommunikation muss beim Menschen liegen
• Durch Zeitdruck, Biases und plausibel klingende AI-Antworten entsteht leicht die Tendenz zu vorschnellen Schlussfolgerungen und Flickwerk-Lösungen; um das zu verhindern, muss evidenzbasiertes Denken mit 5 Whys, Experimenten und Datenvalidierung immer wieder praktiziert werden
• Kritisches Denken wird durch eine Teamkultur aus bescheidener Neugier und Wertschätzung von Evidenz gestärkt, und selbst wenn AI sich noch so stark weiterentwickelt, bleibt „das richtige Problem aus den richtigen Gründen auf die richtige Weise zu lösen“ ein genuin menschlicher Vorteil

---

Überblick über kritisches Denken im Zeitalter der AI

• In einer Zeit, in der AI Code, Design und Antworten erzeugt, wird die menschliche Fähigkeit zum kritischen Denken wichtiger denn je
  • Ganz gleich, wie ausgefeilt Automatisierung wird: die Aufgabe, die richtigen Fragen zu stellen, Annahmen zu hinterfragen und unabhängig zu denken, bleibt beim Menschen
  • AI-Output, der auf falschen Fragen und falsch definierten Problemen aufbaut, kann Projekte nur schneller in die falsche Richtung treiben
• Zur Förderung kritischen Denkens wird das Framework Who·What·Where·When·Why·How als konkrete Handlungsanleitung vorgeschlagen
  • Jede dieser Fragen dient als Werkzeug, um Problemdefinition, Stakeholder, Kontext, Timing, Ursachenanalyse sowie Umsetzung und Kommunikation zu prüfen
  • In einer AI-unterstützten Umgebung ist es entscheidend, diese sechs Punkte nicht zu übersehen, um Projektfehler zu reduzieren und nachgelagerte Probleme zu vermeiden

tl;dr: Checkliste für kritisches Denken in AI-Teams

• Who: AI sollte nicht als allwissende Instanz, sondern als zu prüfender Input betrachtet werden, und es muss immer klar sein, wer die Antwort liefert
  • Antworten von LLMs dürfen nicht mit der Meinung eines Menschen gleichgesetzt werden; es braucht eine Perspektive, die Quelle und Verantwortlichkeit getrennt betrachtet
• What: Bevor man auf eine Lösung zusteuert, müssen die eigentliche Problemdefinition und die Erfolgskriterien klar festgelegt werden
  • Statt sich nur an oberflächlichen Anforderungen zu orientieren, sollte das tatsächlich zu lösende Problem auf Basis von User Experience und Daten präzise definiert werden
• Where: Der Kontext und die Umgebung, in der die Lösung eingesetzt wird (Sandbox, Produktion, Endgeräte der Nutzer usw.), müssen berücksichtigt werden
  • Eine Lösung, die in einer Umgebung gut funktioniert, kann in einer anderen unerwünschte Nebenwirkungen haben
• When: Es muss unterschieden werden zwischen Situationen, in denen einfache Heuristiken ausreichen, und solchen, die eine tiefgehende Analyse erfordern
  • Der Zeitpunkt für Notfall-Fixes und für Root-Cause-Analyse sollte getrennt werden, damit auch unter Zeitdruck ein Mindestmaß an Sorgfalt gewahrt bleibt
• Why / How: Mit den 5 Whys sollten Root Causes verfolgt werden, und Kommunikation sollte sich auf Daten und Evidenz statt auf Meinungen stützen
  • Erforderlich ist eine Haltung, die Belege über Behauptungen und Experimente bzw. Messergebnisse über Intuition stellt

Who: Beteiligte, Verantwortung und Wirkungskreis

• Der Ausgangspunkt kritischen Denkens ist die Zusammensetzung der Menschen und Perspektiven, die ein Problem definieren und an seiner Lösung mitwirken (wer einbezogen ist und wer fehlt)
  • Stakeholder wie Engineers, PMs, Nutzer und Domänenexperten müssen identifiziert und angemessen in den Entscheidungsprozess einbezogen werden
  • Da Probleme meist mehrere Teams und Nutzer betreffen, ist es wichtig, zuerst zu fragen: „Mit wem müssen wir sprechen, wen müssen wir informieren?“
• Um das Risiko von groupthink zu verringern, bei dem sich nur eine einzige Sichtweise durchsetzt, sollten unterschiedliche Perspektiven bewusst einbezogen werden
  • Wenn Gegenstimmen oder alternative Perspektiven ausgeschlossen werden, steigt das Risiko, dass sich etwas ohne Prüfung von Daten und Annahmen als vermeintlich richtige Antwort verfestigt
  • Auch externe Perspektiven oder Personen außerhalb des Teams als „frische Augen“ einzubeziehen, kann die Objektivität erhöhen
• Seit dem Aufkommen von AI ist die Unterscheidung „Wessen Antwort ist das – die eines Menschen oder einer AI?“ unverzichtbar
  • LLMs sind lediglich statistische Engines; daher sollte weniger gelten, „wer hat es gesagt“, sondern vielmehr „auf welcher Grundlage wurde es gesagt“
  • AI-generierter Code sollte wie Code eines Praktikanten behandelt werden: Review, Tests und Prüfung der Kontexttauglichkeit müssen Menschen verantworten
• Letztlich muss auch Verantwortung und Wirkungskreis (wer trägt Verantwortung und wer ist betroffen) mitgedacht werden
  • Ein hastiger Patch erfüllt vielleicht kurzfristig die Forderung des Managements, doch die spätere Last für Wartung und Incident Response kann bei anderen Engineers oder Nutzern landen
  • Wie bei den Auswirkungen einer API-Änderung auf Mobile Apps oder andere Microservices sollte immer mitbedacht werden: „Wer muss die Folgen dieser Entscheidung tragen?“

What: Das eigentliche Problem definieren und Evidenz sammeln

• Der Kern kritischen Denkens besteht darin, präzise zu definieren, was das tatsächliche Problem ist
  • Wenn etwa die Anforderung lautet „Lasst uns eine AI-Zusammenfassungsfunktion einbauen“, sollte zuerst geklärt werden, ob das Ziel besseres Datenverständnis, geringere Ermüdung oder etwas anderes ist
  • Je nachdem, ob die Schwierigkeit der Nutzer in Datenüberlastung, unzureichender Visualisierung oder fehlender Erklärung liegt, kann die Lösung völlig unterschiedlich ausfallen
• Wie unter anderem in der Harvard Business Review betont wird, verringert ausreichend Zeit für die Problemdefinition das Risiko, Ressourcen auf das falsche Problem zu verwenden
  • Anforderungen und Erfolgskriterien sollten explizit festgehalten werden, und es braucht eine Einigung darüber, „ab welchem Zustand das Problem als gelöst gilt“
  • Der plunging-in bias – also die Tendenz, sofort in den „Problemlösungsmodus“ zu springen – muss bewusst vermieden werden
• Wichtig ist eine evidenzbasierte Problemdefinition, die konkrete Fakten statt bloßer Symptome sammelt
  • Die Aussage „Der Service ist langsam“ ist zu vage; Daten müssen eingrenzen, welche Seite, welche Query oder welche Requests langsam sind
  • Fragen wie „Was ist langsam?“, „Was hat sich seit wann verändert?“ und „Was wurde kürzlich geändert?“ sollten durch Logs, Metriken usw. überprüft werden
• Für Lösungen oder Schlussfolgerungen sollte immer wieder gefragt werden: „Welche Evidenz stützt diese Schlussfolgerung?“
  • Wenn AI einen Null Pointer als Ursache benennt, muss dies direkt über Logs, Tests und Reproduktionsversuche validiert werden
  • Wenn eine Leistungsverbesserung behauptet wird, muss geprüft werden, ob sich die Metriken in mehreren Umgebungen und über mehrere Durchläufe hinweg konsistent verbessern
• Antworten von LLMs sollten meist als Hypothesen ohne Garantie auf Korrektheit behandelt werden, die nur plausibel wirken
  • Menschen neigen dazu, die weitere Suche zu beenden, sobald eine Antwort „plausibel genug“ erscheint; gerade diese Kombination ist besonders gefährlich
  • Kritisches Denken beginnt mit der Annahme, dass sowohl Ideen von AI als auch von Kollegen oder von einem selbst Hypothesen sind, die getestet werden müssen und falsch sein könnten

Where: Bewusstsein für Kontext, Umgebung und Reichweite

• Es ist wichtig zu verstehen, wo ein zu lösendes Problem auftritt und wo eine Lösung angewendet wird (Kontext)
  • Um zu verhindern, dass ein CPU-Spike in einem bestimmten Microservice fälschlich als Ausfall des Gesamtsystems interpretiert wird, muss der genaue Ort des Problems identifiziert werden
  • Je nach Ausführungsumgebung – Smartphone der Nutzer, Edge Device oder Cloud-Server – unterliegt derselbe Code völlig unterschiedlichen Randbedingungen
• Beim Debugging sollte entlang von Request-Flows und den Grenzen zwischen Komponenten eingegrenzt werden, wo der Fehler auftritt
  • Mit Logs und Monitoring muss getrennt werden, ob das Problem beim Client, API Gateway, Backend oder in der Datenbank entsteht
  • Auch bei der Diskussion von Feature-Ideen sollte betrachtet werden, welche Phase der User Journey betroffen ist und in welchem Abschnitt sich die Nutzungshäufigkeit konzentriert
• Auch bei Experimenten und Deployments ist die Frage, wo getestet werden soll, ein entscheidender Faktor
  • Ob in Staging, in einer internen Umgebung oder mit einem Teil des Produktions-Traffics getestet wird, verändert sowohl die Aussagekraft als auch das Risiko
  • Wird ein A/B-Test einem Teil realer Nutzer gezeigt, lassen sich Real-World-Probleme schneller entdecken, zugleich sind Schutzmechanismen nötig, um den Einflussbereich zu begrenzen
• Ein Kennzeichen erfahrener Engineers ist es, sich im Voraus vorzustellen: „Wo könnten Nebenwirkungen entstehen, und wie weit könnten sie sich ausbreiten?“
  • Bei Änderungen an einer Shared Library sollten andere Services und Teams, die sie verwenden, aufgelistet und vor dem Release mit Benachrichtigungen und Testplänen bedacht werden
  • Es sollte auch geprüft werden, ob die Optimierung eines bestimmten Moduls in anderen Modulen mehr Komplexität oder Änderungen am Datenformat erzwingt und welche Auswirkungen das auf das Gesamtsystem hat

When: Zeitachse und Wahl der Tiefe

• Informationen darüber, „wann“ ein Problem auftrat und wann gehandelt wurde, sind ein zentraler Hinweis für die Ursachenanalyse
  • Wenn man in einer Timeline festhält, wann etwas zuletzt korrekt funktionierte und was sich seitdem verändert hat, lässt sich die Ursache schneller eingrenzen
  • Es ist wichtig, sich anzugewöhnen, den Zeitpunkt eines Incidents mit Ereignissen wie neuem Deployment, nächtlichem Batch-Job oder Konfigurationsänderungen zu verbinden
• Ein weiterer Teil kritischen Denkens in Entscheidungen ist die Unterscheidung, wann man tief einsteigen sollte und wann Heuristiken ausreichen
  • Würde man bei jedem Problem eine vollständige Analyse versuchen, wären Zeitplan und Ressourcen nicht tragbar; die Tiefe der Analyse muss daher nach Risiko und Auswirkungen gesteuert werden
  • Bei nächtlicher Incident-Reaktion ist es oft realistisch, den Service zunächst mit kurzfristigen Maßnahmen wie einem Neustart wiederherzustellen und die Root Cause dann tagsüber zu untersuchen
• Wie im NASA-Beispiel gezeigt wird, steigt unter Stress und Zeitdruck die Wahrscheinlichkeit menschlicher Fehlurteile stark an
  • Gerade in Situationen, die schnelle Entscheidungen verlangen, ist es wichtig, im Voraus zu markieren, „bis wohin es sich um eine temporäre Maßnahme handelt und ab welchem Punkt eine erneute Prüfung zwingend ist“
  • Schon eine Notiz oder ein Ticket mit dem Vermerk „Das ist jetzt nur eine Zwischenlösung; Ursachenanalyse und grundlegende Gegenmaßnahmen müssen später folgen“ hilft der langfristigen Qualität
• Um unter begrenzter Zeit Sorgfalt zu bewahren, sollten Priorisierung und Triagierung genutzt werden
  • Die riskantesten Annahmen sollten zuerst geprüft werden, während weniger wichtige Entscheidungen auf später verschoben werden
  • Wenn bei der Konzeption eines neuen Features die Gültigkeit des Algorithmus und das Risiko größer sind, sollte vor UI-Details zunächst Zeit in die Verifikation des Algorithmus investiert werden
• Kritisches Denken hängt auch mit der Fähigkeit zusammen, den richtigen Zeitpunkt zu erkennen, um Hilfe zu holen oder innezuhalten und neu nachzudenken
  • Wenn über einen gewissen Zeitraum kein Fortschritt erreicht wird, sollte die Sicht anderer eingebunden werden; vor Sprint-Ende oder Release sollten gezielt Stopppunkte für Reviews gesetzt werden
  • Zwischen Analyse-Paralyse und vorschnellen Schlüssen ist es wichtig, sich selbst regelmäßig zu prüfen, ob für die aktuelle Entscheidung genügend Informationen vorliegen

Why: Motivation, Ursache und Begründung ergründen

• Wiederholt zu fragen, „Warum machen wir das?“, wirkt als Filter gegen bedeutungslose Trends und bloßes Nachahmen und hilft, sich auf echten Wert zu konzentrieren
  • Bei der Einführung neuer AI-Tools oder dem Wunsch nach neuen Features muss klar unterschieden werden, ob es um das Kopieren von Wettbewerbern oder um die Lösung eines realen Nutzerproblems geht
  • Nur wenn es eine überzeugende Antwort auf „Warum ist das wichtig?“ gibt, können die vielen Detailentscheidungen in der Umsetzung konsistent bleiben
• Wenn ein Problem auftritt, ist es wichtig, mit der 5 Whys-Technik von der oberflächlichen Ursache zu tieferliegenden Gründen vorzudringen
  • Beim Beispiel sinkender Modellgenauigkeit müssen Ketten von Ursachen wie veränderte Datenverteilung, neue Datenquellen, fehlende Validierung und unzureichendes Monitoring Schritt für Schritt verfolgt werden
  • Wenn sich als eigentliche Ursache unzureichende Validierung in der Datenpipeline oder fehlendes Monitoring herausstellt, wird sichtbar, dass Retraining allein das Problem nicht grundlegend löst
• Bei der Frage nach dem „Warum“ geraten Menschen leicht in Bestätigungsfehler und vorschnelle Schlussfolgerungen
  • Wenn das Denken an eine vertraute Ursache wie einen früheren Memory Leak gebunden bleibt, werden andere Möglichkeiten wie neue Konfigurations- oder Datenänderungen leicht übersehen
  • Um sich nicht mit der erstbesten Erklärung zufriedenzugeben, braucht es die Haltung, sich selbst zu fragen: „Gibt es noch andere mögliche Ursachen, und gibt es Evidenz, die meiner Annahme widerspricht?“
• Wie Beispiele aus Unternehmen der Vergangenheit zeigen, kann ein falsches Verständnis des „Warum“ dazu führen, dass sinkende Marktanteile oder strategische Fehler lange nicht korrigiert werden
  • Wenn alles nur äußeren Faktoren zugeschrieben wird und interne Probleme bei Prozessen, Qualität oder Kultur unsichtbar bleiben, wiederholt man immer wieder die falsche Behandlung
• Gute Engineers bewahren eine Haltung bescheidener Neugier, fragen nach dem „Warum“ und bleiben offen dafür, dass ihre eigenen Annahmen falsch sein könnten
  • Selbst wenn man an den Erfolg einer Idee glaubt, sollte man zuerst trennen, warum man das glaubt – ob auf Basis von Daten oder Intuition – und daraus die Richtung für die Verifikation ableiten
  • Nach einer Entscheidung sollten die Gründe dokumentiert und geteilt werden, damit bei veränderten Umständen später zuerst die zugrunde liegende Begründung erneut geprüft werden kann

How: Praktische Umsetzung und Kommunikation

• Die praktische Umsetzung kritischen Denkens im Alltag lässt sich in drei Achsen zusammenfassen: Frageweise, Evidenzprüfung und strukturierte Kommunikation
  • Statt vager Fragen wie „Ist das gut oder schlecht?“ sollten konkrete, offene Fragen gestellt werden wie: „Welches Nutzerbedürfnis adressiert das, wie wird es adressiert und wo könnte es scheitern?“
  • Es ist wichtig, sich anzugewöhnen, Bekanntes und Unbekanntes getrennt aufzulisten und zu planen, wie das Unbekannte experimentell oder durch Messung untersucht werden soll
• Beim Umgang mit Evidenz sollten alternative Interpretationen und das mögliche Einfließen von Biases mitgeprüft werden
  • Es muss gegengeprüft werden, ob das Ergebnis eines einzelnen Performance-Tests nur Zufall ist oder reproduzierbar, und ob es anderen Metriken widerspricht
  • Nötig ist eine Haltung, die nicht nur Daten sucht, die die eigene Theorie stützen, sondern bewusst auch Daten, die sie widerlegen könnten
• Auf Teamebene wird auch ein Vorgehen wie premortem vorgestellt, bei dem mögliche Fehlschlag-Szenarien im Voraus angenommen werden
  • Wenn man annimmt, dass ein Projekt gescheitert ist, und die Gründe dafür aufschreibt, können in der Planungsphase übersehene Risiken und verborgene Annahmen sichtbar werden
• Bei der Kommunikation von Lösungen ist es wirksam, die Logik in der Reihenfolge Problemdefinition (What·Why) → vorgeschlagene Lösung (How) → zugrunde liegende Daten und Annahmen aufzubauen
  • Wenn Prämissen und Trade-offs offengelegt werden, können andere die Idee leichter validieren und ergänzen, und man selbst erkennt eher Lücken in der Logik
  • Eine Haltung, die quantifizierbare Fakten vor Meinungen stellt – etwa „Die durchschnittliche Page-Load-Zeit hat sich im Dashboard um 25 % verbessert“ –, erhöht das Vertrauen
• In einem Umfeld, in dem kritisches Denken gut funktioniert, entsteht eine Kommunikationskultur, die Fragen und Widerspruch willkommen heißt
  • Nach einem Vorschlag wird aktiv nachgefragt, „ob es Lücken in dieser Logik gibt oder ob jemand Bedenken hat“, um Ideen gemeinsam zu schärfen
  • Nicht die einseitige Präsentation, sondern gerade der Prozess, in dem mehrere Menschen gemeinsam die Logik überprüfen, steigert die Qualität der Lösung
• Auf individueller Ebene ist kontinuierliche Verbesserung des Denkens durch Retrospektiven und Lernen wichtig
  • Wenn durch eine vorschnelle Entscheidung ein Bug entstanden ist, sollte anschließend in einer kleinen Retrospektive festgehalten werden, „wo was übersehen wurde und was man beim nächsten Mal anders machen wird“
  • Es hilft auch, Postmortems anderer Unternehmen und Materialien zu kognitiven Verzerrungen zu lesen, um Denkfallen, die künftig vermieden werden sollten, frühzeitig kennenzulernen

Fazit: Kritisches Denken als genuin menschlicher Vorteil

• Je stärker AI genutzt wird, desto mehr wird kritisches Denken nicht zur Option, sondern zur Pflichtkompetenz
  • Mit Who·What·Where·When·Why·How sollten Menschen, Probleme, Kontext, Timing, Ursachen und Vorgehensweisen systematisch überprüft werden
• In einer gesunden Teamkultur gelten unabhängiges Denken und eine fragende Haltung als selbstverständlich
  • Jeder sollte fragen können: „Ist das wirklich die Lösung oder nur ein Quick Fix?“, „Wollen Nutzer dieses Feature wirklich?“ und „Zeigen die Daten tatsächlich eine Verbesserung?“
• Kritisches Denken schützt Teams vor der Versuchung schneller Flickwerk-Lösungen
  • Statt Probleme nur kurzfristig zu überdecken, spart es langfristig Zeit und Kosten, erst die Root Cause zu prüfen, zu validieren und dann zu handeln
• Auch in einer Zeit, in der AI und Automatisierung repetitive Arbeit und erste Entwürfe übernehmen, bleibt „das richtige Problem aus den richtigen Gründen auf die richtige Weise zu lösen“ die Aufgabe des Menschen
  • Teams, die bescheidene Neugier und evidenzbasiertes Denken bewahren, werden auch im Zeitalter der AI dauerhaft gute Ergebnisse liefern