Playwright und TypeScript – auch ohne TypeScript-Kenntnisse: Ein Engineer, eine KI-Schicht und vier Kontrollpunkte.

Ein Repository, das geklont werden kann, das Skills und Regeln enthält sowie einen MCP-getriebenen Playwright, der die Anwendung ohne Hilfe durchläuft, lässt sich leicht versprechen, ist aber schwer umzusetzen. Dieses Projekt existiert bereits als funktionsfähiges Projekt: Klonen Sie es, führen Sie einen Befehl aus – und die Tests werden an einer Live-Website ausgeführt. Die Geschichte dahinter beginnt mit einem veralteten Testumfeld und einer Frage bezüglich der verwendeten Sprachen.

Die Migration, die nie genehmigt wurde

Ein QA-Team hatte vier Jahre damit verbracht, ein veraltetes Selenium-Testumfeld am Laufen zu halten, und einige Kollegen, die später in die Entwicklung wechselten, kannten es sogar noch länger. Sein Kern bestand aus Tausenden von C#-UI-Tests, die im Laufe der Jahre von Autoren erstellt worden waren, die größtenteils das Unternehmen bereits verlassen hatten. Der Umstieg auf Playwright stand schon lange auf der Wunschliste – es ist schneller, zuverlässiger und angenehmer in der Nutzung – doch der Umstieg fand letztendlich nie statt.

Der Grund war banal. Niemand hatte hundert zusätzliche Arbeitsstunden für eine Überarbeitung, deren wirtschaftlicher Nutzen gleich null war, und ein Manager kann nicht einfach zustimmen, weil „das neue Tool sich besser anfühlt“. Technische Argumente sind stets verfügbar, doch je umfangreicher das Toolset, desto teurer die Migration und desto geringer erscheinen die Vorteile im Vergleich dazu. Die Überarbeitung muss im Voraus und in voller Höhe bezahlt werden. Der Nutzen zeigt sich niemals als Zahl in einem Bericht – er zeigt sich vielmehr in weniger fehlerhaften Tests und schnelleren Korrekturen über mehrere Jahre hinweg. Deshalb blieb die Idee unverwirklicht. Playwright und TypeScript tauchten in immer mehr Stellenausschreibungen auf, und untätig zu bleiben wurde sowohl für das Projekt als auch für die betreffende Person immer teurer.

Dann begann ein anderes Team etwas Neues – von vorne: keine veralteten Strukturen, keine Mauer aus Tests, die unbedingt funktionieren müssen, und keine Notwendigkeit für Migrationen. Ein Angebot, dort UI- und API-Automatisierung zu entwickeln, brachte schließlich Playwright und TypeScript in die tägliche Arbeit. Gleichzeitig wurde eine unangenehme Tatsache offensichtlich: Java und C# waren vertraut, und es gab zehn Jahre an Testcode dazu, doch es handelte sich dabei um Testing und nicht um Entwicklung, was eine andere Tiefe erfordert. JavaScript, TypeScript sowie Playwright selbst waren neu. Es tauchte eine Frage auf, die vor zwei Jahren noch rhetorisch geklungen hätte: Inwieweit hält das Unwissen um die Sprache jemanden im Jahr 2026 auf, wo KI vorhanden ist?

Ursprung des Experiments

Es gab keinen einzelnen Tag, der diesen Wandel auslöste. Er entstand allmählich aus der Erkenntnis, dass allein das Testen und das Schreiben von Tests zu nichts führt. QA verdient seinen Platz nicht durch die Anzahl der Fehler oder die Anzahl der Codezeilen, sondern durch die Gestaltung der Produktqualität mittels Prozessen, Dokumentation, Automatisierung und Kommunikation – im Laufe der Jahre hat ein systematischer Ansatz individuelle Heldentaten übertroffen.

Zwei Faktoren trieben in dieselbe Richtung.

Eine solche Aktion stammte von einem in Python mit Claude Code geschriebenen Krypto-Handelsbot, der von jemandem entwickelt wurde, der kein Python kannte. Der Versuch begann mit der Aufregung eines ersten Erfolgs und endete in einem Zusammenbruch, sobald der Code jenseits des Verständnisses aller Beteiligten lag und niemand sagen konnte, warum die Tests fehlschlugen oder wie man sie beheben könnte. Die Lektion bestand darin, dass es einen Unterschied zwischen dem Erstellen von Code und dem Aufbau eines Systems gibt: Der Bot funktionierte zwar, konnte aber nicht gewartet werden. Es existierte keine Übersicht über das Projekt, jede Korrektur brachte neue Probleme mit sich, und die Tokens verschwanden im Kreislauf des Beschreibens von Symptomen anstelle der Suche nach Ursachen.

Der weitere Anreiz kam aus der täglichen Arbeit, wo KI allmählich in die QA-Routinen eindrang. Es wurden Prozesse getestet, die von der Aufgabenvergabe bis zum abgeschlossenen Test reichten, Formulierungsregeln festgelegt, damit das Modell diesen genau folgt, und der gesamte Ablauf machbar reproduzierbar und steuerbar gemacht. Kollegen nutzten KI als intelligenteres Suchfeld oder als „Code-Verkaufsmaschine“. Kaum jemand setzte sie in ein System ein, das Vorhersagbarkeit ermöglichte – was wie eine verschwendete Chance erschien, da gerade der systematische Ansatz den Wert ausmacht.

Diese beiden Ansätze führten zum Playwright-Projekt, das als Hypothese formuliert wurde: Wie weit kann ein Ingenieur mit soliden Grundkenntnissen kommen, wenn KI das Tippen übernimmt – und ist ein vollständiges Testframework ohne das Schreiben einer einzigen Zeile in einer Sprache, die der Ingenieur nicht fließend lesen kann, überhaupt realisierbar?

Warum TypeScript und nicht C# oder Java

Die erste Überprüfung war die offensichtliche. Playwright existiert auch für C# und Java, sodass ein Sprachwechsel vielleicht unnötig war. Der Unterschied lag nicht im Steuern des Browsers. Dieser Teil ist überall identisch – mit derselben API, denselben Selektoren und denselben Browsern. Der Unterschied liegt darin, wie die Tests organisiert und ausgeführt werden.

