AI Slop vermeiden: Harness-First Engineering für Teams, die mit Coding Agenten arbeiten

Wer heute mit Cursor oder Copilot arbeitet, kennt das Gefühl: Der Agent produziert Code in einem Tempo, das klassisches Review schlicht überfordert. Man nickt ab, merged und hofft. Wenn es schiefgeht, ist das Ergebnis AI Slop in der Produktion.

Zwei Projekte, eine Erkenntnis

Datadogs Ingenieure haben intern zwei vollständige Systeme mit Coding Agenten gebaut: einen Redis-kompatiblen Server in Rust (redis-rust) und Helix, eine Kafka-kompatible Streaming-Engine auf Object Storage. In beiden Fällen lief der Agent – primär Claude Code – in kurzer Zeit zu beeindruckenden Ergebnissen auf.

Beim redis-rust-Projekt produzierte der Agent innerhalb weniger Stunden einen funktionierenden Server. Er kompilierte, bestand die Tests. Doch der Speicherverbrauch war 8x höher als bei Redis 8.4, weil der Agent 512 × 8 KB Puffer fest vorbelegt hatte, optimiert für einen Mikro-Benchmark, nicht für den Produktivbetrieb. Fehlermeldungen wichen subtil vom Redis-Standard ab. Ohne automatisierte Überprüfung wären diese Probleme unsichtbar geblieben.

Die Lösung war kein besseres Prompting, sondern ein besserer Harness.

Harness-First Engineering: Das Prinzip

Statt jede Zeile agent-generierten Codes zu reviewen – was bei der Iterationsgeschwindigkeit moderner Agents nicht skaliert – setzt Harness-First Engineering auf automatisierte Checks, die mit hoher Konfidenz und in Sekunden sagen können: Ist dieser Code korrekt?

Das Prinzip folgt einem klaren Loop:

1. Invarianten definieren – Was muss das System garantieren, unter allen Umständen?
2. Agent generiert Code – so schnell er will, so viel er will
3. Harness verifiziert – deterministisch, automatisiert, reproduzierbar
4. Produktions-Telemetrie validiert – Observability schließt den Kreis
5. Feedback aktualisiert den Harness – der Agent iteriert

Entscheidend ist Schritt 1: Invarianten zuerst. Wer dem Agenten erst sagen lässt, was das System tun soll, und dann prüft, ob es das tut, hat den Loop umgekehrt und produziert AI Slop.

Was gehört in einen guten Harness?

• Deterministische Simulation Testing (DST): Reproduzierbare Fehlerszenarien mit konfigurierbarer Fault Injection auf Netzwerk-, Disk- und Node-Ebene.
• Formale Spezifikationen: TLA+-Specs für kritische Subsysteme wie Raft-Konsensus oder Commit-Protokolle.
• Property-based Testing: Exhaustive Invarianten-Checks statt punktueller Unit Tests. Gilt Eigenschaft X für alle möglichen Eingaben?
• Protokoll-Konformitätstests: Sie messen nicht, ob der Code läuft, sondern ob er sich korrekt verhält.
• Observability-Feedback-Loops: Produktions-Metriken als direktes Signal für den nächsten Agent-Iterationsschritt.

Invarianten als Sprache zwischen Mensch und Agent

Ein praktisches Beispiel aus Datadogs Helix-Projekt: Bevor eine einzige Zeile Streaming-Code geschrieben wurde, definierten die Ingenieure die semantischen Garantien des Systems explizit:

• Was bedeutet durable vs. acknowledged?
• Was bedeutet committed vs. visible?
• Was passiert bei einem Crash an jeder Systemgrenze?

Der Agent durfte keine Systemsemantik erfinden. Er durfte nur implementieren, was das Team explizit spezifiziert hatte.

Das ist der Kern von Harness-First Engineering: Der Mensch definiert, was “korrekt” bedeutet. Der Agent implementiert, der Harness verifiziert.

Observability schließt den Verifikationskreis

Beim Datadog-Projekt redis-rust lieferte der Observability-Feedback-Loop konkrete Ergebnisse: Mit Produktions-Metriken als direktem Input identifizierte der Agent drei gezielte Optimierungen – Lazy Allocation, adaptives Pool-Sizing und Puffer-Recycling. Das Ergebnis: 87 % Reduktion des Speicherbedarfs innerhalb von Minuten, vollständig agent-gesteuert, verifiziert durch den Harness.

Bei Helix erreichte das Team 93 % des Peak-Disk-Throughputs, bei vollständig bestandenem DST-Regimen mit Millionen deterministischer Simulationsläufe und das ohne Abstriche bei den Kafka-Semantik-Garantien.

Dieser Kreislauf mit Telemetrie als Input, Agent als Optimierer, Harness als Gatekeeper, ist das, was Vibe Coding von produktionsreifem Agent-Engineering unterscheidet.

Was bedeutet das konkret für Developer-Teams?

Das Prinzip gilt universell auch für Business-Applikationen, APIs, Microservices und Datenpipelines:

• Invarianten zuerst dokumentieren, bevor der Agent loslegt.
• Property-based Testing einführen – in .NET z. B. mit FsCheck oder CsCheck.
• Contract Testing für APIs mit Tools wie Pact als Pflichtbestandteil der CI-Pipeline.
• Strukturierte Logs und Metriken als Feedback in den Agent-Kontext einspeisen.
• Code Review neu priorisieren: Zeit besser in den Harness investieren als in das Reviewen jedes Agent-Diffs.

Die Ökonomie der Verifikation hat sich umgekehrt

Vor der Agent-Ära war Code Review die skalierbarste Verifikationsmethode. Formale Methoden waren teuer und spezialisiert. Coding Agenten kehren diese Ökonomie um: Ein LLM kann TLA+-Spezifikationen schreiben, DST-Harnesses aufbauen und formale Proofs als Teil seines Iterations-Loops ausführen. Formale Methoden sind nicht mehr zu teuer, sondern zu billig geworden, um sie zu ignorieren.

Wer mit Coding Agents arbeitet, muss in Systeme investieren, die Korrektheit maschinell prüfen und nicht in Prozesse, die darauf hoffen, dass ein Mensch den Fehler findet.

Fazit: Vertrauen ist kein Gefühl, sondern ein System

AI Slop entsteht nicht, weil Coding Agents schlecht sind. Es entsteht, weil Teams die Verifikationsinfrastruktur nicht mitgebaut haben. Wer Vibe Coding produktionsreif machen will, braucht keinen besseren Prompt, sondern einen besseren Harness.