Link kopiert!

Die große Software-Stagnation: Warum sich Apps im Jahr 2025 kaputt anfühlen

Software fühlt sich fehlerhafter an, weil er es ist. Neue Daten zeigen, wie KI-Codierungsassistenten, schnelle Release-Zyklen und der Tod der Qualitätssicherung eine versteckte technische Schuldenkrise verursachen.

🌐
Automatische Übersetzung

Dieser Artikel wurde automatisch aus dem englischen Original übersetzt. Zum englischen Original

Eine digitale abstrakte Darstellung von frakturierenden Codeblöcken und fehlerhaften Schnittstellen.

Sie entsperren Ihr Telefon, um einen Flug zu überprüfen, aber die App bleibt auf einem weißen Bildschirm hängen. Sie klicken auf einer Website auf „Jetzt kaufen“ und die Schaltfläche wird grau, aber es passiert nichts. Sie versuchen, Ihre intelligente Glühbirne zu koppeln, und es erfordert ein Firmware-Update, das dreimal fehlschlägt.

Wenn Sie das Gefühl haben, dass die Technologie fragiler wird, dann bilden Sie sich das nicht ein.

Im letzten Jahrzehnt hat die Technologiebranche nach dem Mantra „Beweg dich schnell und mach Dinge kaputt“ operiert. Im Jahr 2025 ermitteln unabhängige Analysten endlich die Kosten der kaputten Dinge. Während die Hardware exponentiell schneller und zuverlässiger geworden ist, ist das iPhone 17 ein Wunder der Physik, die darauf laufende Software fühlt sich zunehmend durch Klebeband und Gebete zusammengehalten.

Das ist nicht nur Nostalgie für ein „goldenes Zeitalter“, das es nie gab. Es handelt sich um einen messbaren statistischen Trend. Neue Daten großer Code-Analyseunternehmen zeigen ein beunruhigendes Muster: Da der Codierungsprozess zunehmend automatisiert wird, nimmt die strukturelle Integrität von Systemen ab. Der Markt baut digitale Wolkenkratzer auf Sandfundamenten, und die ersten Risse zeigen sich.

Advertisement

Die Entropie der Geschwindigkeit

Das grundlegende Problem ist eine Verschiebung in der Ökonomie der Softwarebereitstellung. Vor zwanzig Jahren war der Versand von Software ein physischer Akt. Sie haben ein „Gold Master“ auf eine CD-ROM oder DVD gepresst, es in eine Schachtel gesteckt und per Lastwagen zu einem Geschäft transportiert. Wenn diese CD einen kritischen Fehler aufwies, waren die Rückrufkosten astronomisch. Qualitätssicherung (QA) war kein Luxus; Es war eine existenzielle Notwendigkeit für das Unternehmen.

Heute ist die Lieferreibung gleich Null. Mit Over-The-Air (OTA)-Updates und Continuous Integration/Continuous Deployment (CI/CD)-Pipelines kann ein Entwickler innerhalb von Minuten Code an Millionen von Benutzern weitergeben. Dadurch wurde das Risiko effektiv vom Anbieter auf den Benutzer übertragen.

Warum sollten Sie für ein dediziertes QA-Team bezahlen, wenn Sie Ihre ersten 1 Million Benutzer als Betatester behandeln können?

Diese Philosophie, die in DevOps-Kreisen oft als „Shift Left“ bezeichnet wird (was impliziert, dass Tests früher von Entwicklern durchgeführt werden sollten), hat paradoxerweise zu Situationen geführt, in denen niemand wirklich auf „Benutzerebene“ testet. Entwickler testen ihre spezifischen Funktionen (Unit-Tests), aber die komplexen Interaktionen zwischen Tausenden von Microservices, der „Integrationsschicht“, werden dem Zufall überlassen.

Doch im Jahr 2025 wird diesem Feuer ein neuer Beschleuniger hinzugefügt: Künstliche Intelligenz.

Das AI-Code-Qualitätsparadoxon

Das Versprechen von KI-Codierungsassistenten wie GitHub Copilot, Cursor und Googles eigenen Tools war eine Produktivitätsrevolution. Und sie haben dieses Versprechen gehalten. Entwickler schreiben Code 50 % schneller als noch vor drei Jahren.

