Wenn das Coden gelöst ist, warum wird Software dann immer schlechter?

 (ptrchm.com)
1 Punkte von GN⁺ 5 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • AI-Tools haben die Entwicklungsproduktivität und die Fähigkeiten von Teams gesteigert, aber Softwarequalität und Stabilität haben sich nicht in gleichem Maß verbessert, sodass Nutzer nach Updates eher mit einer schlechteren Erfahrung rechnen
  • Wiederholte FaceID-Anmeldungen in Banking-Apps, von Slack gestohlener Fokus, fehlgeschlagene Garantieanträge bei LG, Fehler in Infotainmentsystemen im Auto und mehr stören alltägliche Abläufe in Finanzen, Arbeit, Kundensupport und beim Fahren
  • Anders als in der einfacheren Vergangenheit haben sich neue Abstraktionen, Frontend-Frameworks und Infrastrukturkomplexität angesammelt; zusammen mit gestiegenen Ansprüchen an die User Experience werden Systeme zunehmend fragiler
  • Selbst mit aktuellen Modellen und ausreichendem Token-Budget ist es schwer, mit Stabilitätsverbesserungen in KPIs oder Präsentationen aufzufallen, daher priorisieren Unternehmen statt Bugfixes neue Funktionen und Redesigns
  • Während Unternehmen AI-Schulden aufbauen, können einzelne Entwickler Software angehen, die früher außerhalb ihrer Möglichkeiten lag, und der Wunsch nach besserer Alltagssoftware könnte sich über die Gegenbewegung zu macOS und Windows hinaus ausbreiten

Schlechtere User Experience selbst im AI-Zeitalter

  • Im AI-Boom verbrauchen Menschen übermäßig viele Tokens, um noch Marktwert aufzubauen, bevor alles automatisiert wird
    • Verbesserte Modellleistung, aufeinanderfolgende Entlassungen von Programmierern und Prognosen, dass AI bis Jahresende 100 % des Codes schreiben werde, verstärken die Unruhe
  • Das Zeitalter der Agenten verspricht höhere Produktivität und Qualität
    • Neue Tools haben die Art, wie Software erstellt und genutzt wird, bereits verändert
    • Führungskräfte verlangen von Teams mehr Output, und das durchschnittliche Leistungsniveau von Softwareteams könnte auf ein anderes Niveau als früher gestiegen sein
  • Doch reale Produkte sichern oft nicht einmal grundlegende Stabilität
    • Eine Banking-App verlangt im Schnitt dreimal FaceID-Login, bis der 3D-Secure-Bestätigungsbildschirm erscheint
    • Slack für macOS öffnet sich verspätet und stiehlt Ghostty den Fokus, sodass der im Terminal eingegebene Befehl git pull in einem Gruppenchat landet
    • Der Garantieantrag für einen LG-Kühlschrank scheiterte im letzten Absende-Schritt eines mehrstufigen Formulars mit unzähligen Feldern, und der Fehler war nur nach Blick in die JavaScript-Konsole erkennbar
    • Das Infotainmentsystem im Auto startete nach einem Update bei jeder Fahrt neu, Blinkertöne verschwanden, statt Google Maps öffnete sich das Radio, und Eingaben auf dem Bildschirm verzögerten sich jeweils um 1 bis 2 Sekunden
    • Fehler im Auto sind mehr als bloße UX-Unannehmlichkeiten und beeinträchtigen sogar die Konzentration beim Fahren
  • Der PM des Teams für das Redesign des Auto-OS feierte das Ergebnis auf LinkedIn, während reale Nutzer weiter mit dem Produkt kämpfen mussten
  • Diese Teams nutzen vermutlich aktuelle Modelle und großzügige Token-Budgets, und auch LLMs können bei Bugfixes hervorragende Leistungen zeigen, wenn man ihnen die Gelegenheit gibt

