- Die kontraintuitivste Praxis im AI-Zeitalter ist, zu wissen, wann man langsamer werden muss; je günstiger Ausführung wird, desto wichtiger werden die Entscheidungen in den vorgelagerten Phasen
- Das Framework von Daniel Kahneman mit System 1 (schnelles Pattern Matching) und System 2 (langsames analytisches Denken) wird auf Softwareentwicklung im AI-Zeitalter angewendet
- Falsche Anforderungen oder Design-Annahmen werden von AI noch schneller weiterverbreitet, wodurch sich der Kosten-Nutzen-Effekt langsamer Phasen vor der Ausführung maximiert
- AI kann nicht nur für die Ausführung, sondern auch dafür genutzt werden, Vorab-Reviews, Pre-Mortems und die Suche nach Edge Cases zu beschleunigen
- Um auf die neue Kultur des Geschwindigkeitsdrucks à la „Man kann doch einfach AI nutzen?“ zu reagieren, braucht es Strategien, die langsame Phasen explizit sichtbar machen und timeboxen
Zwei Denkgeschwindigkeiten
- Die zwei Denkmodi aus Daniel Kahnemans Thinking, Fast and Slow werden auf Entwicklung im AI-Zeitalter übertragen
- System 1: schnelles, automatisches, auf Pattern Matching basierendes Denken
- System 2: langsames, absichtsvolles, analytisches Denken
- Andrej Karpathy verglich LLMs in einem Gespräch mit Dwarkesh Patel mit Geistern oder Dschinns: statistische Destillate menschlicher Texte, bei denen Wörter hineingehen, Patterns gematcht werden und Wörter herauskommen — im Kern Wesen des System 1
- AI ist hervorragend in großskaligem schnellem Pattern Matching, aber die Beurteilung, was gebaut werden soll, warum es wichtig ist und ob das richtige Problem gelöst wird, bleibt weiterhin Sache menschlichen Urteilsvermögens
- Der kontraintuitive Kern: AI hat langsame Phasen nicht weniger wichtig gemacht, sondern wichtiger
- Wenn Ausführung günstiger und schneller wird, verlagert sich der Hebel auf die Entscheidungen vor der Ausführung
- Falsche Anforderungen, missverstandene Probleme und fehlerhafte Design-Annahmen pflanzen sich in allem fort, was AI baut — und jetzt noch schneller
- Je mächtiger System 1 wird, desto höher werden die Kosten dafür, System 2 falsch einzusetzen
Die Illusion von Geschwindigkeit
- Ein alter Witz aus der Wissenschaft lautet: „Was in der Bibliothek ein paar Stunden dauert, braucht im Labor Wochen“; die Software-Version lautet: „Ein paar Wochen Coden sparen ein paar Stunden Planung“
- Der entscheidende Punkt ist, dass es in Wahrheit umgekehrt ist — wer zu früh loslegt, entdeckt fundamentale Fehler erst später und landet in schmerzhafter Nacharbeit
- In der Softwareentwicklung gibt es die klare Intuition, dass Fehler möglichst früh in der Anforderungs- oder Designphase gefunden werden sollten
- Box-Diagramme lassen sich leicht ändern, missverstandene Anforderungen deutlich schwerer, und eine grundlegend fehlerhafte Deployment-Architektur bedeutet schnell Neuschreiben
- Das Problem mit AI: Sie kann technische Schulden schneller denn je erzeugen
- Wenn Entscheidungen vor der Ausführung fehlerhaft sind, implementiert AI diese Fehler treu in einer Form, die wie vollständig funktionsfähiger Code aussieht
- Sie generiert bereitwillig Tausende Zeilen Code auf Basis missverstandener Anforderungen und baut elegante Lösungen für das falsche Problem
- Die Illusion von Geschwindigkeit: Es fühlt sich an, als mache man Fortschritte, obwohl man in Wirklichkeit nur ein tieferes Loch gräbt
- Die Antwort ist nicht, Geschwindigkeit aufzugeben, sondern sie gezielt einzusetzen — die Geschwindigkeit von AI sollte erst dann voll wirken, wenn bestätigt ist, dass die Richtung stimmt
Wann Langsamkeit wirkt
- Die Punkte, an denen bewusste Langsamkeit wirksam ist, haben sich im Kern nicht verändert
- Anforderungen sind günstig zu ändern, solange sie nur Worte in einem Dokument sind, und teuer, wenn sie bereits als ausgerollter Code echte Nutzer bedienen
- Design-Entscheidungen lassen sich in Diagrammen leicht korrigieren, in Produktionssystemen dagegen schwer
- AI hat diese grundlegende Physik nicht verändert, sondern den Hebel bei richtiger Anwendung vergrößert
- Das Thinking-First-Protokoll: Der günstigste Punkt, um Fehler zu erkennen, ist die bewusste Investition von Zeit, um klar zu formulieren, was man eigentlich will, bevor man die Aufgabe an AI übergibt
- Ein interessantes Paradox: AI kann nicht nur die Ausführung beschleunigen, sondern auch das Nachdenken selbst
- Anforderungen vor dem Coden klären: 10 Minuten lang das zu lösende Problem, Erfolgskriterien und Constraints aufschreiben, dann AI den Text prüfen lassen und erst danach generieren
- Pre-Mortem durchführen: Vor dem Festlegen eines Designs AI fragen: „Was könnte an diesem Ansatz schiefgehen?“, um übersehene Risiken sichtbar zu machen
- Das Problem umkehren (Invert): AI fragen: „Was würde dieses Projekt scheitern lassen?“, um verborgene Annahmen offenzulegen
- Wegwerf-Prototyp bauen: Mit AI in wenigen Stunden etwas erstellen, Stakeholdern zeigen und das Verständnis prüfen, bevor investiert wird — Geschwindigkeit als Investition in Langsamkeit
- Einfache interne Tools bauen: Bevor Geld in das eigentliche Produkt fließt, mit AI zuerst eine grobe Version erstellen, um zu erkennen, was wirklich nötig ist und was nicht
- Edge Cases früh ableiten: AI schon vor der Implementierung Edge Cases und Fehlermodi des Designs erzeugen lassen, damit sie noch auf Diagramm-Ebene behandelt werden können
Neuer kultureller Gegenwind
- „Man kann doch einfach AI nutzen?“ ist eine neue Form von Geschwindigkeitsdruck und besonders gefährlich, weil dabei der Anschein von Produktivität mit tatsächlichem Durchsatz verwechselt wird
- AI kann zwar in Sekunden Code erzeugen, aber Code zu erzeugen und das richtige Problem zu lösen ist nicht dasselbe
- Strategien für den Umgang damit:
- Explizit teilen, in welcher Phase man sich gerade befindet: Wenn man in einer langsamen Phase ist, klar sagen, dass gerade Anforderungen geschärft, Edge Cases durchdacht oder die Problemdefinition validiert werden
- Stakeholder aktiv einbinden: Input von Stakeholdern ist jetzt günstig einzubauen und später teuer
- Den Arbeitsprozess sichtbar machen: Artefakte langsamer Phasen wie Anforderungsdokumente, Design-Skizzen oder Pre-Mortem-Ergebnisse sichtbar machen, um zu zeigen, dass Fortschritt stattfindet
- Langsame Phasen timeboxen: Klare Grenzen setzen wie „zwei Tage Anforderungsklärung vor dem Schreiben von Code“, damit bewusste Langsamkeit nicht offen, sondern geplant wirkt
- Lernfortschritte teilen: Kurz über entdeckte Edge Cases oder widerlegte Annahmen berichten, um langsame Phasen in einen sichtbaren Wertstrom zu verwandeln
- Quick Wins demonstrieren: Früh einen Wegwerf-Prototyp oder ein Mock-up erstellen, um zu zeigen, dass man sich schnell bewegen kann, und so Vertrauen für langsame, sorgfältige Arbeit aufbauen
- Das ähnelt dem Hill-Chart-Konzept der Shape Up-Methodik von Basecamp
- Bergauf: die langsame Phase mit hoher Unsicherheit, in der die eigentliche Form der Arbeit erst entdeckt wird
- Bergab: die schnelle Phase, in der der Weg klar ist und nur noch ausgeführt werden muss
- Das ist keine Ausrede für Verzögerungen, sondern eine Beschreibung davon, wie gute Arbeit tatsächlich entsteht — langfristig liefern oft die Teams am schnellsten aus, die im richtigen Moment bereit sind, langsamer zu werden
Wie man es umsetzt
- Vor der nächsten AI-unterstützten Aufgabe ausprobieren:
- 10 Minuten lang das Problem aufschreiben, das wirklich gelöst werden soll, und definieren, wie Erfolg aussieht und was außerhalb des Umfangs liegt
- Vor dem Start des Build-Prozesses AI ein Pre-Mortem für den Ansatz durchführen lassen
- Wenn die Arbeit umfangreicher ist, zuerst einen Wegwerf-Prototyp bauen, um die Richtung zu validieren
Fazit
- Geschwindigkeit und Langsamkeit sind keine Gegensätze, sondern Werkzeuge für unterschiedliche Phasen
- AI ist für beides wirksam: schnelle Ausführung, wenn die Richtung klar ist, und beschleunigtes Nachdenken, wenn sie unklar ist
- Die Kernkompetenz besteht darin, zu erkennen, in welcher Phase man sich gerade befindet, und das passende Tempo anzuwenden
4 Kommentare
Man sagt doch: langsam und schnell zugleich.
Ein Satz, den ich im Studium von meinem Professor oft gehört habe,
bekomme nach langer Zeit wieder PTSD davon.
Ich habe das beim Militär gehört.
Ich habe es in den Noten gelesen
allegro non troppo (schnell, aber nicht überhastet)