Vor Kurzem musste ich ein Excel-basiertes Werkzeug in etwas Robusteres überführen und entschied mich, mit Hilfe von Claude Opus eine React.js-Anwendung zu bauen. In weniger als vier Stunden hatte ich eine einwandfrei funktionierende Webanwendung, allein auf Basis von Claudes Analyse der Excel-Struktur und -Inhalte. Ich war natürlich überglücklich und lobte ein Werkzeug, das mir etwas ermöglichte, das mich mindestens 10.000 Dollar gekostet hätte, wenn ich einen Offshore-Entwickler beauftragt hätte – die vielen Stunden Hin und Her beim Debuggen nicht mitgerechnet.

Die folgenden zwei Tage jedoch verbrachte ich damit, Claude Opus durch das Debuggen der Positionierung von Kopf- und Fußzeilen in der PDF-Ausgabe dieses neuen Werkzeugs zu lotsen. Ich war frustriert und drauf und dran, das Handtuch zu werfen. Hätte ich es selbst gemacht oder einen Freiberufler beauftragt, wäre es in höchstens einer halben Stunde erledigt gewesen.

Seit ich KI zur Softwareentwicklung einsetze, gehört dieses Auf und Ab fest zu meinem Alltag.

Was ich hier auseinandernehmen möchte, ist, warum die Erfahrung so heftig zwischen Wunder und Elend schwankt – denn die Gründe sind struktureller Natur und kein Pech – und was sich tatsächlich ändert, sobald man aufhört zu erwarten, dass sich das Werkzeug wie ein verlässlicher Kollege verhält, und beginnt, es als das zu behandeln, was es ist.

Das Wunder ist echt – und das Elend auch

Beginnen wir mit der guten Hälfte meiner Geschichte, denn sie abzutun wäre ein Fehler. Der Vier-Stunden-React-Build war kein Zufallstreffer und kein Spielzeug. Die KI senkt die Kosten genau jener Arbeit dramatisch, die die meisten Entwickler als mühsam empfinden: eine unbekannte Datenstruktur lesen, eine Anwendung aufsetzen, Standardgerüst verdrahten, Absicht in einen ersten lauffähigen Entwurf übersetzen. In diesem Modus ist sie nicht ein bisschen schneller als ein Mensch – sie ist um eine Größenordnung schneller und oft billiger, als man recht glauben mag.

KI bringt dich zu 80 % zum MVP; die letzten 20 % erfordern Geduld, tiefes Lernen oder die Einstellung von Ingenieuren.

Addy Osmani, Director Google Cloud AI, 2026

Was das Wunder des schnellen Erfolgs einem still beibringt: zu vertrauen. Und die zähen zwei Tage, um etwas scheinbar Offensichtliches zu beheben (die Größe eines Logos und seine Platzierung), sind nicht der schlimmste Mangel. Ich erinnere mich an Tage, an denen ich nach einem guten Lauf unaufmerksam war und das KI-Modell mehr zerstörte als reparierte, indem es Abkürzungen nahm, Fehler kaschierte und aufgeblähten Code mit Flickwerk über Flickwerk erzeugte. Das Ergebnis: Ich nahm sämtliche Änderungen dieses Tages zurück und akzeptierte zähneknirschend, dass viel Arbeit vergeudet war.

In all diesen Fällen wurden die Ergebnisse mit Überzeugung präsentiert, und nur meine Prüfung verhinderte, dass sie in die Codebasis durchsickerten. „Jetzt habe ich das vollständige Bild“ ist nur einer der berühmten irreführenden Sätze eines KI-Modells, der Sicherheit suggeriert, wo keine ist.

Das Erste, was man verinnerlichen sollte: Hoch und Tief sind keine getrennten Erfahrungen. Das Hoch schafft die Bedingungen für das Tief. Je reibungsloser die frühen Erfolge, desto weniger prüft man – und desto härter trifft die Wand am Ende.

Der Kern des Problems: Nichts an KI-Ausgaben ist stabil

