Vom Feuerwerk zum Kater - Warum KI-Entwicklung oft wie Silvester endet

Erinnern Sie sich noch an Silvester als Kind? Die Ungeduld, bis es endlich dunkel wurde. Die Faszination, als die ersten Raketen in den Himmel schossen. Als Jugendlicher fühlte man sich mächtig, wenn es überall krachte und blitzte – alles war schnell, laut und spektakulär.

Doch je erwachsener wir wurden, desto nüchterner wurde der Blick. Und nicht selten wachte man am Neujahrsmorgen mit einem ordentlichen Kater auf, rieb sich die Augen und stand vor einem Berg aus Aufräumarbeiten.

Genau dieses Bild ging mir durch den Kopf, als ich mir das Ergebnis eines kleinen, privaten Projekts anschaute. In der ruhigen Zeit zwischen den Feiertagen habe ich eine App entwickelt, mit dem Ziel, maximal viele Aufgaben an die KI zu delegieren. Ich wollte gezielt selber erfahren, was es bedeutet, möglichst viele Aufgaben an die künstliche Intelligenz zu übertragen.

Phase 1: Das Feuerwerk

Als ich mit der Entwicklung meiner App begann, war da wieder diese kindliche Begeisterung. Die KI zündete ein Feuerwerk an Produktivität: Der Code sprudelte, Features standen in Minuten, ich war beeindruckt, was alles möglich ist. Und das nicht nur vom Code her, sondern auch vom Dialog mit der KI bei der Ausarbeitung der Features. Es entsponnen sich geradezu Diskussionen und die KI schlug Vorgehensweisen, Strukturen und Inhalte vor, die ich tatsächlich nicht bedacht hatte.

Phase 2: Der Kater

Doch je tiefer ich ins Projekt einstieg, desto mehr verflog der Rausch. Wie am Neujahrsmorgen setzte die Ernüchterung ein und der „Kater“ meldete sich: Inkonsistenter Code, Logikfehler und ein massiver Geschwindigkeitsverlust.

Der Tiefpunkt? Die KI sollte eine einfache Tabelle generieren. Stattdessen legte sie eigenmächtig ein Python-Script in meinem Projekt an, um die Tabelle zu bauen. Das Problem: Ich entwickle eine iOS-App in Swift. Die KI hatte den Kontext komplett vergessen und „halluzinierte“ eine völlig unnötige Komplexität herbei. Sie zauberte“ auf einmal neue Lösungswege für Problemstellungen herbei, die sie einen Tag zuvor auf andere Weise umgesetzt hatte. Sie behauptete, bestimmte Dinge nicht zu können, obwohl sie Minuten zuvor das Gleiche bereits ausgeführt hatte.

Warum führt das Streben nach 100% KI-Abdeckung oft direkt vom Rausch in den Kater? Folgender Blick spiegeln meine rein subjektiven Erfahrungen in dieser kleinen App-Entwicklung wider und soll ein wenig das „KI-Produktivitäts-Paradoxon“ aufzeigen. Und um es vorweg zu nehmen: ja, ich werde auch weiterhin auf KI setzen, weil ich denke, dass die Fähigkeiten besser werden und weil alles in allem die Produktivität gestiegen ist. Allerdings werde ich meine Arbeitsweise anpassen und bisher gerne vernachlässigte Punkte in der Entwicklung stärken. Daher hier der aktuelle Blick (Stand Dezember 2025) auf das aktuelle „KI-Produktivitäts-Paradoxon“  mit dem Wissen, dass dieses in einem Jahr vermutlich veraltet sein wird.

Das Paradoxon: Geschwindigkeit vs. Qualität

Wenn ich meine Erfahrung in eine Grafik übersetze, sehe ich keine stetig steigende Kurve, wie sie uns das Marketing der Tool-Hersteller oft verkauft. Ich sehe drei Bewegungen, die genau dieses „Silvester-Phänomen“ beschreiben:

Der trügerische Raketenstart (Erfüllungsgrad):

Zu Beginn erledigt die KI die „Low Hanging Fruits“ (Boilerplate, Standard-Klassen u.a.) rasend schnell. Das ist die Phase der reinen Begeisterung. Der Erfüllungsgrad schießt nach oben, die App fühlt sich nach zwei Tagen zu 80% fertig an. Das ist die Täuschung. Die letzten 20% – komplexe Business-Logik und Architektur – lassen sich nicht „generieren“. Hier beginnt der Motor zu stottern.

Der Geschwindigkeits-Kater (Velocity):

Anfangs ist das Tempo phänomenal. Doch mit der Zeit sank meine Geschwindigkeit unter das Niveau, das ich ohne KI gehabt hätte. Warum? Ich programmierte nicht mehr, ich korrigierte nur noch. Ich wurde vom Entwickler zum dauerbeschäftigten Lektor, der absurde Vorschläge (siehe Python-Script) einfangen musste oder verbrachte mehr Zeit damit, der KI den Kontext zu erklären, den sie über Nacht „vergessen“ hatte.

