עבודה מקבילית עם Claude Code: worktree, סוכנים ו-Workflows

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

המדריך הזה מאגד ניסיון מעשי ומפה של המקומות שבהם הכלים מתאימים. ארבעת אבני הבניין הרשמיות של Claude Code, מפת השימושים שלהם, ומסגרת נגד הייפ לקביעה כמה סוכנים מקביליים באמת נדרשים למתכנת vibe. כל הנתונים והציטוטים מקושרים למקורות ראשוניים של Anthropic.

מהו multi-agent ב-Claude Code, ולמה לא „1000 סוכנים”#

מערך multi-agent הוא מערך שבו משימה מפוצלת לכמה זרמי עבודה עצמאיים, וכל אחד מטפל בחלק שלו ומחזיר תוצאה. דוגמה פשוטה: כותבים את החזית בחלון Claude Code אחד ואת צד השרת בחלון אחר באותו מחשב, כשמאגר git משותף ביניהם. זה כבר multi-agent, גם אם „תזמור” היא מילה מיותרת לתיאורו.

מערך מורכב יותר: בתוך הפעלה אחת של Claude Code, מפעילים חמישה תת-סוכנים בתפקידים שונים (מפתח חזית, מפתח צד שרת, בודק אבטחה, בודק תוכנה ומתעד), וכל אחד מחזיר את חלקו בתוצאה לשיחה המשותפת. זו אותה גישת multi-agent, רק עם נקודת בקרה אחת.

מערך מורכב עוד יותר: אומרים ל-Claude, „ערוך ביקורת אבטחה שבועית של כל 500 הקבצים בפרויקט שלי”, והוא כותב סקריפט תזמור ב-JavaScript. זמן הריצה מפעיל כמה עשרות סוכנים ברקע, כל אחד בודק את החלק שלו, ואז סוכנים עצמאיים בודקים זה את הממצאים של זה, ומתקבל דוח אחד. אלה Dynamic Workflows, ש-Anthropic פרסמה ב-28 במאי 2026. פירוט מלא של התכונה מופיע במדריך הנפרד על Dynamic Workflows.

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

אגב, „1000 סוכנים” הוא מספר אמיתי. זהו הגבול העליון להרצת Dynamic Workflow אחת ב-Claude Code. התיעוד הרשמי של Anthropic אומר:

במילים אחרות, זהו אמצעי הגנה טכני מפני התנהגות שיצאה משליטה, ולא עומס עבודה מומלץ. בפועל, 95% מהמשימות מטופלות באמצעות 2–8 זרמי עבודה מקביליים. אם מתכננים יותר, כדאי קודם לשאול את עצמכם מה הם יעשו.

4 אבני בניין של Claude Code: תת-סוכנים, מיומנויות, צוותי סוכנים ו-workflows#

ל-Claude Code יש ארבעה אבני בניין רשמיים לפיצול משימה אחת בין כמה סוכנים. Anthropic איגדה אותם בטבלת השוואה בתיעוד Dynamic Workflows. הנה ההשוואה בשפה פשוטה:

כל אחד מאבני הבניין האלה פותר בעיה אחרת. תת-סוכנים מתאימים להאצלת 2–3 בדיקות בתוך משימה אחת. מיומנויות מתאימות כשיש הוראה מוכנה ש-Claude צריך לפעול לפיה (למשל, „בצע סקירת PR לפי רשימת הבדיקה הזאת”). צוותי סוכנים מתאימים כשחלקים אחדים של מוצר נמצאים בחלונות שונים ונדרש מתאם אחד. Workflows מתאימים כשמשימה גדולה מדי לחלון הקשר אחד.

תת-סוכנים מתוארים בפירוט במדריך Claude Code Subagents 2026. עץ ההחלטה ל„מה להשתמש עבור משימה מסוימת” מופיע במדריך Skills, Subagents, MCP, Plugins. המדריך הזה עוסק בהרכבתם למערך multi-agent על גבי git worktree.

רמה 1: תת-סוכנים בהפעלה אחת — המקום הקל ביותר להתחיל בו#

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