Aber das Schreiben von Code war nie der Engpass. Lesen und Pflege war es.

Aktuelle Daten von GitClear, die über 150 Millionen Codezeilen analysiert haben, die zwischen 2023 und 2025 geändert wurden, zeichnen ein besorgniserregendes Bild. Sie fanden heraus, dass die „Code-Abwanderung“ (der Prozentsatz des Codes, der geschrieben und kurz danach gelöscht oder neu geschrieben wird) sprunghaft angestiegen ist, während die „Code-Wiederverwendung“ stark zurückgegangen ist.

Der „Shotgun Coding“-Effekt

KI-Modelle sind probabilistische Motoren. Sie sagen den nächstwahrscheinlichsten Token voraus. Wenn ein Entwickler eine KI bittet, „eine Funktion zum Parsen dieses Datums zu schreiben“, generiert die KI eine brandneue, maßgeschneiderte Funktion. Es weiß nicht, dass in der gemeinsam genutzten Bibliothek des Unternehmens drei Ordner weiter oben bereits ein einwandfreier Datumsparser vorhanden ist.

Advertisement

Das Ergebnis ist eine Codebasis voller Tausender doppelter, leicht unterschiedlicher Implementierungen derselben Logik. Dies verstößt gegen das „DRY“-Prinzip (Don’t Repeat Yourself), eines der heiligen Gesetze der Softwareentwicklung. Wenn bei der Datumsanalyse ein Fehler gefunden wird, beheben Sie ihn an einer Stelle, die 50 anderen KI-generierten Versionen bleiben jedoch fehlerhaft.

Die Branche erlebt einen massiven Anstieg der Codebasisgröße, ohne dass die Funktionalität entsprechend zunimmt. Eine einfache App, die früher aus 10.000 Codezeilen bestand, besteht heute aus 50.000 Zeilen, nicht weil sie mehr kann, sondern weil sie mit KI-generierten Boilerplates aufgebläht ist.

Die Illusion der Korrektheit

Das zweite Problem ist die „Brüchigkeit“ des synthetischen Codes. Generative Systeme beherrschen die Syntax (die Grammatik des Codes) hervorragend, haben aber Probleme mit der Semantik (der Bedeutung des Codes). Sie produzieren Code, der perfekt aussieht. Es lässt sich kompilieren und ausführen, kann jedoch häufig Randfälle oder seltene Fehlerzustände nicht verarbeiten.

Ein menschlicher Entwickler, der ein Zahlungsverarbeitungssystem schreibt, stellt sich die Frage: „Was passiert, wenn das Netzwerk direkt nach der Belastung der Karte, aber vor der Erfassung der Bestellung ausfällt?“ Sie schreiben Code, um diesen Transaktionsstatus zu verarbeiten. Sofern eine KI nicht ausdrücklich dazu aufgefordert wird, wählt sie häufig standardmäßig den „Happy Path“. Es wird davon ausgegangen, dass alles funktioniert.

Dies führt zu „Heisenbugs“, Fehlern, die verschwinden oder sich verändern, wenn Sie versuchen, sie zu untersuchen, häufig verursacht durch Rennbedingungen und unbehandelte Zustände, die nur unter Last auftreten.

Die Todesspirale der Microservices

Parallel zum KI-Boom findet ein architektonischer Wandel hin zu Microservices statt. Anstelle einer großen Anwendung (einem „Monolithen“) bestehen moderne Apps aus Hunderten kleiner, unabhängiger Dienste, die über ein Netzwerk miteinander kommunizieren.

Auf dem Papier ist das großartig. Es ermöglicht Teams, unabhängig zu arbeiten. In der Praxis verwandelt es jeden Funktionsaufruf in eine Netzwerkanforderung, die fehlschlagen kann.

In einer monolithischen App ruft Funktion A Funktion B auf. Es funktioniert 100 % der Zeit, da sie sich im selben Speicherbereich befinden. In einer Microservices-App sendet Dienst A ein JSON-Paket an Dienst B.

  • Das Netzwerk ist möglicherweise langsam.
  • Dienst B wird möglicherweise neu gestartet.
  • Das JSON-Format hat sich möglicherweise geringfügig geändert.

