פיתוח מונחה-מפרט לא פתר את הבעיה האמיתית
פיתוח מונחה-מפרט (SDD) הוא התשובה החדשה לסוגיית כתיבת הקוד השגוי על ידי סוכני AI.
זרימת העבודה היא פשוטה. אתם כותבים מפרט מובנה. סוכן מבצע את התוכנית. אתם סוקרים את התוצאה. כלים כמו GitHub Spec Kit, OpenSpec ו-Kiro מובילים את השינוי הזה.
הגישה הזו עובדת טוב יותר מ-prompting גולמי. אך יש לה פגם עצום.
היא מסתמכת על כך שהמפרט יישאר מקור האמת. זה שקר.
במשך 20 שנה, ניסינו לשמור על סנכרון בין התיעוד לקוד. מסמכי עיצוב, wikis ו-READMEs – כולם נכשלו. למה? כי עריכת קוד היא מהירה ומספקת ערך. עריכת מסמך היא איטית ולא מספקת דבר נראה לעין. התיעוד תמיד מפסיד בפני המהירות.
SDD מתמודד עם אותה בעיה.
סוכן נתקל במגבלה. הוא מתקן את הקוד כדי לגרום לו לעבוד. כעת הקוד והמפרט אינם תואמים. המפרט הופך לחסר תועלת תוך ימים ספורים. רוב המסגרות אומרות לכם להשתמש ב"משמעת" כדי לתקן זאת. המשמעת אכזבה אותנו בכל פעם מחדש בעבר.
כתיבת מפרט מלא לפני כתיבת הקוד מניחה שלא תלמדו דבר במהלך היישום. זה שובר את לולאת המשוב. זה הופך פיתוח אג'ילי לתהליך כבד ומקדים.
מפתח אחד ניהל פרויקט שנמשך מספר חודשים באמצעות SDD. הסוכן פעל לפי כל מפרט בצורה מושלמת. המערכת עדיין נכשלה. המפרט לא הצליח ללכוד את הידע שמופיע רק במהלך הבנייה. שינוי תשתיתי קטן אחד שבר את כל גרף המפרט.
צוות אחר ניסה SDD ומצא שהוא איטי פי 10. הייתה להם יותר טקסים (ceremony) אך אותו מספר של באגים.
המטרה לא צריכה להיות יותר מסמכים.
הבעיה האמיתית היא איך לשמור על המפרטים חיים. אנחנו צריכים מפרטים שמתעדכנים בעצמם. אנחנו צריכים כלים שמסיקים את המפרט מהקוד ומהמערכת הפועלת. זה צריך לעבוד כמו lockfile. זה חייב להיות אוטומטי.
אני לא בטוח אם זה אפשרי עדיין. אני רוצה לשמוע מאנשים שבונים בסביבת ייצור (production).
- האם המפרט שלכם שורד מעבר לשבוע השלישי?
- כשנוצרת סטייה (drift), מה גורם לשבירה?
- האם ניסיתם לייצר מפרטים מקוד או מטלמטריה?
- האם הקפדנות מוסיפה ערך או רק טקסים?
קהילת למידה אופציונלית: https://t.me/GyaanSetuAi