AI Agent besteht eigene Tests, übersieht dennoch Teile der Anforderung
Ein AWS AI Agent schrieb Python-Code, führte eigene Tests aus und lieferte ein korrektes Ergebnis. Bei genauer Prüfung zeigte sich jedoch, dass die Tests nicht alle gestellten Anforderungen abdeckten. Ein Lehrstück über die Grenzen scheinbar grüner Checks.
Veröffentlicht am 15. Okt. • Zuerst erschienen auf blog.lalitbagga.com
Ich gab meinem AI-Agenten eine kleine Deployment-History und fragte, wie oft die Checks unhealthy waren. Er schrieb den Python-Code, führte seine eigenen Tests aus und lieferte die richtige Antwort.
Dann las ich die Tests. Sie liefen durch, aber sie deckten nicht alles ab, was ich verlangt hatte.
Ein wenig Kontext: Es war ein kleines Experiment in meinem persönlichen AWS-Labor mit erfundenen Deployment-Daten. Dahinter steckt kein Produktionsvorfall.
Ich begann mit dieser CSV, einer kleinen Deployment-History aus meinem persönlichen AWS-Labor. Die Daten sind frei erfunden. Sie enthält zwölf Deployment-Checks im Abstand von fünf Minuten, und jede Zeile verzeichnet, ob der Check healthy war, die erwartete und die laufende Anwendungsversion, die Instanzanzahlen und etwaige aktive Alarme.
timestamp,status,desired_version,running_version,healthy_instances,desired_instances,active_alarms 2026-09-20T10:00:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 2026-09-20T10:05:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 2026-09-20T10:10:00Z,unhealthy,2026.09.20.1,2026.09.19.4,2,3,1 2026-09-20T10:15:00Z,unhealthy,2026.09.20.1,2026.09.19.4,2,3,1 2026-09-20T10:20:00Z,unhealthy,2026.09.20.1,2026.09.19.4,2,3,1 2026-09-20T10:25:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 2026-09-20T10:30:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 2026-09-20T10:35:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 2026-09-20T10:40:00Z,unhealthy,2026.09.20.1,2026.09.20.1,2,3,0 2026-09-20T10:45:00Z,unhealthy,2026.09.20.1,2026.09.20.1,2,3,0 2026-09-20T10:50:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 2026-09-20T10:55:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 Enter fullscreen mode Exit fullscreen mode Das ist genau die Datei, die ich dem Agenten gegeben habe, sodass Sie das gleiche Experiment selbst nachstellen können.
Ich wollte zwei Zahlen wissen: wie viele Checks unhealthy waren und wie lange jede abgeschlossene unhealthy-Periode dauerte.
Für die zweite Zahl brauchte es eine Regel, also habe ich sie festgehalten. Eine Periode beginnt beim ersten unhealthy-Check und endet beim ersten healthy-Check danach. Endet die Datei, während die Checks noch unhealthy sind, bleibt diese Periode unvollständig.
Nehmen wir den ersten unhealthy-Check um 10:10 Uhr. Der nächste healthy-Check ist um 10:25 Uhr, die Periode dauert also fünfzehn Minuten. Das ist genau das, was die vorliegenden Checks zeigen, und nicht mehr. Es ist nicht der exakte Zeitpunkt, an dem eine echte Anwendung ausgefallen oder wiederhergestellt wurde. Ich wollte das klären, bevor ich die Berechnung an einen Agenten übergebe.
Als Modell verwendete ich Amazon Nova 2 Lite über mein verwaltetes Agent-Setup. Ich gab ihm die Berechnungsregeln, drei kleine Testfälle und die Ziel-CSV. Eine Implementierung gab ich ihm nicht vor.
Es erzeugte das Programm und schickte es an den Amazon Bedrock AgentCore Code Interpreter, der Code in einer separaten Ausführungsumgebung ausführt.
Mitgelieferte CSV → Modell erzeugt Python → Code Interpreter führt es aus → Ergebnis kommt zurück
Auf meiner Seite machte ich zwei Dinge: Ich verglich die zurückgegebenen Zahlen mit meinem erwarteten Ergebnis und las dann die generierten Tests.
Der gespeicherte Stream zeigte einen einzigen Code-Interpreter-Aufruf mit dem generierten Programm. Die Tool-Ausgabe enthielt den Marker für bestandene Tests und die berechneten Ergebnisse. Ich konnte also nachsehen, was tatsächlich ausgeführt wurde, statt mich auf die Zusammenfassung des Modells zu verlassen.
Vor dem Agent-Run hatte ich die erwarteten Ergebnisse selbst ausgearbeitet. Die Ausgabe stimmte überein:
Die 41,7 % sind fünf unhealthy Samples von zwölf. Das bedeutet nicht, dass die Anwendung 41,7 % der Zeit ausgefallen war.
Das Programm gab zudem MODEL_GENERATED_TESTS=PASS aus.
Mein Prompt verlangte jedoch Assertions, also die Prüfungen, die das Programm anhalten, wenn eine Erwartung verletzt wird, für jede genannte Test-Erwartung. Die generierten Tests deckten Periodenanzahl und Dauern ab. Sie prüften nicht explizit jeden erwarteten Start- und End-Zeitstempel.
Die Zeitstempel in der Ziel-Ausgabe waren korrekt, die Antwort war also nicht falsch. Die Lücke lag in dem, was die Tests tatsächlich bewiesen.
Genau das ist es, was man sich merken sollte. „Die Tests liefen durch" heißt, dass die geschriebenen Assertions bestanden wurden. Es bedeutet nicht, dass jede Anforderung getestet wurde. Der Vergleich des Ergebnisses und das Lesen der Assertions beantworteten zwei unterschiedliche Fragen.
Es zeigte einen Agenten, der Analysecode generiert und ausführt, dessen Ausgabe mit einem Ergebnis übereinstimmte, das ich unabhängig berechnet hatte. Es zeigte auch, warum ich die generierten Tests lesen musste.
Es zeigt nicht, dass jeder künftige Lauf funktionieren würde. Fehlgeformte Eingaben, Zugriffsbeschränkungen, Session-Verhalten und Prüfungen bei wiederholten Läufen bleiben Gegenstand einer nachfolgenden Evaluation.
Für diese Art von Analyse würde ich drei Dinge zusammen betrachten: die Eingabe, den tatsächlich ausgeführten Code und dessen Ausgabe. Dann würde ich die generierten Tests gegen die ursprünglichen Anforderungen prüfen, bevor ich dem Pass-Marker vertraue.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 15 • Originally published at blog.lalitbagga.com
I gave my AI agent a small deployment history and asked how often the checks were unhealthy. It wrote the Python, ran its own tests, and came back with the right answer.
Then I read the tests. They passed, but they didn't cover everything I'd asked for.
Some context: this was a small experiment in my personal AWS lab, with made-up deployment data. There's no production incident behind it.
I started with this CSV, a small deployment history from my personal AWS lab. The data is made up. It has twelve deployment checks, five minutes apart, and each row records whether the check was healthy, the expected and running application versions, the instance counts, and any active alarms.
timestamp,status,desired_version,running_version,healthy_instances,desired_instances,active_alarms 2026-09-20T10:00:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 2026-09-20T10:05:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 2026-09-20T10:10:00Z,unhealthy,2026.09.20.1,2026.09.19.4,2,3,1 2026-09-20T10:15:00Z,unhealthy,2026.09.20.1,2026.09.19.4,2,3,1 2026-09-20T10:20:00Z,unhealthy,2026.09.20.1,2026.09.19.4,2,3,1 2026-09-20T10:25:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 2026-09-20T10:30:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 2026-09-20T10:35:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 2026-09-20T10:40:00Z,unhealthy,2026.09.20.1,2026.09.20.1,2,3,0 2026-09-20T10:45:00Z,unhealthy,2026.09.20.1,2026.09.20.1,2,3,0 2026-09-20T10:50:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 2026-09-20T10:55:00Z,healthy,2026.09.20.1,2026.09.20.1,3,3,0 Enter fullscreen mode Exit fullscreen mode This is the exact file I gave the agent, so you can run the same experiment yourself.
I wanted two numbers: how many checks were unhealthy, and how long each completed unhealthy period lasted.
The second one needed a rule, so I wrote it down. A period starts at the first unhealthy check and ends at the first healthy check after it. If the file ends while checks are still unhealthy, that period stays incomplete.
Take the first unhealthy check, at 10:10. The next healthy one is at 10:25, so the period is fifteen minutes. That's what the supplied checks show, and nothing more. It isn't the exact moment a real application failed or recovered. I wanted that settled before handing the calculation to an agent.
I used Amazon Nova 2 Lite as the model, through my managed agent setup. I gave it the calculation rules, three small test cases and the target CSV. I didn't give it an implementation.
It generated the program and sent it to Amazon Bedrock AgentCore Code Interpreter, which runs code in a separate execution environment.
Supplied CSV → model generates Python → Code Interpreter runs it → result comes back
On my side, I did two things: compare the returned numbers with my expected result, then read the generated tests.
The retained stream showed a single Code Interpreter call containing the generated program. The tool output had the test-pass marker and the calculated results. So I could look at what actually ran, instead of trusting the model's summary of it.
Before the agent run, I had worked out the expected results myself. The output matched:
The 41.7% is five unhealthy samples out of twelve. It doesn't mean the application was down for 41.7% of the time.
The program also printed MODEL_GENERATED_TESTS=PASS.
But my prompt asked for assertions, the checks that stop the program when an expectation is wrong, for every stated test expectation. The generated tests covered period counts and durations. They didn't explicitly check every expected start and end timestamp.
The timestamps in the target output were correct, so the answer wasn't wrong. The gap was in what the tests actually proved.
That's the part worth remembering. "The tests passed" means the assertions that were written passed. It doesn't mean every requirement was tested. Comparing the result and reading the assertions answered two different questions.
It showed an agent generating and executing analysis code whose output matched a result I'd calculated independently. It also showed why I needed to read the generated tests.
It doesn't show that every future run would work. Malformed inputs, access restrictions, session behaviour and repeated-run checks are still follow-up evaluation.
For this kind of analysis, I'd keep three things together: the input, the code that actually ran, and its output. Then I'd check the generated tests against the original requirements before trusting the pass marker.