Wie Komplexität und KPIs Qualität verdrängen

  • Software hatte schon immer Bugs, und die Nostalgie dafür, dass macOS Snow Leopard völlig stabil gewesen sei, enthält selektive Erinnerung
    • Wenn Software früher besser war, dann vor allem deshalb, weil sie viel einfacher war als heute
    • Danach kamen neue Abstraktionen, Frontend-Frameworks und mehr Infrastrukturkomplexität hinzu
    • Die Ansprüche an die User Experience sind weiter gestiegen, doch das Gesamtsystem ist stattdessen noch fragiler geworden
  • Updates von macOS und den davon abhängigen Apps sind eher zu einem Anlass für Sorge als für Vorfreude geworden, und Nutzer rechnen zuerst damit, dass die neue Version schlechter sein könnte als die vorherige
  • Das Problem ist weniger AI selbst als die Frage, wofür AI priorisiert eingesetzt wird
    • GPU-Infrastruktur hat Entwicklern starke Fähigkeiten gegeben, wird aber nicht ausreichend dafür genutzt, bessere Software zu bauen
    • Softwareunternehmen orientieren sich seit Langem an KPIs, und Verbesserungen der Stabilität schlagen sich womöglich nicht direkt in Kennzahlen nieder
    • Ein Plan, ein Quartal lang auf neue Funktionen und Redesigns zu verzichten und sich nur auf Bugfixes zu konzentrieren, fällt in Präsentationen kaum auf
  • Solange sich diese Prioritäten nicht ändern, wird auch der Verfall der Softwarequalität weitergehen

Eine offene Chance für einzelne Entwickler

  • Während Unternehmen kollektiv in AI-Schulden geraten, erhalten einzelne Entwickler die Chance, Software zu bauen, die früher außerhalb ihrer Möglichkeiten lag
  • Die Erwartungen an Android Auto im Auto oder an die LG-Website sind niedrig, doch der aufgestaute Frust über den aktuellen Zustand kann zum Antrieb werden, Alltagssoftware zu verbessern
    • Gegenbewegungen zum aktuellen Zustand von macOS und Windows, wie Omarchy, sind bereits sichtbar
    • Es besteht Hoffnung, dass sich diese Entwicklung über den gesamten Software-Stack ausbreiten kann

Verwandte Beiträge