In JavaScript und TypeScript bietet Playwright einen eingebauten Testlaufzeitmechanismus, der parallele Ausführung, Fixtures, Berichte sowie automatische Überwachung unterstützt. Für C# und Java gibt es etwas Derartiges nicht. Teams greifen auf die Tools zurück, die bereits im jeweiligen Ökosystem verwendet werden – sei es xUnit, NUnit, JUnit oder TestNG – und Playwright stellt lediglich Basisklassen bereit, wodurch Organisation und Parallelisierung manuell umgesetzt werden müssen. Das ist die eigentliche Einschränkung: nicht seltsame Syntax oder fehlende Methoden, sondern das erneute Erfinden von Lösungen, einschließlich Parallelisierung, Datenausisolierung pro Thread, Infrastruktur und Berichterstattung – Probleme, die bereits einmal gelöst wurden und am besten vermieden werden sollten. Daneben stand eine Option, die bereits vollständig vorbereitet war, allerdings in einer Sprache, die niemand kannte. Playwright entwickelte sich neben JavaScript, weshalb es dort als natives Werkzeug und nicht als Fremdkörper fungiert.

Was „ohne Vorkenntnisse erstellen“ wirklich bedeutet

Das Projekt als ohne Kenntnisse entwickelt zu bezeichnen, wäre nicht nur ungenau – es wäre eine offene Lüge. Hinter diesem Anspruch stehen zehn Jahre Erfahrung in der Qualitätskontrolle: das Aufbauen von Entwicklungsprozessen von Grund auf sowie das Testen von Systemen aller Art, von Webanwendungen und APIs bis hin zu mobilen Apps. Genau diese Erfahrung verhinderte, dass die Arbeit in einem Meer an generiertem Code unterging. TypeScript und Playwright blieben dabei stets die unerwarteten Helfer.

Einige Kurse halfen. Zwischen früheren Experimenten und dieser Entwicklung befassten sich mehrere Anthropic-Kurse mit der Gestaltung von Agenten, dem Verknüpfen von Fähigkeiten sowie der Formulierung von Aufgaben für KI. Sie ergänzten die praktische Erfahrung, ersetzten sie aber nicht. Entscheidend war die Herangehensweise. Das Projekt entstand nicht aus dem Wunsch eines Programmierers nach einigen Tests, sondern von einem Ingenieur, der dem Modell die Regeln, die architektonischen Grenzen sowie die zu überprüfenden Aspekte mitteilte und es anschließend innerhalb dieser Grenzen arbeiten ließ – dadurch verwandelte sich ein unübersichtlicher Austausch in einen geordneten Prozess.

Ein Skelett – mit zwei Einschränkungen

Zwei Punkte müssen vor der Beschreibung der Struktur und ihrer Entscheidungen erwähnt werden.

Zunächst handelt es sich beim Projekt um ein Skelett und nicht um ein fertiges Produkt, das genutzt, angepasst und weiterentwickelt werden soll. Es wird geteilt, um einen Ansatz zu zeigen, nicht um Perfektion zu behaupten. Wer nach einem fertigen Werkzeug sucht, wird enttäuscht sein, während jemand, der ein Modell zur Erstellung eines Systems auf Basis von KI sucht, eines finden wird. Teams haben ihre eigenen Einschränkungen, Sicherheitsanforderungen und Integrationen, und ein Design, das für eine öffentliche Demonstration geeignet ist, benötigt möglicherweise erhebliche Überarbeitungen im Kontext von Unternehmens-SSO, MFA, speziellen Regeln für Testdaten sowie einem Testmanagement-System. Daher ist die Begründung hinter dem Code der portable Teil.

Zweitens war das Werkzeugset minimal. Es bestand aus Claude Code mit der grundlegenden monatlichen Abonnementgebühr von zwanzig Dollar, Visual Studio Code als Editor, einem konfigurierten MCP-Server für Playwright, der es dem Modell ermöglicht, die Anwendung selbst zu erkunden, und – vermutlich am wichtigsten – einem klaren Kopf sowie etwas Freizeit. Es kamen weder teure Unternehmenslösungen noch komplexe Infrastrukturen oder verteilte Testausführer zum Einsatz. Alles läuft auf einem gewöhnlichen Laptop, was ebenfalls eine Botschaft ist: Um damit anzufangen, ist nichts Übernatürliches nötig, nur ein Verständnis dafür, was gebaut wird, und der Wunsch, es zu bauen.

Was das Projekt umfasst und wie es strukturiert ist

Das Ziel ist Toolshop, ein öffentlicher Demo-Online-Shop, der zum Üben mit Automatisierungszwecken entwickelt wurde. Die Wahl ist wichtig: Es handelt sich um kein geschlossenes System ohne Geschäftskontext, sodass jeder das Repository klonen, Abhängigkeiten mit einem Befehl installieren und Tests an einer Live-Seite durchführen kann – ohne Konten anlegen zu müssen oder in Dokumentationen zu wühlen.

Die Suite umfasst siebenunddreißig Tests, davon vierunddreißig erfolgreiche und drei absichtlich fehlgeschlagene, damit der Bericht zeigt, wie ein Fehler aussieht. API-Tests überprüfen die Serverlogik, UI-Tests die Benutzeroberfläche, und hybride Tests erstellen über die API einen Zustand, bevor dieser im Browser überprüft wird. Das reicht aus, um die Architektur zu demonstrieren, ist aber bei weitem nicht ausreichend, um etwas über die Abdeckung des Produkts zu sagen – diese hängt von einem bestimmten Produkt und dessen Geschäftsrisiken ab und nicht davon, wie viele Tests eine Demo enthält. Die Verzeichnisstruktur:

config/
 env.ts // The only place where environment variables are read
 timeouts.ts // Timeouts, also in one place
core/
 run-user.ts // The user registered by this specific run
 global-setup.ts // Register → UI login → data snapshot → download OpenAPI spec
 global-teardown.ts // Cleanup after the run: remove favorites and the user
 allure-labels.ts // Parses [Section / Subsection] from the test name into report structure
 allure-categories.ts // Buckets for triaging failures in the report
