Das Problem: Der Regressions-Loop

Heute war ein klassischer Fall. Ein Dashboard, 15 Iterationen, und nach jedem Fix ging etwas anderes kaputt: User: „Der CTR-Wert ist falsch.“ Agent: „Fixe ich!“ (ändert Query) User: „Super! Aber jetzt sind die Impressionen zu hoch.“ Agent: „Kein Problem!“ (ändert Import-Script) User: „Jetzt ist der CTR wieder falsch.“ Agent: „Ah…“ (beginnt von vorne) 😵 Nach 3 Stunden hatten wir das Dashboard funktionsfähig – aber der Weg war zermürbend. Warum?

Drei Killer-Effekte:

1. Informationsverlust: Jede Session ist ein Reset. Was in Iteration 3 funktionierte, ist in Iteration 8 vergessen.
2. Blindflug: Der Agent hat keine Ahnung, was die korrekten Werte sind. Er rät, bis der User sagt: „8 Klicks wären richtig.“
3. Whack-a-Mole: Import + Query + Layout gleichzeitig geändert. Wenn etwas bricht: Welche Änderung war schuld?

Die Lösung: Drei Schutzschichten

Statt komplexes TDD sofort umzusetzen, haben wir pragmatisch angefangen:

1️⃣ VALIDATION.md – Der unbestechliche Anker

Ein Dokument, das die Wahrheit festhält:

# VALIDATION.md
## GSC Dashboard (14.-20.02.)
- Top Query: "kochtopf kaufen" = 8 Klicks, 26 Impressionen ✅
- Homepage: 33 Klicks, 3.583 Impressionen ✅
- Chart: 7 Datenpunkte (nicht 2450!) ✅

Warum es funktioniert: Der Agent kann nicht mehr raten. Die Zahlen sind dokumentiert.

2️⃣ pytest Tests – Der Wächter

5 automatisierte Tests, die korrekte Werte einfrieren:

def test_top_queries_correct_values(dashboard_data):
    """Regression: Queries dürfen nicht doppelt gezählt werden"""
    top = dashboard_data['data']['topQueries'][0]
    assert top['clicks'] == 8
    assert top['impressions'] == 26

Run:

pytest tests/test_gsc_queries.py -v
→ 5 passed in 0.09s ✅

Warum es funktioniert: In Sekunden wissen wir, ob ein Fix etwas kaputt gemacht hat.

3️⃣ Pre-Fix Protocol – Die Regel

Ein verbindlicher Workflow in AGENTS.md:

BEFORE ANY CODE CHANGE:
1. Read VALIDATION.md (korrekte Werte kennen)
2. Run tests: pytest -v (Baseline muss grün sein)

DURING FIX:
3. Change ONE thing at a time

AFTER FIX:
4. Run tests again: pytest -v
5. Ask user: "Bitte gegen GSC validieren"

Warum es funktioniert: Kein blindes Fixen mehr. Jeder Fix ist isoliert und testbar.

Der Workflow in der Praxis

❌ Vorher (Chaotisch):

User: "CTR falsch"
→ Agent ändert Query blind
→ CTR korrekt, Impressionen falsch
→ Agent ändert Import + Query gleichzeitig
→ CTR wieder falsch
→ 15 Iterationen, 3 Stunden

✅ Nachher (Kontrolliert):

User: "CTR falsch"
→ Agent liest VALIDATION.md: "8 Klicks, 26 Impressionen"
→ pytest -v → Baseline grün
→ Agent ändert NUR CTR-Formel
→ pytest -v → Alle Tests grün ✅
→ User validiert gegen Screenshot
→ 1-2 Iterationen, 20 Minuten

Das Ergebnis

• 15 Iterationen → 1-2 Iterationen
• Keine Frustration mehr
• Vertrauen in Fixes (Tests beweisen, dass nichts kaputt ging)

Die Philosophie: „If you don’t know what correct looks like, you can’t test if your fix works.“

Fazit: Evolutionäres Vorgehen schlägt Perfektion

Wir hätten sofort TDD + QA-Agent implementieren können. Aber:

1. Phase 1 (heute): Checklisten + Snapshot-Tests ✅
2. Phase 2 (nächste Woche): Automatisierte Regression-Tests
3. Phase 3 (später): QA-Agent (zweiter Agent prüft Code)
4. Phase 4 (später): TDD (Tests zuerst, dann Code)

Warum Phase 1 zuerst? Weil wir erst die Basics brauchten:

• Korrekte Werte kennen ✅
• Tests schreiben können ✅
• Tests automatisiert laufen lassen ✅

Übertragbar auf: Dashboards, APIs, UI-Komponenten, Berechnungen – überall, wo ein Fix etwas anderes kaputt machen kann.

---

Häufig gestellte Fragen

Warum vergisst die KI alte Fixes?

Jede Session ist ein Reset. Ohne externe Persistenz (Dateien, Tests) macht der Agent die gleichen Fehler immer wieder.

Was ist der Unterschied zu TDD?

TDD sagt: „Test zuerst, dann Code.“ Unser Ansatz: „User definiert Korrektheit, Test friert sie ein.“ → Verhindert, dass der Agent Tests „passend zum falschen Code“ schreibt.

Wie verhindere ich Regressions?

1. VALIDATION.md (korrekte Werte dokumentieren)
2. pytest Tests (automatisch prüfen)
3. Pre-Fix Protocol (Workflow einhalten)

---

Nächster Schritt: Wenn wir 3-5 Features haben, die stabil laufen: QA-Agent einführen (zweiter Agent prüft Code des ersten). Heute: Checklisten, Tests, Protocol. Das ist die Basis. 🎯 >