Lektion 3. Apps die nicht kaputtgehen — Hurl, Git, CI/CD

Praxistipps — Das reicht zum Loslegen

Vier Saetze sind alles.

An den Agenten: “Erstelle einen Hurl-Test” Die KI schreibt einen Vertrag, der prueft, ob eine Funktion korrekt arbeitet. Plain Text, auch ohne Code-Kenntnisse lesbar.

An den Agenten: “Fuege dieses Feature hinzu. Bestehende Hurl-Tests muessen bestehen” Dieser eine Satz verhindert Drift. Wenn die KI beim Hinzufuegen neuer Features bestehende bricht, meldet Hurl es in roter Schrift.

An den Agenten: “Mach einen Commit” Den funktionierenden Zustand speichern. Wie ein Speicherpunkt im Spiel. Wenn die naechste Aufgabe schiefgeht, hierher zurueckkehren.

An den Agenten: “Mach rueckgaengig” Zum letzten Speicherpunkt zurueckkehren. Was die KI kaputt gemacht hat, wiederherstellen.

Das Muster dieser vier Saetze

Feature fertig → “Erstelle Hurl-Test” → Bestanden pruefen → “Commit” → Naechstes Feature → “Bestehende Hurl muessen bestehen” → Bei Problemen “Mach rueckgaengig”

Das ist der Ratchet. Ein Zahnrad, das nur vorwaerts dreht. Egal ob 5 oder 50 Features — bestehende gehen nicht kaputt.

Warum funktioniert das?

Lektion 2 hat es gezeigt. Gibst du der KI Meinungen, schmeichelt sie. Gibst du Fakten, korrigiert sie. Was Hurl liefert, ist keine Meinung, sondern ein Fakt. “test failed: status 401, expected 200” — da gibt es nichts zu schmeicheln.

Schnelleinstieg

Fuege der To-Do-App aus Lektion 2 einen Hurl-Test hinzu. In 3 Minuten erledigt.

An den Agenten: “Schreibe einen Hurl-Test, der prueft, ob die aktuelle To-Do-Hinzufuegen-Funktion korrekt arbeitet”

Die KI erstellt eine .hurl-Datei.

An den Agenten: “Fuehre den Hurl-Test aus”

Bestanden = gruen. Jetzt absichtlich kaputtmachen.

An den Agenten: “Aendere in der To-Do-Hinzufuegen-API die Antwort von id auf todo_id”

An den Agenten: “Fuehre den Hurl-Test aus”

Rote Schrift zeigt den Fehlschlag. Das ist Drift-Erkennung.

An den Agenten: “Mach rueckgaengig”

Wieder gruen. Das ist der Kern des Ratchets.

Warum man so anweisen muss

In Lektion 2 haben wir die Probleme gesehen. Logik-Drift, Kontextverlust, Schmeichelneigung. Ab 5 Features gehen bestehende kaputt, und die KI erklaert faelschlich “Funktioniert!”.

In dieser Lektion lernst du drei Tools, die das verhindern. Alles Werkzeuge, die Software-Ingenieure seit Jahrzehnten nutzen. Du musst keinen Code lesen koennen. Die KI schreibt und fuehrt aus. Du pruefst nur “Bestanden?”

Die drei Rollen:

Hurl — API-Vertraege in Plain Text deklarieren

Was ist Hurl

Hurl ist eine Datei, in der steht “Wie soll diese API funktionieren”.

Als Spielanalogie: In einem RPG kauft man beim NPC einen Trank — “1 Trank → Gold -50, HP +100”. Pruefen, ob diese Regel auch nach einem Patch noch gilt. Das macht Hurl.

Eine echte Hurl-Datei:

# To-Do hinzufuegen
POST http://localhost:8080/api/todos
{
  "title": "Milch kaufen",
  "priority": "high"
}
HTTP 201
[Asserts]
jsonpath "$.id" exists
jsonpath "$.title" == "Milch kaufen"
jsonpath "$.priority" == "high"
jsonpath "$.completed" == false

Auch ohne Code-Kenntnisse lesbar:

• POST — Anfrage an den Server: “Fuege hinzu”
• http://localhost:8080/api/todos — To-Do-Listen-Adresse
• { “title”: “Milch kaufen” } — Diese Daten senden
• HTTP 201 — Bei Erfolg muss Antwort 201 kommen
• jsonpath “$.title” == “Milch kaufen” — In den zurueckgegebenen Daten muss “Milch kaufen” stehen

Das ist ein Vertrag. “Wenn ein To-Do hinzugefuegt wird, kommt 201, und Titel und Prioritaet kommen unveraendert zurueck.” Wird dieser Vertrag gebrochen, meldet Hurl es in roter Schrift.

Noch ein Beispiel:

# Ohne Authentifizierung wird der Zugang verweigert
GET http://localhost:8080/api/todos
HTTP 401

