yongol — Der Kiel von KI-codiertem SaaS

Bild: KI-generiert

Wenn die KI staendig Ihren Code ueberschreibt, wenn Vibe Coding bei 200 Endpoints zusammengebrochen ist, wenn Sie die Arbeitslast der KI von Code auf Spezifikationen verlagern wollen – yongol ist dieser Kiel.

Der 200. Endpoint

Du baust ein SaaS mit Vibe Coding. Am Anfang ist es schnell. 5 Tabellen, 12 Endpoints — zwanzig Minuten und es laeuft.

Aber ab 50 Endpoints passiert etwas Seltsames. Die KI erzeugt heute ein Muster, das dem von gestern widerspricht. Ab 100 gehen bestehende Features still kaputt. Ab 200 kostet das Hinzufuegen eines einzelnen Features 10-mal so viel wie die ersten zehn.

Der DORA 2025 Bericht hat dies empirisch belegt — KI-Werkzeuge steigern den Durchsatz um 2-18%, erhoehen aber gleichzeitig die Aenderungsfehlerrate und Nacharbeit^[1]. KI ist ein “Spiegel und Verstaerker”, der Schwaechen bestehender Prozesse verstaerkt.

Es liegt nicht daran, dass das Modell dumm ist.

Entscheidungen und Implementierung

Drei Dinge sind im Quellcode verflochten:

• Benutzerentscheidungen — diese Spalte ist BIGINT, dieser Endpoint ist nur fuer den Eigentuemer, die Paginierung ist cursorbasiert.
• Geschaeftslogik — Preisgestaltung, Workflows, Lebenszyklusregeln.
• Implementierungsdetails — Variablennamen, Bibliotheksaufruf-Reihenfolge, Fehler-Wrapping.

Wenn KI diesen Code liest, kann sie nicht unterscheiden, welche Zeile eine Entscheidung und welche ein Detail ist. Wenn sie also “refaktoriert” oder “aufraumt”, ueberschreibt sie stillschweigend Entscheidungen, die sie fuer Details hielt. Der Benutzer merkt es erst, wenn das Verhalten bereits falsch ist. 1972 sagte Parnas: “Verberge Designentscheidungen, die sich wahrscheinlich aendern, hinter Schnittstellen”^[2] — er sprach zu Menschen. Aber jetzt, da KI Code bearbeitet, kann niemand — Mensch oder Modell — die Unterscheidung aufrechterhalten, wenn sie nicht im Medium selbst existiert.

Das ist der Grund, warum Vibe Coding bei 200 Endpoints zusammenbricht. Ein groesseres Modell loest das Problem nicht. Das Medium — roher Code — bewahrt Entscheidungen einfach nicht. Jedes Modell stoesst letztlich an dieselbe Wand.

Der Kiel

Der Kiel ist der erste Knochen, der beim Schiffsbau gelegt wird. Er traegt das Gewicht des Rumpfes, verhindert seitliches Rollen, und jede andere Struktur wird darauf gebaut. Ein Schiff ohne Kiel schwimmt in ruhigem Wasser, verformt sich aber bei Wellengang.

Ein SaaS, das mit Vibe Coding gebaut wurde, ist genauso. Es schwimmt, wenn es klein ist. Es verformt sich, wenn es waechst.

yongol ist der Kiel von KI-codiertem SaaS.

Harness with reins — nicht ein groesseres Modell, sondern praezisere Zuegel. Ein deterministischer Validator beurteilt jedes Artefakt, eine Ratsche erzwingt Fortschritt, und die Maschine entscheidet, ob die Arbeit erledigt ist.

Entscheidungen aus dem Code herausnehmen

Der Kern von yongol ist einfach. Entscheidungen vom Code trennen.

Zehn deklarative Spezifikationen (SSOTs) behandeln jeweils eine einzelne Zustaendigkeit:

Acht von zehn sind Industriestandards (OpenAPI, SQL, sqlc, Rego, Mermaid, Hurl, YAML). Nur SSaC und STML sind von yongol erstellte DSLs. Was die KI von Grund auf lernen muss, wird minimiert.

