Die Situation war klar: Ein Kurs war bereits zweimal abgerechnet, doch ein Dozent musste kurzfristig ersetzt werden. Ein UPDATE-Befehl in der Datenbanktabelle für Einschreibungen schien die naheliegende Lösung zu sein. Doch was als einfache technische Korrektur begann, entwickelte sich zu einem wochenlangen Aufwand, als Eltern plötzlich nachvollziehen wollten, warum die Unterschrift ihres Kindes plötzlich geändert worden war.
Nach diesem Vorfall habe ich eine einfache, aber wirksame Regel eingeführt: Bevor eine KI oder ich allein eine Entscheidung bei Audit-relevanten Änderungen trifft, verlange ich drei strukturell unterschiedliche Optionen. Nicht drei Varianten desselben Ansatzes, sondern drei grundlegend verschiedene Lösungswege – jeweils mit klaren Vor- und Nachteilen.
Die Illusion der schnellen Lösung
Die Versuchung, selbst zu entscheiden, ist groß. Der Code scheint auf den ersten Blick einfach, und die Geschwindigkeit des Schreibens wird oft mit Fortschritt verwechselt. Doch hinter dieser scheinbaren Effizienz verstecken sich drei psychologische Fallstricke:
- Der Kontext-Blindheit-Effekt: Wer jahrelang mit einem System arbeitet, übersieht leicht die Perspektiven, die einem Außenstehenden sofort auffallen würden. Meine Erfahrung mit der Datenbanktabelle machte mich blind für Alternativen, die ein Dritter sofort als sinnvoll erkannt hätte.
- Die Geschwindigkeit-Falle: Es dauert nur Sekunden, einen
UPDATE-Befehl zu schreiben – doch die Zeit, die später für die Rekonstruktion fehlender Protokolle oder die Korrektur von Fehlern aufgewendet werden muss, wird dabei ignoriert.
- Der Autonomie-Irrtum: Viele Entwickler glauben, dass jede Entscheidung, die sie an eine KI delegieren, ihre eigene Expertise untergräbt. Doch in Wahrheit geht es nicht um Macht, sondern um Qualität. Eine KI, die drei Optionen vorschlägt, trifft keine Entscheidung – sie erweitert nur den Entscheidungsspielraum.
Diese drei Fallstricke verstärken sich gegenseitig und führen zu dem, was ich als "Schein-Effizienz" bezeichne: Der Eindruck von Produktivität, der sich am Ende in stundenlanger Nacharbeit auflöst.
Drei Optionen, drei Perspektiven
Seitdem ich diese Regel anwende, beginne ich jeden Audit-relevanten Vorgang mit einer einfachen Frage an die KI: „Gib mir drei strukturell unterschiedliche Optionen für diese Änderung.“ Die Anforderungen an diese Optionen sind klar:
- Sie müssen sich grundlegend unterscheiden – nicht nur in Details, sondern in ihrem Ansatz.
- Jede Option muss drei konkrete Trade-offs benennen:
- Auswirkung auf den Geschäftsprozess (z. B. ob Eltern später die Änderung nachvollziehen können)
- Umfang der Code-Änderungen (z. B. ob nur eine Tabelle aktualisiert oder ein neuer Datensatz angelegt wird)
- Operative Kosten (z. B. ob die Lösung zusätzliche Wartung oder manuelle Dokumentation erfordert)
Im Fall der Dozenten-Ersetzung lieferte die KI drei Optionen zurück:
- Option (a): Direkter `UPDATE`-Befehl
- Änderungen werden in einem Freitextfeld vermerkt.
- Geringer Audit-Aufwand, aber keine strukturierte Nachvollziehbarkeit.
- Risiko: Spätere Recherche in unstrukturierten Notizen erfordert stundenlange Suche in Logs.
- Option (b): Schließung der alten Einschreibung mit Begründung und Neuanlage
- Alte Einschreibung wird mit einem expliziten Grund geschlossen.
- Neue Einschreibung wird für den neuen Dozenten angelegt.
- Vorteil: Volle Audit-Tauglichkeit, da alle Änderungen strukturiert protokolliert werden.
- Nachteil: Erfordert mehr Code-Änderungen und zusätzliche Datenbankoperationen.
- Option (c): Nebenfeld mit manueller Notiz
- Eine zusätzliche Spalte wird genutzt, um die Änderung zu dokumentieren.
- Mittlerer Audit-Aufwand, da die Dokumentation manuell gepflegt werden muss.
In diesem Fall entschied ich mich für Option (b). Hätte ich allein entschieden, wäre wahrscheinlich Option (a) gewählt worden – mit den bekannten Konsequenzen.
Wann diese Regel NICHT gilt
Die Drei-Optionen-Regel ist kein Allheilmittel. Sie ist nur dann sinnvoll, wenn eine Entscheidung Auswirkungen auf Audit-Protokolle, Berechtigungen, Workflows oder andere systemrelevante Prozesse hat. Bei rein technischen Entscheidungen – etwa der Wahl eines Datenbankindex oder der Signatur einer TypeScript-Hilfsfunktion – überwiegt der Nutzen einer schnellen, fachkundigen Lösung.
Konkret bedeutet das:
- Technische Optimierungen wie Index-Optimierungen oder Code-Refactoring können direkt umgesetzt werden.
- Audit-relevante Änderungen wie die Anpassung von Berechtigungen oder die Protokollierung von Änderungen erfordern dagegen eine strukturierte Abwägung.
Der Grund ist einfach: Bei technischen Entscheidungen geht es um Effizienz und Wartbarkeit. Bei Audit-relevanten Änderungen geht es um Nachvollziehbarkeit und Compliance – und die rechtfertigt die zusätzlichen 30 Sekunden, die es dauert, drei Optionen zu prüfen.
30 Sekunden jetzt, drei Stunden später gespart
Die Regel ist simpel, aber wirkungsvoll: 30 Sekunden, um drei Optionen zu prüfen, können drei Stunden Rekonstruktionsarbeit sparen. Sie misst sich nicht in Lines of Code, sondern in Lines of Code, die nicht neu geschrieben werden müssen.
Diese Herangehensweise hat sich in meinem Team etabliert. Statt sich auf die scheinbare Geschwindigkeit einer KI zu verlassen, nutzen wir sie als Sparringspartner für bessere Entscheidungen. Denn am Ende geht es nicht darum, wer die Entscheidung trifft – sondern darum, dass die Entscheidung richtig ist.
Die Zukunft der Softwareentwicklung liegt nicht darin, KI blind zu vertrauen, sondern sie als intelligenten Assistenten zu nutzen – der uns vor den Fallen unserer eigenen Expertise bewahrt.
KI-Zusammenfassung
Yapay zekâ destekli kodlama sürecinde hız adına verilen acele kararlar, gelecekte saatlerce sürecek yeniden yapılanmalara yol açıyor. Kritik değişikliklerde 3 seçenek kuralını uygulamak, sistem güvenilirliğini artırıyor.