להפסיק לכתוב תוכנה פעמיים: פיתוח מונחה מפרט וסוף השכתובים
מדוע תוכנה תמיד נכתבה פעמיים — פעם במפרטים, ושוב בקוד — ומדוע הכתיבה השנייה סוף סוף נעלמת.
בפיתוח תוכנה, כשעושים את זה נכון, אנחנו צריכים לכתוב תוכנה פעמיים: קודם, במפרטים מפורטים שמסבירים בדיוק מה התוכנה צריכה לעשות, ואחר כך שוב כקוד שמביא את המפרטים האלה לחיים. אבל הנה אמת קשה: לעיתים רחוקות עושים את זה נכון בפעם הראשונה.
התהליך נשבר לעיתים תכופות כי יצירת מפרטים ממוצים גוזלת זמן, וצוותים לעיתים רחוקות לוכדים את כל הפרטים הנחוצים מלפנים. זה מוביל לפערים, להנחות ולעבודה חוזרת יקרה. כתוצאה מכך, פרויקטי תוכנה חורגים לעיתים תכופות מהתקציב, מחמיצים מועדים ומשאירים את כולם מתוסכלים.
העלויות הנסתרות של כתיבת תוכנה פעמיים
כדי להבין מדוע כתיבת תוכנה פעמיים הכרחית אך לעיתים רחוקות נעשית היטב, נפרק את שני השלבים:
1. הכתיבה הראשונה: מפרטים בשפה טבעית
בפעם הראשונה שתוכנה נכתבת, אנחנו לא כותבים קוד בכלל. זו יצירה של דרישות, סיפורי משתמש ומסמכי עיצוב — כתובים בשפה טבעית. כאן צוותים מתארים איך התוכנה צריכה לתפקד, מה משתמשים יכולים לעשות, ואיזו חוויה זו צריכה להיות.
אבל הנה הבעיה: לאף צוות אין את הפריווילגיה לכתוב את כל הפרטים. מנהלי מוצר צריכים לעיתים תכופות למהר כדי לעמוד בלוחות זמנים אגרסיביים — בחלק מהפרויקטים אין בכלל מנהלי מוצר מקצועיים. הם משרטטים את הקווים הרחבים, אבל פיצ’רים ואינטראקציות מרכזיים מוחמצים. כפי שסטיב ג’ובס אמר במשפט מפורסם, “מוצרים גדולים נעשים מ־5,000 החלטות קטנות”, אבל ברוב הפרויקטים אנחנו לא מקבלים את ההחלטות האלה מלפנים. הן נשארות למפתחים לפרש אחר כך, וזה מוביל לשלב השני.
2. הכתיבה השנייה: תרגום מפרטים לקוד
ברגע שהמפרטים מועברים, מהנדסים אחראים להפוך את התיאורים האלה לקוד מתפקד. אבל כשה“כתיבה” הראשונה לא שלמה, מפתחים נאלצים להשתמש בדמיונם כדי למלא את החסר. הנחות מתקבלות, ולמרות שלמהנדסים אולי יש אחיזה טובה בטכנולוגיה, אולי אין להם את התמונה המלאה של חזון המוצר.
כאן הבעיות עולות לפני השטח:
- פרטים שהוחמצו מובילים לחיכוך: כשצוותי מוצר לא מפרטים פיצ’ר או מקרה שימוש חשוב, מפתחים צריכים לנחש או לאלתר. זה מוביל לעיתים תכופות לפונקציונליות שלא עומדת בציפיות.
- הנחות מובילות לעבודה חוזרת: כשמפתחים ממלאים את החסר, הם עשויים לבנות פיצ’רים בדרכים שלא מיושרות עם חזון המוצר, וזה גורם לעבודה חוזרת מסיבית בהמשך הפרויקט.
- הצבעת אצבעות הופכת בלתי נמנעת: כשמועדים נשמטים ותקציבים חורגים, צוותים מגלגלים אשמה. צוותי מוצר מאשימים את ההנדסה ב“לא להבין”, ומהנדסים מצביעים על המוצר בגלל מפרטים לא בהירים.
התוצאה היא מפל של בעיות שמובילות ללוחות זמנים שהוחמצו, לתקציבים שנחרגו ולתוצאות לא משביעות רצון. מחקר CHAOS של Standish Group עוקב שנים אחר העובדה שרוב פרויקטי התוכנה חורגים מהתקציב ומחמיצים את מועדי האספקה. מחקר של McKinsey עם אוניברסיטת אוקספורד מצא שפרויקטי IT גדולים חורגים בממוצע ב־45% מהתקציב וב־7% מהזמן, ומספקים 56% פחות ערך מהצפוי — ושב־17% מפרויקטי ה־IT הגדולים הדברים משתבשים עד כדי איום על עצם קיומה של החברה.
בבירור, משהו בתהליך הזה שבור.
לפרקטיקה יש שם עכשיו
התעשייה התיישבה על מונח לזה בזמן שרוב האנשים התווכחו על פרומפטים: פיתוח מונחה מפרט. כתבו קודם את הדרישות, את האילוצים ואת קריטריוני ההצלחה. התייחסו למפרט הזה כמקור האמת. תנו לסוכן לבנות מולו.
GitHub שילחה את Spec Kit. AWS שילחה את Kiro. BMAD-METHOD, OpenSpec ו־Tessl כולם ניסו את מזלם. מרטין פאולר כתב על זה. ההתכנסות הזאת אינה מקרית — זה מה שקורה כשקטגוריה שלמה מגלה את אותו אופן כשל באותו זמן.
ואופן הכשל הוא זה שתואר לעיל. כלים שמתחילים מפרומפט מדלגים על הכתיבה הראשונה לגמרי. הם הולכים ישר לשנייה, ומנחשים כל החלטה שהמפרט מעולם לא קיבל. וזה בסדר לדמו והרסני למוצר.
פיתוח מונחה מפרט לא מבטל את הכתיבה הראשונה. הוא הופך את הכתיבה הראשונה לזו היחידה שדורשת שיקול דעת אנושי.
הכתיבה הראשונה החדשה: מפרטים שאפשר באמת לסיים
הנה מה שמשתנה. הסיבה שאף אחד לא כתב מפרטים שלמים מעולם לא הייתה שהם לא רצו — היא שהעבודה הייתה איטית מדי כדי להצדיק אותה. שבועות של חקירה כדי להפיק מסמך שהתיישן במפגש הראשון עם הספרינט. אז צוותים כתבו את הקווים הרחבים והשאירו את 5,000 ההחלטות הקטנות להתגלות אחר כך, פרשנות אחת בכל פעם.
כשניסוח מפרט לוקח שעות במקום חודשים, החשבון מתהפך. אתם יכולים להרשות לעצמכם להיות ממוצים. דרישות פונקציונליות, עיצוב חזותי, מודל נתונים, מקרי קצה — נלכדים לפני שמישהו פותח עורך, וזולים מספיק כדי לעדכן כשאתם לומדים משהו.
החלק האחרון חשוב. מפרט שאי אפשר לעדכן בזול הופך לשקר ברגע שהמציאות מגיעה. זו אותה אינטואיציה שמאחורי בנייה API-first: קבלו את ההחלטות נושאות המשקל נכון לפני שמישהו כותב מסך, והשאר נובע מכך.
הכתיבה השנייה החדשה: ייצור קוד, לא תרגום
ברגע שהמפרט שלם, הכתיבה השנייה מפסיקה להיות בעיית תרגום. היא הופכת לבעיית ייצור. שפות סטנדרטיות — JavaScript, TypeScript, Python. מסגרות סטנדרטיות — React, Next.js. קוד אמיתי, בצורות שמהנדסים כבר מכירים, נגזר ממסמך שכבר קיבל כל החלטה.
ההבדל הוא לא שמפתחים עובדים מהר יותר. זה שהם מפסיקים לעשות את החלק שמעולם לא היה הנדסה — החזרה המכנית על החלטות שמישהו אחר כבר קיבל.
מה משתנה במורד הזרם
שלושה דברים משתנים בבת אחת:
- הכתיבה הראשונה מסתיימת: כשעבודת המפרט עולה שעות ולא חודשים, צוותים יכולים להרשות לעצמם לקבל את ההחלטות הקטנות מלפנים במקום לגלות אותן בסקירה.
- אף אחד לא ממלא את החסר: קוד שנוצר ממפרט שלם לא דורש שמישהו ינחש למה צוות המוצר התכוון. הניחוש תמיד היה המקום שממנו הפגמים באו.
- עבודה חוזרת מפסיקה להצטבר: כוונה ומימוש מתחילים מיושרים. מה שהיה פעם שכתוב הופך לעריכה במפרט.
עתיד כתיבת התוכנה: שפה טבעית
כל עוד מישהו שילח תוכנה, העבודה דרשה לכתוב אותה פעמיים: פעם בשפה טבעית, שוב בקוד. הכתיבה השנייה הזאת מעולם לא הייתה החלק בעל הערך. היא הייתה האגרה ששילמנו כי לא הייתה דרך אחרת.
זה המהלך שהדור הבא של בוני יישומי הבינה המלאכותית מסודר סביבו: בהירות לפני קוד. תארו את היישום כשרטוט, קבלו את הארכיטקטורה נכון, תנו לקוד להיווצר מולה. לא קיצור דרך שעוקף את עבודת ההגדרה — סיבה לעשות אותה סוף סוף כראוי.
יש דרך אחרת עכשיו. תוכנה תמיד הייתה אמורה להיכתב פעם אחת.
קריאה נוספת
המדריך המלא לפרקטיקה: פיתוח מונחה מפרט. מדוע דור הפרומפט־ראשון דילג על השלב הזה מכוסה בvibe coding הפר את הבטחתו, ומה מחליף אותו במה בא אחרי vibe coding.
שאלות נפוצות
מהו פיתוח מונחה מפרט? פיתוח מונחה מפרט אומר לכתוב את הדרישות, האילוצים וקריטריוני ההצלחה לפני שנוצר קוד, ולהתייחס למפרט הזה כמקור האמת שהסוכן בונה מולו. הוא צמח ב־2025 כתגובה ישירה לתהליכי עבודה שמתחילים מפרומפט ומדלגים על שלב ההגדרה לגמרי.
במה פיתוח מונחה מפרט שונה מכתיבת מסמך דרישות מסורתי? המסמך הוא אותו רעיון; הכלכלה שונה. מפרטים מסורתיים היו יקרים מספיק כדי שצוותים יכתבו את הקווים הרחבים ויגלו את השאר בסקירת קוד. כשמפרט לוקח שעות במקום חודשים ואפשר לעדכן אותו בזול, שווה לסיים אותו — ושווה לשמור אותו מעודכן.
אילו כלים תומכים בפיתוח מונחה מפרט? GitHub Spec Kit, AWS Kiro, BMAD-METHOD, OpenSpec ו־Tessl הם המימושים הנקובים בשם, ו־Cursor תומך בגרסה קלה יותר דרך קובצי כללים. הם נבדלים בעיקר בהידוק הקישור בין המפרט ובין הקוד — אם הוא מניע ייצור פעם אחת, מתפתח לצד הקוד, או שהוא החפץ היחיד שאתם עורכים.
האם פיתוח מונחה מפרט מאט צוותים? הוא מעביר את העבודה, הוא לא מוסיף אותה. ההחלטות שנלכדות במפרט הן החלטות שמישהו מקבל בכל מקרה — או במכוון מלפנים, או במשתמע על ידי מפתח או מודל שמנחש אחר כך. הנתיב השני הוא המקום שממנו עבודה חוזרת באה.
מה קורה למפתחים אם קוד נוצר ממפרטים? החזרה המכנית על החלטות של מישהו אחר נעלמת. שיקול דעת לגבי ארכיטקטורה, פשרות, נכונות ומה לא לבנות לא נעלם. אלה תמיד היו החלקים שדרשו מהנדס.
