Die Spec sagte required. Die API sagte ja.

Drei Runden QA, immer neue Bugs. Einen fixen, zwei neue entdecken. Das Tech-Debt-Ticket, das seit Monaten auf dem Board lag — das große Datenbank-Refactoring, von dem alle wussten, dass es wehtun würde — hielt, was es versprochen hatte.

Irgendwann habe ich aufgehört, die Liste zu verlängern, und es anders probiert: Ich habe einem Agent die OpenAPI-Spec gegeben und gesagt: „Denk um die Ecke, überrasch mich, such nach Edge Cases.”

Er hat Bugs gefunden, die schon vor dem Refactoring da waren. Bugs, die drei Runden menschlichem Review unbemerkt überstanden hatten.

Die falsche erste Version

Meine erste QA-Session war ad-hoc: direkte Prompts, der Agent denkt gegen die API, direktes Feedback. Es hat gut funktioniert. Also habe ich es in einen wiederverwendbaren Skill extrahiert — etwas, das ich nach dem nächsten Refactoring wieder aufrufen kann, ohne den Setup neu aufzubauen.

Die erste Version ist sofort gescheitert. Der Agent fing an, ein End-to-End-Testskript zu schreiben.

Das brauchen wir nicht. Die haben wir. Sie brauchen Pflege — jedes Mal, wenn sich der Code ändert, ändern sich die Tests. Sie laufen gegen gemockte Umgebungen, in denen simulierte Dependencies vorhersehbar reagieren. Sie sind wertvoll, wir behalten sie. Aber das war nicht, was ich bauen wollte.

Der Wert liegt nicht in der Mechanik. Er liegt im Denken. Ein Agent, der den Vertrag liest und entscheidet, was es wert ist zu testen — nicht einer, der Testfälle in Code überträgt.

Ich habe den Skill korrigiert: minimale Hilfsscripts für die mechanische Schicht (Auth-Tokens, HTTP-Requests, sauberer JSON-Output), AI-Reasoning für alles andere. Keine Test-Generierung. Der Agent liest die Spec, bildet Hypothesen, schickt Requests, interpretiert Responses und entscheidet, was er als nächstes untersucht. Die Scripts sind Handwerk. Das Denken ist der Punkt.

Was passiert ist

Der Agent hat die Spec gelesen. Er hat bemerkt, dass ContentSetting-Entities ein properties-Feld haben — Einträge, die jeweils ein required: boolean-Flag tragen.

Er hat sich gefragt: Wenn required eine echte Einschränkung ist, muss die API sie durchsetzen. Was passiert, wenn ich ein ContentSetting anlege und die required Properties einfach weglasse?

Er hat den Request abgeschickt:

POST /api/config/settings
{
  "contentTypeId": "abc-123",
  "name": "My Setting",
  "properties": []
}

Keine required Properties. Felder, die die Spec explizit als Pflichtfelder markiert — nicht vorhanden.

201 Created.

Ich habe den Request zweimal angeschaut. Dann habe ich den Agent gebeten zu prüfen: Ist das eine Einschränkung, die das Framework durchsetzt, oder ein Soft-Check im Controller, den wir selbst fixen können?

Er hat sich in den Code gegraben. Controller-Code. Eine Validierungsmethode in ContentSettingValidator, die Property-Typen prüfte, aber nicht deren Vorhandensein. Die Prüfung existierte — sie hatte nur eine Lücke.

Wir haben CONF-101 angelegt. Root Cause identifiziert, Datei und Methode angegeben.

Der zweite Bug kam aus derselben Session. Ein useDefault-Flag auf Property-Values, kombiniert mit einem leeren Custom Value, hätte den Request ablehnen sollen — die Spec beschrieb eindeutig, wie ein valider Zustand aussieht. Er hat ihn nicht abgelehnt. Der Validierungspfad für useDefault: true hat die Value-Prüfung komplett umgangen.

CONF-102. Dieselbe Datei. Eine andere Lücke.

Beide Bugs existierten vor dem Refactoring. Keiner wurde durch unsere Änderungen eingeführt. Keiner wurde durch drei Runden menschliches QA gefunden.

Der Teil, den ich nicht erwartet hatte

API-QA hinterlässt Spuren. Man legt Test-Entities an, verändert sie, testet Edge Cases — und in einem geteilten Staging-Environment häuft sich das an. Wir hatten bereits Reset-Routinen für die PRE-Umgebung, also habe ich gar nicht über Cleanup nachgedacht. Es stand nicht im Skill. Es stand nicht in den Anweisungen.

