Spec-Driven Development (פיתוח מונחה מפרט)

מה זה פיתוח מונחה מפרט, ולמה זה שונה מהקלדת פרומפט

Spec-Driven Development (פיתוח מונחה מפרט) הוא גישה לכתיבת תוכנה בעזרת סוכני AI. במקום לתת לסוכן תיאור חופשי של המשימה ולסמוך עליו שימלא בעצמו את כל הפרטים החסרים, כותבים קודם מפרט שמגדיר מה בדיוק התוכנה צריכה לעשות, מאשרים אותו, ורק אז מבקשים מהסוכן לייצר את הקוד לפי המפרט. דן דלימרסקי, מנהל מוצר ראשי ב-GitHub שכתב את הכרזת הכלי Spec Kit, ניסח את הביקורת המרכזית על הגישה הקודמת: "אנחנו מתייחסים לסוכני קוד כמו למנועי חיפוש, כשצריך להתייחס אליהם יותר כמו לשותפי תכנות שמבינים כל דבר כפשוטו". לדבריו, "הבעיה אינה ביכולת הקידוד של הסוכן, אלא בגישה שלנו", ופרומפט מעורפל "מכריח את המודל לנחש אולי אלפי דרישות לא כתובות". ההכרזה הרשמית מנסחת זאת במפורש: "אנחנו עוברים מהרעיון ש'הקוד הוא מקור האמת' לרעיון ש'הכוונה היא מקור האמת'", ולפי ההכרזה, התועלת המרכזית של הגישה היא שהיא "מפרידה בין ה'מה' היציב לבין ה'איך' הגמיש" — כלומר בין מה שהמערכת צריכה לעשות לבין הדרך הטכנית שבה היא ממומשת בקוד, כך שאפשר לשנות את המימוש בלי לכתוב הכול מחדש.

GitHub Spec Kit: ארבעה שלבים מ-Specify ל-Implement

הכלי הפתוח שהפך את הגישה לפרקטיקה נוחה לשימוש הוא Spec Kit, שחברת GitHub פרסמה כקוד פתוח ב-2 בספטמבר 2025. בהשקה הכלי הגדיר ארבעה שלבים עם נקודות בדיקה ברורות: Specify, שבו כותבים את המפרט בשפה טבעית; Plan, שבו המפרט מתורגם לתכנית טכנית; Tasks, שבו התכנית מתפרקת למשימות קטנות שניתנות לבדיקה; ו-Implement, שבו סוכן הקוד מבצע את המשימות בפועל. בשלב ההקמה משתמשים בכלי שורת פקודה בשם specify כדי להקים את מבנה הפרויקט, ובגרסת ההשקה עבדו לאחר מכן עם הפקודות /specify, /plan ו-/tasks בתוך סוכן הקוד עצמו. בגרסה הנוכחית של הכלי, נכון לאוקטובר 2026, הפקודות נקראות /speckit-specify, /speckit-plan וכן הלאה, ונוסף להן שלב בדיקת התכנסות (converge) אחרי המימוש. בהכרזה הרשמית ציינה GitHub תמיכה בשלושה סוכני קוד בהשקה: GitHub Copilot, Claude Code ו-Gemini CLI, והציגה שלושה תרחישי שימוש מרכזיים: פרויקט מאפס, הוספת תכונה למערכת קיימת, ומודרניזציה של מערכת ישנה.

מפרטים כמסמכים חיים, ולא ניירת בירוקרטית נוספת

פוסט רשמי נוסף על הכלי, שפרסם דן דלימרסקי בבלוג המפתחים של Microsoft ב-15 בספטמבר 2025, מגדיר פיתוח מונחה מפרט כניסיון להפוך החלטות טכניות ל"מפורשות, ניתנות לבדיקה ולשינוי", ומתאר אותו כ"בקרת גרסאות למחשבה". הפוסט מבהיר במפורש מה הגישה אינה: היא אינה כתיבת דרישות ממצה לכל פרט, אינה תכנון בשיטת המפל, ואינה ניירת בירוקרטית נוספת; המפרטים מתוארים כמסמכים חיים שמשתנים לצד הקוד, לא כמסמך קפוא שנחתם פעם אחת. הכלי כולל גם קובץ בשם constitution.md, שבו קובעים עקרונות מחייבים לפרויקט כולו, וסדרת תבניות, שכלי שורת הפקודה specify מוריד לתיקיית הפרויקט, ושמגדירות איך נראים המפרט, התכנית והמשימות.