דוגמה מסוימת מהפרויקט המתואר. לאחר הטיוטה הראשונה של מדריך, הסקירה מוגדרת כך: Claude מקבל את הבקשה, „הפעל שישה תת-סוכנים במקביל — הראשון בודק סימני AI, השני מונחים משפטיים, השלישי קול וטון, הרביעי בודק עובדות באמצעות WebFetch, החמישי בוחן את מבנה ה-SEO והשישי בודק דיוק של קישורים פנימיים”. כל אחד מחזיר דוח, ולאחר מכן מיישמים את העריכות.

מבחינה טכנית, עושים זאת באמצעות קבצים ב-.claude/agents/[subagent-name].md שמתארים את התפקיד והכלים. הקריאה מתבצעת באמצעות הכלי Agent בשיחה הראשית. Claude מחליט מתי לשלוח בקשה לתת-סוכן.

איפה זה עובד. משימות שכוללות 3–7 בדיקות מקביליות של פריט אחד (קוד, טקסט, עיצוב). כל בדיקה עצמאית. התוצאות נכנסות לחלון ההקשר הראשי.

איפה זה מתחיל להיתקל בקשיים. אם יש לכם 50+ קבצים או שכל בדיקה צריכה הקשר משלה של 50K טוקנים, החלון הראשי יתמלא. דרושים workflows או צוותי סוכנים.

הסיכון העיקרי. כל תת-סוכן צורך טוקנים בנפרד. אם מפעילים שישה על פרויקט עם 200 קבצים וכל אחד קורא מחדש את כל 200 הקבצים, משלמים פי 6. לכן חובה לציין בדיוק אילו קבצים על תת-הסוכן לבדוק. ראו פרטים במדריך לאן הולכים הטוקנים ב-Claude Code.

רמה 2: git worktree — בידוד קבצים בין הפעלות מקביליות#

כשתת-סוכנים אינם מספיקים ונדרשים שני מופעי Claude Code מלאים במסופים שונים שעובדים באותו מאגר, מתעוררת בעיה מוכרת. שניהם מתחילים לערוך את אותו קובץ; אחד שומר ראשון והשני כותב מעל השינויים שלו. לקוח שאל את צוות התמיכה בשבוע שעבר: „5 דורכים זה על זה באותו זמן”.

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

פקודות להתקנה של חמש דקות:

# From the main project directory
cd ~/projects/my-app

# Create a worktree for feature/auth
git worktree add ../my-app-auth feature/auth

# Create a worktree for feature/billing
git worktree add ../my-app-billing feature/billing

# Open two terminal windows
cd ~/projects/my-app-auth && claude   # first Claude Code
cd ~/projects/my-app-billing && claude # second Claude Code

כל עותק נמצא בענף משלו. כל מופע Claude Code כותב לתיקייה שלו. כשהמשימה מסתיימת, מריצים git push מהענף שלו ואז git worktree remove ../my-app-auth.

מה חשוב לדעת. worktree אינו משכפל node_modules,‏ .venv או קבצים אחרים שב-.gitignore. אם דרושות תלויות עצמאיות (גרסת ספרייה שונה בכל ענף), מריצים npm install בנפרד בתיקייה החדשה אחרי worktree add.

כמה worktrees לאדם. על סמך סקרי צוותים מ-2026, התקרה המעשית היא 4–8 worktrees מקביליים למפתח. הגורם המגביל אינו Claude, אלא היכולת של אדם לבדוק ולקבל את התוצאות. אם יש לכם 10 worktrees, הם ממתינים לבדיקה.

בפרקטיקה המתוארת, אנשים משתמשים בדרך כלל ב-2–3 worktrees מקביליים. worktree ראשי אחד לעבודה פעילה, אחד לגיבויים דחופים ואחד לניסוי (תכונה חדשה שלא בטוחים לגביה). אין צורך ביותר.

רמה 3: צוותי סוכנים — כמה חלונות, סוכן מוביל אחד#

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

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

מבחינה טכנית, צוותי סוכנים הם כמה חלונות שעובדים על גבי git worktree עם נקודת תכנון משותפת אחת. בפועל, 80% מהאנשים מנהלים צוותי סוכנים ידנית (כמתואר לעיל עם worktree) ואינם משתמשים ב„מסגרת צוותים” מיוחדת. זה בסדר.

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

