Warum KI uns langsamer macht

Viele denken, dass KI alles automatisch schneller macht. Weniger Tippen, weniger Nachdenken, mehr Output. Ich denke das ehrlich gesagt selbst immer wieder. Sobald KI im Spiel ist, schaltet mein Kopf unbewusst auf „Beschleuniger“.

Die Erwartung ist klar: Ich delegiere Arbeit an die KI, bekomme schneller Ergebnisse und bin damit produktiver. Und wenn es irgendwo hakt, dann habe ich vermutlich einfach noch nicht präzise genug formuliert.

Genau diese Denke hat sich bei mir in letzter Zeit mehrfach als problematisch erwiesen. Nicht, weil KI schlechte Ergebnisse liefert. Sondern weil sie Ergebnisse liefert, die gut aussehen, funktionieren und trotzdem am eigentlichen Ziel vorbeigehen.

Ich habe gemerkt, dass KI mir nicht automatisch Zeit spart. In manchen Situationen hat sie mich sogar langsamer gemacht. Nicht auf eine offensichtliche Weise, sondern subtil: durch zusätzliche Schleifen, durch ein falsches Gefühl von Fortschritt und durch die verzögerte Erkenntnis, wo das eigentliche Problem liegt.

In diesem Artikel geht es genau darum. Nicht darum, ob KI gut oder schlecht ist. Sondern darum, wo sie mich bremst, warum das passiert und was das über meine eigene Arbeitsweise aussagt.

Ich habe Geschwindigkeit mit Fortschritt verwechselt

Wenn ich ehrlich bin, habe ich KI lange wie einen natürlichen Beschleuniger behandelt. Mehr Intelligenz, mehr Automatisierung, mehr Tempo – das schien logisch. Sobald KI im Spiel war, bin ich unbewusst davon ausgegangen, dass ich schneller vorankomme als ohne.

Dieses Gefühl wird durch den Arbeitsprozess selbst verstärkt. Ich schreibe weniger. Ich bekomme schneller Code. Ich sehe in kurzer Zeit sichtbare Ergebnisse. Das fühlt sich nach Produktivität an, auch wenn es zunächst nur Output ist.

Rückblickend ist genau hier mein Denkfehler entstanden. Ich habe Geschwindigkeit bei der Erzeugung von Ergebnissen mit Fortschritt bei der Lösung des Problems gleichgesetzt. KI beschleunigt das Produzieren von Artefakten, aber sie garantiert mir nicht, dass diese Artefakte das richtige Problem adressieren.

Gerade in der Softwareentwicklung liegt der Engpass selten im Tippen von Code. Der eigentliche Aufwand steckt im Verstehen: im Erfassen von Zusammenhängen, im Durchdenken von Randbedingungen, im Erkennen von Abhängigkeiten und im Bewerten von Konsequenzen.

Diese Denkarbeit verschwindet nicht, nur weil ich KI einsetze. Sie verschiebt sich. Oft nach hinten, in Form von Review, Debugging und zusätzlichen Iterationen. Ich bekomme früher Ergebnisse, aber die eigentliche Erkenntnis kommt später.

Das Problem dabei ist nicht offensichtlich. Der Prozess wirkt produktiv. Dinge entstehen. Tests laufen grün. Code sieht plausibel aus. Ich habe das Gefühl, voranzukommen. Erst im Nachhinein wird klar, dass ich mich schneller bewegt habe, aber nicht unbedingt in die richtige Richtung.

Für mich ist daraus eine zentrale Erkenntnis entstanden: KI ist kein Ersatz für Verständnis. Sie verstärkt das, was bereits da ist. Wenn ich das Problem sauber verstanden habe, kann sie mich enorm beschleunigen. Wenn nicht, beschleunigt sie vor allem meine Fehlannahmen.

Wie ich mich von grünen Tests täuschen ließ

Das Problem wurde für mich erst greifbar, als ich an einem ganz konkreten Punkt festhing. Ich wollte einen Test schreiben. Einen, der fachlich korrekt ist und gleichzeitig die Test-Coverage erhöht.

