תהליך פיתוח VM0: ניהול סוכני AI כמו צוות

בצוות הפיתוח של VM0, כל מפתח עובד עם מספר מופעים של Claude Code במקביל. בדרך כלל יותר משמונה.

אנחנו מתייחסים ל-Claude Code כמו למפתח אמיתי. (כן, שם החברה שלנו הוא בחצי בדיחה AI Colleagues Co!)

לכן, פילוסופיית העיצוב מאחורי תהליך הפיתוח של VM0 משקפת עקרונות קלאסיים של ניהול צוותים בהנדסת תוכנה.

אנחנו משתמשים ב-GitHub Issues למעקב אחרי משימות, Pull Requests לסקירת קוד ומיזוג, ו-GitHub Actions לאוטומציה. במהלך תקופה של חודשיים, המבנה הזה עזר לנו לשחרר 404 גרסאות ולכתוב יותר מ-230,000 שורות קוד.

הפוסט הזה מסביר איך הפכנו את זה לישים, ולמה הבעיה המרכזית לא הייתה יכולת ה-AI, אלא התיאום האנושי.

תהליך פיתוח מונע-AI בפועל

כשאתה מתאם הרבה סוכני AI במקביל, צוואר הבקבוק הוא לא אם המודל יודע לכתוב קוד. צוואר הבקבוק האמיתי הוא עומס קוגניטיבי אנושי.

לתהליך הזה יש 14 פקודות סלאש, מאורגנות בשלוש שכבות: חקירה מעמיקה, ניהול משימות, וניהול PR.

בואו נסתכל קודם איך נראה התהליך שלי ואיך בדרך כלל נבנית תכונה.

1. יישור דרישות

   אדם פותח סשן Claude ומתחיל עם /deep-research. Claude אוסף עובדות מהקוד, מהתיעוד ומהקשר רלוונטי. אנחנו דנים בממצאים ומיישרים קו על הבעיה שאותה פותרים.

2. חקר פתרונות

   באמצעות /deep-innovate, Claude מציע מספר כיוונים אפשריים, עם יתרונות וחסרונות. אנחנו דנים, מצמצמים ובוחרים כיוון.

3. יצירת משימה

   אנחנו יוצרים משימת GitHub באמצעות /issue-create. האדם בודק שהדרישות ברורות.

4. תכנון ואישור

   משתמשים ב-/issue-plan כדי לאפשר ל-Claude להמשיך. Claude יריץ אוטומטית את כל תהליך החקירה המעמיקה ויפרסם את התוצאות במשימה, כולל:

   1. ממצאים מ-/deep-research
   2. השוואות מ-/deep-innovate
   3. תכנית מימוש קונקרטית מ-/deep-plan

5. מימוש

   לאחר אישור, /issue-action מאפשר ל-Claude לממש את התכנית, לכתוב בדיקות, לפתוח PR ולוודא ש-CI עובר.

6. סקירה ומיזוג

   אנחנו משתמשים ב-/pr-review לסקירה מובנית, ואז מבצעים סקירה אנושית סופית לפני מיזוג.

   האדם מתערב בשלוש נקודות בקרה: דרישות, כיוון, וקבלה. כל השאר מתבצע אוטונומית.

שינוי גישה: אתה מוביל צוות של מפתחי AI

הרגע שבו הבנתי שאנחנו צריכים תהליך מובנה היה כשלהוסיף עוד סשנים של Claude דווקא החמיר את המצב. ככל שהרצתי יותר מופעים במקביל, היה קשה יותר לעקוב מה כל אחד עושה, מה מצב העבודה, ומה כבר הוחלט.

בלי כלים חיצוניים, פשוט לא הצלחתי לנהל כל כך הרבה מופעים של Claude בבת אחת. ואז זה התחבר: זו לא בעיית AI, זו בעיית ניהול.

GitHub הוא כבר הכלי הטבעי לשיתוף פעולה בפיתוח תוכנה, אז במקום להמציא משהו חדש, התחלתי להתייחס ל-Claude כמו לחבר צוות אנושי. ברגע שעשיתי זאת, רוחב הפס הניהולי שלי קפץ.

עשר שנות ניסיון בניהול פרויקטים וצוותים סוף סוף קיבלו משמעות בהקשר החדש הזה. כשמתייחסים ל-Claude כחבר צוות ול-GitHub כמרחב התקשורת והניהול המשותף, הכל הופך שוב לנשלט.