רמה 4: Dynamic Workflows — Claude כותב סקריפט תזמור ב-JS#

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

דוגמה ספציפית מהתיעוד הרשמי. אומרים:

ultracode: audit every API endpoint under src/routes/ for missing auth checks

Claude כותב סקריפט JavaScript עם היגיון בקירוב כזה: „קח את כל הקבצים מ-src/routes/, חלק אותם לקבוצות של 30 נקודות קצה, הפעל סוכן על כל קבוצה עם אותה בדיקה, ואז הפעל שני סוכני ניקוד עצמאיים שיבדקו את הממצאים ויאחדו אותם לדוח סופי”. הסקריפט רץ. מקבלים טבלת תוצאות ורשימת נקודות קצה שבהחלט דורשות בדיקה.

איפה זה עובד.

• ביקורת של פרויקט שלם לאיתור בעיה אחת (אבטחה, טיפוס או ממשקי API שהוצאו משימוש).
• העברות גדולות (500+ קבצים הכפופים לכלל משותף).
• שאלות מחקר שדורשות בדיקה מכמה זוויות עצמאיות (Anthropic עושה זאת בפקודה המובנית /deep-research).

פירוט מלא של Dynamic Workflows, המגבלות שלהם ואופן הפעולה של ultracode מופיע במדריך הנפרד ל-Dynamic Workflows ב-Claude Code.

מתי לא להשתמש בו. כשהמשימה ליניארית וברורה. אין צורך ב-workflow למשימה כמו „סיים את הרכיב הזה”. workflow מתאים כשהמשימה מתפצלת ל-10+ תתי-משימות עצמאיות ונדרשת בדיקה צולבת ביניהן.

המגבלה העיקרית. workflow צורך משמעותית יותר טוקנים מהפעלה רגילה. Anthropic ממליצה בתיעוד שלה:

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

Outcomes: רובריקה של קריטריונים ובודק עצמאי#

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

Anthropic נותנת מענה לבעיה הזאת באמצעות Outcomes, תכונה של Managed Agents שהושקה ב-6 במאי 2026. הרעיון פשוט: להפעלה נוסף סוכן שני (מעריך), שתפקידו היחיד לבדוק את עבודת הסוכן הראשון מול רובריקה קפדנית.

כך זה עובד מבחינה טכנית. כותבים רובריקה — מסמך Markdown ובו רשימה מפורטת של משמעות המונח „הושלם”, אילו מקורות לבדוק ואילו תוויות להשתמש. הפלטפורמה יוצרת אוטומטית סוכן מעריך בחלון הקשר חדש. הוא מקבל רק את הרובריקה ואת התוצאה, ולא דבר נוסף. אחרי כל ניסיון של הסוכן הראשי (הכותב), המעריך קורא מחדש את התוצאה ומאשר אותה או מחזיר רשימה מפורטת של מה שעדיין חסר.

ציטוט מתוך Anthropic Cookbook:

נתוני השפעה בפועל: לאחר שילוב Outcomes ב-Claude Managed Agents, שיעור השלמת המשימות של חברת ה-AI Harvey גדל פי 6 בערך. ב-Wisedocs (תיעוד רפואי), הזמן שהוקדש לבדיקת מסמך ירד ב-50%. הנתונים האלה לקוחים מההכרזה הרשמית על התכונה.

מה חשוב למתכנת vibe לעומת ארגון גדול. Outcomes הוא דפוס פעולה, לא רק תכונה מסוימת. אפשר ליצור סוכן מעריך משלכם באמצעות תיאור אותם קריטריונים ב-.claude/agents/grader.md ובקשה מהסוכן הראשי להפעיל אותו אחרי כל ניסיון. זה עובד עם כל מערך multi-agent, ולא רק עם Managed Agents.

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

דפוס אנטי: „50 סוכנים שעושים שטויות”#

זהו דפוס האנטי המרכזי בעבודה עם כמה סוכנים. מישהו לומד ש-Claude Code יכול להפעיל 16 סוכנים בו-זמנית ו-Dynamic Workflows יכולים להפעיל 1000 בכל הרצה, ולכן הוא מתיישב ומפעיל אותם. התוצאה: אפס. צריכת טוקנים: פי 10 מהפעלה רגילה.

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