Die Komplexität dieser Interaktionen wächst exponentiell und nicht linear. Wenn Sie 10 Dienste haben, haben Sie 45 mögliche Verbindungspaare. Wenn Sie 100 Dienste haben, haben Sie 4.950. Viele moderne Unternehmensanwendungen verfügen über Tausende.

Advertisement

Ingenieure haben Systeme gebaut, die über das kognitive Verständnis eines einzelnen Menschen hinausgehen. Niemand weiß mehr, wie das Ganze funktioniert. Wenn etwas kaputt geht, ist das Debuggen kein logischer Schlussfolgerungsprozess; Es handelt sich um eine archäologische Ausgrabung durch verteilte Baumstämme.

Die Regression der Benutzererfahrung

Wie äußert sich das für Sie als Benutzer?

  1. Das sich drehende Rad: Da Apps bei jeder Interaktion mehr auf den Echtzeit-Datenabruf angewiesen sind, ist die Benutzeroberfläche von der Netzwerkstabilität abhängig.
  2. Der allgemeine Fehler „Etwas ist schief gelaufen“: Da die Fehlerbehandlung in verteilten Systemen komplex ist, geben Apps häufig standardmäßig eine generische „Catch-All“-Fehlermeldung aus, die Ihnen nichts sagt.
  3. Feature Rot: Funktionen, die früher funktionierten, hörten plötzlich auf oder funktionierten unregelmäßig, weil eine drei Ebenen tiefe Abhängigkeit aktualisiert wurde und niemand die Kompatibilität überprüfte.

Das Ökosystem tritt in eine Ära der „probabilistischen Software“ ein. Es funktioniert wahrscheinlich. Die meiste Zeit.

Der Ausweg: Zuverlässigkeit als Merkmal

Das Pendel beginnt zurückzuschwingen. In der B2B-Welt erkennen Unternehmen, dass „5 Neunen“ (99,999 % Verfügbarkeit) ein Wettbewerbsvorteil sind, für den es sich zu zahlen lohnt.

Auf dem Markt entstehen „Platform Engineering“-Teams, spezialisierte Gruppen, deren einzige Aufgabe darin besteht, diese Komplexität zu bändigen. Sie bauen interne Entwicklerplattformen auf, die die Standardisierung durchsetzen und die KI-Assistenten im Wesentlichen dazu zwingen, die genehmigten Bibliotheken zu verwenden, anstatt neue zu halluzinieren.

Darüber hinaus entsteht eine neue Generation von „Agentic QA“-Tools. Wenn KI das Problem ist, könnte sie auch die Lösung sein. Neue autonome Testagenten können wie ein menschlicher Benutzer durch Apps navigieren, auf Schaltflächen klicken, Formulare ausfüllen und Fehler rund um die Uhr melden. Im Gegensatz zu den fragilen automatisierten Tests der Vergangenheit „sehen“ diese Agenten den Bildschirm und können erkennen, wenn eine Schaltfläche defekt ist, selbst wenn der Code besagt, dass sie funktionieren sollte.

Das Urteil

Software fühlt sich fehlerhafter an, weil die Branche fünfzehn Jahre lang Geschwindigkeit über Stabilität gestellt hat. Technologieunternehmen gaben jedem Entwickler einen Ferrari-Motor (KI), entfernten aber die Bremsen (QA). Entwicklungsteams geraten derzeit an die Leitplanken.

Die nächsten großen Technologieunternehmen werden nicht diejenigen sein, die die meisten Funktionen bieten. Sie werden diejenigen sein, deren Software einfach und leise funktioniert. In einer Welt des digitalen Chaos ist Zuverlässigkeit der ultimative Luxus.

Bis dahin möchten Sie diese Seite möglicherweise weiterhin aktualisieren. Beim zweiten Mal klappt es vielleicht. Wahrscheinlich.

Quellen

Advertisement

🦋 Diskussion auf Bluesky

Auf Bluesky diskutieren

Beiträge werden gesucht...