הכוונת עובדי רקע

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

מה משתנה כשמקלידים /vibe

שני דברים, ורק הראשון נאכף על ידי המנגנון:

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

הראשון הוא זה שנושא את המשקל. מכוון שעדיין יכול להריץ grep ולערוך יעשה את העבודה בעצמו תחת לחץ, וזה בדיוק מצב הכשל שכל העניין נועד למנוע.

/vibe migrate the auth module to the new session API

עובדים מתחילים מדף חלק

עובד מעולם לא ראה את השיחה שלכם, וגם לא יראה. התדרוך הוא ההקשר כולו שלו.

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

תדרוך טוב נוקב בשמות קבצים, בפקודות ובהגדרה של מה נחשב גמור:

ב-lib/features/auth/, החליפו כל קריאה ל-SessionStore.read(key) ב-SessionStore.get(key). המתודה החדשה מחזירה Future<String?> בעוד הישנה החזירה String?, ולכן הקוראים צריכים await. הריצו fvm flutter analyze lib/features/auth כשתסיימו, ודווחו על כל שגיאה שלא הצלחתם לתקן.

חמשת הפעלים

פועל	מה הוא עושה
vibe_spawn	מתחיל עובד על תדרוך. חוזר מיד.
vibe_list	דרגה, מצב, זמן שחלף ותוצאה אחרונה עבור כולם
vibe_send	סבב המשך לעובד שכבר סיים
vibe_wait	חוסם עד שאחד העובדים מגיע למצב סופי
vibe_kill	עוצר אחד

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

שתי דרגות

דרגה	עבור
fast	עבודה מכנית עם מפרט ברור — עריכות, שינויי שמות, טיוטות, הרצת פקודות
good	עיצוב, שיקול דעת, או סקירה של מה שעובד fast הפיק

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

אימות

זה החלק שקובע אם לדפוס הזה יש בכלל ערך.

vibe_list
→ w1 [fast] auth-migrate — done (48s): Edited lib/features/auth/session.dart …
  w2 [fast] tests — running (12s)

ואז קראו את הקבצים שהוא ציין. למכוון יש read, search, lsp ו-ast_grep; זו כל הסיבה להשאיר אותם. מכוון שמקבל את הדוח כפשוטו הוא רק מסכם את האופטימיות של סוכנים אחרים.

lsp(action: "diagnostics", file: "*") אחרי סבב עובדים הוא בדרך כלל הבדיקה הבודדת המהירה ביותר.

כשעובד מאבד את החוט

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

vibe_kill(worker_id: "w2")
vibe_spawn(brief: "…corrected…", label: "tests", tier: "fast")

מגבלות

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

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

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

נושאים קשורים

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