איך לבקר pull request שסוכן ה-AI שלכם כתב

סוכני קוד מבוססי AI כבר לא רק מציעים קוד — הם פותחים pull requests. בצוותים רבים, מהנדס יחיד מפקח כיום על עשרות PRs שכתבו סוכנים מדי יום, וצוואר הבקבוק עבר בשקט מכתיבת קוד לביקורת שלו. המיומנות שמגינה על בסיס הקוד שלכם כבר אינה "האם אתם יודעים לתת הנחיה לסוכן" — אלא "האם אתם יודעים לבקר את מה שהסוכן מחזיר".

הבעיה היא שה-PRs של סוכנים נכשלים בדרכים שונות מאלה של בני אדם. מחקר מינואר 2026 מצא ששינויים שנוצרו על ידי סוכנים נושאים יותר יתירות ויותר חוב טכני לכל שינוי בהשוואה לקוד שנכתב בידי אדם. לכן אי אפשר לבקר אותם על טייס אוטומטי. הנה שגרה מעשית, השאובה במידה רבה מהמדריך של GitHub עצמה על ביקורת pull requests של סוכנים.

בדקו קודם את השינויים ב-CI

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

• בדיקות שהוסרו, שונה שמן או דולגו
• ספי כיסוי שהונמכו
• שלב lint או בדיקת טיפוסים שסונן בשקט מאחורי תנאי חדש
• || true שהוצמד לפקודת בדיקה או בנייה כך שהיא תמיד "עוברת"
• workflows שהושבתו ב-pull requests או ב-forks

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

צודו קוד משוכפל

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

עקבו אחר הנתיב הקריטי ידנית

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

• תנאי קצה: אפס, ריק, מקסימום, null
• בדיקות הרשאה בכל ענף, לא רק בנתיב התקין
• מצבי תחרות (race conditions) כשמצב משותף

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

דוגמה מוחשית. סוכן "מתקן" endpoint של הנחה וכל הבדיקות עוברות. אתם עוקבים אחר הנתיב ושמים לב שהקוד החדש קורא את cart.items לפני שהוא בודק if (!cart) return. אצל משתמש לא מחובר, cart הוא null והנתיב זורק שגיאת 500 — מקרה שהסוכן מעולם לא בדק כי הוא רץ רק על הנתיב התקין. שתי דקות של מעקב ידני תפסו את מה שסימן הווי הירוק הסתיר.

דחו מוקדם כשה-PR גדול מדי

לא כל PR של סוכן ראוי לביקורת מעמיקה. החזירו אותו לבקשת PR קטן יותר אם הוא:

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

PRs גדולים וחסרי תוכנית נוטים ממילא להוביל לשום מקום. לבקש היקף מוגדר מראש מהיר יותר מאשר להתיר diff מסועף מאוחר יותר.

תנו לאוטומציה לבצע את המעבר המכני

השתמשו במבקר אוטומטי — הביקורת של Copilot, Bugbot של Cursor, Greptile או דומיהם — כתנאי מקדים, לא כתחליף. תנו לו לתפוס דקדוקי סגנון, שגיאות ברורות וטיפול חסר בשגיאות, כך שתשומת הלב שלכם תהיה פנויה להכרעות שמודל אינו יכול לעשות: התאמה ארכיטקטונית, נכונות עסקית ואבטחה. הכלים האלה גם מתגמלים על הגדרות: כללים מותאמים אישית הבנויים סביב תקני הקידוד והמדיניות של הריפוזיטורי שלכם מפיקים משוב שימושי הרבה יותר מברירות המחדל.

רשימת תיוג של 10 דקות

עבור PR בעל היקף מוגדר היטב, כל השגרה הזו נכנסת בערך בעשר דקות:

1. סריקה וסיווג (1–2 דקות) — תיקון צר או שינוי מסועף?
2. diff של CI (2–3 דקות) — סמנו כל דבר שמחליש את הבדיקות.
3. פונקציות עזר חדשות (3–5 דקות) — חפשו כפילויות.
4. נתיב קריטי (5–8 דקות) — עקבו אחר הלוגיקה בעצמכם.
5. אבטחה (8–9 דקות) — בדקו סודות, טוקנים וכל שלב עם LLM בלולאה.
6. ראיות (9–10 דקות) — דרשו בדיקה שנכשלת-ואז-עוברת עבור שינויי לוגיקה.

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