Um die Ausschläge zu verstehen, müssen Sie die Intuition fallen lassen, Sie arbeiteten mit einem Kollegen von gleichbleibendem Können. Das tun Sie nicht.

Ein großes Sprachmodell hat keine feste Kompetenz, wie ein Mensch sie hat. Jede Antwort wird neu erzeugt, geformt von einer Kaskade probabilistischer Entscheidungen über den Kontext, den es gerade hält. Dasselbe Modell kann beim selben Problem in einer Sitzung eine elegante Lösung finden und sich in der nächsten durch zehn fehlerhafte Versuche quälen – nicht weil es weniger „weiß“, sondern weil diese Ziehung anders ausgegangen ist. Die sprachliche Flüssigkeit bleibt gleich, ob es auf festem Boden steht oder improvisiert; die Verlässlichkeit darunter nicht.

KI ist dort am verlässlichsten, wo ihre Trainingsdaten am dichtesten sind: gängige Frameworks, verbreitete Bibliotheken, ausgetretene Muster. Sobald weniger Wissen verfügbar ist, verschiebt sich die Ausgabe stillschweigend vom Erinnern zum Erfinden. Das allgemeine React-Gerüst sitzt im dichten Zentrum dessen, was das Modell millionenfach gesehen hat, der PDF-Formatierungsfehler in der dünn besiedelten Peripherie. Das ist kein Zufall, sondern das Muster. Die Aufgaben, die Ihnen klein vorkommen, liegen oft genau dort, wo das Modell am schwächsten ist.

Kein Tag ist wie der andere

Das Modell selbst ist ein bewegliches Ziel. Man könnte annehmen, die Wahl eines bestimmten Modells fixiere eine bekannte Größe. Tut sie nicht. Anbieter betreiben Serverflotten mit unterschiedlicher Hardware und unterschiedlichen Quantisierungsstufen und ändern stillschweigend Routing, voreingestellte Denktiefe, Systemprompts und Caching. Zwischen März und April 2026 meldete eine Welle von Entwicklern, dass Claudes Sonnet- und Opus-Modelle spürbar schlechter geworden seien – eine Entwicklungsleiterin wertete 6.852 eigene Sitzungen und über 234.000 Werkzeugaufrufe aus und zeigte, wie die Denktiefe des Modells einbrach – und die Nachbetrachtung des Anbieters bestätigte reale Ursachen: eine Änderung, die die voreingestellte Denktiefe senkte (später zurückgenommen), ein Fehler in der Sitzungsverwaltung, der das Modell vergesslich und redundant machte, und eine Prompt-Anpassung zur Kürzung der Wortfülle, die die Antworten verschlechterte. Die Gewichte waren nicht verrottet – Modelle und API waren nachweislich unbeeinträchtigt –, doch die Erfahrung verschlechterte sich tatsächlich, aus Gründen, die kein Nutzer sehen konnte. Ein Teil eines „schlechten Tages“ hat also womöglich nichts mit Ihnen und Ihren Prompts zu tun.

Unter diesem Blickwinkel wirkt die Schwankung nicht mehr wie Pech. Sie ist das erwartbare Verhalten eines probabilistischen Systems, dessen Verlässlichkeit ungleich verteilt ist und dessen Infrastruktur sich täglich verschiebt.

Die Zahlen hinter dem Programmieren mit KI

Die Ungleichmäßigkeit ist messbar. KI ist messbar gut in der Routineschicht des Programmierens – und messbar schlechter als Menschen in der tiefen Schicht. Beginnen wir mit der guten Hälfte, denn sie ist real. Eine Apiiro-Analyse KI-gestützter Entwicklung in großen Unternehmen fand, dass die Werkzeuge die üblichen Fehlerarten deutlich senken: einfache Syntaxfehler gingen um rund drei Viertel zurück, gewöhnliche Logikfehler um etwa 60 %. Die KI verringert den Schmerz tatsächlich.

Eine Ebene tiefer kehrt sich das Bild um. Ein paar Zahlen dazu:

