הערה
איך אני משתמש ב-workflow קל של Spec-Driven Development בפרויקטים אמיתיים, מה SDDRush עושה בפועל, ואיפה Kotef נכנס אם רוצים שכבת agent חזקה יותר.
בפועל אני עובד עם workflow די פשוט של Spec-Driven Development. הרעיון פשוט: להוציא את הכוונה, ה-research, הארכיטקטורה וה-tickets מתוך הזיכרון של הצ'אט אל קבצים שאפשר לקרוא, לבדוק ולהעביר הלאה. עם הזמן ארזתי את החלקים החוזרים של הלולאה הזאת לתוך SDDRush.
הלולאה בקיצור
הכשל הישן עוד כאן. התוכנית חיה בצ'אט.
מרגיש מהיר ליום או יומיים. אחר כך המשימה נמשכת לעוד סשן, לעוד מהנדס או לעוד agent, והצורה של העבודה מתחילה לזוז.
מה נשבר קודם. הכוונה המקורית נמרחת. החלטות ארכיטקטורה מתקבלות בחתיכות. tickets מפסיקים לשקף את התוכנית האמיתית. handoff נשען על זיכרון ועל תקווה.
את זה אני מנסה להוריד.
הלולאה קומפקטית:
אין פה משהו אקזוטי. זאת בדיוק הכוונה. אני לא מנסה להקים דת חדשה סביב delivery. אני רוצה trail בתוך הריפו שישרוד יותר משיחה אחת.
SDDRush הוא ה-toolkit הקטן שבניתי סביב השיטה. לוקח את החלקים שנמאס לי להרים ביד.
sdd-init יוצר את ה-.sdd workspace ואת מבנה הקבצים הבסיסי. sdd-prompts מרנדר repo-aware prompts ממצב הפרויקט הנוכחי. sdd-backlog מסנכרן ומתחזק את backlog tickets. sdd-status נותן תמונה קצרה של מה עוד פתוח ומה כבר זז.
להרבה משימות זה מספיק. אם ההקשר של הריפו חשוב, אם העבודה נמשכת יותר מסשן אחד, ואם לא בא לך שה-brief יתפרק לפולקלור, ה-scaffold עוזר.
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 כשהריפו כבר באמת תואם את מה שתוכנן.
אם רוצים לדחוף את אותו 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 בלי הבחנה. לשנות יותר מדי משתנים באותו ניסיון. לסמוך על תשובה שנשמעת נקייה יותר לפני שהמסלול שמאחוריה התייצב.
השיטה אמורה לצמצם ניחושים. אם היא בעיקר מייצרת paperwork יותר יפה, משהו השתבש.
ה-workflow עוזר כי הוא הופך את הכוונה ליותר inspectable, את ה-handoff ליותר נקי, ואת מצב ה-backlog לפחות דקורטיבי. SDDRush קיים כי אני עובד כך מספיק פעמים ורציתי להפסיק להקים את החלקים המשעממים ידנית. Kotef קיים כי לפעמים אני רוצה לאוטומט יותר מאותה לולאה בלי לזרוק את המבנה.