Die schleichende Fehler-Explosion:

Das Tückische ist, dass die Fehlerquote anfangs gering wirkt. Die KI beherrscht die Syntax perfekt; der Code kompiliert meistens. Doch unter der Haube wachsen die logischen Inkonsistenzen. Da die KI oft das „große Ganze“ der Architektur nicht sieht (oder aufgrund begrenzter Kontext-Fenster vergisst), produziert sie Lösungen, die isoliert funktionieren, aber im Zusammenspiel Chaos verursachen. Wir häufen „technische Schulden“ in Lichtgeschwindigkeit an – und die Rechnung dafür kommt erst ganz am Schluss, wenn wir versuchen, die Einzelteile zu einem stabilen Ganzen zu fügen.

Das Ergebnis: Wir starten als Rennwagen und enden als Schnecke, die mühsam einen Berg aus technischen Schulden und Logikfehlern erklimmen muss.

Die Probleme: Warum wir an Fahrt verlieren

Ich dachte erst: es liegt an mir und nicht an ihr. Doch aktuelle Daten bestätigen das Phänomen. Ich bin nicht allein. Das Phänomen ist systemisch und messbar.

1. Code Churn: Wir schreiben viel, wir löschen viel

Was ich in meiner kleinen App erlebt habe – dass die KI Code produziert, den ich kurz darauf wieder verwerfen oder massiv umschreiben muss – hat einen Namen: "Code Churn“. Eine umfassende Analyse von GitClear, die über 150 Millionen Zeilen Code untersuchte, schlug bereits Alarm: Der Anteil an Code, der weniger als zwei Wochen nach Erstellung wieder gelöscht oder ersetzt wird, steigt massiv an.

https://www.gitclear.com/ai_assistant_code_quality_2025_research

https://arc.dev/talent-blog/impact-of-ai-on-code/

Für mich fühlte es sich produktiv an, weil ich ständig neuen Code sah. Aber faktisch habe ich oft nur „digitale Wegwerfware“ produziert. Die KI beherrscht zwar die Syntax (die Grammatik), aber sie verliert den Faden bei der Semantik (dem Sinn).

2. Kontext-Erosion: Die KI hat einen Tunnelblick.

Mein Erlebnis mit dem Python-Script in einer reinen Swift-Umgebung ist das perfekte Beispiel für das, was Experten als „Kontext-Erosion“ bezeichnen. Die KI „sieht“ oft nur das aktuelle Fenster oder die Datei, an der wir gerade arbeiten (und diese häufig nicht vollständig, wenn zu viele Zeilen Code vorhanden sind). Sie versteht nicht zwingend die impliziten Architektur-Entscheidungen, die ich drei Tage vorher getroffen habe.

Je größer mein Projekt (und meine Code-Basis) wurde, desto öfter halluzinierte die KI Lösungen, die isoliert betrachtet korrekt waren, aber im Gesamtgefüge des Projekts keinen Sinn ergaben. Sie optimierte das Detail und zerstörte dabei das Ganze.

3. Der DORA-Blindflug: Hoher Output, sinkende Stabilität

Auch der renommierte DORA-Report (DevOps Research and Assessment) warnt vor diesem Trugschluss. Die Studien zeigen zwar, dass KI-Tools die individuelle Coding-Geschwindigkeit und die Jobzufriedenheit steigern können, aber: Diese lokale Effizienz übersetzt sich nicht automatisch in bessere Software.

https://getdx.com/blog/2024-dora-report/

https://newsletter.getdx.com/p/2024-dora-report

Im Gegenteil: Wenn wir die Geschwindigkeit (Velocity) erhöhen, ohne die Qualitätskontrollen anzupassen, riskieren wir eine Verschlechterung der „Change Failure Rate“. Für Führungskräfte und Entwickler entsteht so ein gefährlicher Blindflug: Die Dashboards zeigen grünes Licht („Wir haben heute 1000 Zeilen Code committed!“), während die tatsächliche Produktivität – also funktionierende Features beim Nutzer – stagniert oder sinkt, weil wir im Hintergrund technische Schulden abtragen müssen.

Die Lösung: 3 Strategien gegen den Knick

Wie verhindern wir also, dass die Fehlerkurve explodiert und wir am Ende nur noch Scherben aufkehren? Für mein Projekt und meine zukünftige Arbeit habe ich drei wesentliche „Leitplanken“ eingezogen. Sie sind das Aspirin gegen den KI-Kater:

1. Vom Passagier zum Piloten (Mindset-Shift) 

Ein Fehler war die Erwartungshaltung. Ich habe mich zu oft zurückgelehnt und die KI „machen lassen“. Aber KI ist kein Senior Developer, der das Projekt allein steuert; sie ist ein extrem schneller, aber etwas naiver Junior.

