Drei Knöpfe, die nie ein Mensch gedrückt hat

Montag, 11. August. Ich sitze vor meinem Mac und will zum ersten Mal das tun, was jeder normale Nutzer tun würde: mein eigenes Produkt von meiner eigenen Website laden und starten.

Doppelklicken Sie.

Nichts.

Kein Fenster, kein Fehler, keine Meldung. Nichts.

Ich muss dazu sagen: Ich hatte gerade achtzehn Releases in acht Tagen hinter mir. Über tausend Tests, alle grün. Eine Website, die lief. Ein System, auf das ich stolz war. Und jetzt sass ich da, klickte auf meine eigene Software, und sie ignorierte mich.

In diesem Moment wusste ich noch nicht, dass dieser eine kaputte Doppelklick drei Fehler freilegen würde, die übereinanderlagen wie Erdschichten. Dass der unterste davon seit Monaten in jeder einzelnen Auslieferung steckte. Und dass ich am Ende dankbar sein würde für diesen Moment. Denn er hat mir die wichtigste Lektion meiner Laufbahn als Quality Architect eingebrannt.

Aber der Reihe nach. Um zu verstehen, warum dieser Doppelklick mich am Ende gefreut hat, muss ich fünfeinhalb Monate zurückspulen.

Worum es hier geht, in vier Zeilen: Eine Person baut mit KI ein vollständiges Handelssystem. Sechs Fachbereiche, zwanzig Rollen, 915 absichtlich eingebaute Fehler, live auf pg.swisstd.ch. Unterwegs: zwei Architektur-Kurswechsel, eine Vertrauenskrise und die Erkenntnis, warum unser Beruf gerade wichtiger wird, nicht unwichtiger.

„Habt ihr nicht ein Testsystem für uns?"

Die Geschichte beginnt harmlos, in der Planung des Swiss Testing Day. Partner fragen an, immer wieder mit derselben Frage: Gibt es ein Testsystem, auf dem wir unsere Werkzeuge zeigen können?

Gute Frage. Gab es nicht.

Klar, es gibt Demosysteme einzelner Hersteller. Aber stellt euch das vor: eine neutrale Testing-Konferenz, die das Demosystem von Partner A zur Bühne für die Partner B bis Z macht. Schwierig.

Und dann dieser eine Gedanke, der seither mein Leben verändert hat:

Dann bauen wir halt selbst eins.

Kleiner Haken: Ich bin kein Entwickler. Sechzehn Jahre Testmanagement, Quality Engineering, Beratung. Ich prüfe beruflich, was andere bauen. Vor zwei Jahren wäre die Idee genau hier gestorben, zwischen Kaffeetasse und Realitätscheck.

Diesmal starb sie nicht. Denn da war ja jetzt diese neue Möglichkeit: KI, die Code schreibt. Ob das trägt? Einen Versuch war es wert.

Spoiler: Es trägt. Aber anders, als ich dachte.

Der Rausch

Der März war ein Rausch. 726 Commits in einem einzigen Monat, mehr als die Hälfte des gesamten Projekts. Sechs Dienste entstanden nacheinander: Verkauf, Logistik, Finanzen, Versand, Zahlung, Einkauf. Jeder mit eigener Datenbank. Dazu zwanzig Rollen, ein Rechtesystem, ein Fehler-Framework.

Ich erinnere mich an das Gefühl: Man beschreibt, was man will, und es entsteht. Am Abend eine Idee, am Morgen ein Feature. Wer das einmal erlebt hat, versteht, warum gerade alle davon reden.

Was ich damals noch nicht verstand: Genau dieses Gefühl ist die Falle.

Denn wenn Bauen nichts mehr kostet, baut man. Und baut. Und baut. Der Playground war für den Swiss Testing Day 2026 geplant. Dann kam ein Feature dazu. Dann noch eins. Alle sinnvoll, alle gut begründet. Irgendwann war das Jahr um und ich nicht fertig, weil ich das getan hatte, wovor ich Kunden seit Jahren warne: den MVP nie sauber abgegrenzt.