Ich habe den Testfall beschrieben, aus meiner Sicht sauber und präzise. Was getestet werden soll, unter welchen Bedingungen und welches Verhalten ich erwarte. GitHub Copilot hat daraufhin Testcode generiert, der auf den ersten Blick absolut plausibel aussah.

Die Tests liefen grün. Keine Fehler. Keine Warnungen. Genau das, was man sehen möchte. Trotzdem war mein Sonar Build weiterhin rot, weil die Coverage nicht ausreichte.

Also habe ich das Problem adressiert. Ich habe erklärt, dass es mir explizit um die Coverage geht. Copilot hat neue Testfälle generiert. Wieder grün. Die Coverage blieb unverändert.

Ich habe diese Schleife mehrere Male durchlaufen. Jedes Mal sah der Code sinnvoll aus. Jedes Mal liefen die Tests durch. Und jedes Mal blieb das Ergebnis gleich. Rückblickend hätte ich hier bereits stutzig werden müssen.

Irgendwann habe ich aufgehört, das Problem weiter an die KI zu delegieren. Ich bin in den Debugger gegangen und habe den Code Zeile für Zeile nachvollzogen. Und genau dort wurde das eigentliche Problem sichtbar.

Die Bedingungen im Code waren so formuliert, dass sich relevante Pfade gegenseitig ausschließen. Logisch betrachtet konnte die Coverage gar nicht steigen, egal wie viele Tests ich hinzufüge. Die KI hat das nicht erkannt. Und ich auch nicht – bis ich gezwungen war, selbst wieder genau hinzusehen.

In diesem Moment wurde mir klar: Die KI hat mich nicht aktiv blockiert. Sie hat mir sogar geholfen, plausible Tests zu schreiben. Aber genau diese Plausibilität hat mich länger in einer falschen Annahme gehalten, als es ohne KI vermutlich der Fall gewesen wäre.

Warum die KI meinen Denkfehler nicht erkennen konnte

Im Nachhinein war die Frage für mich nicht, warum die KI „versagt“ hat. Die eigentliche Frage war, warum ich erwartet hatte, dass sie diesen Fehler überhaupt erkennen kann.

GitHub Copilot hat genau das getan, wofür es gebaut ist. Es hat Testcode erzeugt, der zu meiner Beschreibung passte. Der Code war syntaktisch korrekt, fachlich plausibel und verhielt sich so, wie man es aus den Prompts ableiten konnte.

Was die KI nicht konnte: meine impliziten Annahmen hinterfragen. Sie wusste nicht, dass ich davon ausging, bestimmte Codepfade seien erreichbar. Sie wusste nicht, dass die Coverage-Intention ein zentrales Ziel war. Und sie konnte nicht erkennen, dass sich Bedingungen gegenseitig ausschließen, solange das nicht explizit formuliert war.

Rückblickend wird klar, dass ich selbst diesen Widerspruch zunächst nicht gesehen habe. Die KI hat meinen Denkfehler nicht verursacht, sie hat ihn stabilisiert. Sie hat mir plausible Ergebnisse geliefert, die keinen Anlass boten, meine Annahmen infrage zu stellen.

Genau darin liegt die eigentliche Bremse. KI scheitert hier nicht spektakulär, sondern leise. Sie produziert Ergebnisse, die gut genug sind, um weiterzumachen, aber nicht gut genug, um das Problem wirklich zu lösen.

Ohne KI wäre ich vermutlich früher gezwungen gewesen, tiefer in den Code zu gehen. Mit KI habe ich länger versucht, das Problem durch Iteration zu lösen, statt durch Verstehen. Das hat Zeit gekostet, obwohl sich der Prozess produktiv angefühlt hat.

Kontextarbeit – der Teil, den ich unterschätzt habe

Je länger ich darüber nachgedacht habe, desto klarer wurde mir: Das eigentliche Problem war nicht der generierte Code, sondern der fehlende Kontext. Genauer gesagt: der Kontext, den ich selbst nicht sauber formuliert hatte.

Ich bin davon ausgegangen, dass bestimmte Dinge „klar“ sind. Welche Pfade relevant sind. Welche Bedingungen sinnvoll kombiniert werden können. Welche Intention hinter dem Test steckt. All das war in meinem Kopf vorhanden – aber nicht explizit beschrieben.

