בפועל אני עובד עם workflow די פשוט של Spec-Driven Development. הרעיון פשוט: להוציא את הכוונה, ה-research, הארכיטקטורה וה-tickets מתוך הזיכרון של הצ'אט אל קבצים שאפשר לקרוא, לבדוק ולהעביר הלאה. עם הזמן ארזתי את החלקים החוזרים של הלולאה הזאת לתוך SDDRush.
1. איזו בעיה זה פותר
הכשל הישן עוד כאן: התוכנית חיה בעיקר בתוך הצ'אט.
זה מרגיש מהיר ליום או יומיים. אחר כך המשימה נמשכת לעוד סשן, לעוד מהנדס או לעוד agent, והצורה של העבודה מתחילה לזוז.
מה בדרך כלל נשבר קודם:
- הכוונה המקורית נמרחת
- החלטות ארכיטקטורה מתקבלות בחתיכות
- tickets מפסיקים לשקף את התוכנית האמיתית
- handoff מתחיל להישען על זיכרון ועל תקווה
את זה בדיוק אני מנסה להוריד.
2. מה זה SDD בפועל
בפועל הלולאה די קומפקטית:
- כותבים project brief
- אוספים research ממוקד
- מקבעים החלטות ארכיטקטורה
- מסנכרנים backlog ל-tickets קונקרטיים
- מממשים מול ה-ticket הפתוח
- מעדכנים status וסוגרים מה שבאמת הושלם
אין פה משהו אקזוטי. זאת בדיוק הכוונה. אני לא מנסה להקים דת חדשה סביב delivery. אני רוצה trail בתוך הריפו שישרוד יותר משיחה אחת.
3. מה SDDRush נותן בפועל
SDDRush הוא ה-toolkit הקטן שבניתי סביב השיטה הזאת.
הוא לוקח את החלקים שנמאס לי להרים כל פעם מחדש ביד:
sdd-initיוצר את ה-.sddworkspace ואת מבנה הקבצים הבסיסיsdd-promptsמרנדר repo-aware prompts ממצב הפרויקט הנוכחיsdd-backlogמסנכרן ומתחזק את backlog ticketssdd-statusנותן תמונה קצרה של מה עוד פתוח ומה כבר זז קדימה
לרבה משימות זה כבר מספיק. אם ההקשר של הריפו חשוב, אם העבודה נמשכת יותר מסשן אחד, ואם לא בא לך שה-brief יתפרק לפולקלור, ה-scaffold הזה עוזר.
Quick start
bash bin/sdd-init /path/to/project --stack "Python/FastAPI" --domain "legal"
python bin/sdd-prompts /path/to/project
python bin/sdd-backlog sync /path/to/project
python bin/sdd-status /path/to/project
משם ממלאים את קבצי ה-.sdd, מממשים מול backlog/open, ואז מריצים janitor/status כשהריפו כבר באמת תואם את מה שתוכנן.
4. איפה Kotef נכנס
אם רוצים לדחוף את אותו workflow עוד צעד קדימה, Kotef הוא שכבת ה-agent שבניתי סביב אותן ideas.
אבל הייתי מציג אותו כהמשך שאפתני יותר, לא כדבר שחייבים להתחיל ממנו.
Kotef יודע:
- לאתחל SDD state עבור ריפו
- לעבוד מול tickets והקשר קבצים במקום מפרומפט חשוף
- להריץ לולאה של planner -> researcher -> coder -> verifier -> janitor
- להחזיק runtime state, checkpoints ו-resume עבור משימות ארוכות יותר
זה הופך אותו למעניין כשצריך coding and research agent עמיד לריפוז אמיתיים. אבל הרעיון הבסיסי לא משתנה: לפני שנותנים ל-agent יותר חופש, העבודה צריכה מבנה.
5. מתי זה משתלם
אני ניגש לגישה הזאת כש:
- יש במשימה יותר מהחלטה לא טריוויאלית אחת
- ההקשר של הריפו באמת חשוב
- העבודה תימשך יותר מסשן אחד
- מישהו אחר עוד יצטרך לבדוק אחר כך מה קרה
אם המשימה קטנה מדי וה-overhead יעלה יותר מהתועלת, אני לא משתמש בזה.
אני סומך על ה-workflow הזה גם בעבודת benchmark שבה grounding, latency ו-telemetry חשובים באותו זמן. דוגמה עדכנית היא Agentic RAG Legal Challenge, שבו לא מודדים prompt מוצלח אחד אלא מערכת שלמה.
מה שעבד שם טוב לא היה דרמה אלא משמעת:
- דיפים קטנים עם lineage ברור
- gates מפורשים על grounding, latency ו-provenance
- להרוג מהר branches שנראו חכמים אבל החלישו את מסלול הראיות
מה שלא עזר היה להרחיב context בלי הבחנה, לשנות יותר מדי משתנים באותו ניסיון, או לסמוך על תשובה שנשמעת נקייה יותר לפני שהמסלול שמאחוריה התייצב.
6. מה לא לעשות
הטעויות כאן די צפויות:
- להפוך כל bugfix קטן לטקס
- להתחיל עם ה-agent כשהמשימה עצמה עוד מעורפלת
- להתייחס לתשובת מודל כאילו היא זיכרון פרויקט אמיתי
- לכתוב specs שנשמעים חכמים אבל לא באמת מגבילים את המימוש
השיטה אמורה לצמצם ניחושים. אם היא בעיקר מייצרת paperwork יותר יפה, משהו השתבש.
7. סיכום
ה-workflow הזה עוזר כי הוא הופך את הכוונה ליותר inspectable, את ה-handoff ליותר נקי, ואת מצב ה-backlog לפחות דקורטיבי. SDDRush קיים כי אני עובד כך מספיק פעמים ורציתי להפסיק להקים את החלקים המשעממים ידנית. Kotef קיים כי לפעמים אני רוצה לאוטומט יותר מאותה לולאה, בלי לזרוק את המבנה בדרך.