Alex Chernysh
לדבר על מערכת
חזרה לכתיבה

הערה

Spec-Driven Development: השיטה שאני באמת משתמש בה

איך אני משתמש ב-workflow קל של Spec-Driven Development בפרויקטים אמיתיים, מה SDDRush עושה בפועל, ואיפה Kotef נכנס אם רוצים שכבת agent חזקה יותר.

4 דק׳ קריאהמאת Alex Chernysh
SDDWorkflowEngineeringAgents
לקפוץ לחלק

בפועל אני עובד עם workflow די פשוט של Spec-Driven Development. הרעיון פשוט: להוציא את הכוונה, ה-research, הארכיטקטורה וה-tickets מתוך הזיכרון של הצ'אט אל קבצים שאפשר לקרוא, לבדוק ולהעביר הלאה. עם הזמן ארזתי את החלקים החוזרים של הלולאה הזאת לתוך SDDRush.

ה-trail שאני רוצה לראות בריפו
העניין הוא לא paperwork אלא מסלול קצר וברור מכוונה לראיות בתוך הריפו.

1. איזו בעיה זה פותר

הכשל הישן עוד כאן: התוכנית חיה בעיקר בתוך הצ'אט.

זה מרגיש מהיר ליום או יומיים. אחר כך המשימה נמשכת לעוד סשן, לעוד מהנדס או לעוד agent, והצורה של העבודה מתחילה לזוז.

מה בדרך כלל נשבר קודם:

  • הכוונה המקורית נמרחת
  • החלטות ארכיטקטורה מתקבלות בחתיכות
  • tickets מפסיקים לשקף את התוכנית האמיתית
  • handoff מתחיל להישען על זיכרון ועל תקווה

את זה בדיוק אני מנסה להוריד.

2. מה זה SDD בפועל

בפועל הלולאה די קומפקטית:

  1. כותבים project brief
  2. אוספים research ממוקד
  3. מקבעים החלטות ארכיטקטורה
  4. מסנכרנים backlog ל-tickets קונקרטיים
  5. מממשים מול ה-ticket הפתוח
  6. מעדכנים status וסוגרים מה שבאמת הושלם

אין פה משהו אקזוטי. זאת בדיוק הכוונה. אני לא מנסה להקים דת חדשה סביב delivery. אני רוצה trail בתוך הריפו שישרוד יותר משיחה אחת.

3. מה 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 כשהריפו כבר באמת תואם את מה שתוכנן.

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 יעלה יותר מהתועלת, אני לא משתמש בזה.

6. מה לא לעשות

הטעויות כאן די צפויות:

  • להפוך כל bugfix קטן לטקס
  • להתחיל עם ה-agent כשהמשימה עצמה עוד מעורפלת
  • להתייחס לתשובת מודל כאילו היא זיכרון פרויקט אמיתי
  • לכתוב specs שנשמעים חכמים אבל לא באמת מגבילים את המימוש

השיטה אמורה לצמצם ניחושים. אם היא בעיקר מייצרת paperwork יותר יפה, משהו השתבש.

7. סיכום

ה-workflow הזה עוזר כי הוא הופך את הכוונה ליותר inspectable, את ה-handoff ליותר נקי, ואת מצב ה-backlog לפחות דקורטיבי. SDDRush קיים כי אני עובד כך מספיק פעמים ורציתי להפסיק להקים את החלקים המשעממים ידנית. Kotef קיים כי לפעמים אני רוצה לאוטומט יותר מאותה לולאה, בלי לזרוק את המבנה בדרך.

Repositories