KI kann nur mit dem arbeiten, was explizit gemacht wird. Alles andere wird implizit ergänzt. Nicht, weil die KI schlampig ist, sondern weil sie gar keine andere Wahl hat. Sie füllt Lücken mit Annahmen.

Genau hier entsteht der unterschätzte Mehraufwand. Gute Ergebnisse mit KI erfordern, dass ich Entscheidungen vorziehe: Ich muss klar benennen, was das Ziel ist. Ich muss Abhängigkeiten offenlegen. Ich muss sagen, was ausgeschlossen ist und was auf keinen Fall passieren darf.

Diese Kontextarbeit fühlt sich nicht nach Fortschritt an. Sie produziert keinen sichtbaren Output. Sie lässt sich nicht „delegieren“. Und genau deshalb neige ich dazu, sie zu überspringen oder zu früh an die KI abzugeben.

In meinem Beispiel hätte mir genau diese Arbeit geholfen. Nicht ein weiterer Testlauf, sondern das saubere Durchdenken der Logik. Die KI hätte mir dabei vielleicht assistieren können. Aber sie konnte mir diese Klarheit nicht abnehmen.

Der Zeitgewinn, den ich mir durch KI erhofft hatte, wurde an dieser Stelle vollständig aufgefressen. Nicht, weil KI ineffizient war, sondern weil sie gnadenlos offengelegt hat, wie viel unausgesprochenes Wissen ich selbst vorausgesetzt habe.

Implizites Wissen, auf das nur ich Zugriff hatte

Ein weiterer Punkt, der mir in diesem Zusammenhang klar geworden ist: Ein großer Teil der relevanten Information existierte nur in meinem Kopf. Nicht im Code. Nicht in Tests. Nicht im Prompt.

Ich wusste, wie das System historisch gewachsen ist. Ich kannte frühere Entscheidungen, Workarounds und fachliche Abkürzungen. Ich hatte ein Gefühl dafür, welche Pfade „eigentlich“ relevant sind und welche nur theoretisch existieren.

Für mich war dieses Wissen selbstverständlich. Für die KI war es nicht existent. Und genau hier liegt ein strukturelles Problem: Implizites Wissen lässt sich nicht einfach automatisch mitdelegieren.

Dazu kommen nicht-funktionale Anforderungen, die selten explizit formuliert werden: Performance-Erwartungen, Wartbarkeit, Lesbarkeit, Robustheit gegenüber zukünftigen Änderungen. All diese Aspekte fließen in meine Entscheidungen ein, ohne dass ich sie bewusst ausspreche.

Ich habe implizit erwartet, dass die KI diese Dimensionen mitdenkt. Das war unrealistisch. Nicht, weil die KI „zu dumm“ ist, sondern weil sie keinen Zugriff auf diese unausgesprochenen Kriterien hatte.

Das Ergebnis: Die KI hat mir Lösungen geliefert, die lokal sinnvoll waren, aber systemisch an der Realität vorbeigingen. Je komplexer das System, desto größer wird genau dieser Effekt.

Mir wurde klar, dass KI nicht an Komplexität scheitert, sondern an Unsichtbarkeit. Alles, was nicht explizit gemacht wird, existiert für sie schlicht nicht.

Wann KI mich tatsächlich langsamer gemacht hat

Rückblickend ist der entscheidende Punkt für mich nicht, dass KI mir Arbeit abgenommen hat. Das hat sie. Sondern dass sie mir an der falschen Stelle Arbeit abgenommen hat.

Durch die schnelle Verfügbarkeit von Ergebnissen bin ich länger in einer Schleife geblieben, die eigentlich keine Lösung liefern konnte. Jeder neue, plausible Test hat mich ein Stück davon überzeugt, dass ich „auf dem richtigen Weg“ bin.

Ohne KI wäre ich vermutlich früher gezwungen gewesen, innezuhalten. Früher zu hinterfragen, ob mein Ansatz überhaupt funktionieren kann. Früher in den Code zu gehen und die Logik wirklich zu verstehen.

