BD TECH.

כתיבה

מ-vibe coding לפיתוח מונחה-מפרט: ארכיטקטורה AI-native שבנויה על מפרטים, סקילים ולולאות אימות עצמי

פורסם en

פורסם לראשונה ב-Medium באפריל 2026. הנתונים, שמות הכלים והמקורות עודכנו באוקטובר 2026.

איך בונים מערכות אמינות כשאת הקוד כותבים סוכנים הסתברותיים? העבודה האמיתית היא לא לכתוב פרומפטים טובים יותר.

ממכונת הקלדה למכונת חוב טכני

ב-2024 התעשייה התיישבה על תמונה פשוטה: AI הוא קלדן מהיר. המפתח מתאר בשפה פשוטה מה הוא רוצה, והמודל מספק. זו הייתה ההבטחה של vibe coding, קו ישר מכוונה לקוד.

שנתיים אחר כך, הנתונים מספרים סיפור אחר.

  • מחקר אמפירי גדול שעלה ל-arXiv במרץ 2026 עקב אחרי 302,600 קומיטים שנכתבו ב-AI ב-6,299 ריפואים. הקומיטים האלה הכניסו 484,366 ליקויים. רובם (89%) הם code smells ולא באגים של ממש, ו-22.7% מהם, כ-110,000, עדיין נמצאים בגרסה האחרונה של הקוד.
  • ניתוח של Sonar מאוגוסט 2025 נתן למודלים מובילים לכתוב יותר מ-4,400 משימות ב-Java. יותר מ-70% מהפגיעויות בקוד של Llama 3.2 90B דורגו BLOCKER, החומרה הגבוהה ביותר. ב-GPT-4o הנתון היה 62.5%.

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

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

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

1. מה השתנה

המונח פיתוח מונחה-מפרט (Spec-Driven Development, או SDD) תפס באמצע 2025, כש-Kiro, ‏Spec Kit ו-Tessl יצאו בתוך חודשיים זה מזה. שנה אחר כך זה כבר תחום צפוף, עם עשרות frameworks. כמה מהם:

  • GitHub Spec Kit: קוד פתוח, כ-140,000 כוכבים, בנוי סביב פקודה לכל שלב: specify,‏ plan,‏ tasks,‏ implement.
  • Kiro (AWS): סביבת פיתוח, זמינה לכולם מנובמבר 2025, שמתרגמת כוונה בשפה טבעית לדרישות בכתיב EARS ("WHEN … THE SYSTEM SHALL …").
  • OpenSpec: לולאה קלה יותר של propose,‏ apply ו-archive. היא גמישה בכוונה, בלי שערים בין השלבים.
  • BMAD-METHOD: תזמור של כמה סוכנים עם פרסונות בעלות שם (אנליסט, מנהל מוצר, ארכיטקט, מפתח), שמעבירים הקשר זה לזה דרך מסמכי Markdown: PRD, מסמך ארכיטקטורה, קובצי story.
  • Agent Skills: הפורמט SKILL.md, ש-Anthropic פרסמה כתקן פתוח בדצמבר 2025. האתר agentskills.io מונה היום יותר מארבעים כלים שקוראים אותו, ביניהם Claude Code,‏ Cursor,‏ Codex,‏ Gemini CLI,‏ GitHub Copilot ו-Kiro. ספריות קהילה כמו Antigravity Awesome Skills מציעות יותר מ-2,600 סקילים מוכנים.

כולם נשענים על עיקרון אחד:

אל תיתן ל-AI לכתוב קוד מפרומפט. תן לו מפרט שאומר בדיוק מה, וכלים דטרמיניסטיים שמטפלים באיך.

זה מעביר את השאלה מ"איזה מודל הכי חכם?" ל"איזה הקשר הופך כל מודל לאמין?". לדיסציפלינה קוראים הנדסת הקשר (context engineering). ה-SDD מספק את השיטה, והנדסת ההקשר מספקת את המסגרת: תכנון הסביבה כולה, כלומר מה הסוכן יודע, מתי הוא יודע את זה, ואיך הוא בודק את העבודה של עצמו.

2. ארבעה עמודי מפרט

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

מהמפרט ועד התוצר שאדם רואה:

  1. ארבעה מפרטים: מבנה (YAML,‏ JSON Schema), עיצוב (DESIGN.md ו-tokens), תוכן (Markdown,‏ JSON) והתנהגות (מכונות מצבים).
  2. סקיל (SKILL.md) קורא אותם ומריץ סקריפטים דטרמיניסטיים. הוקים מחזיקים את הצעדים שאסור לדלג עליהם.
  3. הסוכן מייצר תוצר.
  4. אימות דטרמיניסטי. נכשל: חזרה לשלב 2 ותיקון. עבר: ממשיכים.
  5. אדם בודק את התוצר הנקי.