Der Agent hat trotzdem aufgeräumt.

Niemand hatte es ihm gesagt. Es gab keinen Cleanup-Schritt, keine Anweisung, die Umgebung so zu hinterlassen, wie er sie vorgefunden hatte. Er hat einfach alles verfolgt, was er über die REST API im Laufe der Session angelegt hatte — Content Types, Settings, Konfigurationen — und sie am Ende systematisch gelöscht, bevor er seine Ergebnisse gemeldet hat.

Er hat aus dem Kontext geschlossen: Ich habe diese Daten angelegt, ich arbeite in einer geteilten Umgebung, ich sollte sie wieder entfernen. Kein Prompt. Keine Regel. Nur Situationsbewusstsein.

Ein guter Bürger. Besser als die meisten Menschen in einer geteilten Dev-Umgebung.

Was das nicht ist

Das ist kein Ersatz für deine Test-Suite.

Tests sind präzise. Sie fangen Regressionen ab. Sie laufen in CI bei jedem Commit. Behalte sie.

Aber Tests haben eine strukturelle Grenze: Sie können nur testen, was du zu testen gedacht hast. Der Vorteil des Agents in einer Staging-Umgebung liegt nicht darin, dass er auf Dinge kommt, auf die Menschen nicht kämen — Required-Field-Validierung ist ein offensichtlicher Testfall. Der Vorteil ist systematische Abdeckung ohne Ermüdung. Er arbeitet den gesamten Vertrag methodisch durch, ohne die menschliche Tendenz, die langweiligen Fälle zu überspringen, sobald die ersten paar durchlaufen.

Drei menschliche QA-Runden, und niemand hat ein ContentSetting mit leeren required Properties angelegt. Nicht weil es clever wäre — sondern weil es mühsam ist. Man prüft den Happy Path, checkt die offensichtlichen Fehlerfälle, und macht weiter. Der Agent macht nicht weiter. Er arbeitet den Vertrag durch, bis er eine Lücke findet oder der Vertrag aufhört.

Warum Staging und nicht lokal

Lokale Entwicklungsumgebungen lügen. Gemockte Dependencies reagieren vorhersehbar. Testdaten sind sauber. Edge Cases, die nur durch echte Nutzung entstehen, tauchen nicht auf, weil echte Nutzung nicht vorhanden ist.

Staging hat echte Daten, echte Beziehungen, produktionsnahe Konfiguration. Wenn der Agent dort testet, interagiert er mit dem Ding, das fast Production ist. Bugs, die nur unter realen Bedingungen auftauchen, sind auffindbar — aber nur, wenn etwas systematisch danach sucht.

Menschliches QA auf Staging ist wertvoll. Es ist auch langsam und skaliert nicht. Man schickt eine Person durch eine Checkliste. Ein Agent kann den gesamten API-Vertrag ohne Checkliste durcharbeiten, ohne sich zu langweilen, und ohne fertig zu sein, sobald der Happy Path durchläuft.

Das Bild, das geblieben ist

Das Hydra-Ticket hat mir gezeigt, dass menschliches QA an Grenzen stößt, wenn die Domäne komplex genug ist. Drei Runden, immer noch Bugs. Wir haben einen Agent dazugeholt. Er hat Bugs gefunden, wo Menschen nicht hingeschaut haben — nicht weil die Menschen unaufmerksam waren, sondern weil systematische Abdeckung des gesamten Vertrags nicht in einen QA-Sprint passt.

Tests fangen Regressionen auf. AI Contract QA fängt Lücken auf. Beide sind Sicherheitsnetze. Sie sind unterschiedlich positioniert, und was das eine durchlässt, fängt das andere tendenziell auf.

Wer eine Staging-Umgebung mit echten Daten und eine API mit veröffentlichtem Vertrag hat, hat alles, was er braucht, um das laufen zu lassen. Den Agenten auf die Spec ansetzen, sagen „überrasch mich”, eine Stunde einplanen. Der Einsatz ist eine Session. Die Ausbeute könnten die Bugs sein, die drei QA-Runden nicht gefunden haben.

Der Browser-QA-Beitrag hat die Klick-Schicht behandelt — ein Agent, der nach dem Feature-Land eine UI-Checkliste durcharbeitet. Das hier ist die Schicht darunter. Vor der UI, vor der Checkliste — der Vertrag ist bereits da. Die Spec macht Versprechen. Der Agent prüft, ob die API sie hält.