Die Geschichte

Wir hatten die 80 %-Plugins satt. Also haben wir sie neu gebaut — mit KI, geschmiedet im Feuer eines echten Shops mit über 15.000 Artikeln.

Das ist kein Slogan, das ist eine Gründungsgeschichte. Die „80 %“ darin sind keine Statistik — sie sind zwanzig Jahre Erfahrung, verdichtet in einen Stoßseufzer. Hier ist die Geschichte dazu. Und sie beginnt lange vor dem ersten Shop.

Der Junge am C64

Es begann mit dem C64 des Vaters. Mit zwölf der erste Zugang zu einem Computer. Mit vierzehn das erste vollwertige Produkt — eine Vereinsverwaltungssoftware, honoriert mit einem Taschengeld. Mit sechzehn das erste kommerzielle Programm. Und dann die Demoszene: die härteste Schule, die ein Programmierer in den Neunzigern durchlaufen konnte — Kunst aus Rechenzyklen, Wettbewerb um jedes einzelne Byte.

1997 gewann „Pinker“ — unter diesem Namen war KI²T-Gründer Dirk Küppers in der Szene unterwegs — mit Omniscent die 4K-Intro-Competition der Mekka & Symposium: ein kompletter 3D-Levelflug mit prozeduralen Texturen und Musik, in exakt 4.095 Bytes. Das Intro galt jahrelang als das beeindruckendste 4K auf dem PC und wird bis heute seziert und nachgebaut wie ein Kunstwerk.

Die Musik zu Omniscent schrieb übrigens ein Szene-Weggefährte namens Daniel Weinand — der wenige Jahre später mit einem Kumpel eine kleine Firma namens Shopify mitgründete. Das 4-Kilobyte-Duo von 1997 landete also vollständig im E‑Commerce: der eine als Mitgründer der größten Shop-Plattform der Welt, der andere in den Maschinenräumen der Shops — beide mit derselben Herkunft: der Kunst, aus wenig Bytes viel Welt zu machen.

Danach Spieleentwicklung, Web-Entwicklung — und 2003 der erste eigene Shop. Eines aber blieb für immer: Wer aus der Demoszene kommt, dem muss niemand erklären, warum ein 1,6-Megabyte-Hero-Slider eine Beleidigung ist.

2003–2011: Der Veteran

Eigentlich wollten wir nur LEDs verkaufen — die Dotlight GbR war schnell gegründet, jetzt musste ein Online-Shop her. So entstand 2003 der erste eigene Shop: osCommerce, eigene Firma, eigenes Risiko. Das erste große Plugin folgte aus der Not: Das Clearing-Plugin unseres Kreditinstituts war bestenfalls eine Machbarkeitsstudie, also bauten wir das Payment-Modul für das Kreditkarten-Clearing einer großen deutschen Bankengruppe selbst. Danach diverse eigene Plugins — und zwar aus einem Grund, der einem heute bekannt vorkommt: Die gekauften funktionierten nur so halb. Wer etwas Belastbares brauchte, baute es selbst. 2011 wurde die Firma verkauft.

Das Muster hält zwanzig Jahre

Danach: freiberufliche Arbeit für Shop-Betreiber auf XT-Commerce und Veyton. Dann das große Migrationsprojekt — ein Versandhändler, über 15.000 Artikel, Umzug auf Shopware. Neues Ökosystem, moderne Architektur, riesiger Marktplatz.

Und die alte Erfahrung wiederholte sich, Plugin für Plugin: Kommerzielle Erweiterungen funktionieren nach unserer Erfahrung in der Regel nur zu 80 %. Die letzten 20 % — die, in denen Performance, Updatefähigkeit und Details stecken — fehlen. Der Betreiber des Shops brachte es mehrfach auf den Punkt:

„Das kann doch so gar keiner nutzen!“

Die Folgen waren messbar: erbärmliche Ladezeiten, Web Vitals aus der Hölle, und bei jedem Major-Update ein Monat erzwungener Stillstand, weil Fremd-Plugins nicht hinterherkamen.

Dass das kein Einzelschicksal ist, hat die Branche lange vor uns aufgeschrieben: Gerrit van Aaken diagnostizierte schon 2013 „die immer noch unerträgliche Shopsystemsituation“„Fast alle Erweiterungen sind Core-Hacks“, Updates ohne Beschädigung kaum möglich. Das Muster ist über ein Jahrzehnt dokumentiert. Wir haben es nur nicht länger hingenommen.

Der Gamechanger

Dann kam der Wechsel auf KI-native Entwicklung — Vibe Coding mit Claude Code. Der erste große Einsatz: eine systematische Untersuchung aller Fremd-Plugins im Shop. Jede Erweiterung, komplett durchleuchtet — was macht sie mit dem Cache, was mit der Datenbank, was mit dem Frontend, was bei Updates?

Das Ergebnis war erschreckend. Die Befunde ließen sich in vier Typen sortieren — unser Marken-Vokabular seither:

  • Cache Buster — schießen den Seiten-Cache ab, jeder Besucher zahlt den vollen Preis.
  • Performance Killer — Datenbank- und Render-Last, die man erst unter echtem Traffic sieht.
  • Web Vitals Crusher — Layout-Sprünge, Blocking-Skripte, Bilder-Desaster: Google sieht alles.
  • Update Blocker — verhindern wochenlang jedes Shopware-Update.

