סוכן יכול לכתוב קוד מהר יותר ממה שאתם מספיקים לקרוא אותו, ולכן הסקירה הופכת לצוואר הבקבוק. בסרטון הזה ניתן לסוכן משימת סקירה נפרדת, נאחד ממצאים מכמה סקירות שמתחילות מאפס, ונחליט אילו ממצאים מצדיקים תיקון.
בסרטון קודם קבענו שבדיקות ה-CI חייבות לעבור לפני מיזוג. טסטים, בדיקת טיפוסים ולינט הם כלים פורמליים, והם בודקים תנאים שכתבנו בקוד.
סקירה של סוכן מוסיפה לצד ה-CI כלי מעורפל. הסוקר מחפש בעיות שלא כתבנו להן בדיקות, כמו קוד שסוטה מהמפרט, מקרה שגיאה שלא מטופל, או שם מטעה.
מי שכתב את הקוד הוא סוקר גרוע של העבודה שלו, וזה נכון גם לסשן שבו הסוכן כתב את הקוד. בהקשר שלו כבר יש את הסיבות שבגללן הקוד נראה נכון, ולכן הוא נוטה לאשר את הבחירות של עצמו.
פתחו סשן חדש או תת-סוכן, רק עם ה-diff והמפרט, בלי השיחה של מי שכתב את הקוד. מודל אחר גם משנה את סוג הטעויות שהסוקר עושה, למשל, לתת ל-Codex לסקור קוד ש-Claude Code כתב.
תנו לסוקר את ה-diff, את המפרט או ה-issue, ומה לחפש. למשל, בקשו ממנו לבדוק אם המימוש עומד בדרישות ומטפל בכשלים.
צרפו את צ'קליסט הסקירה של הפרויקט, ששמור במאגר, או ארזו את ההוראות האלה כ-skill של סקירה. כללים כמו "אף פעם לא לעשות מוק למסד הנתונים" ו"כל נקודת קצה בודקת הרשאות" הם החלטות של הפרויקט, שסוקר כללי לא יכול לדעת עליהן. אמרו לסוקר במפורש לקרוא את הכללים האלה.
בגלל שסקירה היא כלי מעורפל, הרצה נוספת יכולה להעלות ממצאים אחרים באותו קוד. כדאי להריץ כמה סקירות, בעזרת תת-סוכנים שכל אחד מהם מתחיל בהקשר נקי, ועם אותו תדריך סקירה.
אספו את הממצאים שלהם, ואחדו כפילויות. הסכמה בין סוקרים היא ראיה שימושית, אבל היא לא מוכיחה שהממצא נכון.
בקשו מהסוקר לדרג את הממצאים לפי החשיבות ולפי הקושי או העלות של התיקון. דרשו תרחיש כשל קונקרטי לכל ממצא, כדי שתוכלו להעריך גם את ההשלכה וגם כמה עבודה התיקון דורש.
למשל, הסוקר מדווח: "אם השמירה נכשלת, האפליקציה עדיין מדווחת על הצלחה, ובטעינה מחדש השינויים הולכים לאיבוד." זו השלכה חמורה, גם אם טיפול בשגיאה והוספת טסט הם תיקון קטן. חשיבות ומאמץ הם שתי שאלות נפרדות.
ל-Claude Code יש פקודה מובנית, /code-review, שסוקרת את ה-diff הנוכחי, או pull request או ענף שתציינו. אפשר לבחור רמת מאמץ, מ-low ועד max. הדגל --comment מפרסם את הממצאים כהערות על שורות הקוד ב-pull request. הדגל --fix מבקש מ-Claude Code ליישם את התיקונים בעץ העבודה אחרי הסקירה.
ל-Claude Code יש גם את הפקודה /security-review, שבודקת את השינויים בענף ומחפשת בהם פגיעויות אבטחה. ב-CLI של Codex, הפקודה /review מפעילה סקירת קוד. בדקו במסך העזרה של הגרסה המותקנת אילו אפשרויות יש, כי הפקודות האלה משתנות.
כשמבקשים מסוקר ממצאים, זה מעודד אותו למצוא משהו, כולל בעיות שלא באמת קיימות. אמתו כל ממצא לפני שאתם פועלים לפיו, והכי טוב, הפכו את תרחיש הכשל שלו לטסט שנכשל.
בדוגמה של השמירה, גרמו לשמירה להיכשל, ובדקו שהאפליקציה מדווחת על הכשל ולא על הצלחה. אם הטסט הזה חושף את הבאג, יש לכם ראיה קונקרטית לתיקון, וגם טסט רגרסיה שנשאר בפרויקט.
הפרידו בין סקירה לתיקון: הסוקר מדווח, ואתם מחליטים מה לאשר. סוקר שמתקן בעצמו את מה שמצא הופך לכותב שני, שגם את השינויים שלו צריך לבדוק.
סקירה של סוכן שימושית לבאגים מקומיים, מקרי קצה שפוספסו, סטיות מהמפרט, טיפול חסר בשגיאות, וחוסר עקביות. היא פחות אמינה בשאלה אם בחרתם בפיצ'ר הנכון, או אם השינוי מתאים לארכיטקטורה.
היא גם מפספסת אינווריאנטים בקבצים שהיא לא קראה, וקריאת קוד לא מוכיחה איך הוא מתנהג בזמן ריצה. שינויי אבטחה, מיגרציות של נתונים וממשקי API ציבוריים עדיין צריכים שבן אדם יקרא אותם.
סקירה של סוכן עוזרת להתמודד עם קוד שמגיע מהר יותר ממה שאתם מספיקים לקרוא. סקירות שמתחילות מאפס נותנות לכם ממצאים קונקרטיים לבדוק, ואתם נשארים אלה שמחליטים מה לשנות ומה למזג.
נתראה בסרטון הבא.