yongol — Der Kiel von KI-codiertem SaaS

Der 200. Endpoint

Man baut ein SaaS mit Vibe Coding. Anfangs geht es schnell. 5 Tabellen, 12 Endpoints — zwanzig Minuten und es läuft.

Aber ab 50 Endpoints passiert etwas Seltsames. Die KI erzeugt heute ein Muster, das dem gestrigen widerspricht. Ab 100 gehen bestehende Funktionen still kaputt. Ab 200 kostet das Hinzufügen einer einzigen Funktion das 10-Fache der ersten zehn.

Es liegt nicht daran, dass das Modell dumm ist.

Entscheidungen und Implementierung

Drei Dinge sind im Quellcode verwoben:

• Benutzerentscheidungen — diese Spalte ist BIGINT, dieser Endpoint ist nur für den Eigentümer, Paginierung per Cursor.
• Geschäftslogik — Preisgestaltung, Workflows, Lebenszyklusregeln.
• Implementierungsdetails — Variablennamen, Reihenfolge von Bibliotheksaufrufen, Fehlerumhüllung.

Wenn die KI diesen Code liest, kann sie nicht unterscheiden, welche Zeile eine Entscheidung und welche ein Detail ist. Wenn sie also „refaktorisiert" oder „aufräumt", überschreibt sie still Entscheidungen, die sie für Details gehalten hat. Der Benutzer merkt es erst, wenn das Verhalten bereits falsch ist.

Deshalb bricht Vibe Coding bei 200 Endpoints zusammen. Ein größeres Modell löst das nicht. Das Medium — roher Code — bewahrt Entscheidungen schlicht nicht. Jedes Modell stößt letztlich an dieselbe Wand.

Der Kiel

Der Kiel ist der erste Knochen, der beim Schiffbau gelegt wird. Er trägt das Gewicht des Rumpfes, verhindert seitliches Rollen, und alle anderen Strukturen werden darauf aufgebaut. Ein Schiff ohne Kiel schwimmt in ruhigem Wasser, verformt sich aber, wenn Wellen kommen.

Ein mit Vibe Coding gebautes SaaS ist genauso. Klein schwimmt es. Groß verformt es sich.

yongol ist der Kiel von KI-codiertem SaaS.

Entscheidungen aus dem Code herausnehmen

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

Zehn deklarative Spezifikationen (SSOTs) behandeln jeweils ein einzelnes Anliegen:

Acht der 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, ist minimiert.

Jeder SSOT enthält nur Entscheidungen. Keine Implementierungsdetails. Die KI bearbeitet SSOTs; yongol generate rendert Code daraus. Entscheidungen leben dauerhaft in den SSOTs; der Code ist eine Wegwerfprojektion.

Konsistenz erzwingen

Entscheidungen sind nun über zehn Dateien verteilt, also können Widersprüche auftreten. DDL sagt BIGINT, aber OpenAPI sagt string? SSaC deklariert @auth, aber Rego hat keine passende Regel? Das Zustandsdiagramm hat einen Übergang, aber SSaC hat keine entsprechende Funktion?

Ein widersprüchlicher SSOT ist eine beschädigte Entscheidung. Egal wie sauber der Code ist — wenn Entscheidungen sich widersprechen, ist das Verhalten falsch.

yongol validate fängt 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 jeder SSOT einzeln validiert, dann werden schichtübergreifende Querprüfungen ausgeführt. ~287 Regeln prüfen jede symbolische Referenz zwischen allen zehn SSOTs. Existiert ein einziger Widerspruch, wird die Kompilierung abgelehnt.

Die KI schreibt frei. Verlässt sie die Schienen, fängt validate sie sofort ab. Freiheit auf Schienen.

operationId ist der Schlussstein

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

Geben Sie 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 bis zum Datenbankschema, von Autorisierungsrichtlinien bis zu Zustandsübergängen, von Funktionsimplementierungen bis zu Testszenarien — die vollständige Topologie einer Funktion auf einem Bildschirm. Dutzende Greps durch einen einzigen Befehl ersetzt.

operationId ist der Schlussstein, weil in einer Full-Stack-Anwendung die Einheit einer Funktion der API-Endpoint ist. Ein Benutzer drückt einen Knopf, eine API wird aufgerufen, und diese API durchschneidet alle anderen Schichten. Ein Name verkettet physisch zehn Schichten.

Benchmark: ZenFlow

ZenFlow — ein mandantenfähiges Workflow-Automatisierungs-SaaS. Claude Sonnet 4.6 schrieb die SSOTs; yongol validierte sie.

Ergebnis: 30 Endpoints, 12 Tabellen, 64 Testanfragen. Alles grün.

Zehn Funktionen sequentiell hinzugefügt. Das Hinzufügen von Funktionen wurde nie langsamer. Bestehende Tests gingen nie kaputt. Die 200-Endpoint-Wand existierte nicht.

Dieselbe Spezifikation mit Opus ausgeführt: 30 Endpoints, 73 Testanfragen, ~76 Min. Das Modell wechselt, die Schienen bleiben gleich.

Warum ein größeres Modell nicht die Antwort ist

„GPT-6 wird das lösen."

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, sieht Text, in dem Entscheidungen und Details verwoben sind. Egal wie klug das Modell ist — wenn das Medium die Unterscheidung nicht liefert, kann das Modell sie nicht treffen.

yongol ändert das Medium. Es verlagert das, was die KI bearbeitet, vom Code auf deklarative Spezifikationen. Da Spezifikationen nur Entscheidungen ohne Implementierungsdetails enthalten, verwechselt die KI nie eine Entscheidung mit einem Detail. Das Überleben von Entscheidungen wird unabhängig von der Modellgröße.

Ein kleines LLM, das nur SSOTs bearbeitet, mit validate, das bei jedem Fehler präzises Feedback liefert, kann dieselbe Entscheidungsintegrität aufrechterhalten wie ein viel größeres Modell, das rohen Code bearbeitet. yongol überbrückt diese Lücke.

Loslegen

npx skills add park-jun-woo/yongol

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

Für die direkte CLI-Nutzung:

go install github.com/park-jun-woo/yongol/cmd/yongol@latest

git clone https://github.com/park-jun-woo/yongol && cd yongol
yongol validate examples/zenflow

0 errors, 0 warnings.

Richten Sie eine KI auf diese Spezifikationen und sagen Sie ihr, sie soll eine Funktion hinzufügen. validate legt die Schienen; die KI fährt darauf. Es gibt keine Wand.

Verwandte Artikel

• SSaC — Service Sequences as Code — yongols Schlussstein-DSL. Deklariert Entscheidungen innerhalb von Endpoints.
• Feature Chain — Einen Full Stack mit einer operationId verfolgen — Verfolgung aller acht Schichten über eine einzige operationId.
• Ratchet Pattern — Wie man einen Agenten dazu bringt, die Arbeit zu beenden — Die theoretische Grundlage, wie validate Feedback an Agenten gibt.

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