HumanSlop: Wie liefert ein Konzern mit 110 Milliarden Dollar Marktwert so schlechte Software?

Mein Gasversorger hat seine Website „modernisiert“

Auf Enbridges neuer Website bin ich gelandet, weil ich die Mitteilung bekam, dass meine bestehende Online-Zahlung über die Bank storniert wurde. Ich hatte bereits eine völlig funktionierende Möglichkeit, meine Gasrechnung zu zahlen, aber Enbridge hat auf seiner Seite etwas geändert und mich zur Migration gezwungen.

Gut. Systeme ändern sich.

Ich ging auf die neue Seite, wollte mein Konto anlegen und wurde damit begrüßt:

Das Passwort darf nicht länger als 13 Zeichen sein.

Dreizehn Zeichen.

Im Jahr 2026.

Wir haben jahrelang gepredigt, Passwortmanager zu verwenden, lange zufällige Passwörter zu erzeugen und kurze, merkbare Zugangsdaten nicht länger wiederzuverwenden. Mein Passwortmanager hat genau das getan, was er soll, und ein starkes Passwort erzeugt. Enbridges nagelneues System antwortete im Grunde:

Halt, halt, halt. So sicher bitte nicht.

Das ist keine uralte Grünmonitor-Anwendung hinter einem Mainframe. Das ist die neue kundenseitige Website eines der größten Energieinfrastruktur-Unternehmen Nordamerikas.

Denken Sie noch einmal an die Mittel. Ein Unternehmen dieser Größe kann sich ausgereifte Identitätsinfrastruktur leisten, Penetrationstests, Sicherheitsberater, automatisierte Testsuites, eigene Security-Engineers und jeden Authentifizierungsanbieter, den es will.

Irgendwo in dieser ganzen Maschinerie lautete die endgültige Antwort:

Maximale Passwortlänge: 13. Ausliefern.

Und dann ist da noch das Design

Noch bevor man auf die Fehler stößt, sieht die Seite aus, als wäre sie aus einer SharePoint-Migration von 2003 gerettet worden.

Sehen Sie es sich an.

Eine riesige graue Kopfleiste. Winzige Formularfelder. Unterstrichene blaue Links. Ein Seitenkasten mit „Anmelden“ und „Kontakt“. Dichte Anweisungsblöcke. Harte Rahmen. Kleine Buttons. Layout-Entscheidungen, die weniger nach modernem Kundenportal aussehen als nach einem Antragsformular im Landratsamt von 1998.

Und trotzdem verkündet die Seite stolz:

„Willkommen bei Ihrer neuen Online-Erfahrung!“

Dieser Satz ist vielleicht das Komischste an der ganzen Sache.

Neu im Vergleich wozu? Zu Telnet?

Das ist ein Unternehmen im Wert von rund 110 Milliarden Dollar, und seine „neue Online-Erfahrung“ sieht aus wie die Art von Website, auf der man ein blinkendes <marquee>-Tag und ein „Optimiert für Internet Explorer 6“-Abzeichen im Fußbereich erwartet.

Das Problem ist nicht, dass jede Unternehmenswebsite aussehen müsste wie Apple. Muss sie nicht. Ein Abrechnungsportal eines Versorgers sollte langweilig sein. Es sollte sauber, schnell, offensichtlich, barrierefrei und praktisch unmöglich zu vermasseln sein.

Aber das hier ist nicht langweilig im guten Sinn. Es sieht alt aus, weil Informationsarchitektur, Typografie, Hierarchie, Abstände, Bedienelemente und Interaktionsmuster allesamt antik wirken.

Und noch einmal:

110 Milliarden Dollar.

Stellen Sie sich vor, Sie hätten auch nur eine Milliarde Dollar für Software.

Sie könnten einige der besten Produktdesigner der Welt einstellen. Sie könnten ein Designsystem bauen, das über alle Kundenkontaktpunkte hinweg funktioniert. Sie könnten das Portal mit Tausenden echten Kunden testen. Sie könnten den Login-Ablauf mühelos machen. Sie könnten die Abrechnungsoberfläche auf Desktop und Mobilgerät hervorragend funktionieren lassen. Sie könnten sich in Barrierefreiheit, Performance und Bedienbarkeit verbeißen, bis kaum noch etwas zu verbessern bleibt.

Dafür bräuchte man natürlich keine Milliarde. Mit einem winzigen Bruchteil davon ließe sich eine drastisch bessere Version dieser Seite bauen.

Genau das macht es so komisch.

Das ist keine Geschichte über ein Unternehmen ohne Mittel.

Es ist eine Geschichte darüber, was passiert, wenn Ressourcen aufhören, der limitierende Faktor zu sein, und die Qualität der Organisation an ihre Stelle tritt.

