yongol — השדרה של SaaS מקודד בינה מלאכותית

ה-Endpoint ה-200

אתה בונה SaaS עם vibe coding. בהתחלה מהיר. 5 טבלאות, 12 endpoints — עשרים דקות וזה עובד.

אבל אחרי 50 endpoints, משהו מוזר קורה. ה-AI מייצר היום תבנית שסותרת את אתמול. אחרי 100, פיצ’רים קיימים נשברים בשקט. אחרי 200, הוספת פיצ’ר אחד עולה פי 10 מעשרת הראשונים.

זה לא שהמודל טיפש.

החלטות ומימוש

שלושה דברים שזורים בקוד המקור:

• החלטות משתמש — העמודה הזו היא BIGINT, ה-endpoint הזה רק לבעלים, pagination בשיטת cursor.
• לוגיקה עסקית — תמחור, workflows, כללי מחזור חיים.
• פרטי מימוש — שמות משתנים, סדר קריאות לספריות, עטיפת שגיאות.

כש-AI קורא את הקוד הזה, הוא לא יכול להבחין איזה שורה היא החלטה ואיזו פרט. אז כשהוא “מבצע refactoring” או “מנקה”, הוא דורס בשקט החלטות שטעה לחשוב שהן פרטים. המשתמש מגלה רק אחרי שההתנהגות כבר שגויה.

זו הסיבה ש-vibe coding קורס ב-200 endpoints. מודל גדול יותר לא פותר את זה. המדיום — קוד גולמי — פשוט לא משמר החלטות. כל מודל בסופו של דבר נתקע באותו קיר.

השדרה

השדרה (קיל) היא העצם הראשונה שמניחים בבניית ספינה. היא נושאת את משקל הגוף, מונעת גלגול צידי, וכל מבנה אחר נבנה מעליה. ספינה בלי שדרה צפה במים שקטים אבל מתעוותת כשבאים הגלים.

SaaS שנבנה עם vibe coding זהה. צף כשהוא קטן. מתעוות כשהוא גדל.

yongol הוא השדרה של SaaS מקודד בינה מלאכותית.

להוציא החלטות מהקוד

הליבה של yongol פשוטה. להפריד החלטות מקוד.

עשרה מפרטים הצהרתיים (SSOTs) כל אחד מטפל בתחום אחד:

שמונה מתוך עשרה הם תקנים תעשייתיים (OpenAPI, SQL, sqlc, Rego, Mermaid, Hurl, YAML). רק SSaC ו-STML הם DSL שנוצרו על ידי yongol. מה ש-AI צריך ללמוד מאפס ממוזער.

כל SSOT מכיל רק החלטות. אין פרטי מימוש. ה-AI עורך SSOTs; yongol generate מרנדר קוד מהם. החלטות חיות לצמיתות ב-SSOTs; הקוד הוא הטלה חד-פעמית.

אכיפת עקביות

החלטות מפוזרות עכשיו בעשרה קבצים, אז סתירות יכולות להופיע. DDL אומר BIGINT אבל OpenAPI אומר string? SSaC מצהיר @auth אבל ל-Rego אין כלל מתאים? לדיאגרמת המצבים יש מעבר אבל ל-SSaC אין פונקציה מתאימה?

SSOT סותר הוא החלטה פגומה. לא משנה כמה הקוד נקי, אם ההחלטות סותרות, ההתנהגות שגויה.

yongol validate תופס את זה.

✓ 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

קודם מאמת כל SSOT בנפרד, ואז מריץ בדיקות צולבות בין שכבות. ~287 כללים בודקים כל הפניה סימבולית בין כל עשרת ה-SSOTs. אם קיימת סתירה אחת, הקומפילציה נדחית.

ה-AI כותב בחופשיות. ירד מהפסים — validate תופס מיד. חופש על פסים.

operationId הוא אבן הנעילה

איך קושרים עשר שכבות יחד? עם מזהה PascalCase אחד.

הכנס את operationId ExecuteWorkflow:

── 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

ממפרט API עד סכמת מסד נתונים, ממדיניות הרשאות עד מעברי מצב, ממימושי פונקציות עד תרחישי בדיקה — הטופולוגיה המלאה של פיצ’ר אחד במסך אחד. עשרות grep מוחלפים בפקודה אחת.

operationId הוא אבן הנעילה כי באפליקציית full-stack, היחידה של פיצ’ר היא ה-API endpoint. משתמש לוחץ על כפתור, API נקרא, וה-API הזה חוצה כל שכבה אחרת. שם אחד משרשר פיזית עשר שכבות.

Benchmark: ZenFlow

ZenFlow — SaaS לאוטומציית workflows רב-דיירים. Claude Sonnet 4.6 כתב את ה-SSOTs; yongol אימת אותם.

סיכום: 30 endpoints, 12 טבלאות, 64 בקשות בדיקה. הכל ירוק.

10 פיצ’רים נוספו ברצף. הוספת פיצ’רים אף פעם לא האטה. בדיקות קיימות אף פעם לא נשברו. קיר ה-200 endpoints לא היה קיים.

הרצת אותו מפרט עם Opus: 30 endpoints, 73 בקשות בדיקה, ~76 דקות. המודל משתנה, הפסים נשארים אותו דבר.

למה מודל גדול יותר הוא לא התשובה

“GPT-6 יפתור את זה.”

לא יפתור. הבעיה היא לא אינטליגנציה של המודל — אלא המדיום.

קוד כמדיום לא מבחין בין החלטות למימוש. כל מודל שקורא קוד רואה טקסט שבו החלטות ופרטים שזורים. לא משנה כמה המודל חכם, אם המדיום לא מספק את ההבחנה, המודל לא יכול לעשות אותה.

yongol משנה את המדיום. מעביר את מה ש-AI עורך מקוד למפרטים הצהרתיים. כיוון שמפרטים מכילים רק החלטות בלי פרטי מימוש, AI לעולם לא מבלבל החלטה עם פרט. הישרדות החלטות הופכת לבלתי תלויה בגודל המודל.

LLM קטן שעורך רק SSOTs, עם validate שנותן משוב מדויק בכל טעות, יכול לשמור על אותה שלמות החלטות כמו מודל גדול בהרבה שעורך קוד גולמי. yongol מגשר על הפער הזה.

התחל

npx skills add park-jun-woo/yongol

התקן את skill yongol בסוכן ה-AI שלך (Claude Code, Cursor, Copilot ועוד). הסוכן לומד את זרימת העבודה אוטומטית בהתקנה.

לשימוש ישיר ב-CLI:

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.

כוון AI למפרטים האלה ואמור לו להוסיף פיצ’ר. validate שם את הפסים; ה-AI רץ עליהם. אין קיר.

מאמרים קשורים

• SSaC — Service Sequences as Code — ה-DSL אבן הנעילה של yongol. מצהיר על החלטות בתוך endpoints.
• Feature Chain — לעקוב אחרי Full Stack עם operationId אחד — מעקב בשמונה שכבות דרך operationId אחד.
• Ratchet Pattern — איך לגרום לסוכן לסיים את העבודה — הבסיס התיאורטי לאיך validate נותן משוב לסוכנים.

קוד: github.com/park-jun-woo/yongol