In Veracodes GenAI Code Security Report 2025, der über hundert Modelle standardisierte Sicherheitsaufgaben lösen ließ, führten rund 45 % der erzeugten Codebeispiele eine Schwachstelle aus den OWASP Top 10 ein – den häufigsten, am besten dokumentierten Web-Schwachstellen überhaupt, etwa SQL-Injection und Cross-Site-Scripting. Das sind keine exotischen Grenzfälle, von denen das Modell nichts wissen konnte; es sind die Fehler, die jeder Sicherheitskurs zuerst behandelt. Die Schwäche häufte sich zudem nach Sprache: Java-Code fiel etwa sieben von zehn Mal durch.

Zweitens bessert sich das nicht von allein. Als Veracode die Übung für das Update im März 2026 wiederholte, hatte sich die Bestehensquote kaum bewegt – sie pendelte um 55 %, während dieselben Modelle in Benchmarks zur Programmierfähigkeit immer höhere Werte erzielten. Diese Lücke ist die wichtigste Zahl überhaupt: Die Modelle wurden sichtbar besser im Programmieren und blieben zugleich beim Schreiben sicheren Codes auf der Stelle. Fähigkeit und Sicherheit sind nicht dieselbe Achse, und nur eine davon stieg.

Drittens: was sich daraus aufsummiert. Eine Analyse von 2026 untersuchte KI-verfasste Commits über Tausende öffentlicher Repositories und verfolgte, wie viele ungelöste technische Schulden über die Zeit in der Codebasis überdauerten – von einigen Hundert verbliebenen Problemen Anfang 2025 auf Hunderttausende binnen etwa eines Jahres. Das sind die langsamen Kosten, die man an keinem einzelnen guten Tag spürt: schnell erzeugte Menge, während die tieferen Probleme still liegen bleiben.

Unter allen dreien liegt eine menschliche Zahl, die diesen Abschnitt mit dem Rest des Textes verbindet. Laut einer Branchenumfrage von 2026 gaben 58 % der Entwickler an, KI-Ausgaben ohne Test zu vertrauen. Das ist der Mechanismus, über den die obigen Befunde tatsächlich in die Produktion gelangen. Die Defekte sind nur die halbe Miete; die fehlgeleitete Zuversicht ist die andere Hälfte.

Quellen: Apiiro-Analyse von Unternehmenscode, 2026 (Rückgang der Routinefehler); Veracode GenAI Code Security Report 2025 und dessen Update von März 2026 (OWASP-Schwachstellen und Bestehensquoten); eine Analyse KI-verfasster Commits über öffentliche Repositories, 2026 (Aufbau technischer Schulden); Entwicklerumfrage 2026 (Vertrauen ohne Test). Die Zahlen sind Näherungswerte, und die Methodik unterscheidet sich zwischen den Studien.

Drei Arten, mit KI zu programmieren

Wenn Entwickler auf diese Schwankungen stoßen, sehen wir drei Reaktionen. Nur eine davon ist tragfähig.

Wenn ich mit KI programmiere, erwarte ich keine ruhige Fahrt mehr, und diese eine Anpassung hat mein Verhältnis zu diesen Werkzeugen mehr verändert als jede Prompt-Technik. Das Vier-Stunden-Wunder und der zweitägige Formatierungsfehler sind nicht die gute und die schlechte Version des Werkzeugs. Sie sind dasselbe Werkzeug, das sich genau so verhält, wie sich ein sprachlich flüssiges, probabilistisches, unbeständiges System verhält – großartig im dichten Zentrum, flach an den Rändern und die ganze Zeit still unter einem in Bewegung.

Die Entwickler, die mit KI aufblühen, sind nicht jene, die das perfekte Modell oder den magischen Prompt gefunden haben. Es sind jene, die aufgehört haben, sich über den Ausschlag zu wundern, die Hände am Steuer behalten und gelernt haben, das Ding an guten wie an schlechten Tagen zu fliegen.