Praxistipps — Das reicht zum Loslegen
In Lektion 3 hast du mit Hurl-Tests und Git Drift verhindert. Bis 50 Endpunkte reicht das. Bei wachsendem Umfang entsteht ein neues Problem. Du sagst nur “Raeum auf” und die KI verwechselt deine Entscheidungen mit Implementierungsdetails und ueberschreibt sie.
Kernprinzip: Entscheidungen aus dem Code herausnehmen. Im Code sind deine Entscheidungen (“Diese Spalte ist Integer”) und Details (Variablennamen, Fehlerbehandlung) vermischt. Die KI kann beides nicht unterscheiden. Deklariert man Entscheidungen in separaten Spezifikationen, kann die KI sie nicht ueberschreiben.
yongol installieren:
An den Agenten: “npx skills add park-jun-woo/yongol installieren”
Login-Funktion deklarativ erstellen:
An den Agenten: “Login-Funktion als SSOT deklarieren”
Die KI generiert automatisch API-Spec, DB-Schema, Service-Ablauf, Autorisierungsrichtlinie und Testszenarien.
An den Agenten: “yongol validate ausfuehren und auf 0 Fehler bringen”
Bei Fehlern korrigiert die KI selbststaendig. 287 Regeln kreuzen 10 Spezifikationen. Alle Haekchen gruen = Code-Generierung bereit.
yongol ist derzeit Go-exklusiv. Aber das Prinzip — Entscheidungen aus dem Code herausnehmen und per Kreuzvalidierung Widersprueche finden — ist sprachunabhaengig. Hurl-Tests aus Lektion 3 funktionieren bereits sprachunabhaengig.
Schnelleinstieg
An den Agenten: “npx skills add park-jun-woo/yongol installieren”
An den Agenten: “Login-Funktion als SSOT deklarieren”
Die KI erstellt 5 Dateien: specs/api/openapi.yaml, specs/db/users.sql, specs/service/auth/login.ssac, specs/policy/authz.rego, specs/tests/scenario-login.hurl.
An den Agenten: “yongol validate specs/ ausfuehren”
0 errors = Erfolg.
Absichtlich einen Widerspruch erzeugen:
An den Agenten: “Aendere das email-Feld in OpenAPI zu mail”
An den Agenten: “yongol validate specs/ ausfuehren”
“In OpenAPI steht mail, in DDL steht email” — so ein Fehler erscheint. Eine einzelne Schicht zeigt keinen Fehler. Erst die Kreuzvalidierung deckt den Widerspruch auf.
An den Agenten: “Behebe den validate-Fehler”
Die KI vereinheitlicht den Feldnamen. Erneut validate. 0 errors.
Warum man so anweisen muss
SSOT 10 Typen — Jeder fuer eine Zustaendigkeit
yongol trennt Softwareentscheidungen in 10 deklarative Spezifikationen (SSOT: Single Source of Truth). Jede ist fuer genau einen Aspekt zustaendig.
Daten definieren: features.yaml (Was bauen), manifest.yaml (Projekteinstellungen), SQL DDL (Datenmodell), sqlc (DB-Abfragen)
Verhalten definieren: OpenAPI (API-Vertrag), SSaC (Serviceablauf), Mermaid stateDiagram (Zustandsuebergaenge)
Verifizieren: OPA Rego (Autorisierung), Hurl (Testszenarien)
Oberflaeche definieren: STML (Frontend)
10 Typen klingen nach viel? Drei Fakten genuegen:
- 8 von 10 sind Industriestandards (OpenAPI, SQL, sqlc, Rego, Mermaid, Hurl, YAML)
- Du musst sie nicht lernen — die KI kennt sie. Du sagst “Erstelle Registrierung” und die KI bearbeitet die 10 Spezifikationen
- yongol ist derzeit Go-exklusiv, aber die Prinzipien sind sprachunabhaengig
operationId — Ein Schluessel fuer alle Schichten
Ein einziger Name (z.B. ExecuteWorkflow) verbindet alle 10 SSOT-Schichten: OpenAPI-Route, SSaC-Serviceablauf, DDL-Tabellen, Rego-Richtlinie, Zustandsdiagramm, Funktionsspezifikation, Hurl-Test.
Das ist der Grund, warum yongol operationId den Keystone nennt. Wie der Schlussstein eines Bogens traegt eine einzige PascalCase-Kennung 10 Schichten physisch.
yongol validate — 287 Regeln fangen Widersprueche
Wenn DDL BIGINT sagt aber OpenAPI string, wenn SSaC @auth deklariert aber Rego keine passende Regel hat, wenn Hurl einen nicht existierenden Endpunkt referenziert — yongol validate faengt das ab.
✓ manifest ✓ openapi_ddl ✓ ssac_rego
✓ openapi ✓ openapi_ssac ✓ ssac_authz
...
0 errors, 0 warnings
~287 Regeln pruefen alle symbolischen Referenzen zwischen 10 SSOTs. Ein einziger Widerspruch und die Code-Generierung wird verweigert.
Benchmark: ZenFlow — 32 Endpunkte in 69 Minuten
Reale Messung. ZenFlow — Multitenant Workflow-Automation SaaS. Von Anfang bis Ende mit yongol gebaut. 32 Endpunkte, 14 Tabellen, 47 Hurl-Anfragen. 11/11 Stufen bestanden. Kein Geschwindigkeitsverlust bei wachsenden Features. Keine bestehenden Tests kaputt.
Warum ein groesseres Modell nicht die Antwort ist
Das Problem ist nicht die Intelligenz des Modells, sondern das Medium. Code als Medium trennt nicht zwischen Entscheidung und Implementierung. yongol aendert das Medium: Die KI bearbeitet nicht Code, sondern deklarative Spezifikationen.
Mehr Struktur statt mehr Modellgroesse.
Verwandte Artikel
Reins Engineering Gesamtkurs
| Lektion | Titel |
|---|---|
| Lektion 1 | Wie man KI anleitet |
| Lektion 2 | Warum man KI nicht trauen kann |
| Lektion 3 | Apps die nicht kaputtgehen |
| Lektion 4 | Entscheidungen aus dem Code heraus |
| Lektion 5 | KI mit Zuegeln |
| Lektion 6 | Bestanden heisst gesperrt |
| Lektion 7 | Schmeichelei umkehren |
| Lektion 8 | Die Fabrik des Agenten |
| Lektion 9 | Automatisierung jenseits des Codes |
| Lektion 10 | Das Gesetz der Daten |
Quellenangaben
- ZenFlow Benchmark — 32 Endpunkte in 69 Minuten, 14 Tabellen, 47 Hurl-Anfragen, 11/11 Stufen
- yongol agent Modellexperiment — Grok 4.3 (erster Versuch 0 Fehler), Gemini 2.5 Flash (1 Feedback 0 Fehler), Gemma4 4.5B (1 Feedback 0 Fehler), Qwen3 8B (1 Feedback 0 Fehler)
- yongol validate — 287 Regeln, Kreuzvalidierung zwischen 10 SSOTs