Mit KI habe ich stattdessen iteriert. Nicht, weil ich nicht denken wollte, sondern weil es sich effizient angefühlt hat. Der Prozess war aktiv, sichtbar und scheinbar produktiv.

Genau hier hat KI mich langsamer gemacht. Nicht durch Fehler. Nicht durch schlechte Ergebnisse. Sondern durch das Stabilisieren einer falschen Annahme.

Die Zeit, die ich durch schnelles Generieren gespart habe, habe ich später mit Debugging, Ursachenanalyse und mentalem Neuaufbau wieder verloren. In Summe war ich langsamer, obwohl sich der Weg dorthin zunächst schneller angefühlt hat.

Diese Erkenntnis war unangenehm, aber wichtig. Sie hat mir gezeigt, dass KI nicht nur beschleunigt, sondern auch verzögern kann – abhängig davon, wo ich sie einsetze und was ich ihr überlasse.

Was ich daraus über meinen Umgang mit KI gelernt habe

Der wichtigste Lerneffekt aus dieser Situation war für mich nicht technischer Natur. Es ging nicht um Tests, Coverage oder Copilot. Es ging um meinen Umgang mit dem Werkzeug.

Mir ist klar geworden, dass ich eine neue Fähigkeit lernen muss: bewusst zu entscheiden, wann ich KI einsetze und wann ich sie bewusst nicht einsetze. Diese Entscheidung ist kein Bauchgefühl, sondern Teil der eigentlichen Arbeit.

KI eignet sich hervorragend für Aufgaben, bei denen das Problem klar verstanden ist und die Lösung gut eingegrenzt werden kann. Sie ist stark in der Ausführung, in der Variation, im Beschleunigen von Bekanntem.

Sobald ich aber merke, dass ich selbst unscharf denke, Annahmen nicht klar benennen kann oder mir Zusammenhänge entgleiten, ist Delegation der falsche Reflex. In genau diesen Momenten muss ich selbst tiefer einsteigen.

Das bedeutet nicht, KI weniger zu nutzen. Es bedeutet, sie bewusster zu nutzen. Nicht als Ersatz für Denken, sondern als Verstärker für Klarheit.

Für mich hat sich daraus ein einfaches, aber hartes Prinzip ergeben: Wenn ich ein Problem nicht sauber erklären kann, bin ich noch nicht bereit, es sinnvoll an KI zu delegieren.

Diese Einsicht klingt banal. In der Praxis ist sie alles andere als leicht. Aber genau sie entscheidet darüber, ob KI mich beschleunigt oder mich unbemerkt ausbremst.

Fazit: Das Werkzeug war neu – der Denkfehler nicht

Wenn ich auf das gesamte Beispiel zurückblicke, wird für mich eines sehr deutlich: Die KI war nicht das Problem. Meine Erwartung an sie war es.

Ich habe KI wie einen Beschleuniger behandelt, obwohl ich mich noch mitten in der Denkphase befand. Ich habe delegiert, obwohl ich selbst noch kein sauberes mentales Modell hatte. Die KI hat mir dabei nicht geschadet – sie hat meinen Zustand lediglich verstärkt.

Genau darin liegt die eigentliche Wahrheit über KI: Sie ersetzt kein Denken. Sie überspringt keine Unklarheit. Sie macht keine impliziten Annahmen explizit. Sie verstärkt das, was bereits vorhanden ist – Klarheit ebenso wie Verwirrung.

In meinem Fall hat sie mir Arbeit abgenommen, aber Einsicht verzögert. Sie hat plausible Ergebnisse geliefert, die mich davon abgehalten haben, früher an der richtigen Stelle anzusetzen. Das hat Zeit gekostet, obwohl sich der Prozess zwischendurch produktiv angefühlt hat.

Die eigentliche Lehre daraus ist nicht, KI vorsichtiger oder seltener einzusetzen. Die Lehre ist, Verantwortung für das Denken nicht abzugeben. KI kann mich unterstützen, beschleunigen und entlasten – aber nur dort, wo ich selbst verstanden habe, was ich eigentlich tue.

Oder anders gesagt: A Fool with a Tool is still a Fool. KI macht diesen Satz nicht falsch. Sie macht ihn nur sichtbarer.