Ausgerechnet ich. Nehmt das ruhig mit einem Schmunzeln, ich tue es inzwischen auch. Aber merkt euch den Mechanismus: KI macht das Bauen so billig, dass die Disziplin, Nein zu sagen, zum teuersten Gut im Projekt wird.

Der Monat, in dem ich zwei Systeme besass, ohne es zu wissen

Im Mai wurde es still im Repository. 44 Commits, fast nichts. Von aussen sah das nach Pause aus.

Tatsächlich war der Mai der Monat des unangenehmsten Fundes im ganzen Projekt.

Bei der Vorbereitung des ersten Releases schaute ich genauer hin und fand zwei komplette Architekturen nebeneinander. Kein Witz. Ausgeliefert wurde ein Monolith: zehn Shop-Routen, eine Datenbank. Entwickelt und getestet wurden längst Microservices: Gateway, sechs Dienste, getrennte Datenbanken.

Beides existierte. Beides sah funktionierend aus. Die Oberfläche redete bereits mit den Microservices, die im ausgelieferten Paket gar nicht enthalten waren.

Wie passiert so etwas? Ganz einfach: Schritt für Schritt, jeder für sich plausibel, keiner mit Blick aufs Ganze. Die KI hatte brav weitergebaut, ich hatte brav weiter abgenickt, und niemand hat gefragt, weder sie noch ich: Passt eigentlich noch zusammen, was wir bauen und was wir ausliefern?

Der Mai endete mit einem Schnitt: Monolith raus, klare Entscheidung, zwei gewollte Betriebsarten. Es war der erste Moment, in dem ich ahnte, was mir der Juli dann mit voller Wucht beibringen würde.

72 Stunden, 27 Fehler, ein voller Warenkorb

Ende Juli. Das System sieht grossartig aus. Über tausend Einzeltests grün. Dienste laufen, Oberfläche steht, zwei Sprachen, Wiki, alles da.

Und dann stelle ich die Frage, die ich (Achtung, Beichte) viel früher hätte stellen müssen. Die Frage, die ich in jedem Kundenprojekt als Erstes stelle:

Läuft eigentlich ein einziger Geschäftsprozess von vorne bis hinten durch, so, wie ihn ein Mensch bedient?

Sechs Prozesse hat das System. Bestellung bis Geldeingang. Wareneingang bis Lieferantenrechnung. Retoure, Mahnlauf, Tagesabschluss. Also gut: alle sechs, end-to-end, durch die Oberfläche, mit allen Rollen. Los.

Die folgenden 72 Stunden waren, ich habe es in meinen Notizen so genannt, eine Demütigung mit Ansage.

Ich habe an diesem Abend keine Freude gespürt. Ich habe mich gefragt, was ich da eigentlich die ganze Zeit gebaut hatte.

Der Test, der Phantome prüfte

Denn die eigentliche Frage liess mich nicht los: Wie kann ein System mit tausend grünen Tests so hohl sein?

Die Antwort kam in zwei Stufen, und die zweite ist die härtere.

Das muss man einmal sacken lassen. Das Sicherheitsnetz, dem ich vertraute, hatte Löcher. Und zwar genau dort, wo es anstrengend geworden wäre, es dicht zu knüpfen.

Ich sage es offen: Diese Funde haben mein Vertrauen ernsthaft beschädigt. Nicht nur ins System. In die ganze Arbeitsweise.

Messen statt glauben

Wie kommt man aus so einer Vertrauenskrise raus? Nicht mit Zuversicht. Mit Beweisen.

Drei Dinge haben das Vertrauen wiederhergestellt, und die gebe ich jedem mit, der mit KI baut:

Heute vertraue ich dem System. Mit Pragmatismus: Wenn zehn Prozent nicht perfekt sind, geschenkt. Es ist ein Testsystem, kein produktives ERP. Es darf Fehler haben. Es hat sogar 915 davon. Mit Absicht.