api/
 generated/schema.d.ts // Types generated from OpenAPI, never touched by hand
 types.ts // Domain types derived from the schema
 client.ts // openapi-fetch, paths and params checked by the compiler
 contract.ts // Runtime validation of API responses against the schema
 auth.api.ts // Typed clients on top of api/client.ts
pages/
 base.page.ts // Base page class
 components/ // Elements present on every page (site header)
 auth/ // Page Objects for authorization pages
 account/ // Account area: account, profile, favorites
 shop/ // Catalog, product page, checkout
fixtures/
 base.fixture.ts // All dependency injection, test/expect only imported from here
data/ // Strings and routes, so they don’t live inside tests
utils/ // Logger, reference data snapshot
tests/
 auth/ // Everything auth-related in one folder
   auth.api.spec.ts // API: login, token lifetime
   registration.api.spec.ts
   login.ui.spec.ts // UI: login form, errors, logout
 catalog/
   products.api.spec.ts
   catalog.ui.spec.ts
 cart/
   cart.ui.spec.ts
 favorites/
   favorites.api.spec.ts
   favorites.hybrid.spec.ts // Hybrid: state via API, verification via UI
 profile/
   profile.hybrid.spec.ts
 contract/
   contract.api.spec.ts // Matching live API responses against the spec
 demo/ // Tests tagged @demo that fail on purpose
docs/ // Feature maps, checklists, test cases, plans
.claude/ // AI layer: rules, skills, agents, hooks```

Strukturentscheidungen, die skalierbar sind

• Zuerst die Funktionalität, danach die Schicht. Eine Entscheidung mag auf den ersten Blick seltsam erscheinen, doch sie bestimmt maßgeblich, wie gut alles skalieren kann: Die Tests werden nach Funktionalitäten gruppiert, und die Schicht dient als Dateinamenssuffix, wie in login.ui.spec.ts, auth.api.spec.ts und checkout.hybrid.spec.ts. Ein Entwickler, der die Autorisierungslogik ändert, findet alle damit verbundenen Tests unter tests/auth/ und muss nicht durch drei Ordner wühlen. Bei dreißig Tests fällt das niemandem auf, und eine schichtbasierte Struktur sieht ordentlich aus. Bei dreihundert Tests wird tests/ui/ zu einem Haufen aus sechzig Dateien, denn eine geänderte Funktionalität beeinflusst alle zu ihr gehörenden Tests, unabhängig von der Schicht. Verstreute Tests verwandeln die Analyse in eine Suche.
• Wenn selbst Funktionen überfüllt werden. Durch Tausende von Tests kann eine Funktionskategorie auf Hunderte von Dateien anwachsen. Der nächste Schritt besteht darin, Unterordner nach Unterfunktionen oder Szenarien zu erstellen, wie zum Beispiel tests/auth/login/, tests/auth/registration/ und tests/auth/password-reset/, was die gleiche Idee fortsetzt, den Kontext neben dem Code zu halten. Ebenso sollten Hunderte von Tests keine einzige Datei teilen, da dies zu einem unlesbaren und unüberprüfbaren „Monster“ führt.
• Hybrid als Ausgangspunkt. Die Demo ist in API-, UI- und Hybrid-Tests unterteilt, doch ein echtes Projekt muss das nicht nachahmen oder für jede Funktion drei Schichten erstellen. Es kann keine eigenständige API geben, die es wert ist, getestet zu werden, oder die UI-Tests können bereits hybrid sein, wobei Voraussetzungen über die API oder die Datenbank eingestellt werden und nur der für die Benutzeroberfläche relevante Teil im Browser überprüft wird. Das ist legitim, denn Trennung um der Trennung willen ist ein Fehler. Das Schreiben von hybriden UI-Tests von Anfang an vermeidet reine UI-Tests, bei denen der Zustand über den Browser übertragen wird und dadurch Minuten verschwendet werden. Struktur ist ein Mittel, und jede zusätzliche Abstraktion erhöht die Wartungsaufwände.

Vier Entscheidungen, die den Rest erklären

Das Repository dokumentiert vierzehn architektonische Entscheidungen in .claude/rules/architecture.md, wobei jede davon die Frage „Warum auf diese Weise?“ beantwortet und nicht „Was ist das?“ Die vier wichtigsten werden hier erneut erläutert, da der Rest besser im Repository belassen wird, anstatt paraphrasiert zu werden.

Jeder Ausführungsvorgang registriert seinen eigenen Benutzer

Die übliche Einstellung besteht aus einem Testkonto, das von allen Tests gemeinsam genutzt wird. Das funktioniert solange, bis die Testsuite wächst und die Tests parallel ausgeführt werden. Dann leert ein Test den Warenkorb genau in dem Moment, in dem ein anderer prüft, ob sich ein Produkt darin befindet, was zu einem Fehler führt, der nur einmal alle zwanzig Ausführungen auftritt und niemals auf dem eigenen Rechner des Debuggers.

Die Regel klingt langweilig: Jeder Lauf erhält seinen eigenen Sandbox. Das unterscheidet sich davon, Versprechen zu machen, gemeinsame Daten zu vermeiden oder danach aufzuräumen. Es bedeutet, dass physisch niemand vorhanden ist, mit dem es zu Kollisionen kommen könnte. In der öffentlichen Demo übernimmt ein neu registrierter Benutzer in global-setup diese Aufgabe. Eine Unternehmensumgebung kann dies durch Mieterbeschränkungen, gemeinsame Entitäten oder bereits vorhandene Datenwiederherstellungsprozesse blockieren. Das Prinzip bleibt bestehen – die Methode zur Erstellung des Sandboxes ist eine separate Frage.

