Von Nils Ekström, CTO bei Stomme AI
Dein Agent hat 28 Fähigkeiten. E-Mail-Triage. Kalenderverwaltung. Webrecherche. Code-Bereitstellung. Zahlungsabwicklung. CRM-Operationen. Dokumentengenerierung. Zwanzig weitere.
Jede davon durchlief einen Prozess, den wir die Schmiede nennen.
Die Schmiede ist keine Code-Review. Es ist eine automatisierte adversarielle Pipeline, die eine Fähigkeit generiert, umfassende Tests erstellt und dann ihr eigenes Ergebnis angreift, um die Sicherheitslücken, Randfälle und Fehlermodi zu finden, die normale Tests übersieht.
Hier ist, wie es funktioniert — und warum wir sie gebaut haben.
Das Problem mit normaler Testung
Standard-Softwaretestung funktioniert so: Ein Entwickler schreibt Code, dann schreibt er Tests, um zu überprüfen, ob der Code funktioniert. Das Problem ist offensichtlich — die Person, die die Tests schreibt, hat dasselbe mentale Modell wie die Person, die den Code geschrieben hat. Sie teilen dieselben Annahmen, dieselben blinden Flecken.
Wenn der Entwickler nicht darüber nachgedacht hat, was passiert, wenn eine Zeitzone UTC-12 ist, hat der Test es auch nicht.
KI-generierter Code verschärft dieses Problem. Wenn du eine KI bittest, eine Fähigkeit zu schreiben, und dann dieselbe KI bittest, Tests dafür zu schreiben, bekommst du Tests, die die Annahmen der KI überprüfen — keine Tests, die sie herausfordern.
Du brauchst einen feindlichen Prüfer.
Die Schmiede-Pipeline
Schritt 1: Spezifikation
Wir schreiben eine kurze Beschreibung für jede Fähigkeit. Kein Pseudocode — eine funktionale Spezifikation:
- Was die Fähigkeit tut
- Welche Eingaben sie akzeptiert
- Welche Ausgaben sie erzeugt
- Welche Randfälle wichtig sind
- Welche Sicherheitsbeschränkungen gelten
- Welche Integrationen sie berührt
Die Spezifikation ist der Vertrag. Alles Weitere wird dagegen getestet.
Schritt 2: Generierung
Ein KI-Agent schreibt die erste Implementierung. Vollständig mit Fehlerbehandlung, Eingabevalidierung, Typprüfung und Integrationspunkten. Dies ist ein kompetenter erster Entwurf — nicht endgültig, wird nie so ausgeliefert.
Schritt 3: Testgenerierung
Ein separater KI-Agent — einer, der die Implementierung nicht gesehen hat — generiert Tests allein aus der Spezifikation. Das ist entscheidend: Der Testschreiber weiß nicht, wie der Code funktioniert. Er weiß nur, was er tun soll.
Das erzeugt Tests, die die Annahmen der Implementierung herausfordern, anstatt sie zu bestätigen. Wenn die Implementierung einen Null-Eingabewert mit einer leeren Array behandelt, die Spezifikation aber sagt, dass sie einen Fehler werfen soll, fängt der Test es auf.
Minimum: 50 Tests pro Fähigkeit. Komplexe Fähigkeiten erhalten 150–200.
Schritt 4: Adversarielle Überprüfung
Ein dritter KI-Agent überprüft die Implementierung und die Tests mit einem einzigen Auftrag: Brich sie.
Dieser Agent sucht nach:
- Sicherheitslücken. Injektionsangriffe, Offenlegung von Zugangsdaten, nicht validierte Eingaben, Wege zur Rechteausweitung.
- Randfälle, die die Tests übersehen. Unicode-Zeichen in E-Mail-Betreffen. Kalenderereignisse, die über Mitternacht hinausgehen. Dateien ohne Erweiterung. Rate-Limit-Antworten von APIs.
- Leistungsprobleme. N+1-Abfragen. Unbegrenzte Schleifen. Speicherlecks in langlaufenden Operationen.
- Integrationsfehler. Was passiert, wenn das E-Mail-API eine 429 zurückgibt. Wenn das Kalender-API offline ist. Wenn das Dateisystem schreibgeschützt ist.
Der adversarielle Prüfer ist absichtlich feindlich. Er versucht nicht zu bestätigen, dass der Code funktioniert. Er versucht zu beweisen, dass er es nicht tut.
Schritt 5: Iteration
Fehler aus der adversariellen Überprüfung fließen zurück in die Generierung. Die Fähigkeit wird neu gebaut — nicht nur geflickt. Eine neue Implementierung behebt die identifizierten Probleme, neue Tests prüfen die Korrekturen, und der adversarielle Prüfer greift erneut an.
Diese Schleife läuft, bis die Fähigkeit alles besteht. Typischerweise 2–4 Iterationen pro Fähigkeit. Manche komplexen Fähigkeiten brauchten 6.
Schritt 6: Menschliche Prüfung
Ein Mensch prüft das finale Ergebnis. Nicht Zeile für Zeile — sondern die Architektur, das Sicherheitsmodell und die Integrationsqualität. Erledigt diese Fähigkeit, was die Spezifikation verlangt? Werden die Sicherheitsbeschränkungen durchgesetzt? Würden wir ihr die E-Mail eines Kunden anvertrauen?
Was die adversarielle Prüfung tatsächlich auffängt
In unserem Sprint mit 28 Fähigkeiten hatte jede Fähigkeit, die die anfängliche Generierung bestand, Probleme, die vom adversariellen Prüfer entdeckt wurden:
- Eine E-Mail-Triage-Fähigkeit, die E-Mails ohne Betreffzeile nicht handhabte
- Eine Kalenderfähigkeit, die die Dauer von Ereignissen über Sommerzeit-Übergänge falsch berechnete
- Eine Dateiverwaltungs-Fähigkeit, die Symlinks außerhalb der Sandbox folgte
- Eine Zahlungsabwicklungs-Fähigkeit, die Karten-Metadaten im Klartext protokollierte
- Eine Webrecherche-Fähigkeit, die URL-Schemata nicht validierte und file://-Zugriff erlaubte
Keines davon wäre bei konventioneller Testung aufgefallen. Jedes hätte bei einem echten Kunden zu einem echten Ausfall geführt.
Warum das für dich wichtig ist
Du musst die Schmiede nicht verstehen, um deinen Agenten zu nutzen. Aber du solltest wissen, dass es sie gibt.
Jede Fähigkeit deines Agenten — jede E-Mail, die er triagiert, jedes Meeting, das er plant, jede Datei, die er verwaltet — wurde mit dieser Pipeline erstellt. Generiert, getestet, angegriffen, neu gebaut, neu getestet und geprüft.
2.939 Tests. 100 % bestanden. Null Sicherheitslücken im finalen Set.
Das ist keine Marketing-Zahl. Das ist ein Ingenieursstandard. Und das ist der Grund, warum dein Agent deine E-Mails um 3 Uhr morgens bearbeitet, ohne dass du dir Sorgen machen musst.