1 Kommentare

 
GN⁺ 5 시간 전
Hacker-News-Kommentare

  • Früher habe ich Updates noch mit Vorfreude installiert und mich gefragt, welche neuen Funktionen kostenlos dazukommen würden, und ich habe mir auch die Änderungen in Fedora Workstation 45 angesehen. Heute machen mir Updates für Smartphones, Fernseher, Autos und Nicht-Linux-Betriebssysteme erst einmal Angst.
    Ich fürchte, dass schon wieder unerwünschte Funktionen und externe Anbindungen hinzugefügt werden, und macOS hat mir die Vorfreude schon vor langer Zeit genommen, etwa indem man zum Ändern der Fenstergröße nach einem kleinen transparenten Rand suchen muss.
    Bei Windows 11 wirkte es so, als würde es nach Sicherheitsupdates mit Dark Patterns wieder unerwünschte Verbindungsfunktionen oder AI-Funktionen anpreisen.

    • Wenn ich heute ein Symbol für „Update ausstehend“ sehe, frage ich mich zuerst, was diesmal kaputtgemacht wird.
      Abgesehen von Videospielen hasse ich fast jedes Software-Update, und selbst bei Dead By Daylight ist der einzige Trost, dass die Inkompetenz des Entwicklers Behaviour immerhin auf das Spiel selbst beschränkt bleibt.
    • Die einzige Software, vor deren Updates ich keine Angst habe, ist freie und Open-Source-Software (FOSS).
      Proprietäre Software wird nicht mehr für die Nutzer gemacht, aber manche FOSS-Projekte stellen die Nutzer noch immer an erste Stelle.
    • Die kumulativen Sicherheitsupdates von Windows selbst enthalten keine neuen Betriebssystemfunktionen, und in der Pro-Edition konnte man zumindest früher Qualitäts- und Funktionsupdates auslassen.
      Stattdessen wird die „vernetzte Umgebung“ über sich automatisch aktualisierende Store-/AppX-Pakete ausgeliefert, und nach einem Patch wird beim Neustart OOBE ausgeführt, um Funktionen erneut zu bewerben oder zu aktivieren.
      Technisch ist das nicht an das Sicherheitsupdate gekoppelt, aber es bleibt trotzdem ein Dark Pattern, das den Nutzer ignoriert.

  • Diese Werkzeuge zusammen mit der Silicon-Valley-Kultur des „move fast and break things“ haben die Erwartungen des Managements an den Team-Output nach oben getrieben, und genau diese Erwartungen erfüllen zu müssen, ist am zermürbendsten.

  • Software kann schnell erstellt werden, aber um sicher zu sein, dass sie korrekt ist, braucht man mehr Zeit.
    Mit AI-Codegenerierung kann ein erfahrener Engineer etwas, das früher eine Woche dauerte, vielleicht in einer Stunde erstellen, aber die Zeit zur Verifikation der Korrektheit wird dadurch nicht kürzer.
    Viele Entwickler nehmen nur den Vorteil der höheren Generierungsgeschwindigkeit mit und ignorieren die Kosten für die Prüfung von Stabilität, Performance und Fehlerfreiheit; allerdings ging der Qualitätsverfall bei Consumer-Software schon vor AI los.

    • Wenn man dieselbe Qualität voraussetzt, ist eine Verkürzung von 1 Woche auf 1 Stunde fast ein extrem optimistischer Best Case; meist wirkt es eher so, als würde etwas, das zwei oder drei Stunden dauert, in einer Stunde erledigt.
      Je nach Aufgabe schwankt der Effekt stark, in langfristigen Projekten skaliert er nicht linear, und manchmal verursacht AI sogar noch größere Verzögerungen.
      Wenn man Qualität ignoriert, kann man ein enormes Tempo erreichen, aber auch ohne AI ist man viel schneller, wenn man sich nicht um Qualität kümmert.
    • Vertrauen schafft weniger die Entwicklungsdauer als vielmehr die Zeit, in der es sich im realen Einsatz bewährt hat.
      Egal wie lange etwas entwickelt wurde: Wenn es drei Monate lang im Feld ordentlich funktioniert hat, ist das vertrauenswürdiger; deshalb sollte man früh und oft releasen.

  • Softwarequalität wurde schon immer von Marktanreizen bestimmt, und AI schafft nicht von selbst einen Anreiz, robuste Software zu bauen.
    Der Markt belohnt eher die Wahl eines One-Stop-Produkts von Microsoft als Apps, die nicht bei jedem Update kaputtgehen, oder Kombinationen mehrerer unabhängiger Lösungen.
    Früher ging das nur wegen fehlender Rechenleistung und mangelnden Wissens nicht; heute scheint die Branche die Mindestbedingungen gefunden zu haben, unter denen Software gerade noch so steht, und die Grenze der kleinen Unannehmlichkeiten, die Nutzer noch hinnehmen.

    • Ob es wirklich ein Zustand ist, bei dem sich eine Gesellschaft einpendeln sollte, wenn man alle dauerhaft knapp davor hält zu gehen oder Schaden zu nehmen, ist fraglich.
    • Wenn Vollständigkeit und Korrektheit den Bereich von 90–99 % erreichen, steigt die Kostenkurve asymptotisch an, sodass sich die Investition aus Ertragssicht nicht mehr lohnt.
      Vollständige und korrekte Software wird nur dann gebaut, wenn das Risiko rechtlicher Haftung bei Fehlern groß ist.
    • Ich frage mich, wo der tatsächliche Grenzpunkt liegt, an dem Menschen die sinkende Qualität weiter hinnehmen und konsumieren, bis sie sagen: „Jetzt reicht’s.“

  • In Wayland unter KDE Plasma gibt es eine globale Einstellung, mit der sich steuern lässt, welche Fenster den Fokus an sich reißen dürfen, und sie funktioniert sehr gut.
    Jedes Mal, wenn ich einen Mac oder Windows-PC für die Arbeit benutze, vermisse ich diese Funktion; dokumentiert ist sie unter „Focus stealing prevention“: https://docs.kde.org/trunk_kf6/en/kwin/kcontrol/windowbehavi...

    • Eine sichere Methode, schlechter werdende Software zu vermeiden, ist der Wechsel zu FOSS und Linux/KDE.
      Es fühlt sich an wie eine Umgebung, in der Windows 7 sich weiter langsam verbessert und zu einem nützlichen Reifegrad entwickelt hätte.
      NixOS hat zwar schon lange das Problem, dass das Laden von Bibliotheken n² ist und GUI-Programme deshalb langsam starten, aber selbst auf einem N100-Mini-PC startet alles in etwa innerhalb einer Sekunde, und auch ein 4K-240Hz-HDR-Monitor wird flüssig angesteuert.
      Vor allem macht der Computer genau das, was man ihm sagt.
    • Es ist nicht so sehr, dass macOS keine Funktion zur Verhinderung von Fokusdiebstahl hätte; eher scheint es, als hätten die Designer sich eine Situation mit verzögert startenden Apps gar nicht vorgestellt.
      Wenn ein Nutzer wartet und dann etwas anderes eingibt, kann das ein Signal sein, dass er dieser App keinen Fokus mehr geben will, aber das Design wirkt so, als sei nur der optimistische Fall angenommen worden, in dem die App sofort öffnet.
    • Das Qualvollste an heutiger Technik ist die Unvorhersehbarkeit, wenn sich die Oberfläche genau in dem Moment verändert, in dem der Nutzer etwas anklicken oder antippen will.
      Bei Touch-Tastaturen ändern sich empfohlene Wörter unmittelbar vor dem Tippen, und in iOS Liquid Glass oder instabilen Web-Apps bewegen sich sogar die Buttons.
      Dazu kommen endlose Pop-ups und Aufforderungen zur Interaktion wie „Gefällt Ihnen diese App?“.
      Fokusdiebstahl in Windows war schon 1995 ein Problem, und solche unerwarteten Änderungen im 100-ms-Takt reizen ständig die Schreckreaktion der Muskeln und das limbische System, sodass der Körper nach einigen Stunden regelrecht zittert.
      Man sollte mit diesen Slotmachine-artigen Reizen und Engagement-Metriken, die nur auf Klickzahlen zielen, aufhören und den Menschen ermöglichen, sich auf ihre Arbeit zu konzentrieren.
    • Tolle Funktion, aber aktuell gibt es bei einer Verhinderungsstufe über „Low“ einen Bug, bei dem zu aggressiv blockiert wird: https://bugs.kde.org/show_bug.cgi?id=509990
    • Unter Windows wird Slack im Hintergrund geladen, und sobald es bereit ist, blinkt nur das Taskleisten-Symbol; den Fokus der aktuellen App übernimmt es nicht, bevor der Nutzer nicht selbst dorthin wechselt.

  • Während der Benutzer tippt oder mit der UI interagiert, sollte standardmäßig ein Debounce gegen Focus-Stealing gelten, damit keine andere App jemals den Fokus übernehmen kann
    Selbst wenn Pop-ups, Töne oder blinkende Icons verwendet werden, darf eine App, die nichts mit der aktuellen Aufgabe zu tun hat, die Eingabe nicht abfangen
    Es sollte auch keinen Anlass für Ausnahmen geben, wie bei Cisco AnyConnect, das nach dem Klick auf den Verbinden-Button wegen des erfolgreichen Verbindungsaufbaus eine Ausnahme beansprucht; genauso wie man es nicht dulden würde, dass eine Terminal-App STDIN wegnimmt, sollte es auch in GUIs nicht erlaubt sein

    • Es gibt praktisch keine Situation, in der man möchte, dass der Fokus automatisch weggenommen wird, und trotzdem ist dieses Verhalten der Standard und passiert ständig — das ist unverständlich
    • Auch macOS kann neu gestartete Apps außerhalb des Fokus lassen, und das tritt konsistent auf, wenn ein Laptop lange nicht neu gestartet wurde
      Es könnte ein Bug sein, aber wenn der Benutzer vor Abschluss des App-Starts auf ein anderes Fenster geklickt hat, könnte es im Gegenteil ein sinnvolles Verhalten sein
    • Da die Event-Queue des Betriebssystems prozess- und fensterübergreifend arbeitet, ist ein einfaches Debouncing schwierig
      Wie bei X11 kann man einem neuen Fenster den Fokus verweigern, aber das ist möglicherweise nicht das Verhalten, das die meisten Benutzer wollen
    • Pop-ups, Warntöne und blinkende Icons sind schon störend genug, und die Konzentration des Benutzers ist noch wertvoller

  • Das Problem war nie das bloße Schreiben von Code, sondern der Prozess, etwas sorgfältig und präzise zu bauen
    Softwareentwicklung hat sich über lange Zeit weiterentwickelt, indem sie Gewohnheiten, Schutzmechanismen und bewährte Strukturen angesammelt hat; jetzt beschreibt man nur noch das Problem und kann die zu schnell generierten Ergebnisse nicht mehr ordentlich prüfen, sodass man nicht einmal mehr weiß, was eigentlich ausgeliefert wurde
    Wie handgefertigte Möbel durch Fabrikware ersetzt wurden, bei der niemand mehr weiß, wer welchen Teil gebaut hat und die nicht lange hält, ist auch Software bei einem Stadium von Zusammenbau und Auslieferung ohne Verständnis angekommen
    Die Minderwertigkeit wird sich anhäufen, aber vielleicht ist das auch der Beginn eines Zyklus, in dem man wieder ernsthaft darüber nachdenkt, wie man Dinge gut baut

    • Der NPM-left-pad-Vorfall liegt schon 10 Jahre zurück, über Supply-Chain-Angriffe und SBOM wird ebenfalls seit Langem diskutiert, und SourceForge hat sogar Adware in Distributionsdateien eingeschleust
      Wenn man Code ohnehin nicht prüft, ist es nicht besonders viel schlimmer, KI Code schreiben zu lassen, als PIP oder NPM install ungeprüft auszuführen

  • Schon die Prämisse „Coding ist gelöst“ ist falsch, und deshalb wird Software immer schlechter

    • Selbst wenn Coding gelöst wäre, war es nie der Engpass
      Coding war schon lange billig, und Unternehmen haben es an die günstigsten Kräfte ausgelagert, aber die Fähigkeit, Probleme zu erkennen und Lösungen zu entwerfen, ist etwas anderes
      Code ist eher Schuld als Vermögenswert, deshalb sollte man nur das Minimum schreiben, das das reale Problem löst, und dafür braucht man Ingenieure
      Wenn man KI-Ausgaben prüft und Fehler korrigiert hat, ist der Zeitaufwand ähnlich wie beim direkten Schreiben, also hilft das im Arbeitsalltag nicht besonders
    • Das eigentliche Problem ist nicht, dass Coding gelöst sei, sondern dass man das glaubt

  • Ich stimme zu, dass Software schlechter wird, aber man kann nicht allein die KI dafür verantwortlich machen
    Fehlgeschlagene TV-Übertragung beim Streaming, 500er-Fehler im Browser und Bluescreens auf öffentlichen Touchscreens gab es schon vorher
    Hinzu kommt, dass die Zahl der Programmierer exponentiell gewachsen ist und die Hälfte nur wenige Jahre Erfahrung hat; außerdem reicht das Üben von Single-Thread-Algorithmen nicht aus, um verteilte Systeme, CQRS, Event Sourcing, Auditierbarkeit und Idempotenz zu beherrschen
    Wenn zudem fachfremde Product Owner den Lebenszyklus dominieren und dafür sorgen, dass nur der Happy Path des MVP umgesetzt wird, sind Bugs und spätere Neuschreibungen garantiert
    Die Sprachen wurden von C++ über Java und JavaScript bis Python anfängerfreundlicher, während die Arbeit selbst mit B2B-Distributed-Systems, 24/7-Betrieb, Millionen von Benutzern, Sicherheit und Machine Learning komplexer geworden ist

    • Sobald das MVP fertig ist, gilt es wie durch Magie als auslieferbares Produkt, und gerade wenn das Team verstanden hat, wie man es verbessert, mischt das Management die Organisation schon wieder neu
      Während Beförderungen ins Executive-Management und Abteilungszusammenlegungen als „aufregende Neuigkeiten“ verkauft werden, geht die Kontinuität bei der Produktverbesserung verloren
    • Product-Manager-Zentrismus und MVP-Fixierung sind große Ursachen des Qualitätsverfalls
      Man muss Agile nicht wortwörtlich auf dumme Weise anwenden; auch bei Infrastruktur oder User-Apps kann man auf Basis früherer Produkte, Wettbewerber und Teamerfahrung planen, welche Funktionen in 3, 6 und 12 Monaten gebraucht werden
      Selbst wenn man einem GPS folgt, schaut man auf die gesamte Route und die nächsten drei Schritte — Agile bedeutet nicht, erst nach Abschluss eines Schritts überhaupt zum ersten Mal über den nächsten nachzudenken
    • Wenn man Programmierung so vereinfacht, dass sie jeder machen kann, wird sie tatsächlich von jedem gemacht
    • Auch Uncle Bob läuft nun Gefahr, das Problem mitzuverursachen, weil er KI inzwischen vollständig annimmt
    • KI ist vielleicht nicht die Ursache des Qualitätsverfalls, aber sie beschleunigt den Niedergang
      Wenn eine Maschine Betten 150 % schneller herstellt, aber eine Ausschussquote von 70 % hat, steigen gleichzeitig die Zahl mangelhafter Produkte, das Verschwinden von Schreinerkompetenz sowie der Verlust an Motivation und Nutzen für Handwerker
      Selbst wenn die Maschine irgendwann besser wird, müssen in der Zwischenzeit unzählige Menschen auf miserablen Betten schlafen

  • LLMs können nicht die gesamte Codebasis auf einmal lesen, verstehen und auf dieser Grundlage Entscheidungen treffen
    Der schwierige Teil der Programmierung ist nicht eine einzelne Funktion oder Klasse, sondern wie sie in einem riesigen System miteinander interagieren, und der Umfang von Software ist grundsätzlich größer als das LLM-Kontextfenster
    Selbst wenn das Kontextfenster größer wird, sammelt das Modell kein Verständnis wie ein Mensch an; deshalb kann man nicht sagen, dass KI das Coding gelöst hat
    Bei neuen Projekten ist sie nützlich, aber neue Software schnell zu erstellen war schon immer leichter, als an altem Code zu arbeiten