Spec-Driven Development — בניית תוכנה מתוך Specification

מאת צוות מדיה דיל · 09.08.2026 · Technology · 7 דק׳

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

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

למה זה הפך רלוונטי במיוחד עכשיו

Spec-driven development כרעיון לא חדש - תעשיית התוכנה מכירה אותו עשורים תחת שמות שונים (waterfall, design docs, RFC processes). מה שהשתנה הוא ההקשר: כשמפתח אנושי כותב קוד, הוא מביא איתו הבנה מובלעת עצומה - קונטקסט עסקי, ניסיון קודם, יכולת "לשאול שאלה טובה" כשמשהו לא ברור. סוכן קוד אוטונומי לא מביא את זה - הוא מתחיל כל משימה בלי הקשר מובלע, ולכן איכות הפלט תלויה הרבה יותר באיכות הקלט. Spec מדויק הוא בעצם הדרך להעביר לסוכן AI את ההקשר שמפתח אנושי היה סופג מעצמו לאורך זמן בצוות.

מה כולל Spec טוב

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

הגדרת בעיה - מה בדיוק המצב הנוכחי, ומה לא עובד בו. לא "מה לבנות" אלא "למה בכלל צריך את זה".
דרישות פונקציונליות מדויקות - לא "תמיכה בהנחות" אלא "הנחה של X% מוחלת על סכום העגלה לפני מע"מ, ללקוחות עם tier=VIP, לא ניתנת לשילוב עם קופון אחר".
תרחישי קצה מפורשים - מה קורה כשאין מלאי, כשהמשתמש לא מחובר, כשקלט לא תקין. ככל שתרחישי הקצה מפורטים יותר מראש, פחות ניחושים נדרשים בזמן הכתיבה.
קריטריוני קבלה (Acceptance Criteria) - איך יודעים שהמימוש נכון, בדרך כלל מנוסח כרשימת תנאים בדיקים - כמעט תרגום ישיר לבדיקות אוטומטיות.
מה במפורש מחוץ לתחום (Out of Scope) - חשוב לא פחות מהדרישות עצמן, כדי למנוע scope creep או פירוש רחב מדי.

Spec כחוזה בין אדם ל-AI

ההבדל המהותי בין Spec לתיאור חופשי הוא שה-Spec הופך למקור אמת יחיד (single source of truth) שגם בן אדם וגם סוכן AI יכולים "להסכים" עליו לפני שהעבודה מתחילה. כשסוכן קוד מקבל spec מדויק, הוא לא רק כותב קוד - הוא יכול לגזור ממנו ישירות בדיקות (ראו סוכני בדיקות), ולבדוק את עצמו מול קריטריוני הקבלה בשלב ה-Verify של לולאת התכנון. זה הופך את מחזור העבודה למדיד באופן אובייקטיבי: "האם המימוש עומד בכל הסעיפים ב-Spec" הוא שאלה שאפשר לענות עליה בבדיקה אוטומטית, בעוד "האם המימוש טוב" היא שאלה עמומה שקשה לבדוק.

## Spec: הנחת VIP בעגלת קניות

### דרישה
לקוח עם customer.tier === "VIP" מקבל הנחה של 10%
על סכום הביניים (subtotal) לפני מע"מ ומשלוח.

### תרחישי קצה
- לקוח VIP עם קופון פעיל: ההנחות לא מצטברות, מוחל הגבוה מביניהן
- subtotal = 0: אין הנחה להחיל, אין שגיאה
- tier משתנה תוך כדי סשן: ההנחה מחושבת לפי הערך בזמן ה-checkout

### קריטריוני קבלה
- [ ] VIP + subtotal=100 => discount=10
- [ ] non-VIP + subtotal=100 => discount=0
- [ ] VIP + coupon(15%) => discount=15 (הגבוה מביניהם)

מאיפה Spec נולד - Requirement Extraction

בפועל, מפרט מדויק לא צץ יש מאין - הוא נגזר משיחה, טיקט, או דרישת מוצר עמומה. חלק מתהליכי Spec-Driven Development המתקדמים משתמשים ב-AI כבר בשלב הזה: מודל שמנתח את הבקשה המקורית ומייצר טיוטת Spec ראשונה, כולל שאלות הבהרה מפורשות שמוצגות לבעל הדרישה לפני שהעבודה מתחילה - בדיוק כמו שhuman-in-the-loop עובד בהקשרים אחרים. זה הופך את שלב "השאלות המבהירות" מתהליך אד-הוק שתלוי בזיכרון ובניסיון של המפתח, לשלב מובנה וחוזר בתהליך העבודה.

Spec כמנגנון סינון קלט לפני שהסוכן בכלל מתחיל

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

Trade-off: פורמליות מול מהירות

יש מתח אמיתי בין Spec מפורט ומדויק לבין מהירות פיתוח. כתיבת Spec מלא לכל תכונה קטנה היא בזבוז - overhead שלא משתלם למשימה של חצי שעה. הכלל המעשי: ככל שהמשימה גדולה, מורכבת, או קריטית יותר (למשל נוגעת בתשלומים או הרשאות), כך ה-Spec הפורמלי משתלם יותר. שינוי טריוויאלי - תיקון טעות כתיב, שינוי צבע כפתור - לא צריך Spec בכלל. תכונה חדשה שמערבת כמה מודולים ולוגיקה עסקית לא-טריוויאלית כן. ארגונים בוגרים מגדירים ספי כניסה ברורים - למשל, כל PR שמשנה יותר מ-200 שורות או נוגע בקוד תשלומים דורש Spec מאושר לפני תחילת עבודה.

Spec ל-AI לעומת Spec לבן אדם - מה שונה

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

שילוב עם ה-SDLC הרחב

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

דוגמה מהשטח: מה קורה בלי Spec מול עם Spec

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

Spec כתשתית לתכנון הסוכן

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

טעויות נפוצות

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

שאלות נפוצות

האם Spec-Driven Development מתאים גם לצוותים קטנים?

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

מי כותב את ה-Spec - מוצר, פיתוח, או AI?

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

מה הקשר בין Spec-Driven Development ל-Test-Driven Development?

קרוב מאוד - קריטריוני הקבלה ב-Spec הם למעשה תיאור ברמה גבוהה של הבדיקות שיאמתו את המימוש. TDD הוא בעצם המימוש הקוד-רמה של אותו עיקרון.

איך יודעים מתי ה-Spec "מספיק טוב" כדי להתחיל לכתוב קוד?

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

מה עושים כשמגלים באמצע הפיתוח שה-Spec חסר משהו?

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

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

תגיות: Spec-Driven Development · Specification · Requirements · Acceptance Criteria · AI Agents · SDLC · Software Engineering

← חזרה לבלוג · צור קשר