Claude כותב, Codex בודק

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

אני עובד עם שני coding agents. Claude כותב. Codex, ממשפחת models אחרת, עושה review. model לא בודק את העבודה של עצמו, וגם לא את זו של model מאותה משפחה. ה-review רץ כפקודה אחת, /code-review-x, על כל השינוי בסוף העבודה ולא על כל קובץ בנפרד.

השאלה

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

ההגדרה

• הכותב: Opus פשוט הוא ברירת המחדל שלי ל-build.
• ה-reviewer: Codex דרך /code-review-x, פעם אחת על כל השינוי. בזרימה הנוכחית (/drive) זה ה-review האחרון, והוא מוגבל לקבצים של המשימה.
• מה שמקיף אותה: tests מקצה לקצה, Playwright על כל שינוי בממשק, שינויים קטנים, ובסוף מבט אישי שלי. הקריאה הראשונה נמסרת לכלי או ל-agent אחר.
• מה לא נעשה כאן: אין ניסוי מבוקר. אלה תצפיות ממשימות אמיתיות, ובחלקן הייתה הרצה אחת בלבד לכל תנאי.

הזרימה

1. ה-reviewer הראשון. את הקריאה הראשונה של שינוי גדול שנכתב בעזרת בינה מלאכותית אני מוסר ל-agent אחר, כי אי אפשר להעמיק בכל קובץ. אחריה באים tests, ואחריהן אני.
2. reviewer מאותה משפחה. בניסוי קטן החלפתי את Codex ב-reviewer Opus טרי. הסשן לקח 10 דקות ועלה 4.72$, ולא הוסיף כלום. שני reviewers עם אותה נקודת מבט מחזירים את אותה תשובה במילים אחרות, ולכן הם צריכים להיות שונים בעדשה, לא רק ב-prompt. את הכלל הזה קראתי בדיון של מתרגלים על pipeline מסירה: reviewer אחד על רגרסיה אבטחתית ו-reviewer אחר על התאמה למפרט. התיאור שם לא אומת, ואצלי הוא לא נבדק, אבל הוא מתיישב עם מה שראיתי.
3. state machine. על monitor של ריצת צי הסשנים שלי, state machine של כ-300 שורות, ה-review מצא 12 ממצאים חמורים בארבעה סבבים. שניים נשארו פתוחים כשהגעתי לתקרת התיקונים: אובדן קובץ גיבוי בקריסה, ופנייה ל-agent המוביל שלא נשלחה מחדש. הלקח: קוד שרושם תופעות לוואי צריך review בין-משפחתי לפני שסומכים עליו.
4. כשה-review שתק. הכלי דיווח "אין ממצאים חדשים" לקבצים שלי, ושחררתי מייבא נתונים. בפועל הוא חזר ודיווח על אותם שני ממצאים ישנים בכל הרצה, ושלושה פגמים חמורים בקוד החדש לא נראו. agent צד שם לב, ו-review ישיר של Codex שהוגבל לקבצים האלה מצא אותם. התיקון: כל review מוגבל נקרא עם prompt להתעלם מההיסטוריה ולסקור רק את הקבצים האלה. ממצא שחוזר מילה במילה אומר שהטווח לא עבר review.
5. review שלא נגמר. ב-build של רכיב נוחות הסבבים המשיכו לרדוף אחרי עוד דרך לעקוף שער, והעבודה נמשכה כשבע שעות. ב-review אבטחתי של מסנן שמסתיר סודות, כל תיקון פתח את הצורה הבאה: ערכים במרכאות, תווי בריחה, גרשיים הפוכים, פקודות מקוננות. מספר הממצאים הקריטיים עבר מ-2 ל-5, אחר כך 2 ו-3, ורק אחרי שהחלפתי גישה הגיע ל-0.
6. מה שינה את הגישה. במסנן הסודות לא עזרו עוד טלאים. עברתי לרשימת היתרים של מה שמותר לתעד, להשמטת בלוקי קוד ושורות פקודה לפני הסיכום במקום לנסות לטשטש בתוכם, ולסורק חיצוני מוכן (gitleaks) כשער אחרון.

המספרים

מקרה	מה נמדד	תוצאה
state machine, כ-300 שורות	ממצאים חמורים	12 בארבעה סבבים, 2 פתוחים בתקרה
reviewer Opus טרי במקום Codex	זמן ועלות	10 דקות, 4.72$, בלי תועלת נוספת
ארבעה באגים אמיתיים, /work	זמן ועלות	149 דקות, 14.88$
אותם באגים, Opus לבד	זמן ועלות	7 דקות, 2.46$
אותם באגים, Opus ו-review של Codex אחד	זמן ועלות	27 דקות, 6.30$
מסנן סודות, ממצאים קריטיים	לפי סבב	2, 5, 2, 3, ואז 0
רכיב נוחות	משך ה-build	כ-7 שעות

בארבעת הבאגים כל שלוש הדרכים עברו את ה-tests הנסתרים, כך שה-review לא שינה את התוצאה אלא את המחיר: עוד 20 דקות לעומת Opus לבד. שורת ה-reviewer הטרי באה מניסוי אחר, ולכן אין לחבר אותה לשלוש השורות שמעליה.

מה השתנה אצלי

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

הסתייגויות

• ההשוואה בין שלוש הדרכים היא הרצה אחת לכל תנאי על ארבעה באגים. היא לא מראה שכמות כזאת של review תמיד עוזרת או תמיד מיותרת.
• 12 הממצאים החמורים נספרו על ידי ה-reviewer עצמו. אני לא יכול לומר כמה מהם היו נשארים בלי review, או כמה היו מתגלים ב-tests.
• ה-reviewer הטרי ממשפחת Opus נבדק פעם אחת. זה מצביע על כיוון ולא מוכיח ש-reviewers מאותה משפחה אף פעם לא מוסיפים.
• הדוגמה של שני reviewers בעדשות שונות באה מדיון של אחרים ולא נבדקה אצלי.

מה אפשר לקחת מזה

1. reviewers צריכים להיות שונים בעדשה, לא רק ב-prompt. reviewer Opus טרי במקום Codex עלה 4.72$ ולא הוסיף כלום.
2. ממצא שחוזר מילה במילה אומר שהטווח לא עבר review. "אין ממצאים חדשים" הוא לא review: הרץ את Codex ישירות עם prompt להתעלם מההיסטוריה ולעשות review רק לקבצים שלך.
3. שים תקרה של שני סבבי תיקון. כשסבב שלישי עדיין מוצא מקרי קצה חדשים, החלף גישה: רשימת היתרים, השמטה במקום טשטוש וסורק חיצוני. במסנן הסודות זה הוריד את הממצאים הקריטיים ל-0.
4. קוד שרושם תופעות לוואי צריך review בין-משפחתי לפני שסומכים עליו. במכונת המצבים נשארו שני ממצאים חמורים פתוחים בתקרת התיקונים.
5. בשינוי גדול, בקש מראש דיאגרמות ודוגמה שרצה דרכו, ובנה מפת שינוי. כך מחליטים איפה להעמיק במקום לקרוא הכול.