Parallel Coding Agents — חלוקת Feature בין מספר סוכני קוד

מאת צוות מדיה דיל · 12.08.2026 · Agentic Development · 5 דק׳

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

מפתח שניסה להריץ שלושה סוכני קוד במקביל על אותו feature גדול גילה תוך שעה שהם כתבו קוד שסותר זה את זה: סוכן אחד שינה את החתימה של פונקציה משותפת, סוכן שני עדיין כתב קוד שקורא לחתימה הישנה, וסוכן שלישי כתב טסט שציפה לגרסה שלישית שאף אחד מהם לא כתב בפועל. התוצאה הייתה שלוש שעות של עבודה מקבילה שהצריכו יותר זמן איחוד (merge) מאשר אם מפתח אחד היה כותב הכול ברצף. Parallel Coding Agents הוא תחום שעוסק בדיוק בבעיה הזו: איך מחלקים עבודה בין כמה סוכנים בו-זמנית בלי שהמקביליות תהפוך לעלות נטו במקום לחיסכון.

למה מקביליות נאיבית נכשלת

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

הפתרון הראשון והבסיסי הוא בידוד פיזי: כל סוכן עובד ב-Git worktree נפרד, כדי שהשינויים שלו לא "ידלפו" לעבודתם של האחרים לפני שהוא מסיים. אבל בידוד לבדו לא פותר את בעיית הקונפליקטים בשלב האיחוד — הוא רק דוחה אותה למועד מאוחר יותר.

קיים גם היבט תשתיתי שקל להתעלם ממנו: worktrees נפרדים דורשים גם סביבות ריצה נפרדות — אם כל הסוכנים חולקים אותו port של שרת פיתוח מקומי או אותו מופע DB, הם עדיין ידרסו זה את עבודתו של זה בזמן ריצה, גם אם הקוד עצמו מבודד לגמרי ב-Git. הפתרון המעשי הוא להקצות לכל worktree גם container או תצורת פורטים נפרדת, כדי שהבידוד יהיה מלא ולא רק ברמת מערכת הקבצים.

חלוקת עבודה לפי גבול ממשק, לא לפי גודל

המפתח המרכזי לחלוקת עבודה מוצלחת בין סוכנים מקבילים הוא לחלק לפי גבולות ממשק (interface boundaries) ולא לפי כמות שורות קוד. אם feature דורש שינוי ב-API layer, ב-business logic, וב-UI, הדרך הבטוחה לחלק היא להקפיא תחילה את חוזה ה-API — הגדרת ה-endpoints, הטיפוסים, ה-response shape — ורק אז לשחרר שלושה סוכנים במקביל: אחד על המימוש בפועל של ה-API, אחד על ה-UI שצורך אותו (מול mock שתואם לחוזה המוקפא), ואחד על הטסטים. כל עוד החוזה לא זז, שלושתם יכולים לעבוד באמת במקביל בלי לדרוס זה את זה.

הגישה הזו דומה לעיקרון ש-Spec-Driven Development מבוסס עליו: ה-spec, או במקרה הזה חוזה ה-API, הופך למקור אמת יציב שכל סוכן עובד מולו, במקום שהאמת "תתגלה" באמצע העבודה ותשנה את הקרקע מתחת לרגליים של סוכן אחר.

תיאום, לא רק בידוד

מעבר לחלוקה מראש, סוכנים מקבילים בשלים זקוקים למנגנון תיאום פעיל תוך כדי עבודה — לא רק בתחילת המשימה. הדרך המעשית ביותר היא Shared State מרכזי, לרוב קובץ יומן משימות או לוח מצב, שכל סוכן קורא לפני כל פעולה משמעותית וכותב אליו אחריה: "שיניתי את הטיפוס של Order — כל סוכן שעובד על קוד שתלוי בו צריך לבדוק מחדש". זה לא צריך להיות מורכב — לעיתים די בקובץ JSON פשוט שמתעדכן אטומית, שכל סוכן סורק בתחילת כל צעד.

כלים לניהול sub-agents, כמו אלה שמפורטים במדריך Sub-Agents ב-Claude Code, מספקים תשתית מובנית יותר לתיאום כזה — סוכן אורקסטרטור מרכזי שמחלק משימות לסוכני-משנה ומרכז את התוצאות, במקום שכל סוכן יפעל כישות עצמאית לחלוטין בלי פיקוח.

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

איחוד (Merge) כתהליך מובנה, לא אירוע מפתיע

גם עם חלוקה טובה ותיאום שוטף, שלב האיחוד עדיין דורש תשומת לב. הפרקטיקה הטובה ביותר היא merge תדיר וקטן במקום merge יחיד וגדול בסוף — כל סוכן ממזג את השינויים שלו ל-branch ביניים ברגע שהוא משלים יחידת עבודה קטנה, ולא ממתין לסיום כל המשימה. זה מקטין דרמטית את גודל כל קונפליקט בודד, וחשוב מכך — חושף בעיות תיאום מוקדם, כשעוד קל לתקן אותן, במקום בסוף כשכל הצדדים כבר בנו שכבות נוספות מעל ההנחות השגויות. עיקרון זה משיק ישירות לנושא Autonomous Pull Requests, שם נדון תהליך ה-PR האוטונומי עצמו לעומק. חשוב גם להגדיר סדר מיזוג קבוע — למשל תמיד לפי סדר השלמת המשימה ולא לפי סדר אקראי — כדי שקונפליקטים שכן מתעוררים יהיו צפויים וניתנים לשחזור, ולא תלויי-תזמון בין ריצה לריצה.

מתי מקביליות לא שווה את זה

לא כל משימה מתאימה למקביליות. features קטנים, שמסתיימים תוך פחות משעה עבודה לסוכן בודד, כמעט תמיד ייצאו יותר טובים ומהירים מסוכן יחיד בלי תקורת תיאום. המקביליות משתלמת בעיקר כשמדובר בעבודה שבאמת ניתנת להפרדה לחלקים עצמאיים באמת — לא רק "נראים" עצמאיים — ושהתועלת מקיצור זמן ה-wall-clock עולה על עלות התיאום הנוספת. הכלל הפרקטי הפשוט ביותר: אם קשה להסביר בפסקה אחת איך שני חלקי העבודה לא ייגעו זה בזה, כנראה שהם לא באמת מתאימים למקביליות.

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

תגיות: parallel agents · coding agents · git worktree · multi-agent coordination · merge conflicts · spec-driven development

← חזרה לבלוג · צור קשר