Jedes SSOT enthaelt nur Entscheidungen. Keine Implementierungsdetails. Die KI bearbeitet SSOTs; yongol generate rendert Code daraus. Entscheidungen leben dauerhaft in den SSOTs; der Code ist eine Wegwerf-Projektion.

Konsistenz erzwingen

Entscheidungen sind nun auf zehn Dateien verteilt, also koennen Widersprueche auftreten. DDL sagt BIGINT, aber OpenAPI sagt string? SSaC deklariert @auth, aber Rego hat keine passende Regel? Das Zustandsdiagramm hat einen Uebergang, aber SSaC hat keine entsprechende Funktion?

Ein widerspruchliches SSOT ist eine beschaedigte Entscheidung. Egal wie sauber der Code ist — wenn die Entscheidungen im Konflikt stehen, ist das Verhalten falsch.

yongol validate faengt das ab.

✓ manifest        ✓ openapi_ddl       ✓ ssac_rego
✓ openapi         ✓ openapi_ssac      ✓ ssac_authz
✓ ddl             ✓ hurl_openapi      ✓ ssac_sqlc
✓ query           ✓ hurl_statemachine ✓ ddl_statemachine
✓ ssac            ✓ hurl_manifest     ✓ ddl_rego
✓ statemachine    ✓ openapi_manifest  ✓ rego_manifest
✓ rego            ✓ ssac_ddl          ✓ stml_openapi
✓ hurl            ✓ ssac_statemachine
✓ funcspec        ✓ ssac_func

0 errors, 0 warnings

Zuerst wird jedes SSOT einzeln validiert, dann werden schichtuebergreifende Pruefungen durchgefuehrt. ~287 Regeln inspizieren jede symbolische Referenz ueber alle zehn SSOTs. Wenn ein einziger Widerspruch existiert, wird die Kompilierung verweigert. Die systematische Literaturuebersicht von Torres et al.^[3] stellte fest, dass die meisten Modellmanagement-Tools nur die Konsistenz innerhalb eines einzelnen Modells behandeln und die Kreuzverifikation zwischen heterogenen Modellen als offenes Problem belassen — yongol validate fuellt genau diese Luecke.

Die KI schreibt frei. Verlaesst sie die Schienen, faengt validate sie sofort. Freiheit auf Schienen.

yongol next — Der Ratschen-Befehl

Waehrend yongol validate alle Fehler auf einmal zeigt, zeigt yongol next Fehler einzeln. Das ist die Ratsche.

$ yongol next specs/

[ERROR] DDL-003: users.id must be BIGINT, got INT
  file: specs/db/users.sql:2
  ▶ Fix this error. Then run `yongol next specs/`.

Die einzige Anweisung, die ein KI-Agent braucht, ist ein Satz: “Fuehre yongol next specs/ aus und behebe Fehler, bis es 0 sind.”

Behebe den Fehler, der naechste erscheint. Bestehe alle, und es stoppt:

$ yongol next specs/

✓ All validations passed. 0 errors.

Der Agent erklaert nicht “Ich bin fertig”. Die Maschine urteilt “noch uebrig” oder “alle bestanden”. Der Agent hat keine Entscheidungsbefugnis ueber das Abschlussurteil.

Projekterstellung und Feature-Management

yongol init

Generiert automatisch SSOT-Geruest aus features.yaml.

yongol init Myapp features.yaml "My workflow automation SaaS"
cd Myapp && yongol validate specs     # 0 errors

Manifest, OpenAPI-operationId-Stubs, SSaC-Stub-Dateien, Rego-Autorisierungsregeln, Hurl-Smoke-Tests und sqlc-Konfiguration werden auf einen Schlag generiert. Das Projekt startet sofort im yongol validate-bestandenen Zustand.

yongol features add / remove

Features hinzufuegen oder entfernen:

yongol features add new_features.yaml         # SSaC-Stubs fuer neue operationIds generieren
yongol features remove ExportWorkflow --yes    # operationId + SSaC-Stubs loeschen

yongol import

Go-Client-Pakete aus externen OpenAPI-Spezifikationen (Stripe, GitHub, etc.) generieren:

yongol import https://api.stripe.com/openapi.yaml ./external/

Generierte Funktionen in SSaC mit @call <pkg>.<Func>({...}) aufrufen.

