Ofer Shapira

איך עושים review ל-PR שסוכן AI כתב?

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

בקצרה

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

מתחילים מהבעיה ומההחלטה

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

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

דורשים בדיקה שיכולה להיכשל

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

בדקו גם תרחישי שגיאה, הרשאות ונתונים רגישים כשאלה חלק מהשינוי. שינוי במסד נתונים דורש התייחסות למיגרציה ולדרך חזרה. רמת הבדיקה צריכה להתאים לסיכון, לא לגודל ה-diff בלבד.

משתמשים ב-review אוטומטי כמשוב נוסף

התיעוד הנוכחי של GitHub מציין ש-Copilot code review יכול לפספס בעיות, וגם להציע הערה שאינה נכונה. ההמלצה המפורשת היא לאמת את המשוב ולשלב review אנושי. לכן גם קוד שנכתב על ידי סוכן וגם תיקון שהציע כלי review צריכים בדיקה.

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

בודקים מחדש אחרי שינוי

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

כללי branch protection יכולים לדרוש בדיקות ואישורים לפני merge, ולבטל אישורים שהתיישנו אחרי שינוי בקוד. זו אפשרות להגנה על התהליך, לא טענה שכך מוגדר כל repository.

מסיימים בהחלטה שאפשר להסביר

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

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

מקורות ופרטים נוספים

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

איך מגדירים לסוכן מה נחשב הצלחה

שאלות נפוצות

האם review של AI מחליף review אנושי?

GitHub ממליצה לאמת את משוב Copilot ולשלב review אנושי. כלי אוטומטי יכול לפספס בעיות או להציע הערה שגויה.

מה צריך לבקש מסוכן לפני review?

תיאור שינוי והיקף, פקודות בדיקה ותוצאות, בדיקת רגרסיה ומה שלא נבדק. משווים את ההסבר ל-diff ולבקשה.

האם צריך review חדש אחרי כל תיקון?

מוודאים שהבדיקות וה-review מכסים את הגרסה העדכנית. שינוי משמעותי יכול לדרוש בדיקה ואישור מחדש.