“Ohne Login auf die To-Do-Liste zugreifen ergibt 401 (Authentifizierung erforderlich).” Auch das ist ein Vertrag. Wenn die KI beim “Aufraeumen” des Auth-Codes diese Regel bricht, faengt Hurl es sofort.

Warum Hurl — Unterschied zu Unit-Tests

“Es gibt viele Test-Tools — warum Hurl?” Fuer Vibe-Coder gibt es einen besonderen Grund.

Unit-Tests pruefen interne Funktionen im Code. In der Auto-Analogie: Unit-Tests zerlegen den Motor und pruefen Einzelteile. Hurl ist ein Fahrtest auf echten Strassen. Wenn sich Funktionsnamen aendern, brechen Tests auch; bei KI-Refactoring muessen Tests mitgeaendert werden. Wenn die KI sowohl Code als auch Tests aendern darf, passt sie Tests an den Code an. Tests bestehen, aber die urspruenglichen Regeln sind verschwunden.

Hurl ist anders. Es prueft am Eingang des Servers. Anfrage senden und Antwort pruefen. Es kennt die interne Code-Struktur nicht. Egal wie die KI den Code aendert — wenn das von aussen beobachtbare Verhalten gleich bleibt, besteht es. Wenn es sich aendert, schlaegt es fehl.

Hurl verifiziert nicht Code, sondern Verhalten. Code darf die KI frei aendern. Verhalten darf sich nicht aendern. Diese Unterscheidung ist der Schluessel zur Drift-Erkennung.

Warum das effektiv ist — Forschung beweist es

In Lektion 2 hast du die Schmeichelneigung gelernt. Auch der Rat “Schreib Tests” liefert voellig unterschiedliche Ergebnisse je nach wie man ihn gibt.

Die TDAD-Studie (Test-Driven AI Development, 2026) testete genau das. Der KI wurde Bugfixing mit unterschiedlichen Test-Bedingungen aufgetragen:

Erstaunlich. “Mach TDD” verschlechtert das Ergebnis. Die KI verirrt sich beim Befolgen prozeduraler Anweisungen. Aber “Diese Testdatei muss bestehen” als konkreter Kontext reduziert Regression um 70%.

Der Unterschied ist klar:

• “Entwickle testgetrieben” → Prozedurale Anweisung → KI verwirrt
• “Diese Hurl-Datei muss bestehen” → Konkreter Vertrag → 70% weniger Regression

Nicht die Methode anweisen, sondern den Vertrag: was bestehen muss.

Git — Rueckkehrbare Speicherpunkte

Was ist Git

Im Spiel speichert man. Vor dem Bossfight speichern, bei Niederlage laden.

Git ist die Speicherfunktion fuer Code. “Jetzt funktioniert alles” → Speichern (Commit). Naechste Aufgabe schiefgegangen → Vorherigen Speicherstand laden.

Vibe Coding ohne Git:

Feature 1 hinzugefuegt → funktioniert
Feature 2 hinzugefuegt → funktioniert
Feature 3 hinzugefuegt → Feature 1 kaputt!
→ Zurueck will ich — aber wie war Feature 2 nochmal?
→ "Mach es wie vorher" zur KI → sie weiss nicht, was "vorher" war
→ Von vorn anfangen

Vibe Coding mit Git:

Feature 1 hinzugefuegt → funktioniert → Commit (Speicher 1)
Feature 2 hinzugefuegt → funktioniert → Commit (Speicher 2)
Feature 3 hinzugefuegt → Feature 1 kaputt!
→ "Zurueck zu Speicher 2" → Feature 1 und 2 funktionieren wieder
→ Feature 3 auf anderem Weg nochmal versuchen

Git-Bedienung: Zwei Woerter reichen

Keine Dutzende Git-Befehle lernen. Fuer Vibe-Coder braucht es zwei Dinge.

“Commit” — Aktuellen Zustand speichern

"Mach einen Commit mit der Nachricht 'To-Do-Hinzufuegen-Feature fertig'"

“Mach rueckgaengig” — Vorherigen Zustand wiederherstellen

"Zum letzten Commit zurueck"

Wann committen

Einfache Regel:

1. Feature fertig und funktioniert → Commit
2. Alle Hurl-Tests bestanden → Commit
3. Vor Beginn des naechsten Features → Unbedingt committen

Ohne Commit weitermachen heisst, bei Problemen keinen Rueckkehrpunkt zu haben. Wie 3 Stunden spielen ohne zu speichern.

Gits Analogie: Basislager am Berg

Beim Everest-Aufstieg geht man nicht direkt zum Gipfel. Basislager → Camp 1 → Camp 2 → … → Gipfel. An jedem Camp Zelt aufbauen und Vorraete lagern. Bei schlechtem Wetter zum vorherigen Camp absteigen. Ohne Camps stirbt man im Sturm.