operationId ist der Schlussstein

Wie bindet man zehn Schichten zusammen? Mit einem einzigen PascalCase-Bezeichner.

Gib die operationId ExecuteWorkflow ein:

── Feature Chain: ExecuteWorkflow ──

  OpenAPI    api/openapi.yaml                POST /workflows/{id}/execute
  SSaC       service/workflow/execute_workflow.ssac   @get @empty @auth @state @call @publish @response
  DDL        db/workflows.sql                CREATE TABLE workflows
  DDL        db/execution_logs.sql           CREATE TABLE execution_logs
  Rego       policy/authz.rego               resource: workflow
  StateDiag  states/workflow.md              diagram: workflow → ExecuteWorkflow
  FuncSpec   func/billing/check_credits.go   @func billing.CheckCredits
  FuncSpec   func/billing/deduct_credit.go   @func billing.DeductCredit
  FuncSpec   func/worker/process_actions.go  @func worker.ProcessActions
  FuncSpec   func/webhook/deliver.go         @func webhook.Deliver
  Hurl       tests/scenario-happy-path.hurl  scenario: scenario-happy-path.hurl

Von der API-Spezifikation zum DB-Schema, von der Autorisierungsrichtlinie zu Zustandsuebergaengen, von Funktionsimplementierungen zu Testszenarien — die gesamte Topologie eines Features auf einem Bildschirm. Dutzende Greps durch einen einzigen Befehl ersetzt.

operationId ist der Schlussstein, weil in einer Full-Stack-Anwendung die Einheit eines Features der API-Endpoint ist. Ein Benutzer drueckt einen Button, eine API wird aufgerufen, und diese API durchschneidet jede andere Schicht. Ein Name verkettet physisch zehn Schichten.

SSaC — Warum ein benutzerdefiniertes DSL

Acht der 10 SSOTs von yongol sind Industriestandards. Nur SSaC (Service Sequences as Code) und STML wurden von yongol erstellt. SSaC erfasst Service-Fluss-Entscheidungen.

Die Luecke, die SSaC fuellt. Betrachte das Spektrum deklarativer Werkzeuge: An einem Ende stehen Vertragsstandards (OpenAPI, SQL, Rego) — sie deklarieren was, aber nicht in welcher Reihenfolge. Am anderen Ende stehen Workflow-Laufzeiten (Temporal, Inngest, Restate) — das ist Code. Entscheidungen und Implementierungsdetails rekombinieren sich in derselben Datei. SSaC sitzt in der Luecke dazwischen: “Innerhalb eines einzelnen Endpoints, was passiert, in welcher Reihenfolge, mit welchen Guards.”

SSaC hat insgesamt 16 Annotationen. Erlernbar mit einem einseitigen Handbuch.

Vollstaendige SSaC-Annotationsliste

SSaC-Beispiel — AcceptProposal

Autorisierung + doppelte Zustandsmaschinen + Treuhand + Warteschlange:

package service

import "github.com/org/project/internal/billing"

// @get Proposal p = Proposal.FindByID({ID: request.id})
// @empty p "Proposal not found" 404
// @get Gig gig = Gig.FindByID({ID: p.GigID})
// @empty gig "Gig not found" 404
// @auth "AcceptProposal" "gig" {ResourceID: request.id} "Forbidden" 403
// @state proposal {status: p.Status} "AcceptProposal" "Cannot accept" 409
// @state gig {status: gig.Status} "AcceptProposal" "Cannot accept on gig" 409
// @put Proposal.UpdateStatus({ID: p.ID, Status: "accepted"})
// @put Gig.AssignFreelancer({ID: gig.ID, FreelancerID: p.FreelancerID, Status: "in_progress"})
// @call billing.HoldEscrowResponse escrow = billing.HoldEscrow({GigID: gig.ID, Amount: gig.Budget})
// @publish "proposal.accepted" {GigID: gig.ID, FreelancerID: p.FreelancerID}
// @get Proposal updated = Proposal.FindByID({ID: p.ID})
// @response { proposal: updated }
func AcceptProposal() {}

16 Zeilen. 10 Annotationen. Zwei Zustandsmaschinen, Autorisierung, Treuhand, Warteschlangenereignis, Antwort — jede Entscheidung sichtbar, jedes Detail abwesend.

