סביבות עבודה קיימות לסוכנים, כמו Claude Code, דורשות ממשתמש להיות מחובר וזמין לעבודה משותפת. אם תבקשו פתרון לבעיה ארוכה ומורכבת, המודל עשוי לפתור חלק ממנה, אך בסופו של דבר יעצור וימתין לקלט נוסף – שאלה, עדכון סטטוס או בקשת הבהרה.
כדי לעורר התקדמות מתמשכת ואוטונומית, בניתי סביבת עבודה שמכניסה את Claude ללולאה פשוטה (אם ראיתם Ralph-loop, זה ייראה מוכר). כשהוא מסיים משימה אחת, הוא מיד עובר למשימה הבאה. (יש להריץ זאת בתוך קונטיינר, לא על המחשב הפיזי שלכם).
#!/bin/bash
while true; do
COMMIT=$(git rev-parse --short=6 HEAD)
LOGFILE="agent_logs/agent_${COMMIT}.log"
claude --dangerously-skip-permissions \
-p "$(cat AGENT_PROMPT.md)" \
--model claude-opus-X-Y &> "$LOGFILE"
done
ב-System Prompt של הסוכן, אני מנחה את Claude איזו בעיה לפתור ומבקש ממנו לגשת לבעיה על ידי פירוקה לחתיכות קטנות, מעקב אחר מה שהוא עובד עליו, וזיהוי המשימה הבאה, תוך התקדמות מתמשכת עד לשלמות. (בנקודה האחרונה, ל-Claude אין ברירה. הלולאה רצה לנצח – אם כי במקרה אחד, ראיתי את Claude מבצע בטעות pkill -9 bash, ובכך 'הורג' את עצמו ומסיים את הלולאה. אוי!).
הרצת Claude במקביל
הרצת מספר מופעים במקביל יכולה לתת מענה לשתי חולשות של סביבת עבודה עם סוכן יחיד:
- סשן יחיד של Claude Code יכול לבצע רק דבר אחד בכל פעם. במיוחד ככל שהיקף הפרויקט מתרחב, איתור באגים מרובים במקביל יעיל הרבה יותר.
- הרצת מספר סוכני Claude מאפשרת התמחות. בעוד שחלק מהסוכנים מופקדים על פתרון הבעיה העיקרית, ניתן להפעיל סוכנים מתמחים אחרים כדי (לדוגמה) לתחזק תיעוד, לפקח על איכות הקוד, או לפתור תתי-משימות ייעודיות.
היישום שלי של הרצת Claude במקביל הוא בסיסי ביותר. נוצר מאגר Git חדש וריק, ולכל סוכן מופעל קונטיינר Docker כשהמאגר מותקן בנתיב /upstream. כל סוכן משכפל עותק מקומי לנתיב /workspace, וכאשר הוא מסיים, הוא דוחף את השינויים מהקונטיינר המקומי שלו למאגר המרכזי (upstream).
כדי למנוע משני סוכנים לנסות לפתור את אותה בעיה בו-זמנית, סביבת העבודה משתמשת באלגוריתם סנכרון פשוט:
- Claude 'נועל' משימה על ידי יצירת קובץ טקסט בתיקיית current_tasks/ (לדוגמה, סוכן אחד עשוי לנעול את current_tasks/parse_if_statement.txt, בעוד אחר נועל את current_tasks/codegen_function_definition.txt). אם שני סוכנים מנסים לתפוס את אותה משימה, מנגנון הסנכרון של Git מאלץ את הסוכן השני לבחור משימה אחרת.
- Claude עובד על המשימה, מושך עדכונים מהמאגר המרכזי, ממזג שינויים מסוכנים אחרים, דוחף את שינוייו ומסיר את הנעילה. קונפליקטים במיזוג תכופים, אך Claude מספיק חכם כדי להתמודד איתם.
- לולאת יצירת הסוכנים האינסופית מפעילה סשן חדש של Claude Code בקונטיינר טרי, והמחזור חוזר על עצמו.
זהו אבטיפוס מחקרי מוקדם מאוד. עדיין לא יישמתי שיטות אחרות לתקשורת בין סוכנים, וגם איני אוכף תהליך כלשהו לניהול יעדים ברמה גבוהה. איני משתמש בסוכן תזמור.
במקום זאת, אני משאיר לכל סוכן Claude להחליט כיצד לפעול. ברוב המקרים, Claude בוחר את הבעיה ה"ברורה הבאה" לפתור. כאשר הוא נתקע על באג, Claude לרוב מתחזק מסמך מתמשך של גישות כושלות ומשימות שנותרו. במאגר ה-Git של הפרויקט תוכלו לקרוא את ההיסטוריה ולצפות בו נועל משימות שונות.
לקחים מתכנות עם צוותי סוכני Claude
סביבת העבודה מריצה את Claude בלולאה, אך לולאה זו מועילה רק אם Claude יכול להבין כיצד להתקדם. רוב מאמציי הוקדשו לתכנון הסביבה סביב Claude – הבדיקות, הסביבה עצמה, המשוב – כך שיוכל להתמצא ללא עזרתי. אלו הן הגישות שמצאתי כמועילות ביותר בעת תזמור מופעים מרובים של Claude.
כתבו בדיקות באיכות גבוהה במיוחד
Claude יעבוד באופן אוטונומי כדי לפתור כל בעיה שאציב בפניו. לכן, חשוב שמאמת המשימות יהיה כמעט מושלם, אחרת Claude יפתור את הבעיה הלא נכונה. שיפור סביבת הבדיקה דרש מציאת חבילות בדיקה איכותיות למהדרים, כתיבת מאמתים וסקריפטים לבניית חבילות תוכנה בקוד פתוח, ותצפית על טעויות ש-Claude עשה, ולאחר מכן תכנון בדיקות חדשות ככל שזיהיתי דפוסי כשל אלו.
לדוגמה, לקראת סוף הפרויקט, Claude החל לשבור לעיתים קרובות פונקציונליות קיימת בכל פעם שיישם תכונה חדשה. כדי לטפל בכך, בניתי צינור אינטגרציה רציפה (continuous integration pipeline) ויישמתי אכיפה קפדנית יותר שאפשרה ל-Claude לבדוק טוב יותר את עבודתו, כך ש-commits חדשים לא ישברו קוד קיים.
היכנסו לנעליו של Claude
נאלצתי להזכיר לעצמי כל הזמן שאני כותב את סביבת הבדיקה הזו עבור Claude ולא עבורי, מה שאומר שצריך לחשוב מחדש על רבות מההנחות שלי לגבי האופן שבו בדיקות צריכות לתקשר תוצאות.
לדוגמה, כל סוכן מוכנס לקונטיינר טרי ללא חלון הקשר, ויבלה זמן משמעותי בהתמצאות, במיוחד בפרויקטים גדולים. עוד לפני שהגענו לבדיקות, כדי לעזור ל-Claude לעזור לעצמו, כללתי הוראות לתחזק קובצי README מקיפים וקובצי התקדמות שצריכים להתעדכן לעיתים קרובות עם הסטטוס הנוכחי.
כמו כן, זכרתי את העובדה שלמודלי שפה יש מגבלות מובנות, שסביבן היה צורך לתכנן במקרה זה. אלו כוללות:
- זיהום חלון הקשר: סביבת הבדיקה לא צריכה להדפיס אלפי בתים חסרי תועלת. לכל היותר, עליה להדפיס כמה שורות פלט ולתעד את כל המידע החשוב לקובץ, כך ש-Claude יוכל למצוא אותו בעת הצורך. קובצי לוג צריכים להיות קלים לעיבוד אוטומטי: אם יש שגיאות, Claude צריך לכתוב ERROR ולציין את הסיבה באותה שורה, כך ש-grep יוכל למצוא אותה. זה עוזר לחשב מראש סטטיסטיקות סיכום מצטברות כדי ש-Claude לא יצטרך לחשב אותן מחדש.
- עיוורון זמן: Claude אינו מסוגל לזהות זמן, ואם יישאר לבד, ישמח להשקיע שעות בהרצת בדיקות במקום להתקדם. סביבת העבודה מדפיסה התקדמות הדרגתית לעיתים רחוקות (כדי למנוע זיהום חלון הקשר) וכוללת אפשרות ברירת מחדל
--fast המריצה דגימה אקראית של 1% או 10%. תת-דגימה זו היא דטרמיניסטית לכל סוכן אך אקראית בין מכונות וירטואליות, כך ש-Claude עדיין מכסה את כל הקבצים, אך כל סוכן יכול לזהות רגרסיות באופן מושלם.
הפכו את המקביליות לפשוטה
כאשר ישנן בדיקות כושלות רבות ונפרדות, מקביליות היא טריוויאלית: כל סוכן בוחר בדיקה כושלת אחרת לעבוד עליה. לאחר שחבילת הבדיקות הגיעה לשיעור הצלחה של 99%, כל סוכן עבד על קומפילציה של פרויקט קוד פתוח קטן אחר (לדוגמה, SQlite, Redis, libjpeg, MQuickJS, Lua).
אך כשהסוכנים החלו לקמפל את ליבת לינוקס, הם נתקעו. בניגוד לחבילת בדיקות עם מאות בדיקות עצמאיות, קומפילציית ליבת לינוקס היא משימה ענקית אחת. כל סוכן נתקל באותו באג, תיקן אותו, ואז דרס את השינויים של הסוכנים האחרים. הפעלת 16 סוכנים לא עזרה, מכיוון שכל אחד נתקע בפתרון אותה משימה.
הפתרון היה להשתמש ב-GCC (קישור ל-GCC) כ"אורקל" (Oracle) למהדר תקין ידוע להשוואה. כתבתי סביבת בדיקה חדשה שקימפלה באופן אקראי את רוב הליבה באמצעות GCC, ורק את הקבצים הנותרים עם מהדר ה-C של Claude. אם הליבה עבדה, הבעיה לא הייתה בתת-הקבוצה של הקבצים ש-Claude קימפל. אם היא נשברה, ניתן היה לחדד עוד יותר על ידי קומפילציה מחדש של חלק מהקבצים הללו באמצעות GCC. זה איפשר לכל סוכן לעבוד במקביל, לתקן באגים שונים בקבצים שונים, עד שמהדר ה-Claude הצליח בסופו של דבר לקמפל את כל הקבצים. (לאחר שזה עבד, עדיין היה צורך ליישם טכניקות "דיבוג דלתא" (delta debugging) כדי למצוא זוגות קבצים שנכשלו יחד אך עבדו בנפרד).
תפקידי סוכנים מרובים
מקביליות מאפשרת גם התמחות. קוד שנכתב על ידי LLM לעיתים קרובות מיישם מחדש פונקציונליות קיימת, ולכן הטלתי על סוכן אחד לאחד קוד כפול שמצא. הטלתי על סוכן אחר לשפר את הביצועים של המהדר עצמו, ועל סוכן שלישי הטלתי את האחריות להפקת קוד מקומפל יעיל. ביקשתי מסוכן נוסף לבקר את עיצוב הפרויקט מנקודת מבט של מפתח Rust, ולבצע שינויים מבניים בפרויקט כדי לשפר את איכות הקוד הכוללת, ועל סוכן נוסף הטלתי לעבוד על תיעוד.
בחינת גבולות צוותי סוכנים
פרויקט זה תוכנן כ-benchmark (מדד ביצועים) לבחינת יכולות. אני מעוניין לבחון עד קצה גבול היכולת מה ש-LLMs בקושי רב מסוגלים להשיג כיום, כדי שנוכל להתכונן למה שמודלים יוכלו להשיג באופן אמין בעתיד.
השתמשתי בפרויקט מהדר ה-C כ-benchmark לרוחב כל סדרת מודלי Claude 4. כפי שעשיתי בפרויקטים קודמים, התחלתי בניסוח מה שרציתי: מהדר אופטימיזציה מאפס ללא תלויות, תואם GCC, המסוגל לקמפל את ליבת לינוקס, ומתוכנן לתמוך במספר backends. למרות שציינתי היבטים מסוימים של התכנון (לדוגמה, שיהיה לו SSA IR כדי לאפשר מספר מעברי אופטימיזציה), לא נכנסתי לפרטים כיצד לעשות זאת.
מודלי Opus 4 קודמים בקושי רב היו מסוגלים לייצר מהדר פונקציונלי. Opus 4.5 היה הראשון שחצה סף ואיפשר לו לייצר מהדר פונקציונלי שיכול לעבור חבילות בדיקה גדולות, אך עדיין לא היה מסוגל לקמפל פרויקטים גדולים אמיתיים. מטרתי עם Opus 4.6 הייתה לבחון שוב את הגבולות.
הערכה
במהלך קרוב ל-2,000 סשנים של Claude Code במשך שבועיים, Opus 4.6 צרך 2 מיליארד טוקנים של קלט ויצר 140 מיליון טוקנים של פלט, בעלות כוללת של קצת פחות מ-20,000 דולר. בהשוואה אפילו לתוכניות Claude Max היקרות ביותר, זה היה פרויקט יקר במיוחד. אך סכום זה הוא שבריר ממה שהיה עולה לי לייצר זאת בעצמי – שלא לדבר על צוות שלם.
זו הייתה הטמעה ב"חדר נקי" (Claude לא הייתה לו גישה לאינטרנט בשום שלב בפיתוח); היא תלויה רק בספריית הסטנדרט של Rust. המהדר בן 100,000 השורות יכול לבנות לינוקס 6.9 עם יכולת אתחול על x86, ARM ו-RISC-V. הוא יכול גם לקמפל את QEMU, FFmpeg, SQlite, postgres, redis, ויש לו שיעור הצלחה של 99% ברוב חבילות הבדיקה של מהדרים, כולל חבילת ה-GCC torture test. הוא גם עובר את מבחן הליטמוס האולטימטיבי של מפתחים: הוא יכול לקמפל ולהריץ את Doom.
עם זאת, המהדר אינו חף ממגבלות. אלו כוללות:
- חסר לו מהדר x86 של 16 ביט הדרוש לאתחול לינוקס ממצב real mode. לשם כך, הוא קורא ל-GCC (המהדרים ל-x86_32 ו-x86_64 הם שלו).
- אין לו אסמבלר (assembler) ומקשר (linker) משלו; אלו הם החלקים האחרונים ש-Claude החל להפוך לאוטומטיים ועדיין מכילים באגים מסוימים. סרטון הדגמה הופק באמצעות אסמבלר ומקשר של GCC.
- המהדר בונה בהצלחה פרויקטים רבים, אך לא את כולם. הוא עדיין אינו תחליף מלא למהדר אמיתי.
- הקוד שנוצר אינו יעיל במיוחד. גם כשכל האופטימיזציות מופעלות, הוא מפיק קוד פחות יעיל מ-GCC כאשר כל האופטימיזציות מנוטרלות.
- איכות קוד ה-Rust סבירה, אך אינה מתקרבת לאיכות שמתכנת Rust מומחה היה מפיק.
המהדר שהתקבל הגיע כמעט לגבולות יכולותיו של Opus. ניסיתי (ובקושי!) לתקן כמה מהמגבלות הנ"ל אך לא הצלחתי במלואי. תכונות חדשות ותיקוני באגים שברו לעיתים קרובות פונקציונליות קיימת.
כדוגמה מאתגרת במיוחד, Opus לא הצליח ליישם מחולל קוד x86 של 16 ביט הדרוש לאתחול למצב real mode של 16 ביט. בעוד שהמהדר יכול להפיק קוד x86 נכון של 16 ביט באמצעות קידומות opcode 66/67, הפלט המקומפל המתקבל הוא מעל 60 קילובייט, הרבה מעבר למגבלת הקוד של 32 קילובייט שנאכפת על ידי לינוקס. במקום זאת, Claude פשוט "מרמה" כאן וקורא ל-GCC עבור שלב זה (זה המצב רק עבור x86. עבור ARM או RISC-V, מהדר ה-Claude יכול לקמפל לחלוטין בעצמו).
קוד המקור של המהדר זמין ב-GitHub. הורידו אותו, קראו את הקוד, ונסו אותו על פרויקטי ה-C המועדפים עליכם. תמיד מצאתי שהדרך הטובה ביותר להבין מה מודלי שפה יכולים לעשות היא לדחוף אותם לגבולותיהם, ולאחר מכן ללמוד היכן הם מתחילים לקרוס. בימים הקרובים, אמשיך לאפשר ל-Claude לדחוף שינויים חדשים אם תרצו לעקוב אחר ניסיונותיו המתמשכים של Claude לטפל במגבלות אלו.
מבט קדימה
כל דור של מודלי שפה פותח דרכים חדשות לעבודה איתם. מודלים מוקדמים היו שימושיים להשלמה אוטומטית (tab-completion) בסביבות פיתוח משולבות (IDEs). תוך זמן קצר, מודלים יכלו להשלים גוף פונקציה מתוך ה-docstring שלה. השקת Claude Code הכניסה את הסוכנים למיינסטרים ואפשרה למפתחים לבצע תכנות בזוגות (pair-program) עם Claude. אך כל אחד ממוצרים אלו פועל תחת ההנחה שמשתמש מגדיר משימה, LLM פועל במשך כמה שניות או דקות ומחזיר תשובה, ואז המשתמש מספק המשך.
צוותי סוכנים מראים את האפשרות ליישם פרויקטים מורכבים שלמים באופן אוטונומי. זה מאפשר לנו, כמשתמשים בכלים אלה, להיות שאפתניים יותר עם מטרותינו.
אנחנו עדיין בשלב מוקדם, ופיתוח אוטונומי לחלוטין מגיע עם סיכונים אמיתיים. כאשר אדם יושב עם Claude במהלך הפיתוח, הוא יכול להבטיח איכות עקבית ולתפוס שגיאות בזמן אמת. במערכות אוטונומיות, קל לראות בדיקות עוברות ולהניח שהעבודה הסתיימה, כשזה נדיר. בעבר עסקתי בבדיקות חדירה (penetration testing), ניצול פגיעויות במוצרים של חברות גדולות, והמחשבה על מתכנתים הפורסים תוכנה שהם מעולם לא אימתו בעצמם היא דאגה אמיתית.
לכן, בעוד שניסוי זה מרגש אותי, הוא גם מותיר אותי בתחושה של אי-נוחות. בניית מהדר זה הייתה אחת החוויות המהנות ביותר שהיו לי לאחרונה, אך לא ציפיתי שזה יהיה אפשרי כל כך מוקדם בשנת 2026. ההתקדמות המהירה הן במודלי שפה והן בסביבות העבודה שאנו משתמשים בהן לאינטראקציה איתם, פותחת דלת לכתיבת כמות עצומה של קוד חדש. אני מצפה שהיישומים החיוביים יעלו על השליליים, אך אנו נכנסים לעולם חדש שידרוש אסטרטגיות חדשות כדי לנווט בו בבטחה.
תודות
תודות מיוחדות ליוסף באצ'יק (Josef Bacik), אדווין צ'ן (Edwin Chen), ברנרדו מאורר קוסטה (Bernardo Meurer Costa), ג'ייק איטון (Jake Eaton), דן קלי (Dan Kelley), פליקס קלוק (Felix Klock), ג'אנט פארק (Jannet Park), סטיב וייס (Steve Weis), ורבים אחרים מכל רחבי אנתרופיק על עזרתם ותרומותיהם.