Und dann hörte die Website auf zu funktionieren

Nachdem ich die Passwortvorgabe umgangen hatte, bekam ich reihenweise generische Fehler:

„Auf unserer Seite gibt es ein Problem. Bitte warten Sie ein paar Minuten und versuchen Sie es erneut.“

Das ist auf jeder Website ärgerlich, aber der Kontext macht es schlimmer. Ich habe mich nicht freiwillig gemeldet, um Enbridges aufregende neue digitale Erfahrung zu testen. Mein alter Zahlungsweg funktionierte. Enbridge hat ihn entfernt und mich zum Ersatz geschickt.

Wenn Sie Kunden zu einer Migration zwingen, sollte der Ersatz funktionieren.

Das sollte keine umstrittene Produktphilosophie sein, erst recht nicht, wenn das migrierende Unternehmen elfstellig bewertet ist.

Der 110-Milliarden-Konzern, der vergaß, wie American Express funktioniert

Irgendwann erreichte ich das Kreditkartenformular. Enbridge zeigte American Express als unterstützte Karte an, also gab ich meine Amex-Daten ein.

Dann kam ich zum Feld für die Prüfnummer.

American Express verwendet einen vierstelligen Sicherheitscode.

Enbridges Formular erlaubte drei Stellen.

Ich gab drei Ziffern ein und wollte die vierte tippen. Nichts passierte. Das Feld nahm sie schlicht nicht an.

Das ist mein Lieblingsfehler, weil er so wunderbar unkompliziert ist.

Es gibt keinen raffinierten Sonderfall zu debuggen. Keine Race Condition, versteckt in einem verteilten System. Keine obskure Browser-Inkompatibilität, die nur dienstags auftritt, wenn Merkur rückläufig ist.

American-Express-Karten haben vierstellige Sicherheitscodes.

Wenn Sie sagen, dass Sie American Express akzeptieren, muss Ihr Formular vier Ziffern akzeptieren.

Das ist die gesamte Anforderung.

Ein Junior-Entwickler würde das verstehen. Ein Tester würde es finden. Ein automatisierter Integrationstest würde es finden. Ein Produktmanager, der sein Mittagessen mit einer Amex bezahlt, würde es finden.

Trotzdem hat dieser Fehler die gesamte Maschinerie aus Entwicklung, Dienstleistern, Design, QA, Sicherheit, Deployment und Freigaben eines 110-Milliarden-Konzerns durchlaufen und kam auf der anderen Seite lebend heraus.

Das muss man erst mal schaffen.

Ernsthaft, stellen Sie sich vor, was Sie mit einer Milliarde bauen könnten

Eine Milliarde Dollar ist eine so große Zahl, dass sie abstrakt wird. Vergessen Sie also kurz Enbridges Bewertung von 110 Milliarden.

Stellen Sie sich vor, jemand drückt Ihnen eine Milliarde Dollar in die Hand und sagt:

Bauen Sie das beste Kundenerlebnis für Versorgungsdienste auf der Welt.

Was könnten Sie bauen?

Sie könnten 500 herausragende Ingenieure für 250.000 Dollar im Jahr einstellen und acht Jahre lang beschäftigen.

Sie könnten eigene Teams für Produktdesign, Frontend, Backend, Sicherheit, Barrierefreiheit, Zuverlässigkeit, Mobile, Zahlungen, Kundenforschung, Analytics, QA und Infrastruktur aufbauen.

Sie könnten Testumgebungen in voller Größe bauen, die die Produktion spiegeln.

Sie könnten jede Zahlungsart testen. Jeden Browser. Jedes Telefon. Jedes Barrierefreiheitsszenario. Jeden Authentifizierungsablauf.

Sie könnten echte Kunden dafür bezahlen, den ganzen Tag zu versuchen, die Seite kaputtzumachen. Sie könnten Usability-Studien mit jeder Zielgruppe durchführen, die Sie bedienen. Sie könnten Fachleute engagieren, die sicherstellen, dass Menschen mit Sehbehinderung, motorischen Einschränkungen oder wenig technischer Erfahrung ihre Gasrechnung ohne Frust bezahlen können.

Sie könnten eine App bauen. Sie könnten ein erstklassiges Web-Erlebnis bauen. Sie könnten APIs bauen. Sie könnten Echtzeit-Rechnungsprognosen, Verbrauchsanalysen, Störungsinformationen, Lastschrifteinstellungen, Kontofreigaben, Warnungen, Benachrichtigungen und Integrationen mit allen großen digitalen Wallets schaffen.

Sie könnten die gesamte Plattform vermutlich mehrfach neu bauen.

Und danach hätten Sie immer noch Hunderte Millionen übrig.

Und jetzt erinnern Sie sich: Enbridge ist etwa das 110-Fache davon wert.