Die vollständige Liste mit Namen bleibt intern. Veröffentlicht werden nur anonymisierte Befunde — es geht uns um das Muster, nicht um den Pranger.

Die traurige Erkenntnis: Der Artikel von Gerrit van Aaken hat auch nach 13 Jahren nichts von seiner Aktualität eingebüßt. In der Summe blicken wir seit fast 25 Jahren auf dieselben Probleme.

Fairerweise: Es lag in der Regel nicht an mangelnder Kompetenz oder Fleiß der Hersteller. Die letzten 20 % eines Plugins — Performance, Updatefestigkeit, die tausend Kantenfälle — kosten 80 % des Aufwands, und zu Marktplatz-Preisen rechnet sich das für niemanden. Die Branche saß 25 Jahre in einer Kostenfalle. Der Gamechanger ist, dass KI genau diese Rechnung dreht: Die letzten 20 % sind bezahlbar geworden. Man muss es nur tun.

Dass diese Rechnung keine Marketing-Behauptung ist, lässt sich in Stufen belegen. Schon für die erste Generation der KI-Assistenten — reine Code-Vervollständigung — zeigen randomisierte Feldexperimente mit fast 5.000 Entwicklern bei Microsoft, Accenture und einem Fortune-100-Konzern messbare Effekte: rund 26 % mehr abgeschlossene Aufgaben (Management Science, 2026). Der eigentliche Sprung kam aber erst mit der jüngsten Modellgeneration und agentischer Entwicklung — zu neu für breite Studien, aber eindrucksvoll dokumentiert: Software-Architekt David Tielke führt in „Der Moment, der die Softwareentwicklung geändert hat“ an einem konkreten Projekt vor, wie sich die Größenordnungen verschieben — von rund 4.180 Personentagen und ~2 Mio. € auf ~45 Tage und ~25.000 €, bei null technischen Schulden, 100 % Dokumentation und 85 % Testabdeckung. Genau diese neue Ökonomie hat den Neubau von zwölf Modulen möglich gemacht. Und weil Studien der Praxis immer hinterherlaufen, legen wir die Beweise am liebsten selbst auf den Tisch — live und messbar, auf dieser Website.

Bedeutet das, die KI²T-Module sind bugfrei? Nein. Es gibt kein Bugfrei in der Softwareentwicklung — der berühmteste Satz der Softwaretechnik sagt es seit über einem halben Jahrhundert:

„Program testing can be used to show the presence of bugs, but never to show their absence.“ — Edsger W. Dijkstra, 1969

Wer dir Fehlerfreiheit verspricht, verkauft dir die nächste Enttäuschung. Auch in unseren Modulen werden Bugs auftauchen — das ist keine Schwäche des Verfahrens, das ist Software. Aber Dijkstras Satz bekommt durch KI eine neue Pointe: Testen kann die Abwesenheit von Fehlern nicht beweisen — doch jeder Test verkleinert den Raum, in dem sie sich verstecken können. Wenn dank KI 200 statt 20 Tests für eine Funktion definiert werden, wird dieser Raum drastisch kleiner. Das ist keine Theorie — Tielkes gezeigtes Projekt bringt es bei 420.000 Codezeilen auf rund 2.900 API-Tests und 392 Workflow-Tests. Klassische Entwicklung konnte sich diese Gründlichkeit schlicht nie leisten; mit 100 % Dokumentation, unter 10 % technischen Schulden (im gezeigten Fall sogar null) und 85 % Testabdeckung liegen die Ergebnisse KI-nativer Entwicklung deutlich über dem, was sie erreicht. Unser Versprechen ist deshalb nicht Fehlerfreiheit, sondern: Fehler werden schnell gefunden, schnell verstanden und schnell behoben. Wenn ein Bug auftaucht, machen wir es dem Kunden maximal einfach, ihn zu melden — im besten Fall ist er innerhalb von Minuten Geschichte (wie das geht, zeigt der Maschinenraum). Der Unterschied zum 80 %-Plugin liegt nicht darin, dass bei uns nie etwas kaputt geht. Er liegt darin, was dann passiert.

Die Konsequenz: Neubau

Alle betroffenen Plugins wurden ersetzt — from scratch, in Reihenfolge ihrer Schädlichkeit. Frisches Konzept, keine Kopie: weder Funktion noch Algorithmen noch Code wurden übernommen. Sauber auf dem aktuellen Shopware-Core, 6.8-ready by design.

Und weil wir selbst unter halbfertigen Plugins gelitten haben, bekommt jedes unserer Module eine ehrliche Betriebsklasse-Ampel: Was läuft sofort, was braucht Einrichtung, was braucht Infrastruktur. Die Ampel ist unser Anti-80 %-Versprechen.

Das Ende erzählt der Google-Bot

Wie die Geschichte ausgeht, behaupten wir nicht — wir lassen es messen. Auf der Shopware-Seite entsteht ein Live-Panel mit echten Google-Felddaten (Web Vitals, p75) aus dem Shop, in dem unsere Module im Feuer stehen: automatisch aktualisiert, nicht handgepflegt.

Von Web Vitals aus der Hölle zu diesen Zahlen — live, jeden Tag neu.