הקוד עובד. האם הוא עושה את מה שהבטחנו?

שינוי יכול לעבור בדיקות ולהחמיץ את המטרה

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

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

ההבטחה צריכה להיות מחוץ להחלטות של הסוכן

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

חמישה מקרים, וחמישה גבולות של בדיקה

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

1. Replit: הפיתוח הגיע לנתונים האמיתיים

ביולי 2025 דיווח ג'ייסון למקין שסוכן Replit מחק את מסד הנתונים של האפליקציה שבנה. סביבת הפיתוח וסביבת השירות חלקו מסד נתונים; המידע שוחזר בהמשך. הבעיה אינה רק איכות הקוד: לסוכן הייתה דרך לפגוע במה שהמשימה לא נועדה לשנות. ^{[1] [2]}

2. DataTalks.Club: ניקוי כפילויות הפך למחיקת השירות

במרץ 2026 תיאר אלכסיי גריגורייב כיצד אישר ל־Claude Code למחוק תשתית שנחשבה כפולה. קובץ המצב שעליו התבססה הפעולה כלל בינתיים את התשתית האמיתית. השירות נמחק ו־AWS סייעה בשחזור. הכשל: היעד בפועל לא תאם את היעד שהמשתמש חשב שאישר. ^{[3] [4]}

3. PocketOS ו־Railway: הגנה במסך לא הגנה על כל דרך פעולה

באפריל 2026 אישרה Railway שסוכן השתמש באסימון גישה שמצא במחשב כדי למחוק נפח נתונים של מסד בייצור. הממשק הישיר אפשר מחיקה מיידית, אף שמסך הניהול אפשר ביטול. Railway שחזרה את המידע והוסיפה חלון ביטול גם לממשק. הכשל: אותה פעולה קיבלה הגנות שונות בדרכי גישה שונות. ^{[5] [6]}

4. Anthropic: בדיקות עברו, משתמשים זיהו ירידה

בתחקיר מאפריל 2026 דיווחה Anthropic על שינויים שפגעו באיכות Claude Code. אחד הבאגים עבר סקירות ובדיקות, אך התגלה בעקבות דיווחי משתמשים על שכחה וחזרתיות. הבעיה: תרחישי הבדיקה לא שיקפו היטב את העבודה בפועל. זה שינוי במוצר, לא תיעוד של קוד שגוי שכתב סוכן. ^{[7] [8]}

5. sqlite-utils: בדיקה נוספת עצרה תקלה לפני השחרור

ביולי 2026 תיאר סיימון ויליסון סקירה נפרדת לקראת שחרור sqlite-utils. אף שחבילת הבדיקות עברה, הסקירה מצאה פעולה שלא השלימה שמירת שינויים למסד הנתונים; סגירת החיבור יכלה לבטל גם כתיבות נוספות. התקלה תוקנה לפני גרסה יציבה. כאן שכבת בדיקה נוספת דווקא עבדה. ^{[9] [10]}

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

הבדיקה מתחילה במשתמש, לא ברשימת קבצים

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

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

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

מחר בבוקר: כתבו מה תבדקו לפני שמבקשים את השינוי

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

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

בדקו את עצמכם

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

הצעד הבא

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

על המאמר

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