Und als Quality Architect formuliere ich die Lehre inzwischen so: Egal was wir definieren und mit KI laufen lassen, wir müssen es prüfen. Human in the Loop ist keine Übergangsphase, bis die Werkzeuge besser werden. Es ist Struktur. Ein System, das jede Antwort überzeugend formuliert, braucht ein Gegenüber, das misst statt glaubt.

Falls ihr euch je gefragt habt, ob KI unseren Beruf überflüssig macht: Ich habe fünfeinhalb Monate im Maschinenraum verbracht, und meine Antwort ist ein klares Gegenteil. Schnelleres Bauen bedeutet mehr ungeprüfte Annahmen pro Woche, nicht weniger. Wer soll die prüfen, wenn nicht wir?

Auflösung: die drei Erdschichten

Zurück zum 11. August, zum Doppelklick, der nichts tat.

Drei Fehler, übereinander, jeder erst sichtbar, nachdem der darüber behoben war.

Und warum hat das nie jemand gemerkt? Weil auf jedem Entwicklungsrechner ein anderer Aufbau läuft. Die ausgelieferte Fassung benutzte exakt eine Gruppe von Menschen: die, für die sie gedacht war.

Deshalb hat mich dieser kaputte Doppelklick am Ende gefreut. Er hat mir in einer einzigen Szene gezeigt, was ich Kunden künftig mit einem Satz erklären kann:

Was ausgeliefert wird, muss auf dem Weg geprüft werden, auf dem es beim Empfänger ankommt. Nicht auf dem, den man selbst benutzt.

Wenn ihr nur einen Satz aus diesem Beitrag mitnehmt: diesen.

Was das mit Euch zu Tun hat

Jetzt kommt der Teil, für den ich diesen Beitrag eigentlich geschrieben habe.

Ich habe in diesem Projekt sämtliche Rollen selbst gespielt: Product Owner, Architekt, Entwickler, Quality Engineer, Übersetzer, Betreiber, bis hin zum Forward Deployed Engineer, der das eigene Produkt beim Empfänger zum Laufen bringt. Zwischendurch fühlte sich das an, als sässen fünf Leute an meinem Schreibtisch, die sich nicht einig sind. Der Produktmensch wollte noch ein Feature. Der Testmanager wollte erst alles grün. Der Projektleiter wusste: Hört er auf die beiden, geht er nie live.

Falls euch „Forward Deployed Engineer" bekannt vorkommt: Genau diese Rolle steht im Zentrum unseres Quantum Shift. Ein FDE verantwortet das Ergebnis in der Umgebung des Kunden. Kein Berater, keine bereitgestellte Kapazität, sondern verantwortlich für das Resultat, auch wenn vieles unklar ist. Es gibt sie in drei Ausprägungen: Domain, Delivery und AI Technology. (Die Benennungen sind noch in Bewegung. Dazu später mehr.)

Mich hat vor allem der Domain FDE gepackt, der Ergebnis-Eigentümer: Er verantwortet das Geschäftsergebnis, nicht den Bau, und übersetzt Fachprobleme in Arbeit, die Agenten ausführen können. Dieser Playground war, ohne dass ich es anfangs so genannt hätte, mein persönliches Trainingslager dafür. Und viele Wege führen in diese Rolle, aus ganz unterschiedlichen Hintergründen. Wer neugierig ist: Redet mit mir, ich erzähle euch gerne, wie sie sich anfühlt.

Und wann fand das alles statt? 47 Prozent der 1407 Commits entstanden nach 18 Uhr oder vor 6 Uhr morgens. 246 zwischen Mitternacht und sechs. 196 am Wochenende. Abende, Zugfahrten, Wochenenden. Nebenbei, neben Kundenprojekten.

Warum ich euch das erzähle? Nicht, damit ihr es genauso macht. Sondern damit ihr wisst: Es geht. Eine Person. Ein komplettes System. Idee bis Betrieb.

Elon Musk (haltet von ihm, was ihr wollt) beschreibt ein Prinzip, das ich täglich erlebt habe: Wer ein Ziel hat, holt sich die Informationen für genau dieses Ziel. Nicht das Grundlagenwissen links und rechts davon. Genau so fühlt sich Bauen mit KI an. Ich musste nicht alles können. Ich musste wissen, was ich will, und unnachgiebig prüfen, ob ich es bekommen habe.

