Wir spotten über KI-Slop, während riesige menschliche Organisationen seit Jahrzehnten ihren eigenen produzieren.
In letzter Zeit wird viel über „KI-Slop“ gejammert.
KI-generierte Websites. KI-generierter Code. KI-generierte Inhalte. Oberflächen, die ungefähr richtig aussehen, bis man sie benutzen will. Funktionen, die technisch existieren, aber offensichtlich nicht zu Ende gedacht wurden. Produkte, bei denen man den Eindruck hat, jemand habe einen Prompt getippt, kurz auf das Ergebnis geschaut und es veröffentlicht.
Viel an dieser Kritik ist berechtigt. Aber Menschen produzieren seit Jahrzehnten miserable Software, und manchmal tun sie das mit Mitteln, die sich ein KI-Startup kaum vorstellen könnte.
Vor Kurzem bin ich bei Enbridge auf ein besonders schönes Beispiel gestoßen, einem Unternehmen mit einer Marktkapitalisierung von rund 110 Milliarden US-Dollar, als ich nachgesehen habe.
Enbridges Marktkapitalisierung an dem Tag, an dem ich meine Gasrechnung zahlen wollte.
Halten Sie einen Moment bei dieser Zahl inne.
Einhundertzehn Milliarden Dollar.
Stellen Sie sich vor, was Sie bauen könnten, wenn Sie auch nur einen winzigen Bruchteil der Mittel einer Organisation dieser Größe hätten. Sie könnten Spitzeningenieure aus aller Welt einstellen. Sie könnten eigene Teams für Produkt, Design, Sicherheit, Barrierefreiheit, QA, Infrastruktur und Kundenerlebnis unterhalten. Sie könnten jeden Ablauf gegen jeden relevanten Browser, jedes Gerät, jedes Zahlungsnetz und jede Authentifizierungsmethode testen. Sie könnten Usability-Studien machen, bis Sie sie nicht mehr sehen können.
Sie könnten eine außergewöhnliche Website bauen.
Stattdessen hat Enbridge eine gebaut, die mich kein Passwort mit mehr als 13 Zeichen benutzen lässt.
Das ist HumanSlop.
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.
Die Antwort, die mein Passwortmanager bekam.
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 andere, was die „neue Online-Erfahrung“ kann.
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.