Benchmark: ZenFlow

ZenFlow — ein Multi-Tenant-Workflow-Automatisierungs-SaaS.

Ergebnis: 32 Endpoints, 14 Tabellen, 47 Hurl-Anfragen. 11/11 Stufen bestanden.

Das Hinzufuegen von Features hat sich nie verlangsamt. Bestehende Tests sind nie gebrochen. Die 200-Endpoint-Wand existierte nicht.

Opus 4.7 Benchmark — 32 Endpoints, 14 Tabellen, 47 Hurl-Anfragen, ~69 Min. Sonnet 4.6 Benchmark — 32 Endpoints, 9 Tabellen, 37 Hurl-Anfragen, ~43 Min.

yongol agent

Ein LLM korrigiert SSOT-Dateien automatisch durch eine Validate-Fix-Schleife.

yongol agent specs/ --model ollama:gemma4:e4b --max-rounds 20

Validate-Fehler werden dem LLM zurueckgegeben, das LLM behebt sie, und die Validierung laeuft erneut. Die Schleife wiederholt sich bis 0 Fehler. Funktioniert sogar mit einem lokalen 4.5B-Modell (Gemma4).

Unterstuetzte Backends: ollama (lokal), xai (Grok), gemini.

Kann man generierten Code bearbeiten

Ja. yongol generate bewahrt Benutzeraenderungen bei erneuter Ausfuehrung:

• Jede generierte Datei erhaelt eine //yg:checked llm=yongol-gen hash=<8hex>-Annotation.
• Wenn der Hash abweicht, wird die Datei als preserved markiert und beim naechsten generate uebersprungen.
• yongol status zeigt preservierte Dateien und Vertragsdrift (PRV-01/PRV-02-Fehler).
• Um die Absicht festzuhalten, fuege //yg:preserve reason="..." hinzu (optional). Zum Aufheben der Preservierung die Datei loeschen.

Eingebaute Funktionen und Modelle

Eingebaute Funktionen (aufgerufen via @call in SSaC)

Eingebaute Modelle (konfiguriert via manifest.yaml)

Automatische DDL-Migrationsgenerierung

yongol generate erkennt DDL-Aenderungen und generiert automatisch Migrationsdateien.

specs/db/
└── users.sql                         # SSOT — hier bearbeiten

artifacts/db/
├── .latest_schema.sql                # Baseline-Snapshot
└── migrations/
    ├── 0001_initial.up.sql
    ├── 0001_initial.down.sql
    ├── 0002_add_users_email.up.sql
    └── 0002_add_users_email.down.sql

Mehrdeutige Aenderungen (Spaltenumbenennungen, Typumwandlungen, NOT-NULL-Backfill) werden mit DDL-Kommentar-Hinweisen (-- @rename, -- @cast, -- @backfill, -- @data_migration, -- @allow_destructive) eindeutig gemacht. Sechs Regeln (MIG-001 bis MIG-006) kontrollieren gefaehrliche Aenderungen. Die tatsaechliche DB-Anwendung wird an Standardwerkzeuge wie golang-migrate, flyway usw. delegiert.

Warum ein groesseres Modell nicht die Antwort ist

“GPT-6 wird das loesen.”

Wird es nicht. Das Problem ist nicht die Intelligenz des Modells — es ist das Medium.

Code als Medium unterscheidet nicht zwischen Entscheidungen und Implementierung. Welches Modell auch immer den Code liest, es sieht Text, in dem Entscheidungen und Details verflochten sind. Egal wie intelligent das Modell ist — wenn das Medium die Unterscheidung nicht bietet, kann das Modell sie nicht treffen.

yongol aendert das Medium. Es verschiebt, was die KI bearbeitet, von Code zu deklarativen Spezifikationen. Da Spezifikationen nur Entscheidungen ohne Implementierungsdetails enthalten, kann die KI nie eine Entscheidung mit einem Detail verwechseln. Das Ueberleben von Entscheidungen wird unabhaengig von der Modellgroesse.