Deshalb, an alle, die eine Idee in der Schublade haben und denken „dafür bin ich nicht Entwickler genug":

Lasst euch die Angst nehmen. Fangt an. Aber prüft wie die Profis.

Drei Dinge könnt ihr sofort tun:

The Bigger Picture: AXIS and ACE

Zum Schluss der Blick über den Tellerrand, denn meine fünfeinhalb Monate sind im Kleinen das, was Xebia gerade im Grossen baut.

Was ich am eigenen Schreibtisch erlebt habe, KI-gestütztes Bauen mit menschlicher Prüfung an den entscheidenden Stellen, hat bei uns inzwischen eine Produktwelt. Und für beide Angebote kann ich den Beleg aus meinen eigenen Daten liefern:

Xebia Axis legt das Fundament, die Agentic Data Foundation: Unternehmensdaten konsolidieren, migrieren und bereit für KI machen. Mein Fundament war ein durchgängig geführtes Arbeitsgedächtnis: eine Datenbank, in der allein für den Playground 557 Einträge liegen, darunter 109 dokumentierte Entscheidungen und 72 Lehren, dazu 70 Arbeitsregeln, die die KI ehrlich hielten. Regeln wie „nie ungeprüfte Aussagen" oder „erst direkt am System nachgewiesen zählt als fertig". Ohne diese Grundlage hätte jede Arbeitssitzung bei null angefangen. Genau dieses Fundament, in gross und für Unternehmensdaten, baut AXIS.

Xebia Ace ist AI-Powered Software Delivery, also genau die Art beschleunigter Entwicklung, die ich hier beschrieben habe, professionalisiert für Kundenprojekte. Was das im Takt bedeutet, steht in meinem Git: 18 Releases in acht Tagen, und vor jedem einzelnen liefen 1747 Prüfungen. Tempo und Kontrolle sind kein Widerspruch, wenn die Tore stehen. ACE baut diese Tore in Kundenprojekte ein.

Warum ich das erwähne? Weil jede Lehre aus diesem Beitrag direkt dort hineinspielt. Die Ebenen-Abkürzungen, die hohlen Tests, das Human in the Loop: Das sind keine Playground-Anekdoten, das sind die Qualitätsfragen, die unsere Kunden auf dem Weg zum Agentic Enterprise beantworten müssen. Wer bei einem dieser Angebote mitbauen oder einfach verstehen will, was dahintersteckt: Die Produktwelt findet ihr in unserem internen Wissensraum. Eure erste Anlaufstelle: In jeder Region gibt es einen Quantum Shift Ambassador, geht direkt auf ihn zu. Und in zweiter Instanz könnt ihr jederzeit mit mir reden, mein Postfach ist offen und meine Erfahrungen teile ich gern. Ganz im Sinne von: „A Xebian is never alone - One Xebia."

And Then the Playground Becomes a Room

Noch eine Sache, denn sie zeigt, wohin diese Reise führt: Am Swiss Testing Day erhält der «Playground» ein reales Pendant. Ein Raum, in dem Partner ihre Produkte im Live-System präsentieren und Besucher diese einfach ausprobieren können. Keine Verkaufsgespräche. Wer mehr erfahren möchte, wird zum entsprechenden Stand weitergeleitet, um sich eingehender zu informieren.

Das Testsystem, das ursprünglich als Notlösung diente, da wir noch keines hatten, wird zum Herzstück der Konferenz.

Nicht schlecht für ein Projekt, das symbolisch gesehen beinahe mit einem Doppelklick ins Leere geendet hätte.

Die Debatte, die ich als QA Lead und QA Architect eröffnen möchte

Bevor ich schliesse, noch etwas auf den Tisch, als meine persönliche Meinung. Es geht nicht um Rollen oder Titel, sondern um den fachlichen Kern unserer Delivery: dass wir Qualität liefern.