עמוד ראשון: מבנה

  • השאלה: אילו רכיבים קיימים, ואיך הם מחוברים?
  • הפורמט: YAML לתצורה ולהיררכיה; JSON Schema לנתונים ולחוזי API.
  • התפקיד: החוקה של הפרויקט, שרטוט הצהרתי שקובע את הגבולות. פורמט שמכונה קוראת חשוב כי אפשר לבדוק אותו: סכמה עוברת אימות או שלא, ואילו פסקת פרוזה אפשר רק לפרש.

עמוד שני: עיצוב

  • השאלה: איזו חוויה המערכת נותנת?
  • הפורמט: קובץ DESIGN.md ייעודי ו-design tokens.
  • התפקיד: עקביות חזותית. ה-tokens (צבע, טיפוגרפיה, ריווח) יושבים בקובץ נפרד שכל רכיב מייבא. זה הופך אותם לחוזה שאפשר לאכוף: משנים token אחד, והמערכת כולה מתעדכנת.

עמוד שלישי: תוכן, מדיה ונתונים

  • השאלה: מה המערכת מציגה?
  • הפורמט: Markdown לתוכן, JSON לנתונים מובנים.
  • התפקיד: הפרדה בין תוכן לקוד. הפרדה פיזית היא גם הפרדה לוגית. היא מונעת מהסוכן לסבך עדכון תוכן עם שינוי קוד, מקור נפוץ לעריכות מומצאות.

עמוד רביעי: התנהגות ולוגיקה

  • השאלה: איך המערכת מתנהגת?
  • הפורמט: מודל היברידי שמפריד בין מה לאיך.
    • מה: לוגיקה הצהרתית (מכונות מצבים, תהליכים, אינווריאנטים) ב-YAML.
    • איך: חישוב (אלגוריתמים מורכבים, אינטגרציות חיצוניות) ארוז בסקילים או בשרתי MCP.

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

3. לכל עמוד צריך בעלים אנושי

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

עמוד תפקיד AI-native המקבילה המסורתית אחריות
מבנה בונה אפליקציות ארכיטקט פתרונות, ראש צוות טכני מגדיר היררכיה וחוזי API. כותב את project-structure-skill.
עיצוב מהנדס עיצוב מהנדס UX, מוביל עיצוב מגדיר tokens ומתחזק את DESIGN.md. כותב את design-tokens-skill.
תוכן ונתונים מוביל תוכן אסטרטג תוכן, מהנדס נתונים מגדיר מבני נתונים ותקני Markdown. כותב את content-md-skill.
התנהגות מהנדס התנהגות מומחה תחום, מהנדס backend מגדיר מכונות מצבים ותהליכים. כותב את state-machine-skill.

אבחון מהיר. מי בארגון תופס צבע hex שנכתב ישירות בקוד במקום token? מי חוסם חוזה API שהשתנה בלי העלאת גרסה? מי שם לב לתהליך עם מצב מת, או לנתון לא תקין שחמק לקובץ JSON? בלי בעלות מפורשת, כל כשל הופך לבעיה של המפתח האחרון. זה הדפוס שמשאיר עשרות אלפי ליקויים שהכניס AI יושבים בקוד שבפרודקשן.

התפקיד החמישי: אחראי הסקילים

מעבר לבעלי העמודים, אחראי הסקילים (או מהנדס הפלטפורמה) הוא הבעלים של המנוע הדטרמיניסטי עצמו:

  • הסקריפטים שאוכפים את המפרטים (validate.py,‏ test.py);
  • הסקילים הרוחביים: אימות, בדיקות, קומיט;
  • ניהול גרסאות ובקרת איכות לספריית הסקילים כולה.

4. סקילים: המנוע שמריץ את המפרטים

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

4.1 איך סקיל עובד

סקיל הוא תיקייה: נקודת כניסה (SKILL.md), סקריפטים דטרמיניסטיים ותבניות. ה-front matter שלו מאפשר חשיפה הדרגתית (progressive disclosure): המודל רואה רק את התיאור של הסקיל, וטוען את ההוראות המלאות רק כשמשימה מתאימה לו. זה חוסך הקשר ומפחית רעש.

