סקר של Sonar משנת 2026 מראה כי 88% מהמפתחים טוענים שקוד המיוצר על ידי בינה מלאכותית (AI) מגדיל את החוב הטכני, ותומכי הפיתוח מבוסס-המפרט (spec-driven development) טוענים כי שלב מפרט ממושמע יכול לעצור את הסטייה הזו.

למה הבעיה הזו חשובה

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

איך נראה פיתוח מבוסס-מפרט

פיתוח מבוסס-מפרט (SDD) הופך את הסדר הקיים. במקום לתת הנחיה (prompt) למודל AI באמצעות סיפור משתמש (user story) קצר, הצוות כותב מפרט מפורט הניתן להרצה על ידי סוכן (agent-executable) שחי באותה מערכת בקרת גרסאות כמו הקוד. המפרט הופך למקור האמת היחיד (single source of truth) – הוא מתעד את הכוונה, מקרי קצה, ציפיות ביצועים וכל אילוץ שמודל ה-AI חייב לכבד.

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

שינוי זרימת העבודה

Product backlog – שמרו על פריטים קצרים, המתעדים רק את הכוונה ואת קריטריוני הקבלה (acceptance criteria) ברמה גבוהה. רשימה זו ממשיכה להוביל את תהליך התעדוף.

Sprint planning – צוותים דנים במטרה הכוללת ומסכימים על מטרת ספרינט (Sprint Goal), אך הם נמנעים ממימוש מפורט עד שהמפרט מוכן.

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

Definition of Done – הוסיפו את "המפרט נסקר ואושר" לשער האיכות (quality gate). שום קוד אינו נחשב גמור עד שהמפרט עובר את אותם סטנדרטים של סקירה כמו המימוש.

התאמת Kanban – הכניסו שתי עמודות חדשות: "Spec Drafted" ו-"Spec Approved". פריטי עבודה זורמים כעת מ-backlog ← Sprint Goal ← Spec Drafted ← Spec Approved ← In Progress ← Done. השינוי הוויזואלי הזה הופך את שלב התיאום, שהיה בלתי נראה בעבר, למפורש.

כלים שכבר אוכפים מפרטים

פלטפורמות כמו GitHub Spec Kit ו-AWS Kiro הוסיפו "שערים" (gates) הדורשים מסמך דרישות לפני תחילת כל יצירת קוד על ידי AI. הן אינן מחליפות את מודל ה-AI; הן מתאימות סוכנים בעלי חשיבה מילולית (literal-minded) לכוונה האנושית. על ידי הפיכת המפרט לדרישת קדם, כלים אלו מבצעים אוטומציה של המעבר מבלי לשבור צינורות (pipelines) CI/CD קיימים.

התנגדות פוטנציאלית

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

חשש נוסף הוא שמפרטים עלולים להפוך למיושנים ככל שהדרישות מתפתחות. שילוב בקרת גרסאות פותר זאת: כל שינוי במפרט יוצר commit חדש, מפעיל סקירה ומאלץ את הצוות להעריך מחדש את הקוד הקשור. בפועל, התייחסות למפרטים כמו לקוד שומרת על תיעוד עדכני.

מה כדאי לעקוב אחריו בהמשך

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

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