Dieselbe Logik führt zu retries: 0. Eine Wiederholung dient als Stummschalter und nicht als Absicherung: Sie lässt eine echte Ressourcenkonfliktsituation als erfolgreich erscheinen und verschiebt die Konsequenzen auf den Zeitpunkt, an dem sie am meisten schaden. Ein Test, der eine Wiederholung benötigt, weist keinen instabilen Ablauf auf, sondern meldet einen Isolationsfehler – und dieser Bericht verdient eine genaue Prüfung. Die Kosten sind klar definiert: In der Demo erfordert die Registrierung eines Benutzers nur eine Anfrage, die immer erfolgreich ist, während der Mechanismus an anderen Stellen anders ist.

Die Typen stammen aus der Spezifikation, und ein Vertragstest überprüft diese Spezifikation

Es handelt sich dabei um zwei unterschiedliche Überprüfungen, die ständig verwechselt werden.

• Die erste erfolgt zur Kompilierzeit. Die API verfügt über ein OpenAPI-Dokument, aus dem die Typen generiert werden; daher verhindert ein im Code referenziertes, aber in der Spezifikation fehlendes Feld, dass das Projekt kompiliert wird. Dies dauert zwei Sekunden und erfordert keine Anfrage an den Server.

Der zweite Prüfpunkt fragt, ob der Server tatsächlich seinen eigenen Spezifikationen entspricht. Ein generierter Typ kann das nicht beweisen, da er lediglich Übereinstimmung mit dem Dokument nachweisen kann. Vertragstests rufen die echte API auf und vergleichen die tatsächlichen Antworten mit dem Schema. Schon beim ersten Ausführungsvorgang stießen sie auf eine Pfadunterschiedlichkeit: Im Dokument stand products/{productId}, während der Code products/{id} verwendete. Ein anderes Mal zeigten sie, dass der Katalogfilter by_category_slug aufrief – ein Parameter, der überhaupt nicht in den Spezifikationen enthalten ist. Der Server akzeptiert ihn und die Tests laufen erfolgreich, sodass alles „funktioniert“. Doch ein außerhalb des Vertrags liegender Parameter darf sich nicht vom Vertrag unterscheiden. Er kann nur eines Tages still verschwinden.

Ein Vertragstest ist daher keine Überprüfung darauf, ob ein Endpunkt funktioniert. Er prüft vielmehr, ob es sich um den Endpunkt handelt, auf den sich alle geeinigt haben.

Ein Token, das dreihundert Sekunden lang gültig ist

Der ursprüngliche Entwurf lud sich vor dem Ausführen einmal ein, speicherte das Token in einer Datei und ermöglichte es jedem Worker, es zu lesen. So wäre es fast gewesen. Doch das Token dieser API ist genau dreihundert Sekunden lang gültig – was durch einen speziellen Test überprüft wird, indem zwei Felder innerhalb des Tokens verglichen werden; der gesamte Testzyklus dauert jedoch länger. Der langsamste Test würde mit einem ungültigen Token enden und mit einem 401-Fehler fehlschlagen, was wie ein Berechtigungsfehler und nicht wie ein Ablaufzeitfehler aussieht, wodurch die Fehlersuche an der falschen Stelle beginnen würde.

Deshalb enthält die Datei Anmeldedaten und nicht Token. Jeder Worker speichert sein eigenes Token im Speicher und erneuert es frühzeitig. Daraus folgt eine Konsequenz: Das Token muss immer genau dort abgerufen werden, wo es verwendet wird, und niemals in eine Variable ganz oben in einem Block übernommen werden. Eine solche Zeile allein würde genau das Problem wieder auftreten lassen, das der Entwurf eigentlich beseitigen sollte.

Snapshot-Referenzdaten einmalig und veränderliche Zustände niemals

Kategorien, Marken sowie die Produktseite ändern sich zwischen den Ausführungen nicht. Sie können vor Beginn einmal abgerufen und an die Tests übergeben werden, sodass dreißig Tests nicht jeweils dieselbe Liste anfordern. Favoriten, der Warenkorb und das Profil dürfen niemals in einen solchen Snapshot aufgenommen werden, da die Tests sie selbst ändern. Das Erstellen von Snapshots für veränderliche Zustände ist keine Optimierung – es erzeugt verzögerte Daten: Ein Test liest etwas, das vor fünf Sekunden noch wahr war, scheitert anschließend, und jemand sucht nach einem Fehler in einer Anwendung, der gar nicht vorhanden ist.

Auch die Aufräumarbeiten folgen derselben Logik. Sie werden nacheinander ausgeführt – zunächst die Entitäten und danach deren Eigentümer – und scheitern niemals; kurze Berechtigungen führen lediglich zu einer Warnung. Ein fehlerhafter Teardown verwandelt einen einzelnen fehlerhaften Test in eine fehlerhafte Ausführung mit der falschen Erklärung – die schlimmste Art von Fehlermeldung.

Die KI-Schicht

Betrachten Sie, was passiert, wenn Claude Code in einem Projektverzeichnis geöffnet wird und die Anfrage „Schreibe Tests für den Warenkorb“ erhält. Das Modell erhält lediglich diese Anfrage und nichts weiter. Es weiß nicht, dass gemeinsame Konten verboten sind, dass Lokatoren von einer überprüften Karte stammen müssen oder dass das Festlegen eines globalen Zählers in einer parallelen Suite eine Falle darstellt. Es tippt einfach – und tut dies recht gut – sodass der Code ansprechend aussieht und vermutlich auch läuft. Die meisten Menschen hören hier auf und bezeichnen das als Arbeit mit KI.

Die KI-Schicht formuliert das Problem um. Die Frage lautet nicht mehr, was das Modell erraten wird, sondern was es wissen muss und was es niemals tun darf. Sie setzt sich aus fünf Komponenten zusammen, von denen jede ihre eigene Aufgabe hat.