Git-Commits sind Camps. Bei jedem fertigen Feature ein Camp aufbauen. Wenn die KI beim naechsten Feature etwas kaputt macht, kann man zum vorherigen Camp zurueck.

CI/CD — Die Maschine bewacht automatisch

Was ist CI/CD

CI (Continuous Integration) = “Bei jedem Code-Upload automatisch Tests ausfuehren”. CD (Continuous Deployment) = “Bei bestandenen Tests automatisch deployen”.

Jetzt reicht CI. CD kommt spaeter.

Ohne CI:

Du: "Fuege Feature hinzu"
KI: "Fertig!"
Du: (Prueft nur neues Feature auf der Oberflaeche) "Sieht gut aus!"
→ Dass bestehende Features kaputt sind, bleibt unbemerkt

Mit CI:

Du: "Fuege Feature hinzu"
KI: (Schreibt Code)
Maschine: (Fuehrt automatisch alle Hurl-Tests aus)
Maschine: "Login-Test fehlgeschlagen!"
Du: "Login ist kaputt. Reparier es."
KI: (Korrigiert)
Maschine: "Alle Tests bestanden"
Du: "Commit"

Du musst Hurl-Tests nicht jedes Mal manuell ausfuehren. Die Maschine macht es jedes Mal automatisch.

CI mit GitHub Actions

Wenn drei Tools zusammenkommen: Ratchet-Sperre

Hurl + Git + CI ergibt einen Ratchet. Ein Zahnrad, das nur in eine Richtung dreht. Vorwaerts drehen ja, zurueckdrehen nein.

Feature 1 fertig → Hurl-Test geschrieben → Alles bestanden → Commit → Gesperrt
Feature 2 fertig → Hurl-Test hinzugefuegt → Alt + Neu bestanden → Commit → Gesperrt
Feature 3 Arbeit → Bestehender Hurl-Test fehlgeschlagen → Commit verweigert → Korrektur → Bestanden → Commit → Gesperrt

Die Regeln sind einfach:

1. Bestandene Hurl-Tests werden gesperrt
2. Gesperrte Tests duerfen nicht geloescht/geaendert werden
3. Bei neuen Features werden neue Hurl-Tests hinzugefuegt
4. Alle bestehenden + alle neuen Tests muessen fuer Commit bestehen

Genau wie die TDAD-Forschung zeigt: Nicht die prozedurale Anweisung “Mach TDD”, sondern der konkrete Vertrag “Diese Hurl-Datei muss bestehen”.

Wie die Probleme aus Lektion 2 geloest werden

Zusammenfassung

Was in dieser Lektion behandelt wurde:

1. Hurl — “So muss es funktionieren” als Plain-Text-Vertrag deklarieren. Nicht Code, sondern Verhalten verifizieren
2. Git — “Zu diesem Zeitpunkt zurueckkehren” als Speicherpunkt
3. CI/CD — “Jedes Mal automatisch pruefen” als maschinelle Verifikation
4. Ratchet — Die drei zusammen ergeben ein “Bestanden = gesperrt, nicht zurueck”-Zahnrad

Kernprinzip:

Weise der KI keine Methode an. Gib ihr einen Vertrag: was bestehen muss.

“Mach TDD” → Regression verschlechtert. “Diese Hurl muss bestehen” → 70% weniger Regression. Der Unterschied ist Anweisung vs. Vertrag.

Nicht das Modell wechseln, sondern Vertraege hinzufuegen.

Vorschau naechste Lektion

In Lektion 3 hast du gelernt, einzelne APIs mit Hurl zu schuetzen. Aber bei wachsenden Projekten muessen nicht nur APIs geschuetzt werden. Datenbankstruktur, Sicherheitsrichtlinien, UI-Komponenten — alles muss konsistent sein.

In Lektion 4 lernst du yongol. API, DB, Sicherheit, UI in einer deklarativen Spezifikation verwalten und die Arbeitsgrundlage der KI von Code zu Spezifikation verschieben. Die Methode, die 200-Endpunkt-Mauer des Vibe Codings zu durchbrechen.

Verwandte Artikel

• Hurl verhindert Drift im Vibe Coding
• Ratchet Pattern

Reins Engineering Gesamtkurs

Quellenangaben

• TDAD (Test-Driven AI Development) 2026 — Prozedurale Anweisung “Mach TDD” verschlechtert Regressionsrate auf 9,94%. Bereitstellung von Testdateien im Kontext reduziert auf 1,82% (70% Reduktion)
• Ratchet Pattern Experiment — Autonomer Agent 40/527 (7,6%) vs. Ratchet CLI 527/527 (100%), selbes Modell, Unterschied liegt bei der Kompletierungsbeurteilung