Ein kleines LLM, das nur SSOTs bearbeitet, wobei validate bei jedem Fehler praezises Feedback gibt, kann die gleiche Entscheidungsintegritaet aufrechterhalten wie ein viel groesseres Modell, das rohen Code bearbeitet. yongol ueberbrueckt diese Kluft.

Laufzeittests

Hurl-Tests werden alle vom Benutzer geschrieben. Schreibe sie in specs/tests/ und yongol generate spiegelt sie nach artifacts/tests/. Bei der Validierung pruefen die Regeln XOH-01 bis XOH-09 Hurl kreuzweise gegen OpenAPI, Zustandsmaschinen und manifest.auth.

hurl --test --variable host=http://localhost:8080 artifacts/my-project/tests/*.hurl

Drei Kategorien:

• smoke.hurl — Endpoint-Smoke-Tests
• scenario-*.hurl — Geschaeftsszenario-Tests
• invariant-*.hurl — Endpoint-uebergreifende Invarianten-Tests

Aktueller Stand

Go+Gin-Backend-Generierung: Beta — End-to-End funktionsfaehig. React-Frontend-Generierung: Alpha (in Arbeit).

Erste Schritte

Methode 1: Skill installieren (Empfohlen)

npx skills add park-jun-woo/yongol

Installiere den yongol-Skill in deinen KI-Agenten (Claude Code, Cursor, Copilot und mehr). Der Agent lernt den Workflow bei der Installation.

/yongol Baue ein Multi-Tenant-Todo-SaaS mit Auth und CRUD.

Methode 2: Direkte Installation

Erfordert Go 1.25+ und gcc (cgo-Abhaengigkeit: pg_query_go linkt libpg_query fuer DDL-Parsing).

git clone https://github.com/park-jun-woo/yongol && cd yongol
make install

yongol validate examples/zenflow

0 errors, 0 warnings.

Richte eine KI auf diese Spezifikationen und sage ihr, ein Feature hinzuzufuegen. validate legt die Schienen; die KI laeuft darauf. Es gibt keine Wand.

Quellen

1. Google DORA Team. DORA State of AI-Assisted Software Development 2025. Google Cloud, 2025. dora.dev/dora-report-2025
2. David L. Parnas. “On the Criteria to Be Used in Decomposing Systems into Modules.” Communications of the ACM 15(12): 1053-1058, 1972. doi:10.1145/361598.361623
3. Weslley Torres, Mark G.J. van den Brand, Alexander Serebrenik. “A Systematic Literature Review of Cross-Domain Model Consistency Checking by Model Management Tools.” Software and Systems Modeling 20(3): 897-916, 2021. doi:10.1007/s10270-020-00834-1
4. Deepak Babu Piskala. “Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants.” arXiv:2602.00180, January 2026. arxiv.org/abs/2602.00180
5. Ehsani et al. “When AI Code Doesn’t Stick: An Empirical Study on Reverted Changes Introduced by AI Coding Agents.” MSR 2026 Mining Challenge, April 2026. 2026.msrconf.org
6. Anton Jansen, Jan Bosch. “Software Architecture as a Set of Architectural Design Decisions.” EWSA 2005, LNCS 3527, Springer, 2005. semanticscholar.org
7. Marco Brambilla, Jordi Cabot, Manuel Wimmer. Model-Driven Software Engineering in Practice. 2nd ed., Springer, 2017. doi:10.1007/978-3-031-02546-4
8. GitClear. AI Copilot Code Quality 2025. February 2025. gitclear.com

Verwandte Artikel

• SSaC — Service Sequences as Code — yongols Schlussstein-DSL. Deklariert Entscheidungen innerhalb von Endpoints.
• Feature Chain — Einen Full Stack mit einer operationId verfolgen — Alle acht Schichten durch eine einzelne operationId verfolgen.
• Ratchet Pattern — Wie man einen Agenten die Arbeit beenden laesst — Die theoretische Grundlage, wie validate Feedback an Agenten gibt.
• IFEval-ausnutzender Ratchet-Code — Eine Codegenerierungsschleife, die Schmeichelei-Bias ausnutzt, und Reins.

Code: github.com/park-jun-woo/yongol

Aenderungshistorie

Änderungsverlauf

• 2026-05-18: Erstveröffentlichung