• CLAUDE.md, immer geladen. Eine Datei im Projektverzeichnis, die zu Beginn jeder Sitzung geladen wird. Sie dient als Einführung für neue Kollegen – in diesem Fall das Modell – und ist auf zwei Bildschirme verteilt: Was das Projekt ist, wo die Elemente sich befinden, die fünf wichtigsten Punkte sowie was ausdrücklich verboten ist. Das Wort „immer“ legt den Rahmen fest, da jede Konversation die Nutzung der Datei im jeweiligen Kontext bezahlt. Nur das, was jedes Mal benötigt wird, kommt darin vor. Vierzig Stilrichtlinien befinden sich in einer separaten Datei, auf die sie verlinkt ist.
• Regeln/, Gründe und keine Befehle. Diese Dateien enthalten Architekturentscheidungen, Codekonventionen sowie Browserverfahren. Ein Befehl besagt, dass das Token nicht in eine Variable übertragen werden darf. Eine Regel erklärt, dass das Token dreihundert Sekunden lang gültig ist; daher stirbt ein in die oberste Ebene übertragenes Token während des Laufs ab und führt im langsamsten Test zu einem Fehler mit 401. Mit dem Grund vor Augen benötigt das Modell keine spezifische Verbotsregel – es erkennt die Problemklasse und findet sie auch in unbekannten Umgebungen.
• Fähigkeiten/, Verfahren mit Kontrollmechanismus. Eine Fähigkeit ist ein Leitfaden für eine bestimmte Aufgabe: Schritte, eine Beschreibung, Auslösephrasen, ein festgelegtes Modell sowie eine Liste der erlaubten Tools. Die Tool-Liste stellt eine echte Beschränkung dar und keine Dokumentation. Die Fähigkeit, die Testfälle erstellt, kann keine Befehle ausführen und kann daher auch keine Tests einfach so starten, so sehr sie es auch wünschen würde.
• Agenten – eine separate Einheit mit eingeschränkten Rechten. Zwei praktische Gründe rechtfertigen dies. Der erste ist der Kontext: Eine Ausgabe einer Seite mit allen Attributen umfasst Tausende von überflüssigen Datenpunkten, und wenn diese in das Hauptgespräch gelangen, verdrängt die Markup-Struktur die Diskussionen zur Checkliste. Ein Agent arbeitet in seinem eigenen Kontext und liefert ein Ergebnis statt Rohmaterial. Der zweite Grund sind die Grenzen: Der Forschungsagent hat keinen Zugriff auf Testcode, weshalb Erkundungen lediglich Dokumentation statt tatsächlichen Codes liefern. Der Agent, der Tests schreibt, kann diese möglicherweise nicht ausführen, sodass das Schreiben ohne Ausführung ausreicht.
• Hooks – durchgesetzt und nicht in Erinnerung behalten. Eine Prose-Regel gilt solange, wie sich jemand daran erinnert, weshalb die teuersten Sperren zu Hooks werden: kleine Skripte, die vor einer Aktion ausgeführt werden und diese ablehnen können. Generierte Typen sowie .env-Dateien sind unveränderlich. git push --force, --no-verify und --amend werden automatisch abgelehnt. Ein Hook überzeugt oder erklärt danach nicht. Die Aktion findet nicht statt, und die Antwort nennt den Grund sowie den richtigen Weg.

Jeder Punkt in einer Zeile: CLAUDE.md ist die Einführung für Neulinge, Regeln sind die Teamstandards, Fähigkeiten sind Prozessleitfäden, Agenten sind Praktikanten mit eingeschränktem Zugriff, und Hooks sind die Schranke, die geschlossen bleibt.

Dieselbe Ebene bei einem Live-Ticket

Abstraktionen machen nur dann Sinn, wenn eine reale Aufgabe durch sie abgewickelt wird. Nehmen wir PROJ-431, „Bezahlung einer Bestellung per Karte“. Die übliche Arbeitsabfolge hat nichts mit KI zu tun: Jemand testet die Funktion manuell, jemand erstellt eine Checkliste, jemand wandelt sie in Fallbeispiele um und jemand automatisiert sie. Eine Person kann alle vier Schritte erledigen oder drei Personen können sie aufteilen. Für den Prozessfluss spielt es keine Rolle, welcher Weg gewählt wird – genau das ist der Sinn, denn der Prozessfluss wird einfach auf den bestehenden Ablauf aufgesetzt, anstatt ihn zu ersetzen. Die Aufgabennummer ist der rote Faden, der durch alles verläuft, und wird den Namen einer Funktion oder eines Branches vorgezogen, weil sie Beständiger gegenüber Umbenennungen und Umzuweisungen ist.

Schritt eins: die Checkliste

Der QA-Engineer startet die Skill und gibt ihr die Nummer. Da MCP mit Jira verbunden ist, liest die Skill das Ticket direkt – inklusive Beschreibung, Akzeptanzkriterien und, was oft am nützlichsten ist, der Kommentare, in denen ein Entwickler bereits die Hälfte der Funktionsweise erläutert hat, ohne die Beschreibung zu aktualisieren. Fehlt MCP oder ist das Ticket leer, beschreibt der Engineer die Funktion in der Anweisung. Der Pipeline benötigt eine Eingabe und kümmert sich nicht darum, woher sie stammt.

Dann beginnt der Schritt, für den alles entwickelt wurde. Die Funktion erstellt keine Checkliste aus dem Tickettext. Stattdessen ruft sie den Forschungsagenten auf, der in die Anwendung – sei es im lokalen oder Testumfeld – eintritt, die Seiten der jeweiligen Funktion besucht, auf Elemente klickt, den aktiven DOM liest, selbst die API aufruft und die Antworten mit den Spezifikationen vergleicht. Erst danach wird die Checkliste erstellt – basierend auf dem, was tatsächlich vorhanden ist, und nicht auf dem, was das Ticket versprochen hat. Akzeptanzkriterien sind Eingabedaten, keine Gewissheiten, und die Hälfte der Abweichungen davon von der Realität stellen bereits die ersten Fehler der Aufgabe dar, die bereits vor dem Entstehen jeglichen Codes entdeckt werden.

Zwei Dateien entstehen, und das Wichtigste hier ist, sie voneinander zu trennen. Die erste ist die Checkliste: priorisierte Geschäftsscenarien im Format des Teams – keine Elementüberprüfungen. Ein roter Rand um ein Feld bedeutet kein Scenario; ein Benutzer, dem die Karte eines anderen entzogen wird und dem erklärt wird, warum, ist hingegen ein Scenario. Die zweite Datei ist die Funktionskarte, die überprüfte Lokatoren, API-Felder, Validierungsregeln sowie auf dem Weg dorthin entdeckte Probleme enthält. Die Checkliste ist das direkte Ergebnis der Aufgabe, während die Karte als Grundlage für spätere Schritte dient. Der QA-Engineer liest die Checkliste, streicht das Unnötige durch, fügt hinzu, was nur eine bestimmte Person weiß, und diese Überprüfung dient als Kontrollpunkt: Ohne Freigabe darf nichts weitergehen.