4.2 שלושה מנגנוני ציות

  1. חשיפה הדרגתית. המודל יודע רק את מה שנוגע למשימה שלפניו.
  2. צעדים אכופים. לקוחות כמו Claude Code חושפים הוקים: מיירטים במחזור החיים שרצים לפני קריאה לכלי או אחריה. הוק מסוג PreToolUse יכול לחסום כתיבה, להחזיר למודל שגיאה מובנית, או לדרוש אישור אנושי לפני פעולה הרסנית. זה ההבדל בין "המודל אמור לאמת" לבין "המודל לא יכול להמשיך בלי לאמת". (מקרה מוחשי אחד תיארתי ברשימה על RepoGuards.)
  3. אימות דטרמיניסטי. סקריפטי הבדיקה נכתבים בידי אנשים, ב-Python או ב-JavaScript. המודל לא יכול להמציא "עבר"; הוא חייב לקבל אות הצלחה מובנה מהסקריפט.

4.3 קבוצת סקילים לכל עמוד

לכל סוג רכיב יש קבוצת סקילים משלו, שמתחזק הבעלים של העמוד:

  • מבנה (בונה האפליקציות): project-structure-skill בודק היררכיה ותלויות; api-contract-skill מנהל גרסאות של OpenAPI ו-JSON Schema.
  • עיצוב (מהנדס העיצוב): design-tokens-skill אוכף tokens וחוסם ערכים קשיחים; component-style-skill מחיל אותם על רכיבי הממשק.
  • תוכן ונתונים (מוביל התוכן): content-md-skill בודק front matter ועימוד; data-json-skill בודק את שלמות הרשימות המובנות.
  • התנהגות (מהנדס ההתנהגות): state-machine-skill בודק מעברים תקינים וכיסוי אירועים; mcp-integration-skill מטפל בניסיונות חוזרים ובהזדהות מול APIs חיצוניים.

4.4 סקילים הם שכבה אחת מכמה

סקילים הם לא כל הארכיטקטורה. התיעוד של Claude Code מסדר את שכבות ההרחבה שלו לפי המחיר שלהן בהקשר:

  • CLAUDE.md: נטען לכל בקשה. השכבה היקרה ביותר.
  • סקילים: רק התיאורים שלהם נוכחים תמיד; הגוף נטען לפי הצורך.
  • שרתי MCP: זולים עד שמשתמשים בכלי, כי חיפוש הכלים פעיל כברירת מחדל.
  • Subagents: רצים בהקשר משלהם, מבודד מההקשר הראשי.
  • הוקים: לא עולים כלום אלא אם הם מחזירים פלט.

סקילים ו-MCP משלימים זה את זה ולא מתחרים. הסקיל מתאר את סדר הפעולות, שרת ה-MCP מבצע את הפעולה, וההוק אוכף את הסדר.

5. לולאת האימות העצמי

מה ששובר את מעגל התסכול הוא לולאה של ייצור, אימות, תיקון:

  1. הסוכן מייצר תוצר מתוך המפרט.
  2. רץ מאמת דטרמיניסטי: linter, בודק טיפוסים, סקריפט ייעודי.
  3. נכשל: הסוכן מקבל שגיאה מובנית ומתקן.
  4. עבר: אדם בודק את התוצר הסופי והנקי.

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

App Factory, ספריית הסקילים שבתיבה למטה, עובדת כך. לפני כל העלאה לחנות, pull_and_diff מושך את הרישום החי ומשווה אותו לעותק המקומי, ועוצר אם שני הצדדים השתנו באופן שונה. copy-edit סופר את הטענות בכל שפה, ומכשיל תרגום שיש בו טענה אחת פחות מבאנגלית. אף אחת מהבדיקות לא שואלת את המודל אם הוא עשה עבודה טובה. כל אחת מריצה סקריפט, והסקריפט מחזיר עבר או נכשל.

6. סקילים ו-MCP כנכסי ידע

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

  • הפצה: רישומי MCP כמו Smithery ו-Glama, ומרקטפלייסים של פלאגינים ב-Claude Code, הפכו למקום שבו מוצאים יכולות, בדומה לחנות אפליקציות.
  • מומחיות כמוצר: ידע תחומי (איך מתנהג ה-API של ספק תשלומים, איך מפעילים כלי תשתית) אפשר היום לשחרר כסקיל או כשרת MCP לשימוש חוזר, במקום כעמוד בוויקי.
  • חוב הקשר: החוב הטכני של 2026 הוא לא רק קוד מסובך. הוא היעדר של הנדסת הקשר. צוות בלי ספריית סקילים פנימית מתוחזקת לא יכול להשתמש ב-AI בבטחה, וגם לא בהיקף.

סיכום: הנדסת הקשר כדיסציפלינה

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

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

מקורות וקריאה נוספת