זרימת עבודה קודקס ומרובת סוכנים: עבוד עם סוכנים מבלי לאבד שליטה

spinny:~/writing $ vim codex-multi-agent-workflows.md

1~
2בפעם הראשונה שסוכן קידוד באמת מתקן לך באג, התגובה כמעט תמיד זהה: תערובת של התלהבות וחשדנות. נחמד, בטח. אבל אז אתה מסתכל על השוני ושואל את עצמך: "בסדר, אבל במה בדיוק הוא נגע? האם אני יכול לסמוך עליו? האם הוא יעשה את זה שוב באותה צורה מחר?".
3~
4שם אני חושב שהחלק המעניין מתחיל. לא כשהסוכן כותב פונקציה, אלא כשהיא הופכת להיות מסוגלת מספיק לקחת על עצמה חלקים שלמים של עבודה: קרא את המאגר, צור תיקון, הרץ בדיקות, פתח יחסי ציבור, חזור אחרי הערת ביקורת. Codex נע בדיוק בכיוון הזה: עבודת רקע, עצי עבודה נפרדים, דפדפן משולב, אוטומציות, תוספים, זיכרון ובקרות הרשאות מפורשות יותר.
5~
6העניין הוא לא לדמיין עתיד שבו אף אחד לא קורא קוד יותר. זה יהיה עתיד נורא, כמו גם די נאיבי. העניין הוא להבין איך לעבוד עם סוכנים שיכולים לעשות הרבה בלי לתת להם לעשות הכל.
7~
8## שינוי ההרגל
9~
10עם ההשלמה האוטומטית המסורתית תמיד היית ליד ההגה. ה-AI הציע קו, החלטת. עם סוכן, לעומת זאת, מערכת היחסים משתנה: אתה נותן לו מטרה והוא עובר מספר שלבים בעצמו.
11~
12זה חזק, אבל זה מסיט את הבעיה. השאלה היא כבר לא רק "האם הדגם יכול לתכנת?". השאלה הופכת:
13~
14- האם נתתי לו היקף קטן מספיק?
15- אתה יודע איך לבדוק את התוצאה?
16- האם אני עובד בסביבה מבודדת?
17- האם הביקורת הסופית עדיין אנושית וזהירה?
18~
19זרימת עבודה בריאה נראית יותר כך מאשר שרביט קסמים:
20~
21```mermaid
22flowchart LR
23    Idea[משימה אנושית] --> Scope[מטרה קטנה וניתנת לאימות]
24    Scope --> Agent[סוכן בעץ עבודה מבודד]
25    Agent --> Checks[בדיקה, מוך, בנייה, דפדפן]
26    Checks --> Review[סקירה אנושית]
27    Review --> Merge[מיזוג או איטרציה חדשה]
28    Review --> Iterate[הערות מדויקות על ההבדל]
29    Iterate --> Agent
30```
31~
32זה נשמע פחות רומנטי מ"הסוכן בונה הכל", אבל זה עובד הרבה יותר טוב. וזה גם איך עובדים צוותים טובים עם בני אדם: משימות ברורות, משוב מהיר, אחריות מפורשת.
33~
34## ההנחיה הטובה היא כמעט כרטיס טוב
35~
36ההנחיה המסוכנת ביותר היא המעורפלת אך בטוחה: "תקן את דף החשבוניות", "שפר את הארכיטקטורה", "נקה את מודול האישור". אלו הן בקשות שנשמעות פרודוקטיביות ויוצרות הבדלים עצומים. אבל אז אתה מוצא את עצמך עושה ארכיאולוגיה.
37~
38הנחיה מועילה משעממת יותר. לדוגמה: יישמו ייצוא CSV עבור דף החשבוניות, בידיעה שהטבלה נמצאת ב-`app/(dashboard)/invoices/page.tsx`, השאילתות נמצאות ב-`src/server/invoices.ts` וכבר יש דפוס דומה ב-`app/(dashboard)/reports`.
39~
40לאחר מכן הוסף אילוצים ברורים: אל תשנה את סכימת מסד הנתונים, אל תוסיף תלות אם מספיקה כלי עזר קטן, שמור על סגנון ממשק המשתמש הקיים. וסגור עם האימות: `npm test -- invoices` ו`npm run build`.
41~
42בריף מסוג זה אינו "להסביר טוב יותר ל-AI". זה משמש מעל הכל כדי להבהיר לך יותר מה אתה מאציל. אם אתה לא יכול לרשום את זה בצורה קונקרטית, אולי המשימה עדיין לא מוכנה לסוכן.
43~
44## שלוש משרות שאני מאציל ברצון
45~
46הראשון הוא עבודה חוזרת אך ניתנת לאימות: הוספת בדיקות, העברת שיחות ל-API פנימי חדש, עדכון יבוא, החלפת רכיבים שהוצאו משימוש, תיקון שגיאות TypeScript. כאן הסוכן יכול לחסוך שעות והסיכון ניתן לשליטה.
47~
48השני הוא עבודת חקר: "מצא היכן מחושב הסכום הזה", "הסביר לי מדוע הבדיקה הזו שברירית", "שחזר את הבאג ותגיד לי אילו קבצים נראים מושפעים". גם כאשר הוא לא מייצר תיקון מיד, הוא יכול לעשות סיור מועיל.
49~
50השלישית היא עבודת תחזוקה חוזרת: עדכוני תלות קטנים, ניקוי של דגלי תכונה ישנים, סיכום של PRs חסומים, בדיקת TODOs שנשכחו. זה לא זוהר, אבל זה בדיוק סוג העבודה שנוטה להיערם.
51~
52## שלוש עבודות שאני שומר על בני אדם
53~
54החלטות מוצר נשארות אנושיות. אם שינוי משנה את האופן שבו משתמש משלם, מוחק נתונים, רואה מחירים או מבין הרשאה, אני רוצה אדם אחראי.
55~
56גם גבולות אבטחה ראויים לתשומת לב אנושית: אישור, תפקידים, אסימונים, רישום נתונים רגישים, העברות של מסדי נתונים. סוכן יכול לעזור ליישם, אבל לא חייב להיות מקבל ההחלטות הבלעדי.
57~
58לבסוף, אני שומר על כל מה שדורש טעם אדריכלי אנושי. סוכן יכול להציע רפקטור, אבל ההבנה אם הפשטה היא באמת הכרחית או שמא אנחנו רק מלטשים בעיה לא קיימת נשארת עבודה.
59~
60## הביקורת אינה אופציונלית
61~
62הפיתוי, כשסוכן טוב, הוא לסמוך על הירוק של ה-CI. זה מובן. זה גם כשהבעיות מתחילות.
63~
64אני תמיד מסתכל על לפחות חמישה דברים:
65~
661. האם התיקון פותר רק את המשימה המבוקשת?
672. האם הוא נגע בקבצים שלא קשורים לזה?
683. האם המבחנים מכסים התנהגות חדשה או סתם סיכוי שמח?
694. האם הקוד עוקב אחר דפוסים מקומיים?
705. האם השגיאות מטופלות כמו בשאר הפרויקט?
71~
72כשמשהו לא בסדר, המשוב צריך להיות ספציפי. "תקן את זה" זה עצלן. טוב יותר: כלי זה משכפל את `parseMoney` לתוך `src/lib/money.ts`; השתמש מחדש בפונקציה הזו, הוסף בדיקה למקרה של EUR ואל תשנה את ה-API הציבורי של מודול החיוב.
73~
74סוכנים מגיבים הרבה יותר טוב להערות קטנות וניתנות לאימות. באופן מוזר, גם האנשים.
75~
76## מעקות בטיחות שווה את המאמץ
77~
78אם סוכן יכול לקרוא קבצים, לכתוב קוד ולהפעיל פקודות, יש להתייחס אליו כאל תהליך רב עוצמה. אין צורך בפרנויה, צריך היגיינה.
79~
80השתמש בעצי עבודה נפרדים או בענפים. אז אתה יכול להשוות את ההבדל, לזרוק ניסויים כושלים, ולא לערבב את העבודה של הסוכן עם מה שאתה עושה.
81~
82הגבל הרשאות. פקודות כמו `rg`, `git diff`, `npm test` ו`npm run build` יכולות להיות די חינמיות. פריסות, העברת מסדי נתונים, גישה לסודות ופקודות הרסניות חייבות להישאר מפורשות.
83~
84צמצם את הגישה לרשת כאשר אינך זקוק לה. למשימות רבות מספיקים תיעוד רשמי, רישום חבילות ושירותים פנימיים ספציפיים. פחות שטח פנים, פחות הפתעות.
85~
86עקוב אחר פעולות. כאשר תיקון מגיע לבדיקה, אתה אמור להיות מסוגל לשחזר הנחיות, פקודות שבוצעו, בדיקות שעברו וקבצים שונו. לא כדי ליצור בירוקרטיה, אלא כדי להיות מסוגל להבין מה קרה אם משהו השתבש.
87~
88## דרך קלה להתחיל כצוות
89~
90אם הייתי מכניס סוכנים לצוות קטן, הייתי מתחיל בלי מהפכות גדולות.
91~
92הייתי יוצר תווית `agent-ready` לבעיות עם היקף ברור. הייתי מוסיף תבנית עם הקשר, אילוצים ופקודות אימות. הייתי מבקש יחסי ציבור קטנים, באופן אידיאלי מתחת לכמה מאות שורות. אדרוש בדיקות או צילומי מסך לשינויים גלויים. ומעל הכל הייתי שומר על אדם אחראי למיזוג.
93~
94אחרי שבועיים הייתי מסתכל על הנתונים: אילו משימות באמת זירזו, אילו ביקורות היו כבדות, אילו הנחיות היו מבלבלות, אילו חלקים של בסיס הקוד שבריריים מכדי להאציל.
95~
96זו גישה פחות מרהיבה מ"מהיום נעשה הכל עם הסוכנים", אבל היא זו שמאפשרת להגיע לשבוע השלישי בלי חרטות.
97~
98## החלק הכי אנושי
99~
100הדבר המצחיק הוא שככל שסוכנים אוטונומיים הופכים ליותר חשיבות, הכישורים הקלאסיים הופכים להיות חשובים יותר: כתיבת כרטיס טוב, ביצוע חתכים קטנים, יצירת מבחנים, קריאת הבדלים, העברת פשרות. הסוכן מאיץ את מי שכבר יודע לעבוד היטב. זה גם מגביר את הכאוס של אלה שמחלקים יד גרועה.
101~
102אז לא, אני לא רואה בזרימות עבודה מרובות סוכנים קיצור דרך להפסיק לעשות הנדסה. אני רואה בהם דרך להעביר יותר אנרגיה לחלקים החשובים: להחליט מה לבנות, לוודא שזה עובד, לשמור על מובנת המערכת.
103~
104סוכנים יכולים להיות עמיתים אסינכרוניים נהדרים. אבל עמית אסינכרוני, כדי להיות שימושי, צריך הקשר, גבולות וסקירה. בדיוק כמו כולם.
105~
106## מקורות שימושיים
107~
108- [קודקס עבור (כמעט) הכל - OpenAI](https://openai.com/index/codex-for-almost-everything/)
109- [הפעלת Codex בבטחה ב-OpenAI](https://openai.com/index/running-codex-safely/)
110- [הכירו את Codex - OpenAI](https://openai.com/index/introducing-codex/)
111- [מה חדש עם סוכן הקידוד של GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)
112~

NORMAL · codex-multi-agent-workflows.md [readonly]112 lines · :q to close

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

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

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

8## שינוי ההרגל

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

11~

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

13~

14- האם נתתי לו היקף קטן מספיק?

15- אתה יודע איך לבדוק את התוצאה?

16- האם אני עובד בסביבה מבודדת?

17- האם הביקורת הסופית עדיין אנושית וזהירה?

18~

19זרימת עבודה בריאה נראית יותר כך מאשר שרביט קסמים:

20~

21```mermaid

22flowchart LR

23 Idea[משימה אנושית] --> Scope[מטרה קטנה וניתנת לאימות]

24 Scope --> Agent[סוכן בעץ עבודה מבודד]

25 Agent --> Checks[בדיקה, מוך, בנייה, דפדפן]

26 Checks --> Review[סקירה אנושית]

27 Review --> Merge[מיזוג או איטרציה חדשה]

28 Review --> Iterate[הערות מדויקות על ההבדל]

29 Iterate --> Agent

30```

31~

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

33~

34## ההנחיה הטובה היא כמעט כרטיס טוב

35~

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

37~

38הנחיה מועילה משעממת יותר. לדוגמה: יישמו ייצוא CSV עבור דף החשבוניות, בידיעה שהטבלה נמצאת ב-`app/(dashboard)/invoices/page.tsx`, השאילתות נמצאות ב-`src/server/invoices.ts` וכבר יש דפוס דומה ב-`app/(dashboard)/reports`.

39~

40לאחר מכן הוסף אילוצים ברורים: אל תשנה את סכימת מסד הנתונים, אל תוסיף תלות אם מספיקה כלי עזר קטן, שמור על סגנון ממשק המשתמש הקיים. וסגור עם האימות: `npm test -- invoices` ו`npm run build`.

41~

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

43~

44## שלוש משרות שאני מאציל ברצון

45~

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

47~

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

49~

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

51~

52## שלוש עבודות שאני שומר על בני אדם

53~

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

55~

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

57~

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

59~

60## הביקורת אינה אופציונלית

61~

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

63~

64אני תמיד מסתכל על לפחות חמישה דברים:

65~

661. האם התיקון פותר רק את המשימה המבוקשת?

672. האם הוא נגע בקבצים שלא קשורים לזה?

683. האם המבחנים מכסים התנהגות חדשה או סתם סיכוי שמח?

694. האם הקוד עוקב אחר דפוסים מקומיים?

705. האם השגיאות מטופלות כמו בשאר הפרויקט?

71~

72כשמשהו לא בסדר, המשוב צריך להיות ספציפי. "תקן את זה" זה עצלן. טוב יותר: כלי זה משכפל את `parseMoney` לתוך `src/lib/money.ts`; השתמש מחדש בפונקציה הזו, הוסף בדיקה למקרה של EUR ואל תשנה את ה-API הציבורי של מודול החיוב.

73~

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

75~

76## מעקות בטיחות שווה את המאמץ

77~

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

79~

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

81~

82הגבל הרשאות. פקודות כמו `rg`, `git diff`, `npm test` ו`npm run build` יכולות להיות די חינמיות. פריסות, העברת מסדי נתונים, גישה לסודות ופקודות הרסניות חייבות להישאר מפורשות.

83~

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

85~

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

87~

88## דרך קלה להתחיל כצוות

89~

90אם הייתי מכניס סוכנים לצוות קטן, הייתי מתחיל בלי מהפכות גדולות.

91~

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

93~

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

95~

96זו גישה פחות מרהיבה מ"מהיום נעשה הכל עם הסוכנים", אבל היא זו שמאפשרת להגיע לשבוע השלישי בלי חרטות.

97~

98## החלק הכי אנושי

99~

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

101~

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

103~

104סוכנים יכולים להיות עמיתים אסינכרוניים נהדרים. אבל עמית אסינכרוני, כדי להיות שימושי, צריך הקשר, גבולות וסקירה. בדיוק כמו כולם.

105~

106## מקורות שימושיים

107~

108- [קודקס עבור (כמעט) הכל - OpenAI](https://openai.com/index/codex-for-almost-everything/)

109- [הפעלת Codex בבטחה ב-OpenAI](https://openai.com/index/running-codex-safely/)

110- [הכירו את Codex - OpenAI](https://openai.com/index/introducing-codex/)

111- [מה חדש עם סוכן הקידוד של GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)

112~