Schritt zwei: Testfälle

Wer auch immer Schritt eins ausgeführt hat, kann fortfahren – oder eine andere Person, falls manuelle Tests und Automatisierung getrennt werden. Eine zweite Aufgabe beginnt mit derselben Aufgabennummer und findet selbstständig die Checkliste sowie die Karte. Der Ingenieur entscheidet, was abgedeckt werden soll – alles oder nur das, was vereinbart wurde. Die Aufgabe wandelt diese Punkte in Fälle um und klärt pro Fall eine Sache: die Schicht, zu der die Überprüfung gehört.

• Regeln, die vom Server durchgesetzt werden, werden zu API-Tests.
• Dinge, die der Benutzer sieht, werden zu UI-Tests.
• Eine Überprüfung, die für eine Aussage fünfzehn Einstellklicks erfordert, wird zu einem hybriden Test, wobei der Zustand über die API erstellt wird und nur der sichtbare Teil visuell überprüft wird.

Fehler hier kosten mehr als schlecht verfasste Fälle, denn sie führen zu einer langsamen, überschneidenden Abdeckung, die später niemand mehr zu löschen wagt. Die Fachkraft fügt außerdem zu jedem Fall einen Service-Abschnitt hinzu: Daten, die verwendet werden sollen, Lokatoren, was einzigartig sein muss, was bereinigt werden soll und unter welchem Konto. Für einen Menschen sieht das wie Papierkram aus. Für den nächsten Schritt handelt es sich dabei um eine fertige Spezifikation. Der Ingenieur prüft und genehmigt sie – das ist die zweite Kontrollstelle. Teams in Qase oder TestRail können hier eine Fachkraft hinzufügen, die die genehmigten Fälle über die API hochlädt und sie später als automatisiert markiert.

Schritt drei: Automatisierung

Die Automatisierungsfunktion übernimmt außerdem die Aufgabennummer und holt die Checkliste, die Fälle sowie die Karte selbst ab. Ihr erster Schritt ist unerwartet: Sie prüft, wie aktuell die Karte ist. Jeder Abschnitt weist ein Überprüfungsdatum auf, und alles, was älter als einen Monat ist, gilt nicht mehr als Fakt, sondern als Behauptung. Die Funktion lehnt weder ab noch vertraut blind. Sie verschiebt veraltete Teile in einen Risikobereich des Plans und überlässt die Entscheidung einem Menschen – entweder eine erneute Erkundung durchzuführen oder das Risiko in Kauf zu nehmen. Ein veralteter Standort wird dennoch sichtbar, allerdings erst nach drei Schritten als Zeitüberschreitung, deren Ursache verborgen bleibt.

Danach folgt der Plan: Welche Dateien verwendet werden, welche Daten jeder Test benötigt, was vor dem Ausführen erstellt und danach entfernt wird, welche Seiten- und Client-Methoden hinzugefügt werden und welche Fragen noch offen sind. Der Plan ist die dritte und wichtigste Hürde, denn er entscheidet darüber, ob der Batch sicher parallel ausgeführt werden kann – Änderungen danach sind kostspielig.

Sobald der Plan genehmigt wurde, geht er an den Agenten für die Codeerstellung, dessen entscheidendes Merkmal darin besteht, dass er keine Lokatoren erfindet. Fehlt ein benötigter Lokator in der Karte, so vermutet er keinen ähnlichen und versteckt die Lücke auch nicht, indem er den Test überspringt. Stattdessen hinterlässt er im Code eine Anmerkung, dass der Lokator nicht überprüft wurde, und meldet dies. Der Test wird weiterhin geschrieben und scheitert – was richtig ist, denn das Problem bleibt sichtbar und löst sich nicht auf.

Was früher separate Befehle waren, findet sich nun in diesem Schritt wieder: Ausführen, Fehler lesen, beheben. Jeder Test erhält zwei Versuche, danach stoppt der Agent und gibt auf. Ein sequenzieller Ausführungsvorgang überprüft die Logik, während zwei parallele Ausführungen die Isolierung prüfen. Es ist kein zusätzliches Button erforderlich, da nichts davon eine menschliche Entscheidung erfordert. Es handelt sich um ein Verfahren, das in den Regeln festgelegt ist.

Die hier genannten Verbote sind eindeutig und stehen nicht zur Diskussion:

• Deaktivieren Sie keinen fehlerhaften Test, um den Ausführungsvorgang als erfolgreich darzustellen.
• Erhöhen Sie die Anzahl der Wiederholungsversuche nicht.
• Swächen Sie keine Überprüfung heimlich ab, um sie dem beobachteten Verhalten anzupassen.

Falls sich die Anwendung falsch verhält, ist ein roter Test das richtige Ergebnis.

Schritt vier: Überprüfung und Freigabe

Überprüfung und Commit gehören zu zwei verschiedenen Fähigkeiten und nicht zu einer – eine bewusste Trennung, denn ein Schritt, der mit der Absicht zum Commit beginnt, neigt eher dazu, Gründe zum Nicht-Commitzen zu finden. Die Überprüfung beinhaltet projektbezogene Kenntnisse, die ein allgemeiner Prüfer nicht besitzt: Was hier eine gemeinsame Einheit bedeutet, was ein Token am Anfang eines Blocks gefährdet und warum sich eine Behauptung bezüglich eines globalen Zählers irreführend auswirkt. Jeder Eintrag in der Liste stammt von einem früheren Fehler in diesem Prozess. Um zu verhindern, dass diese Trennung zur Formalität wird, hinterlässt die Überprüfung einen „Fingerabdruck“ des untersuchten Diffs, und das Commit weigert sich, fortzufahren, wenn sich der Diff seitdem geändert hat. Das ist kein Schutzmechanismus im engeren Sinne – es handelt sich vielmehr um eine Frage mit einer exakten Antwort: Wurde dieser Code überprüft, oder handelt es sich um einen anderen Code? Der Unterschied zwischen einem Prozess und einer Gewohnheit liegt genau darin.