1. מה בדיוק הוא עושה (משפט אחד).
2. באילו קבצים הוא נוגע.
3. מה הוא מחזיר.
4. מי בודק אותו.

אם אינכם יכולים לענות אפילו על אחת מהשאלות האלה בתוך 30 שניות, לא צריך להפעיל את הסוכן הזה. הכלל עובד בכל רמה: תת-סוכנים, צוותי סוכנים ו-Dynamic Workflows.

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

דפוס האנטי השלישי הוא שימוש ב-multi-agent כדי להאיץ עבודה. זה עובד רק עד גבול מסוים. אם מפצלים משימה לארבעה זרמי עבודה עצמאיים, הם יסתיימו בערך בזמן שיידרש לזרם אחד (בתוספת תקורת תיאום מזערית). אבל אם יש 50 זרמים במכונה אחת, כל אחד פועל לאט יותר כי הם חולקים את ה-CPU. התקרה המעשית במחשב נייד היא 4–6 מופעי Claude Code בו-זמנית; מעבר לכך מתחילה האטה מכוונת.

כמה זה עולה, ואיך אפשר להימנע מניצול כל המכסות?#

במאי–יוני 2026 התעשייה נאלצה להתמודד עם המציאות שלפיה קידוד בעזרת AI עולה יותר מהצפוי.

שיחת Claude Code רגילה אחת עולה סכום סביר יחסית. הפעילו Dynamic Workflows על מאגר שלם, ותקבלו חשבון גבוה פי 20. מתוך התיעוד הרשמי של Anthropic:

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