מנהל צוות טוב יודע מתי להתערב ומתי לסגת:

נקודת בקרה	מה אני עושה	מה ה-AI עושה
דרישות	מיישר קו על הבעיה, מחדד תחום	חוקר קוד, אוסף הקשר
כיוון	סוקר ממצאים, מאשר גישה	מציע 2-3 גישות, מעריך יתרונות וחסרונות
קבלה	סוקר PR, בודק איכות	מממש, בודק, מתקן CI

זה משקף את אופן הפעולה של צוותי תוכנה יעילים. אני לא מיקרו-מנהל מפתחים אלא מגדיר דרישות ברורות, סוקר החלטות מפתח, ומוודא את התוצאה הסופית. אותו עיקרון חל גם בניהול סוכני AI.

תהליך החקירה המעמיקה כופה חשיבה איטית ומובנית

תהליך החקירה המעמיקה כופה חשיבה מכוונת לפני מימוש. לפעמים Claude מגיע למבוי סתום. כשזה קורה, אנחנו עוצרים את Claude לחשוב ואז מדברים יחד. יש שלושה שלבים:

שלב	פקודה	מטרה	פלט
חקירה	/deep-research	איסוף עובדות, הבנת הקשר	research.md
חדשנות	/deep-innovate	חקר מספר גישות	innovate.md
תכנון	/deep-plan	הגדרת צעדים קונקרטיים	plan.md

לכל שלב יש גבולות ברורים.

• חקירה: בלי הצעות
• חדשנות: בלי פירוט
• תכנון: בלי מימוש

המגבלות האלו מאלצות את Claude לחשוב לאט ובכוונה, במקום לקפוץ ישר לקוד. בלעדיהן, מקרים חריגים ודאגות ארכיטקטוניות לרוב מתפספסים!

דוגמה לשימוש

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude researches, analyzes 12 related files, finds 3 similar patterns]

/deep-innovate what are our options for fixing this?

[Claude presents 3 approaches with trade-offs, you pick one]

/issue-create let's track this fix

במשימות פשוטות, אפשר לדלג על החקירה המעמיקה ולעבור ישירות ל-/issue-create.

במשימות מורכבות עם אי-ודאות טכנית, שלבי החקירה המעמיקה עוזרים לוודא שאתה ו-Claude מיושרים לפני תחילת המימוש.

השתמשו ב-GitHub כזיכרון משותף

רוב כלי ה-AI מתייחסים להקשר כזמני. כשהסשן מסתיים, הזיכרון נעלם.

VM0 משתמש ב-GitHub כזיכרון מתמשך:

פיצ'ר ב-GitHub	מה נשמר
גוף המשימה	דרישות והחלטות
תגובות למשימה	חקירה, אפשרויות, תכניות
תגובות PR	סקירות וסיכומים
תוויות	מצב התהליך

זה גם פותר בעיה אנושית: שחזור הקשר.

כשאני מנהל 8+ מופעי Claude, אני מקבל התראות שהעבודה הושלמה. אבל אני לא יכול לשחזר מהשיחה עם Claude מה הוא עשה, אילו החלטות התקבלו, או מה המצב הנוכחי.

GitHub Issues פותרים את זה. כל משימה מציגה:

• את הדרישות המקוריות
• ממצאי החקירה (מה התגלה)
• שלב החדשנות (אילו אפשרויות נשקלו)
• התכנית שאושרה (מה ימומש)

הפורמט המובנה הזה הופך את הסקירה ליעילה. כך אני יכול לסרוק במהירות את השלבים, להבין את הגישה, לאשר או לבקש שינויים – בלי לזכור את השיחה המקורית.

כשהעבודה מסתיימת, אין צורך לזכור מה קרה בחלון הצ'אט. אני פותח את המשימה ורואה את כל הסיפור, מובנה ומתועד.

העברת משימות בין סוכנים

מכיוון שכל ההקשר נשמר ב-GitHub, העבודה יכולה לעבור בין סוכנים בצורה חלקה:

• סוכן אחד יוצר משימה או PR
• אחר ממשיך מאוחר יותר עם /deep-research issue 123 או /issue-plan 123 או /deep-research PR 124