Sobald die gesamte Kette abgeschlossen ist, enthält PROJ-431 die vollständige Übersicht: Was erforscht wurde, was zur Überprüfung ausgewählt wurde, was durch Automatisierung abgedeckt ist, was manuell bleibt und was nicht automatisiert werden wird – sowie der Grund dafür. Der Grund liegt nicht in einer Vorliebe für Dokumentation. Sechs Monate später wird bei einer Retrospektive eine lebende Person die Frage stellen, warum ein Szenario nicht abgedeckt ist, und es muss bereits eine Antwort geben.

Was über die Aufgabe hinausbesteht

Das größte Risiko der Konfiguration liegt nicht im schlecht generierten Code. Vielmehr verfällt der Kontext nach sechs Monaten zu einem unübersichtlichen Haufen, wobei niemand sicher ist, welchem Datei man vertrauen kann. Daher haben die Artefakte drei getrennte Lebenszyklen, und ihre Mischung ist verboten.

• Regeln bestehen so lange wie das Projekt und ändern sich nur zusammen mit dem Code.
• Die Feature-Karte bleibt über Jahre hinweg bestehen und gehört zum Feature und nicht zur Aufgabe. Sie wird durch datierte Abschnitte, neue Seiten sowie neu auftretende Probleme erweitert, wird aber niemals für jede einzelne Aufgabe neu erstellt.
• Checklisten, Fallbeispiele und Pläne gehören zu einer Aufgabe und werden zu Geschichte, sobald diese abgeschlossen ist.

Ohne diese Aufteilung existiert ein Jahr später die Lagekarte in zehn Exemplaren, die über verschiedene Aufgabennummern verteilt sind, wobei die Hälfte davon falsch ist und es keine Möglichkeit gibt, herauszufinden, welche Hälfte. Wenn die Karte einer Eigenschaft an Größe zunimmt – wie es bei Karten großer Eigenschaften der Fall ist – ähnelt die Lösung der für Code: Man teilt sie entlang natürlicher Grenzen wie Seite, Unter-Eigenschaft oder Szenario in Teile auf und führt einen kurzen Index darüber, was wo zu finden ist. Es gilt außerdem eine strenge Eingaberegel: Nur überprüfte Fakten dürfen in die Karte aufgenommen werden, also das, was der Agent tatsächlich in der Live-Anwendung gesehen hat, inklusive Datum. Vermutungen und Wiedergaben aus Tickets gehören nicht dazu. Eine Karte, die solche Elemente zulässt, ist innerhalb eines Sprints wertlos, und Fakten können danach nicht von Vermutungen getrennt werden.

Nichts davon ist ein universelles Rezept. Vier Pipeline-Schritte, fünf Komponenten der KI-Schicht, Türen sowie die Lebensdauer von Artefakten bilden eine mögliche Anordnung. Die Teams unterscheiden sich in ihrer Größe, ihren Produkten und Werkzeugen, weshalb die Hälfte der Details anders umgesetzt werden muss. Einige Ansätze funktionieren, andere erfordern Anpassungen, wieder andere halten nicht – und das ist in Ordnung.

Der zentrale Punkt bleibt jedoch unverändert: Die KI-Schicht muss ordnungsgemäß aufgebaut werden, sodass das Modell innerhalb der Grenzen des Teams unter Verwendung der dortigen Artefakte die Regeln des Teams befolgt, während die routinemäßigen Aufgaben wie das Lesen von Tickets, das Schreiben ähnlicher Fälle, das Auswählen von Schichten, das Suchen nach Orten, das Erneut Ausführen und Beheben von Fehlern sowie die erneute Überprüfung derselben Fehlerquellen dem Team erspart bleiben. QA-Ingenieure werden nicht ersetzt und der bestehende Prozess nicht abgeschafft. Die Zeit, die für Aufgaben aufgewendet werden könnte, die an andere übertragen werden können, wird einfach eingespart.

Sind erfahrene Mitarbeiter immer noch notwendig?

Senior-Ingenieure sind mehr denn je gefragt – allerdings in einer veränderten Rolle. David Heinemeier Hansson hat festgestellt, dass die beste beschleunigende Wirkung durch Agenten von den erfahrensten Fachleuten erzielt wurde, jenen, die beurteilen können, ob die Ausgabe des Agenten für den Einsatz geeignet ist.

Einst wurden Ingenieure dafür geschätzt, Code zu schreiben, die Syntax zu kennen und Aufgaben schnell zu erledigen – was sinnvoll war, da Code das Hauptprodukt war. Mit KI hat sich dieser Wert um ein Vielfaches verändert, und das nicht nur um ein paar Prozent. Die Maschine schreibt den Code, der Mensch entscheidet, was geschrieben werden soll, warum, innerhalb welcher Grenzen und wie man überprüfen kann, dass das Ergebnis nicht falsch ist.

Stellen Sie sich zwei Spezialisten vor. Der erste öffnet Claude Code und bittet um einen Anmeldetest. Dieser wird geschrieben und bestanden, wodurch der Spezialist produktiv wirkt – was heute zutrifft. Ein Monat später bricht der Test zusammen, die Ursache bleibt unklar, Patches werden zufällig eingefügt, während Tokens verbraucht werden, und letztendlich wird alles neu geschrieben oder der Test gelöscht und vergessen.

Der zweite Spezialist entwirft zunächst alles: wie Tests isoliert werden, welches Muster der API-Client befolgt, wie Tokens verwaltet werden und was mit dem Zustand geschieht, der zwischen den Tests wechselt. Erst danach kommt die Anweisung an das Modell: Schreiben Sie einen Anmeldetest nach diesen Regeln.