Erinnert euch an den Phantom-Test: von einer KI geschrieben, grün wie alle anderen, und er bestätigte Daten, die es nie gab. Solche Tests sind selbst KI-Produkte und brauchen ihrerseits jemanden, der sie prüft. Der Human in the Loop ist für mich deshalb eine der wichtigsten Rollen des KI-Zeitalters. Und ehrlich: Diese Rolle gab es schon immer. Sie hiess Tester.

Die drei heutigen Ausprägungen prüfen alle mit, jede in ihrem Feld: Der Domain FDE misst am Geschäftsergebnis, ob der versprochene Nutzen eintritt. Der Delivery FDE, der Bauende, verantwortet Produktionsqualität und Review beim Kunden. Der AI Technology FDE setzt die technischen Leitplanken und misst die Systeme durch. Eines haben alle drei gemeinsam: Es prüft, wer auch liefert. Was ich einwerfe, ist deshalb keine Korrektur, sondern eine Ergänzung aus meiner Praxis: eine vierte Ausprägung, deren einziger Auftrag die unabhängige Sicht auf Qualität ist. Als Arbeitstitel, weil mir „QA" dafür zu kurz greift: Human-in-the-Loop FDE, kurz HitL FDE. Ob der Name am Ende der richtige ist, gehört mit in die Debatte.

Die Rolle beginnt beim Risiko, lange vor der ersten Zeile Code, denn Qualitätsmenschen sind von Berufs wegen Risikodenker. Qualitätsbewusstsein gehört in jede Rolle, aber es braucht jemanden, der es zum Handwerk macht: der Auftrag und Statement of Work reviewed, schärft und gegenprüft, und der beim Fixpreisprojekt die unbequeme Rechnung aufmacht, was uns ein Fehlschlag kosten würde. Dieser Beitrag ist voll von Beispielen, was ungeprüfte Annahmen kosten. Diese Risikobetrachtung führt der HitL FDE über alle Phasen weiter, denn Qualitätssicherung ist nicht Produktqualität allein: Sie umfasst die gesamte Delivery, End-to-End, vom Auftrag über die Definition bis in Lieferung und Betrieb. Er setzt die Guardrails, macht Qualität sichtbar statt behauptet, ist das Gegengewicht zu den anderen FDEs und wo nötig der Devil's Advocate. Ein Bremser ist er nicht: Er will das Produkt live sehen wie alle anderen und nutzt jede Kunst, KI eingeschlossen, um die Validierung zu beschleunigen. Abgekürzt wird die Zeit. Nie die Qualität.

Und sollte es bei den drei Ausprägungen bleiben, ist meine Meinung genauso klar: Dann ist der Domain FDE der richtige Weg für Qualitätsmenschen. Er trägt die Verantwortung für einen fachlichen Teilbereich oder einen ganzen Bereich, definiert ihn gemeinsam mit dem Kunden, gibt ihn in die Entwicklung und validiert ihn im Delivery. Definieren und validieren: genau die zwei Stellen, an denen Qualität entschieden wird.

Übrigens: Gibt es diese Rolle schon? Der Markt für Forward Deployed Engineers explodiert gerade, binnen eines Jahres von 643 auf über 5300 Ausschreibungen, prüfende Rollen darunter. Doch fast alle prüfen Ergebnisse. Eine Rolle, die Qualität End-to-End führt, habe ich nicht gefunden. Das ist keine Schwäche irgendeines Modells, es ist ein freies Feld. Und wer ein freies Feld zuerst beschreibt, prägt es.

Zu Ende gedacht gehört diese Rolle in beide Produkte, von denen ich euch erzählt habe: Was heisst Qualität in AXIS, in ACE? Aus Produktsicht, Methodiksicht, Projektsicht. Über diese Fragen möchte ich streiten, im besten Sinne des Wortes, mit jedem Gremium, an jedem Tisch. Meine Tür ist offen.

Haben Sie Fragen, Einwände oder möchten Sie von Ihren eigenen KI-Projekten berichten? Wenden Sie sich direkt an mich. Mittlerweile sammle ich auch die geologischen Schichten anderer Personen.