פיתוח מונחה מפרט: הפרקטיקה שהקטגוריה התכנסה אליה
כל כלי קידוד בינה מלאכותית רציני שילח את אותו פיצ’ר בטווח של כשנה זה מזה — וזה כמעט לעולם לא קורה במקרה.
ב־2025 השאלה המעניינת הייתה כמה טובים המודלים נעשים. ב־2026 השאלה המעניינת היא מה אתם מוסרים להם.
GitHub שילחה את Spec Kit. AWS שילחה את Kiro, סביבת פיתוח שנבנתה סביב הרעיון. BMAD-METHOD, OpenSpec ו־Tessl כל אחד ניסה את מזלו. Cursor הגיע לשם דרך קובצי כללים. מרטין פאולר פרסם השוואה של המימושים. כששישה צוותים עצמאיים מתכנסים לאותה תשובה בתוך שנים־עשר חודשים, הם לא מעתיקים זה מזה. כולם נחבטים באותו קיר.
לקיר יש שם עכשיו. גם לתיקון.
מהו פיתוח מונחה מפרט בפועל
כתבו את הדרישות, את האילוצים ואת קריטריוני ההצלחה לפני שנוצר קוד. התייחסו למסמך הזה כמקור האמת. תנו לסוכן לבנות מולו.
זה הכול. זה לא רעיון חדש — זו הנדסת דרישות, שהתעשייה עשתה גרוע במשך שלושים שנה ואז נטשה במידה רבה כאיטית מדי. מה שהשתנה הוא לא הרעיון. זו הכלכלה.
מפרטים היו פעם יקרים לכתוב ויקרים לשמור מעודכנים, ומשמעות הדבר הייתה שרוב הצוותים כתבו את הקווים הרחבים וגילו את כל השאר בסקירת קוד. זו הייתה פשרה רציונלית כשלמפתח לקח שלושה שבועות לבנות את הפיצ’ר בכל מקרה. היא הפסיקה להיות רציונלית כשהייצור נעשה מהיר, כי עכשיו המפרט הוא החלק האיטי — והחלק האיטי הוא המקום שכל שיקול הדעת מתגורר בו.
אופן הכשל שנגדו הוא הומצא
כלים שמתחילים מפרומפט מדלגים על המפרט לגמרי. אתם מתארים תוצאה, הכלי מפיק משהו שדומה לה, וכל החלטה שהתיאור לא כיסה מתקבלת בשקט על ידי המחולל.
אילו החלטות? אלה שמסתבר שחשובות. אם כתובת דואר אלקטרוני היא ייחודית, וייחודית ביחס למה. מה חשבון מבוטל עדיין יכול לראות. מה קורה כששני אנשים עורכים את אותה רשומה. אם הרשימה הזאת צריכה עימוד לפני שיהיו בה עשרת אלפים שורות.
אף אחד לא שאל את השאלות האלה, ולכן אף אחד לא ענה עליהן — אבל ליישום יש תשובה לכל אחת מהן, שנבחרה בהסקה מהקשר שמעולם לא כלל את העסק שלכם.
אותה דינמיקה מופיעה בכל כלי שמדלג על שלב ההגדרה. זה המנגנון שמאחורי בעיית ה־70%: ההתקדמות נעצרת לא כי העבודה שנשארה קשה, אלא כי היא חסומה על ידי החלטה ארכיטקטונית שהתקבלה במשתמע, מאות גנרציות קודם לכן, ושאי אפשר לשנות עוד בלי לפרק את המערכת.
הנתונים על מה שקורה בלעדיו
דוח State of AI-assisted Software Development של DORA ל־2025 הוא הקריאה הבהירה ביותר שזמינה. 90% מאנשי המקצוע בטכנולוגיה משתמשים כיום בבינה מלאכותית בעבודה ויותר מ־80% מאמינים שהיא הגדילה את הפרודוקטיביות שלהם. ואימוץ גבוה יותר של בינה מלאכותית מקושר לעלייה בתפוקת אספקת התוכנה וגם לעלייה באי־יציבות אספקת התוכנה, בבת אחת.
מהירים יותר בשילוח. גרועים יותר בשמירה על דברים עובדים. שניהם, יחד.
הניתוח של GitClear ל־2026 על 623 מיליון שינויי קוד מראה את צורת הנזק. מול קו בסיס של 2023: בלוקי קוד משוכפלים עלו ב־81%, העתק/הדבק בתוך קומיט טיפס מ־9.4% ב־2022 ל־15.7% במחצית הראשונה של 2026, מבנים שמסתירים שגיאות עלו ב־47%. במקביל קריאות פונקציה בין־קבצים — הפרוקסי הזמין הטוב ביותר לשימוש חוזר בקוד — ירדו ב־35%, ופעילות השכתוב קרסה מ־21% מהשינויים ב־2022 ל־3.8% ב־2026.
הסיכוי שמפתחים יעתיקו וידביקו כיום גדול בפי חמישה בקירוב מהסיכוי שישכתבו. ב־2022 היחס הזה רץ בכיוון ההפוך.
שום דבר מזה הוא לא בעיה של איכות מודל. זה מה שקורה כשייצור זול ומבנה הוא לא התפקיד המוצהר של אף אחד.
שלוש דרגות המחויבות
לא כולם מתכוונים לאותו דבר כשהם אומרים את זה, וההבדלים חשובים בפועל. המסגור של מרטין פאולר הוא הנקי ביותר שראיתי.
מפרט־ראשון. אתם כותבים את המפרט, מייצרים ממנו, ואחר כך מתחזקים את הקוד ביד. המפרט מניע את הבנייה ההתחלתית ואחר כך הופך בהדרגה להיסטורי. הקל ביותר לאמץ, ההבטחות החלשות ביותר — חצי שנה אחר כך, המסמך מתאר מערכת שכבר לא קיימת.
מפרט־מעוגן. המפרט והקוד מתפתחים יחד. שנו את המפרט, ייצרו מחדש את החלקים המושפעים, שמרו על שניהם מעודכנים. יותר משמעת, והתמורה היא שהמסמך נשאר מהימן.
מפרט־כמקור. המפרט הוא החפץ היחיד שאתם עורכים. קוד הוא תוצר, באופן שבו קובץ בינארי מקומפל הוא תוצר — אתם לא מטליאים אותו ביד. ההבטחות החזקות ביותר, והקפיצה הגדולה ביותר באופן שבו צוות עובד.
רוב הצוותים שקוראים לעצמם מונחי מפרט עושים מפרט־ראשון. זה שיפור אמיתי לעומת פרומפט בעיניים עצומות, וזו גם הגרסה שנשחקת בשקט.
מה שייך למפרט
הבדיקה השימושית: אם המחולל היה צריך לנחש, זה שייך למסמך.
- מודל הנתונים. ישויות, קשרים, עוצמות, מה הופך רשומה לייחודית, מה קורה במחיקה. זו החטיבה בעלת הערך הגבוה ביותר וזו שמדולגת לרוב.
- סוגי משתמשים והרשאות. מי קיים, מה כל אחד יכול לראות ולעשות, מה קורה בגבולות.
- האינווריאנטים. כללים שאסור להפר לעולם, מנוסחים בפשטות. לא “טפל בשגיאות בחן” — זו משאלה, לא אילוץ.
- קריטריוני הצלחה. איך תדעו שהדבר עובד, במונחים ספציפיים מספיק כדי שמחלוקת על השאלה אם הוא עובד תהיה ניתנת ליישוב.
מה שלא שייך: פרטי מימוש שהמחולל טוב יותר בבחירתם מכם. מפרט שנוקב בשמות משתנים הוא לא מפרט, הוא קוד עם כלים גרועים יותר.
החלק שכולם טועים בו
מפרט עוזר רק אם הוא אכיף במקום אחר מלבד בפרוזה.
אם אילוץ חי רק במסמך, הוא הצעה. המחולל קרא אותו פעם אחת ואולי כיבד אותו ואולי לא בקובץ הארבעה־עשר שנגע בו. אילוצים צריכים להגיע למקום שהמערכת בודקת: not-null ו־unique בבסיס הנתונים ולא במטפל טפסים, טיפוסים בגבולות ולא בהערה, הרשאות כמדיניות שהמערכת מעריכה ולא כתנאי שמישהו זכר לכתוב.
זה ההבדל בין פיתוח מונחה מפרט כפרקטיקה ובין פיתוח מונחה מפרט כסוגה של מסמך. המסמך הוא איך אתם מחליטים. האכיפה היא איך אתם שומרים את ההחלטה.
איך לדעת אם אתם באמת עושים את זה
ארבע שאלות, והן לא נוחות במכוון.
- כשמשהו נשבר, אתם מתקנים את הקוד או את המפרט? אם התשובה היא תמיד הקוד, אתם מפרט־ראשון במקרה הטוב והמסמך כבר מיושן.
- האם אדם חדש יכול לקרוא את המפרט ולחזות איך המערכת מתנהגת? אם הוא יצטרך לקרוא את הקוד כדי לדעת, המפרט הוא תקציר ולא מקור.
- האם יש במפרט משהו שהמערכת לא יכולה להפר? אם כל כלל הוא פרוזה, אף אחד מהם לא מובטח.
- אתם סוקרים את המפרט או את ההפרש? לסקור אלפי שורות של קוד שנוצר זה תיאטרון. התווכחו על המסמך בזמן שהוויכוח עדיין זול.
איפה זה משאיר את הכלים
רוב המימושים הנוכחיים הם מונחי מפרט עבור ייצור קוד באופן ספציפי. הם מפיקים מפרט ומייצרים מימוש מולו, והחפץ שהם פועלים עליו הוא בסיס קוד.
הגרסה הקשה יותר מרחיבה את אותה לוגיקה לכל היישום — מודל הנתונים, משטח ה־API, גבול האימות, הממשק — כך שהמפרט מכסה לא רק מה הקוד עושה אלא מה המערכת היא. זה מה ששלב השרטוט של Archie הוא, וזו הסיבה שאני מתאר אותו כפיתוח מונחה מפרט שמוחל על המקבץ המלא ולא על מאגר. היקף שונה, אותו עיקרון: להגדיר לפני שמייצרים.
אנשים סבירים חולקים על עד כמה להרחיק את זה. אף אדם רציני לא טוען שצריך לחזור אחורה.
מה זה עולה
הקדמת שיקול הדעת איטית יותר בשבוע הראשון של פרויקט ומהירה יותר בכל שבוע לאחר מכן. העלות הזאת אמיתית והיא משולמת בדיוק ברגע שבו המומנטום מרגיש בעל הערך הרב ביותר, בזמן שמתחרה משלח משהו נראה. יהיו ספרינטים שבהם הצוות שדילג על זה נראה כמנצח.
המשמעת גם נשחקת. לכתוב אילוצים פחות מהנה מלראות ממשק מופיע, ולסקור מסמך פחות מספק מלסקור קוד. ההרגלים האלה נשחקים תחת לחץ מועדים, וזה בדיוק הלחץ שהופך אותם לחשובים.
וזה באמת לא חל על הכול. אם אתם מאמתים רעיון בסוף השבוע הזה ומתכוונים לזרוק את התוצאה, זרקו אותה. שום דבר מזה לא שווה עשייה עבור תוכנה עם תוחלת חיים של יומיים.
הסיבה שזה נדבק
כל ניסיון קודם לגרום לצוותים לכתוב מפרטים קודם נכשל, והוא נכשל מסיבה טובה: המפרט היה עומס מעל העבודה האמיתית. כתבתם את המסמך ואחר כך עוד היה עליכם לבנות את הדבר.
זו כבר לא הפשרה. עכשיו המסמך הוא רוב העבודה, והבנייה היא החלק הזול. שישה צוותים עצמאיים שמו לב לזה בטווח של שנה זה מזה כי זו הייתה התוצאה המובנת מאליה של המודל שנעשה טוב.
הפרקטיקה לא ניצחה בוויכוח. הכלכלה זזה מתחתיה.
קריאה נוספת
האבחנה המקורית: vibe coding הפר את הבטחתו. לאן הקטגוריה הלכה אחר כך: מה בא אחרי vibe coding. אותו טיעון שמוחל על מערכות שלמות: תכנון תוכנה AI-first מן היסוד. והמסגור הוותיק יותר של אותו רעיון: להפסיק לכתוב תוכנה פעמיים.
שאלות נפוצות
מהו פיתוח מונחה מפרט? כתיבת הדרישות, האילוצים וקריטריוני ההצלחה לפני שנוצר קוד, והתייחסות למפרט הזה כמקור האמת שסוכן הבינה המלאכותית בונה מולו. הוא צמח ב־2025 וב־2026 כתגובה ישירה לתהליכי עבודה שמתחילים מפרומפט ומדלגים על שלב ההגדרה.
במה זה שונה ממסמכי דרישות מסורתיים? הרעיון זהה; הכלכלה לא. מפרטים מסורתיים היו יקרים מספיק כדי שצוותים יכתבו את הקווים הרחבים ויגלו את השאר במהלך המימוש. כשניסוח אחד לוקח שעות במקום חודשים ואפשר לעדכן אותו בזול, שווה לסיים אותו ושווה לשמור אותו מעודכן.
אילו כלים תומכים בפיתוח מונחה מפרט? GitHub Spec Kit, AWS Kiro, BMAD-METHOD, OpenSpec ו־Tessl הם המימושים הנקובים בשם, ו־Cursor תומך בגרסה קלה יותר דרך קובצי כללים. הם נבדלים בעיקר בהידוק הקישור בין המפרט ובין הקוד — אם הוא מניע ייצור פעם אחת, מתפתח לצידו, או שהוא החפץ היחיד שאתם עורכים.
מהן שלוש דרגות הפיתוח מונחה המפרט? מפרט־ראשון, שבו המפרט מניע את הבנייה ההתחלתית ואתם מתחזקים את הקוד ביד. מפרט־מעוגן, שבו המפרט והקוד מתפתחים יחד. מפרט־כמקור, שבו המפרט הוא הדבר היחיד שאתם עורכים והקוד נחשב לתוצר. רוב הצוותים שמתרגלים את זה עושים מפרט־ראשון.
האם פיתוח מונחה מפרט מאט צוותים? הוא מעביר את העבודה ולא מוסיף אותה. ההחלטות שבמפרט מתקבלות או במכוון מלפנים או במשתמע על ידי מחולל שמנחש אחר כך, והנתיב השני הוא המקום שממנו עבודה חוזרת באה. הוא איטי יותר בשבוע הראשון ומהיר יותר לאחר מכן.
מה צריך להיכנס למפרט? כל מה שהמחולל היה צריך אחרת לנחש: מודל הנתונים עם קשרים וכללי ייחודיות, סוגי משתמשים והרשאות, אינווריאנטים שאסור להפר לעולם, וקריטריוני הצלחה ספציפיים מספיק כדי ליישב מחלוקת. השאירו בחוץ פרטי מימוש שהמחולל בוחר טוב יותר מכם.
האם פיתוח מונחה מפרט זהה לתכנון AI-first? פיתוח מונחה מפרט הוא הפרקטיקה של הגדרה לפני ייצור. תכנון AI-first הוא המערך הרחב יותר של ההשלכות הארכיטקטוניות, שמכסה גם את המקום שבו אילוצים נאכפים, את הסדר שבו אתם מקבלים החלטות, ואת התכנון לצרכנים סוכניים לצד אנושיים.