Der erste enthält einen Test, der derzeit funktioniert. Der zweite enthält ein System, das weiterhin funktioniert, weil es auf einer Architektur beruht und nicht auf Zufall. Bei einer kleinen Anzahl von Tests ist der Unterschied unsichtbar – außer dass der erste zehn oder fünfzehn Tests in zehn Minuten abschließt, während der zweite für die Grundlegende Arbeit zwei Stunden oder länger benötigt. Nach hundert, zweihundert oder tausend Tests sowie fünfzig bis hundert Pipeline-Ausführungen wird der Unterschied deutlich.

Heißt das, man muss eine Programmiersprache lernen?

Ja, allerdings nicht zum Schreiben von Code. Man benötigt eine Sprache, um zu verstehen, was die KI erzeugt hat, Fehler im generierten Code aufzudecken, Pull Requests zu überprüfen und zu entscheiden, was in die Hauptversion gelangt. Syntax ist ein Werkzeug. Eine komplexe Struktur aus dem Gedächtnis ist für einen Tester in unbekanntem Gebiet unerreichbar, doch Architektur ist vertrautes Terrain: wie das System aussehen sollte, wie Tests isoliert bleiben, wie Pipelines organisiert sind und was ein guter Bericht enthält. Diese Grundlage hat das Playwright-Projekt möglich gemacht.

Architektur entsteht nicht aus einer Anweisung. KI kann sie vorschlagen, manchmal gut, aber Architektur ist eine Wahl unter verschiedenen Lösungen und nicht einfach nur eine Lösung. Ein Modell bietet fünf Optionen an, die alle plausibel erscheinen. Welche davon in sechs Monaten unter zehnmal so vielen Tests und geänderten Anforderungen funktionieren wird, lässt sich nicht einfach erzeugen. Sie entsteht aus Erfahrung – aus den Herausforderungen beim Beheben fehlerhafter Tests, beim Verständnis, warum ein Test lokal funktioniert und in der CI-Fehler gibt, sowie beim Entdecken, dass ein gemeinsamer Account ein verborgenes Problem darstellt, das jederzeit ausbrechen kann.

Unternehmen haben kein Interesse an Menschen, die nur Knöpfe drücken und Anweisungen in Claude Code oder Cursor eingeben. Solche Personen gibt es in großer Zahl und es werden immer mehr, und der Markt ist voller Entwickler, die glauben, auf Gold gestoßen zu sein – was jedoch nur von kurzer Dauer ist. Gesucht sind Menschen, die verstehen, warum die KI etwas tut, erkennen, wenn sie falsch liegt, Aufgaben so formulieren, dass das Modell eine funktionierende Lösung liefert und nicht nur einen fehlerhaften, aber „polierten“ Ausgangswert, sowie Systeme entwickeln anstatt endlose „Versuch noch einmal, nicht so“-Runden mit Token zu füttern.

Erfahrung in Prozessen, Automatisierung und Pipelines ist kein veraltetes Konzept. Sie bildet die Grundlage für kompetente Arbeit mit KI und unterscheidet denjenigen, der Chaos verursacht, vomjenigen, der ein System schafft. Früher diente das Wissen dazu, Dinge manuell zu erledigen. Heute dient es dazu, Aufgaben für KI zu definieren und die Ergebnisse zu überprüfen. Die Rolle hat sich geändert, doch der Wert der Expertise nicht. Dies ist wohl leichter zu erkennen, denn neben der KI wird deutlich, wer lediglich etwas erzeugt und wer versteht, was erzeugt wurde und warum.

Was das Experiment zeigt

Ein Framework wurde in einer Sprache entwickelt, die sein Schöpfer nicht kennt – und das ist keine Geschichte über Genialität. Es handelt sich vielmehr um eine Geschichte darüber, nicht zu versuchen, vorherzusagen, was KI tun würde, sondern stattdessen Zeit in die Erklärung der Spielregeln zu investieren: Was erlaubt ist, was nicht, und warum auf diese Weise und nicht auf eine andere. Es ist langweilig, hat nichts mit Stimmung zu tun und es dauert, bis das erste Ergebnis erscheint. Genau das ist es, was funktioniert.

Das Repository beweist weder, dass Ingenieure überflüssig sind, noch dass Sprachen keine Bedeutung mehr haben. Es ist ein lebendiger Test dafür, wie sich die Rolle des Ingenieurs verändert, wenn der Wert vom Schreiben von Code auf das Formulieren von Aufgaben, das Entwerfen von Systemen und das Überprüfen von Ergebnissen verschoben wird. Das Manuell-Schreiben von Code bleibt eine Fähigkeit. Eine zweite Fähigkeit hat sich dazugesellt und sich als genauso wichtig erwiesen: das Verständnis dafür, was erzeugt wurde, warum und was als Nächstes kommt.

KI ersetzt den Ingenieur nicht. Sie wird zum schnellsten und gehorsamsten jungen Assistenten, den man sich vorstellen kann – unermüdlich, niemals streitlustig und stets bereit für einen weiteren Versuch. Sie hat einen Tick: Sie liefert eine korrekte Lösung genauso wie völligen Unsinn mit derselben Zuversicht, und nur jemand, der die Arbeit versteht, kann sie voneinander unterscheiden. Deshalb muss der Ingenieur am Steuer bleiben – als derjenige, der das Ziel und den Weg kennt, und nicht nur als jemand, der das Lenkrad hält.

Verwandte Artikel

• MAF 1.0, LangGraph oder CrewAI? Die Wahl eines Agent-Frameworks im Jahr 2026 — Vergleich von Microsoft Agent Framework 1.0, LangGraph und CrewAI hinsichtlich Zustand, Speicher, Fehlersuche, Protokolle, Azure-Optionen und Kosten, inklusive kurzer Entscheidungshilfen und Implementierungsmodellen.

Loop Engineering: Vier verschachtelte Schleifen für selbstverbessernde KI-Agenten — Wie vier verschachtelte Steuerschleifen (ReAct, Retry, Queue, Hill Climbing) zusammen mit einem Bewertungssystem, einem Budgetanzeiger und einer Manipulationsprüfung einen Agenten zuverlässig machen, am Beispiel der Versicherungsprüfung dargestellt.