Marktkapitalisierung ist natürlich kein Geld auf der Bank. Enbridge hat keine 110 Milliarden im Tresor liegen und wartet darauf, dass jemand sie in Passwortfelder investiert. Darum geht es nicht.

Es geht um Größenordnung.

Wir sprechen nicht von einem Gründer mit 40.000 Dollar auf dem Konto, der versucht, die Server am Laufen zu halten.

Wir sprechen von einem riesigen Konzern mit praktisch unbegrenztem Zugang zu genau der Expertise, die diese Probleme löst.

Und das Ergebnis ist eine Website, die Jahrzehnte alt aussieht, moderne Passwortlängen ablehnt, generische Serverfehler wirft und behauptet, American Express zu unterstützen, während sie eine American-Express-Prüfnummer verweigert.

Das ist kein Ressourcenproblem.

Das ist Human Slop.

Mehr Prozess erzeugt nicht zwangsläufig bessere Software

Eine der seltsamsten Annahmen in der Softwareentwicklung ist, dass mehr organisatorischer Prozess automatisch zu höherer Qualität führt.

Ein Großkonzern hat vermutlich Produktmanager, Projektmanager, Entwickler, Designer, Sicherheitsteams, QA-Teams, externe Dienstleister, Berater, Compliance-Prozesse, Staging-Umgebungen, Deployment-Verfahren, Ticketsysteme und Freigabeketten. All das sollte theoretisch etwas wie ein Zahlungsformular zuverlässiger machen.

Aber Komplexität verwässert auch Verantwortung.

Das Authentifizierungsteam besitzt ein Stück. Der Zahlungsdienstleister ein anderes. Ein Frontend-Team besitzt das Formular. Ein Designsystem gibt die Komponente vor. Security hat Anforderungen. Produkt hat die Akzeptanzkriterien geschrieben. QA hat die dokumentierten Fälle getestet. Ein externer Dienstleister hat einen Teil gebaut.

Alle können ihre zugewiesene Aufgabe korrekt erledigen, und das Endprodukt ist trotzdem schlecht.

Das ist der Teil, den ich interessant finde.

Keine einzelne Person hat sich zwangsläufig entschieden, etwas Dummes zu bauen. Die Organisation hat die Dummheit kollektiv hervorgebracht.

Ein System kann Schichten menschlicher Prüfung, Planung, Meetings, Tests, Beschaffung und Freigaben durchlaufen und trotzdem in Produktion ankommen, unfähig, den Sicherheitscode einer der Karten anzunehmen, die es zu unterstützen behauptet.

Geld kauft Talent, aber es garantiert keine Verantwortungsübernahme.

Geld kauft Prozess, aber es garantiert kein Urteilsvermögen.

Geld kauft QA-Teams, aber es garantiert nicht, dass jemand das Offensichtliche getestet hat.

Manchmal macht all dieser Prozess den Slop einfach nur teurer.

KI-Slop hat wenigstens eine Ausrede

Deshalb finde ich einen Teil der Empörung über KI-generierte Software auch amüsant. Wir messen eine Technologie, die es erst seit wenigen Jahren gibt, an menschlichen Softwareorganisationen, die Jahrzehnte Zeit hatten, das herauszufinden.

Natürlich produziert KI manchmal schlechten Code. Natürlich kann ein Agent eine Anforderung missverstehen. Natürlich können generierte Oberflächen seltsame Annahmen enthalten. Das sind reale Probleme, und KI-generierte Software sollte unbedingt getestet werden, bevor sie Nutzer erreicht.

Aber was genau ist die Ausrede, wenn Hunderte oder Tausende Menschen, ausgereifte Engineering-Praktiken, enorme Budgets und jahrzehntelanges institutionelles Wissen dasselbe Ergebnis erzeugen?

Wenn ein KI-Coding-Agent ein Amex-Formular gebaut hätte, das nur drei Ziffern annimmt, könnte ich ihm vermutlich sagen:

American Express verwendet eine vierstellige Prüfnummer. Behebe das und ergänze einen Regressionstest.

Die Chance ist gut, dass das Problem ein paar Minuten später behoben wäre.

Die riesige menschliche Organisation hat es geschafft, den Fehler bis in die Produktion zu bringen.

Das eigentliche Problem sind die Anreize

Es gibt noch einen Grund, warum mich das Enbridge-Erlebnis mehr gestört hat als eine gewöhnlich schlechte Website: Was genau soll ich dagegen tun?

Wenn ein Onlineshop den Checkout zur Qual macht, kaufe ich woanders. Wenn ein SaaS-Produkt immer schlechter wird, kündige ich. Wenn ein Restaurant mich dauerhaft schlecht bedient, gehe ich nicht mehr hin.