1. ציינו במדויק את הקבצים עבור כל סוכן. לא „עבור על הפרויקט וחפש בעיות”, אלא „בדוק את src/auth/*.ts וודא שכל פונקציה מאמתת את userId”. ההנחיה השנייה תיתן לכם בדיוק את העבודה שעליה אתם משלמים.

2. נסו תמיד workflow על תיקייה אחת תחילה. לא על כל src/. התחילו ב-src/auth/. אם התוצאות מוצאות חן בעיניכם ואתם מבינים את העלות, הרחיבו את ההיקף.

3. השתמשו כברירת מחדל ב-/effort high, וב-ultracode רק בכוונה תחילה. /effort ultracode פירושו xhigh בתוספת תזמור אוטומטי. זה יקר מאוד. השתמשו בו כשמשימה באמת דורשת כמה זרמי עבודה מקביליים.

4. העבירו תת-סוכנים למודל קטן יותר כשאפשר. אם שישה תת-סוכנים בודקים מדריך אחד, אין צורך שסוכן בקרת האיכות שבודק סימני AI או בודק הקישורים הפנימיים ישתמש ב-Opus. Sonnet יספיק. כך השימוש מצטמצם פי 3–5.

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

מאיפה להתחיל היום: רשימת בדיקה של 30 דקות#

1. עדכנו את Claude Code לגרסה v2.1.154+

   זו הגרסה המינימלית שתומכת ב-Dynamic Workflows. הריצו claude update במסוף.

2. הפעילו Dynamic Workflows ב-/config

   הם מושבתים כברירת מחדל בתוכנית Pro. פתחו את /config, מצאו את השורה “Dynamic workflows” והפעילו אותה. הם כבר מופעלים בתוכניות Max, Team ו-Enterprise.

3. צרו את ה-worktree הראשון שלכם

   בתיקיית הפרויקט הראשית הריצו git worktree add ../<project>-experiment <branch>. פתחו חלון מסוף שני בתיקייה הזאת. הריצו claude.

4. הוסיפו רשימת משימות משותפת

   השתמשו בנתיב מוחלט אחד מחוץ לכל עצי העבודה. tasks.md בכל worktree הוא קובץ נפרד ואינו מסתנכרן אוטומטית. השאירו את ההפעלה המובילה ככותב היחיד; עובדים קוראים את הרשימה המשותפת ומדווחים תוצאות למוביל.

   צרו את תיקיית התיאום ואת רשימת המשימות פעם אחת:

       mkdir -p "$HOME/projects/my-app-coordination"
   
       printf '%s\n' '# Tasks' '- Auth: assigned to the auth worktree' '- Billing: assigned to the billing worktree' > "$HOME/projects/my-app-coordination/tasks.md"
   

   במסוף הראשון:

       cd "$HOME/projects/my-app-auth"
       printf 'Shared task list: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
       claude
   

   במסוף השני:

       cd "$HOME/projects/my-app-billing"
       printf 'Shared task list: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
       claude
   

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

5. עבדו כך במשך שבוע

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

6. רק אז הפעילו `/effort ultracode`

   בחרו משימה אחת, למשל „מצא את כל נקודות הקצה של API ללא בדיקות אימות ב-src/routes/”. הפעילו /effort ultracode. בדקו איזה workflow Claude כותב, כמה הוא עולה ואיזו תוצאה הוא מפיק. זה יהיה ה-Dynamic Workflow הראשון שלכם.

לאן להמשיך: זיכרון בין הפעלות, Code Review ו-Multi-Agent v2#

מה הופיע במאי–יוני 2026, ולאן מועדות פניו של multi-agent ב-Claude Code.

Managed Agents עם Dreaming. הושק ב-6 במאי 2026 בכנס Code with Claude. תהליך מתוזמן שקורא את התמלילים הקודמים של סוכן בין הפעלות, מזהה דפוסים חוזרים ומעדכן את הזיכרון שלו. השלמת המשימות של חברת ה-AI המשפטית Harvey גדלה פי שישה, במיוחד לאחר Dreaming. עדיין בתצוגת מחקר מקדימה.

Outcomes כתכונה של Managed Agents. תואר לעיל. זמין באמצעות Claude Agent SDK, לא ישירות דרך CLI של Claude Code. אפשר ליישם את אותו דפוס ידנית כבר עכשיו באמצעות תת-סוכן מעריך.

Multi-Agent Orchestration v2 ב-Claude Agent SDK. סוכן מוביל מאציל בעצמו לתת-סוכנים באמצעות מערכת קבצים משותפת. זהו מעבר מ„הפעל N תת-סוכנים באופן ידני” ל„תאר משימה, והסוכן המוביל יחליט בעצמו למי להאציל וכיצד”. אם אתם רק לומדים על תת-סוכנים, אין צורך לדאוג ל-v2 עדיין. למדו את הדפוס הקלאסי — „סוכן ראשי אחד + 3–5 תת-סוכנים בעלי תפקידים” — והתקדמו ל-v2 באופן טבעי בעוד 3–6 חודשים.

Code Review בידי צוות סוכנים. Anthropic הכריזה בכנס Code with Claude על תכונה לבדיקת קוד אוטומטית בעת פתיחת PR. צוות של סוכני AI בודק את ה-diff במקביל, מחפש באגים, מאמת את הממצאים זה מול זה ומדרג אותם לפי חומרה. זמין בתוכניות Team ו-Enterprise, עדיין לא ב-Pro.

Plugin Marketplace. הושק ב-23 במאי 2026 בגרסאות v2.1.128-136. חלק מהתוספים בשוק הם מערכי multi-agent מוכנים (parallel-review, security-audit, migration-helper). אפשר להתקין אותם באמצעות /plugin install <name>@claude-plugins-official ולראות איך הם בנויים — דרך טובה ללמוד לכתוב תוסף משלכם.

multi-agent ב-Claude Code עדיין נראה כמו אוסף אבני בניין ברמות בשלות שונות. תת-סוכנים ו-git worktree יציבים, מוכחים ועובדים בכל מקום. צוותי סוכנים הם חצי אוטומטיים וחצי ידניים. Dynamic Workflows נמצאים בתצוגת מחקר מקדימה ומשתנים במהירות. Managed Agents v2 מיועדים לארגונים בלבד. פירוש הדבר שבמהלך השנה הבאה, המערך המיטבי למתכנת vibe לא יהיה הגרסה האחרונה, אלא המערך המצומצם ביותר שנדרש למשימה המסוימת. שני worktrees ותת-סוכן מעריך אחד מספיקים לחודש של עבודה פעילה. הוסיפו מורכבות רק כשתתחילו להרגיש מוגבלים.

מערך עבודה לקידוד vibe#

חומרים מעשיים: התיעוד של Ailoot.

חומרים וכלים נוספים: Ailoot.