לדיונים ארוכים, /issue-compact מאחד הכל לגוף משימה מסודר. זה הופך את ההעברה לקלה גם לאנשים וגם ל-AI.

נסכם את דפוסי התהליך

אחרי כל זה, הנה כמה טיפים מעשיים.

משימות פשוטות

/issue-create → /issue-plan → /issue-action → /pr-check-and-merge

השתמש בזה כשהדרישות ברורות והעבודה פשוטה.

משימות מורכבות

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check

זה מונע בזבוז מאמץ על כיוון שגוי.

עבודה במקביל

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

Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements

עזר פקודות

פקודות חקירה מעמיקה

פקודה	מטרה
/deep-research	איסוף מידע, הבנת הקוד. אין הצעות.
/deep-innovate	חקר 2-3 גישות, הערכת יתרונות וחסרונות. אין קוד.
/deep-plan	יצירת צעדי מימוש קונקרטיים. אין מימוש.

פקודות משימה

פקודה	מטרה
/issue-create	יצירת משימה מהקשר השיחה
/issue-bug	יצירת דיווח באג עם שלבי שיחזור
/issue-feature	יצירת בקשת פיצ'ר ממוקדת בדרישות
/issue-plan	הרצת תהליך חקירה מלא, פרסום תוצאות למשימה
/issue-action	המשך מימוש לאחר אישור אנושי
/issue-compact	איחוד גוף משימה + תגובות להעברה

פקודות PR

פקודה	מטרה
/pr-check	ניטור CI, תיקון אוטומטי, ניסיון חוזר עד 3 פעמים
/pr-review	סקירת PR לפי קומיט מול סטנדרטים של הפרויקט
/pr-comment	סיכום דיון השיחה לתגובה ב-PR

התחלת עבודה

1. התחל פשוט: השתמש ב-/issue-create → /issue-plan → /issue-action למשימה הראשונה שלך
2. הוסף חקירה מעמיקה למשימות מורכבות: כשיש חוסר בהירות בדרישות או מורכבות טכנית, התחל עם /deep-research
3. הגדל בהדרגה: הוסף עוד מופעי Claude ככל שתתרגל לקצב הסקירה
4. סמוך על התהליך: אפשר ל-Claude לעבוד אוטונומית בין נקודות בקרה

התהליך בנוי לאימוץ הדרגתי. אין צורך להשתמש בכל 14 הפקודות מהיום הראשון. התחל בזרימת משימות בסיסית, ואז הוסף שלבי חקירה ועבודה במקביל ככל שתצבור ביטחון.

שיקולי התרחבות: מה לעשות כשיש יותר סוכנים

התהליך נוסה עם 10+ מופעי Claude במקביל. ההמלצה שלנו:

• עד 10 סוכנים: נוח לשיתוף פעולה עמוק עם כל אחד
• מעבר ל-10: לא מומלץ

הגורם המגביל הוא לא התהליך, אלא תשומת הלב האנושית ואיכות ההחלטות. כשמנהלים יותר מ-10 סוכנים, יש סיכון להפוך לצוואר בקבוק בנקודות הסקירה, ואיכות ההחלטות יורדת.

עקרון "צוות שתי פיצות" הקלאסי תקף גם כאן. אותם מגבלות שמגבילות גודל צוות אנושי מגבילות גם את מספר סוכני ה-AI שאדם אחד יכול לנהל ביעילות.

אני בוחן כרגע מבנה צוות דו-שכבתי של 8×8 להתרחבות מעבר ל-10 סוכנים, אך טרם פיתחתי שיטות יעילות. אשתף כשיהיו תוצאות קונקרטיות…

תהליך הפיתוח של VM0 משנה את החשיבה על פיתוח תוכנה כשה-AI הופך לחלק מהצוות.

כשמתייחסים לסוכני AI כחברי צוות ולא ככלים, הכל מסתדר. GitHub הופך לזיכרון המשותף של הצוות. משימות הופכות לפריטי עבודה. PRs הופכים לתוצרים. ואתה הופך למוביל הצוות, מתמקד בארכיטקטורה, כיוון ואיכות בזמן שצוות ה-AI שלך מממש.

כך שחררנו 404 גרסאות ב-2 חודשים. וכך גם אתה יכול להרחיב את הפיתוח שלך עם AI.