Wettbewerb erzeugt eine brutale, aber wirksame Rückkopplung:

Machen Sie Kunden lange genug unglücklich, verlieren Sie sie irgendwann.

Bei Versorgern läuft das anders.

Ich kann schlecht verkünden, dass mich Enbridges Nutzererlebnis enttäuscht, und ein anderes Unternehmen bitten, sein konkurrierendes Erdgasnetz an mein Haus anzuschließen.

Welchen Hebel habe ich hier?

„Repariert eure Website, sonst nehme ich meine unterirdischen Gasleitungen und gehe zur Konkurrenz“?

Wenn Kunden nicht einfach gehen können, verschwindet einer der stärksten Mechanismen, schlechte Software zu bestrafen.

Das heißt nicht, dass irgendjemand bei Enbridge bewusst entschieden hätte, dass das Kundenerlebnis egal ist. Ich bin sicher, dort ist vielen Menschen sehr wichtig, gute Arbeit zu leisten. Aber Anreize wirken auch dann, wenn niemand ausdrücklich über sie spricht.

Wenn Sie den Kunden nicht verlieren können, ist der Druck, ihn zu begeistern, schlicht ein anderer.

Und manchmal spürt man dieses Fehlen im Produkt.

Das sind keine schweren Probleme

Vielleicht stört mich genau das am meisten.

Keine meiner Beschwerden erfordert schwierige Ingenieursarbeit.

Ich verlange von Enbridge nicht, die Kernfusion zu lösen.

Ich verlange:

• Passwörter in moderner Länge zulassen.
• Die Website am Laufen halten.
• Vier Ziffern in einem vierstelligen Prüfnummernfeld akzeptieren.
• Ein Kundenportal bauen, das nicht Jahrzehnte alt wirkt.
• Das Abrechnungssystem testen, bevor man Kunden zur Migration zwingt.

Das sind gelöste Probleme.

Eine kompetente Entwicklerin könnte einige davon vor dem Mittagessen beheben. Ein kompetentes Designteam könnte die gesamte Oberfläche modernisieren, ohne irgendetwas neu zu erfinden. Ein kompetenter QA-Prozess sollte den Amex-Fehler sofort finden.

Und trotzdem hat all das den Weg bis in die Produktion überlebt, bei einem Unternehmen im Wert von zig Milliarden.

Das sollte uns die Annahme überdenken lassen, die größte Bedrohung für Softwarequalität seien unerfahrene Entwickler mit KI-Werkzeugen.

Manchmal wäre es gerade der unerfahrene Entwickler mit einem KI-Agenten, der das Problem mit der vierstelligen Prüfnummer bemerkt.

Menschen bekommen keinen Qualitätsfreibrief

Ich bin begeistert von KI-gestützter Softwareentwicklung. Ich finde auch, wir sollten extrem kritisch mit dem Müll umgehen, den sie produzieren kann. Diese beiden Positionen sind vollkommen vereinbar.

Generierter Code braucht Review. Agenten brauchen Tests. KI-erzeugte Oberflächen brauchen echte Nutzer. Unternehmen sollten keinen Schrott ausliefern, nur weil das Erzeugen billiger geworden ist.

Aber der Maßstab muss in beide Richtungen gelten.

Software sollte keinen Qualitätsfreibrief bekommen, nur weil ein Modell beim Bauen geholfen hat.

Und Software sollte keinen Qualitätsfreibrief bekommen, nur weil Menschen sie gebaut haben.

Wenn wir KI-Systeme für kaputte Formulare, unsinnige Bedienung, Sicherheitsfehler und offensichtlich ungetestete Funktionen verspotten, sollten wir genau denselben Maßstab an klassische Softwareorganisationen anlegen.

Vielleicht sogar einen strengeren.

KI-Slop stammt von einer Technologie, die wir noch verstehen lernen.

Menschlicher Slop entsteht, nachdem man es seit Jahrzehnten besser weiß.

Wenn mir das nächste Mal jemand eine lächerliche KI-generierte Anwendung als Beweis zeigt, dass man Maschinen den Softwarebau nicht anvertrauen kann, werde ich an das Unternehmen im Wert von rund 110 Milliarden Dollar denken, dessen neue Abrechnungsseite mein sicheres Passwort für zu lang hielt, dessen „neue Online-Erfahrung“ aussah, als hätte sie das Jahr 2000 überstanden, und dessen Zahlungsformular fand, meine vierstellige American-Express-Prüfnummer müsse irgendwie in drei Stellen passen.

Stellen Sie sich vor, was Sie mit einer Milliarde Dollar bauen könnten.

Und dann stellen Sie sich vor, Sie hätten Zugriff auf die Mittel einer Organisation, die das 110-Fache wert ist, und liefern das hier aus.