AWS Kiro: מפרט כתוב ב-EARS, ו-hooks אוטומטיים

דרך מוקדמת יותר למימוש הגישה היא Kiro, סביבת פיתוח מבוססת סוכן (agentic IDE) שחברת AWS השיקה ב-14 ביולי 2025, לפני השקת Spec Kit, ותיארה אותה בהכרזה הרשמית כבנויה על בסיס הקוד הפתוח של VS Code. התהליך ב-Kiro מתחיל מפרומפט יחיד שממנו נוצר מסמך דרישות עם תנאי קבלה הכתובים בתחביר שנקרא EARS, ראשי תיבות של Easy Approach to Requirements Syntax; משם נוצר מסמך תכנון שמסתמך על בסיס הקוד הקיים ומכיל, בין השאר, תרשימי זרימת מידע וממשקי API; ולבסוף רשימת משימות מסודרת לפי תלות ומקושרת לדרישות המקוריות. ההכרזה, שכתבו ניקיל סוואמינתן, מוביל המוצר של Kiro, ודיפאק סינג, סגן נשיא ב-AWS, מציגה את התועלת של הגישה כך: "לפעמים עדיף לקחת צעד אחורה ולחשוב על ההחלטות", במקום להתחיל מקוד ולגלות בדיעבד אילו הנחות הניח המודל בזמן הבנייה. Kiro מוסיפה גם מנגנון בשם hooks, אוטומציות שרצות ברקע כשקובץ נשמר, נוצר או נמחק, למשל עדכון בדיקות כשרכיב משתנה, או סריקה לאיתור מפתחות גישה שדלפו לפני ביצוע commit.

ההבדל מ-Vibe Coding: סדר הפעולות, לא השימוש בסוכן

ההבדל המרכזי בין פיתוח מונחה מפרט לבין וייב קודינג (Vibe Coding) הוא סדר הפעולות, לא עצם השימוש בסוכן AI: בווייב קודינג המשתמש מתאר את המשימה בשיחה חופשית ומתקן תוך כדי דיאלוג, כשהקוד עצמו הוא התוצר הראשון שנראה; בפיתוח מונחה מפרט נכתב ומאושר קודם מסמך שמגדיר את ההתנהגות הנדרשת, והקוד נגזר ממנו רק בשלב מאוחר יותר. ההכרזה הרשמית של Kiro מתארת את Kiro כסביבה שטובה ב"וייב קודינג", אבל "הולכת הרבה מעבר לזה", ומציינת שהחוזק שלה הוא בהעברת אבי הטיפוס האלה למערכות ייצור. העמדה הזו, המשותפת ל-Kiro ול-Spec Kit, לא פוסלת וייב קודינג, אלא ממקמת אותו כשלב מתאים לאב טיפוס מהיר, לפני שפרויקט עובר לסביבת ייצור שדורשת תנאי קבלה כתובים ונבדקים.

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

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

קנה המידה, ולמה לא כל שינוי דורש מפרט מלא

ההיקף שאליו הגיעה הגישה ניכר במאגר הקוד הפתוח של Spec Kit ב-GitHub: נכון לבדיקה ב-22 באוקטובר 2026, יש למאגר כ-142 אלף כוכבים, ותיאור המאגר מציג אותו כ"ערכת כלים שעוזרת להתחיל עם SDD, או עם כל תהליך אחר". ה-README של הכלי מבהיר נקודה שלעיתים מוחמצת: שלושת התהליכים המוכנים שלו — פיתוח מונחה מפרט, אבחון ותיקון באג, והערכת רעיון — הם "נקודות כניסה עצמאיות, לא שלבים שחובה לעבור", ותיקון באג, למשל, לא מחייב לעבור קודם את תהליך המפרט המלא. במילים אחרות, פיתוח מונחה מפרט לא נועד להחליף כל שורת קוד קטנה בתהליך של מפרט מלא, אלא להציע מסלול כתוב ומאושר לפרויקטים ולתכונות שגדולים מספיק כדי שעלות הניחוש הסמוי תהיה גבוהה.