Ich habe gelernt: „Ich muss der Architekt bleiben.“ Bevor die KI eine Zeile Code schreibt, definieren wir (ich!) die Struktur. Ich nutze die KI jetzt als Sparringspartner für den Entwurf („Kritisiere meinen Ansatz für das Datenbank-Modell“), aber nicht mehr als alleinigen Bauleiter. Ein striktes „Human-in-the-Loop“-Prinzip bei Entscheidungen über die Architektur ist nicht verhandelbar.

2. Context is King (Manuelles RAG) 

Das Problem mit dem halluzinierten Python-Script passierte, weil die KI den Kontext („Wir sind in einem reinen Swift-iOS-Projekt“) vergessen hatte. Meine Lösung: Ich füttere die KI proaktiv.

In meinem Projekt gibt es nun dedizierte Dateien (z. B. eine "bestPractice.md", eine "todo.md" und "Protokoll.md"), die ich der KI bei komplexen Anfragen und jedem neuen Dialog explizit mitgebe. Quasi Pflichtdokumente für jeden Arbeitsauftrag. Das ist eine manuelle Form von RAG (Retrieval-Augmented Generation). Darin steht klipp und klar: „Nutze keine externen Skripte, bleibe in Swift, beachte diese Architektur-Pattern, usw.“ Seitdem ich die KI zwinge, erst diese „Hausregeln“ zu lesen, bevor sie codet, ist die Qualität der Vorschläge massiv gestiegen.

3. TDAI: Test-Driven AI Development 

Häufig habe ich Tests vernachlässigt („Code steht, ich lese und habe ihn verstanden, brauche keinen Test“). Jetzt drehe ich den Spieß um: „Erst der Test, dann der KI-Code.“

Ich lasse die KI (oder schreibe es selbst) zuerst einen Unit-Test für die gewünschte Funktion erstellen. Erst wenn dieser Test steht, darf die KI den eigentlichen Code generieren, um den Test „grün“ zu machen. Hätte ich das von Anfang an konsequent gemacht, wäre der Logik-Fehler in meiner Standort-Berechnung sofort aufgefallen, bevor er sich tief in drei andere Klassen gefressen hätte. Tests sind die härteste Währung gegen die schleichende Fehler-Explosion.

Fazit: Dauerlauf statt Sprint

Klingt das alles nach Ernüchterung? Vielleicht. Aber es ist eine gesunde Ernüchterung. Denn trotz aller Warnsignale und dem Kater nach der anfänglichen Euphorie: Ich möchte nicht mehr ohne KI entwickeln. Der Einsatz ist für mich alternativlos – aber eben nicht mehr als blindes Vollgas, sondern als kontrolliertes Fahren.

Wenn man die Kurven kennt und die Leitplanken installiert hat, bleibt ein enormer Gewinn:

Befreiung von der Routine: Auch wenn ich die Architektur streng kontrolliere – die KI schreibt mir immer noch den Boilerplate-Code, die JSON-Parser, die Unit-Test-Gerüste uvm. in Sekunden. Zeit, die ich früher mit Tippen verbracht habe, kann ich jetzt in das Durchdenken der App-Features, Logik und in die Architektur stecken.

Schnelleres Verstehen: Ironischerweise hilft mir die KI oft genau da, wo sie Probleme verursacht: beim Verstehen von komplexem Code. Wenn ich nach zwei Tagen Pause in mein Projekt zurückkehre, lasse ich mir von der KI zusammenfassen, was eine bestimmte Klasse eigentlich tut. Das ist der perfekte „Onboarding-Buddy“ für mein eigenes Gehirn.

Höhere Resilienz durch Tests: Da ich gezwungen bin, mehr Tests zu schreiben (um die KI zu kontrollieren), ist meine Codebasis am Ende stabiler als meine früheren Projekte ohne KI – nicht wegen der KI-Codequalität, sondern wegen der Sicherheitsnetze, die ich wegen ihr spannen musste. Allerdings könnte man hier einwenden, dass die Tests doch sowieso schon immer dabei sein sollten. Ja, genau 😉

Der Weg zur produktiven KI-Entwicklung ist kein 100-Meter-Sprint, bei dem man einfach die Rakete zündet und hofft, im Ziel anzukommen. Es ist ein strategischer Dauerlauf. Wer nur auf das Anfangstempo schaut, wird auf halber Strecke mit Seitenstechen liegen bleiben.

Meine Lektion aus meinem kleinen Projekt: Das Silvester-Feuerwerk ist schön anzusehen, aber echte Software-Qualität entsteht am Morgen danach – wenn man mit klarem Kopf, einer guten Tasse Kaffee und einem soliden Plan die Arbeit macht. Wer Qualität und Kontext von Anfang an mit plant, macht aus dem anfänglichen Rausch einen echten, nachhaltigen Vorsprung.

Und was bleibt noch? Hoffentlich eine App, die bald im App-Store zu finden ist. Ich arbeite noch (kontrolliert) daran. 😉