בפועל אני עובד עם workflow די פשוט של Spec-Driven Development. הרעיון פשוט: להוציא את הכוונה, ה-research, הארכיטקטורה וה-tickets מתוך הזיכרון של הצ'אט אל קבצים שאפשר לקרוא, לבדוק ולהעביר הלאה. עם הזמן ארזתי את החלקים החוזרים של הלולאה הזאת לתוך SDDRush.
איזו בעיה זה פותר
הכשל הישן עוד כאן. התוכנית חיה בצ'אט.
מרגיש מהיר ליום או יומיים. אחר כך המשימה נמשכת לעוד סשן, לעוד מהנדס או לעוד agent, והצורה של העבודה מתחילה לזוז.
מה נשבר קודם. הכוונה המקורית נמרחת. החלטות ארכיטקטורה מתקבלות בחתיכות. tickets מפסיקים לשקף את התוכנית האמיתית. handoff נשען על זיכרון ועל תקווה.
את זה אני מנסה להוריד.
מה זה SDD בפועל
הלולאה קומפקטית:
- כותבים project brief
- אוספים research ממוקד
- מקבעים החלטות ארכיטקטורה
- מסנכרנים backlog ל-tickets קונקרטיים
- מממשים מול ה-ticket הפתוח
- מעדכנים status וסוגרים מה שבאמת הושלם
אין פה משהו אקזוטי. זאת בדיוק הכוונה. אני לא מנסה להקים דת חדשה סביב delivery. אני רוצה trail בתוך הריפו שישרוד יותר משיחה אחת.
מה SDDRush נותן
SDDRush הוא ה-toolkit הקטן שבניתי סביב השיטה. לוקח את החלקים שנמאס לי להרים ביד.
sdd-init יוצר את ה-.sdd workspace ואת מבנה הקבצים הבסיסי. sdd-prompts מרנדר repo-aware prompts ממצב הפרויקט הנוכחי. sdd-backlog מסנכרן ומתחזק את backlog tickets. sdd-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 כשהריפו כבר באמת תואם את מה שתוכנן.
איפה Kotef נכנס
אם רוצים לדחוף את אותו workflow עוד צעד, Kotef הוא שכבת ה-agent שבניתי סביב אותן ideas. המשך שאפתני. לא הדבר שחייבים להתחיל ממנו.
Kotef יודע לאתחל SDD state עבור ריפו, לעבוד מול tickets והקשר קבצים במקום מפרומפט חשוף, להריץ לולאה של planner → researcher → coder → verifier → janitor, להחזיק runtime state, checkpoints ו-resume עבור משימות ארוכות יותר.
מעניין כשצריך coding and research agent עמיד לריפוז אמיתיים. הרעיון הבסיסי לא משתנה. לפני שנותנים ל-agent יותר חופש, העבודה צריכה מבנה.
מתי זה משתלם
אני ניגש לגישה הזאת כשיש במשימה יותר מהחלטה לא טריוויאלית אחת, כשההקשר של הריפו חשוב, כשהעבודה תימשך יותר מסשן אחד, כשמישהו אחר יצטרך לבדוק אחר כך מה קרה.
אם המשימה קטנה מדי וה-overhead יעלה יותר מהתועלת, לא משתמש בזה.
סומך על ה-workflow גם בעבודת benchmark שבה grounding, latency ו-telemetry חשובים באותו זמן. Agentic RAG Legal Challenge דוגמה עדכנית, מודדים מערכת שלמה לא prompt מוצלח אחד.
מה שעבד שם היה משמעת. דיפים קטנים עם lineage ברור. gates מפורשים על grounding ו-provenance. ענפים שנראו חכמים אבל החלישו את מסלול הראיות נקטעו מוקדם.
מה שלא עזר. להרחיב context בלי הבחנה. לשנות יותר מדי משתנים באותו ניסיון. לסמוך על תשובה שנשמעת נקייה יותר לפני שהמסלול שמאחוריה התייצב.
מה לא לעשות
- להפוך כל bugfix קטן לטקס
- להתחיל עם ה-agent כשהמשימה עוד מעורפלת
- להתייחס לתשובת מודל כאילו היא זיכרון פרויקט אמיתי
- לכתוב specs שנשמעים חכמים אבל לא מגבילים את המימוש
השיטה אמורה לצמצם ניחושים. אם היא בעיקר מייצרת paperwork יותר יפה, משהו השתבש.
ה-workflow עוזר כי הוא הופך את הכוונה ליותר inspectable, את ה-handoff ליותר נקי, ואת מצב ה-backlog לפחות דקורטיבי. SDDRush קיים כי אני עובד כך מספיק פעמים ורציתי להפסיק להקים את החלקים המשעממים ידנית. Kotef קיים כי לפעמים אני רוצה לאוטומט יותר מאותה לולאה בלי לזרוק את המבנה.