לעבוד עם Opus 5.5: משימה אחת, ריצה ארוכה

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

הפוסט מבוסס על הכתבה Getting the most out of Opus 5.5 in Claude and Claude Code של אדי אוסמאני בבלוג של Claude (ספטמבר 2026). לקחתי ממנה את הרעיונות המרכזיים, סידרתי אותם מחדש והוספתי דוגמאות מהעבודה שלי. למי שרוצה את התמונה המלאה, כדאי לקרוא גם את המקור.

מגדירים את המשימה כולה, כולל איפה היא נגמרת

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

העבר את כל הקומפוננטות בתיקייה components מ־Options API ל־script setup.
סיימת כש־pnpm typecheck ו־pnpm test עוברים, ואין יותר export default עם data() בתיקייה.

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

עוד הרגל ששווה לשבור: הוראות כמו ״חשוב לעומק לפני שאתה עונה״. Opus 5.5 חושב לפני כל תשובה ממילא, כך שההוראה הזו רק תופסת מקום בפרומפט. עדיף להשקיע את המילים בהגדרה מדויקת של המשימה.

ריצה ארוכה צריכה נקודות עצירה

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

## Stop and ask

- Before deleting files or dropping database tables.
- Before changing a public API or a migration that already ran.
- Before any git push or deploy.
- When a test fails twice for the same reason.

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

רשימת משימות בקובץ, לא בזיכרון

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

# Migration: Options API to script setup

- [x] PostCard.vue
- [x] SearchDialog.vue
- [ ] ArticleToc.vue
- [ ] SiteHeader.vue (sticky logic, check the spacer)

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

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

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

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

בסוף הריצה: קודם מה שהוא צריך מכם

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

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

להראות במקום להקליד

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

מתי לעבור למצב מהיר

לא כל עבודה היא ריצה ארוכה. כשמתקנים משהו קטן ורוצים תגובה מהירה, למשל לשנות טקסט ולראות את התוצאה, אפשר להפעיל ב־Claude Code את /fast. זה עדיין אותו מודל, רק עם תשובות מהירות יותר, שמתאימות לעבודה אינטראקטיבית. כשחוזרים למשימה גדולה, חוזרים למצב הרגיל.

בקצרה

1. 01מגדירים סוף

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

2. 02קובעים עצירות

   הפעולות שדורשות אישור כתובות פעם אחת ב־CLAUDE.md.

3. 03שומרים התקדמות

   רשימת משימות בקובץ, ועבודה רחבה מחולקת לסוכני משנה.

4. 04קוראים חכם

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