סוכן כותב את הקוד — מי בודק את עבודתו?

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

ב-4 בפברואר 2026 הודיעה GitHub על השקת גרסת תצוגה ציבורית של Claude ו-Codex כסוכני קידוד. החברה מסרה שאפשר להקצות לסוכנים משימות מתוך issues ובקשות משיכה, ולאחר מכן לבדוק את טיוטת ה-PR שהכינו. הדבר מאשר שתהליך עבודה כזה הופיע בממשק הפיתוח, אך אינו מוכיח חיסכון בזמן או שיפור באיכות הקוד.

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

פיקוח הוא לא רק בדיקה בסוף

במאמר קדם שפורסם ב-arXiv ב-21 בספטמבר 2026, מציעים החוקרים להתייחס לפיקוח על סוכן קידוד כתהליך רציף. העבודה The Work Behind Delegation מבוססת על תצפיות ומיפוי תהליכי עבודה של 19 מפתחים מנוסים. המחברים מתארים שבעה שלבים של פיקוח ומיישמים את המסגרת הזו על דיונים ציבוריים של מפתחים ב-Reddit.

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

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

ניסיון של הקהילה אינו נתונים סטטיסטיים

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

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

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

טיוטת PR אינה PR שאושר

בתרחיש שתואר ב-GitHub, אפשר להקצות לסוכן issue ולקבל טיוטת בקשת משיכה. בין יצירתה לבין קבלתה נותרות שאלות נפרדות: האם השינוי תואם לדרישות, האם נלקחו בחשבון מקרי קצה, האם יש מספיק בדיקות והאם הפתרון מתאים לארכיטקטורה של הפרויקט.

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

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

מה אפשר להסיק

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

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

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