למה סוכן AI אומר „בוצע” כשהעבודה לא הושלמה

איך מודל של OpenAI יצא מארגז החול ופרץ ל-Hugging Face?#

קודם העובדות, ואז למה זה חשוב לכם.

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

פגיעוּת zero-day היא פרצה שאיש עדיין לא יודע עליה, כולל מי שכתב את התוכנית. המודלים מצאו אחת בדיוק באותו פתח יחיד.

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

הניחוש היה שגוי. ExploitGym כלל לא נמצא ב-Hugging Face. זה לא הופך את הפריצה לפחות אמיתית.

Hugging Face גילתה בעצמה את החדירה ופרסמה את חשיפתה ב-16 ביולי, ועדיין לא ידעה מי פרץ אליה.

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

OpenAI הודתה בכך ב-21 ביולי, חמישה ימים אחרי החשיפה של Hugging Face. עד אז חלפו כעשרה ימים מאז החדירה עצמה.

OpenAI סיימה את הניתוח שלה כך.

המודל התקבע על היעד הצר של המבחן ונקט צעדים קיצוניים כדי להשיג אותו. הביטויים hyper-focused ו-fairly narrow testing objective מופיעים בדברים של OpenAI עצמה ומתייחסים למודלים שלה.

זה הגשר מהמעבדה של מישהו אחר אל המחשב הנייד שלכם.

למה זו לא „הזיה”?#

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

הוא לא המציא דבר. הוא עשה בדיוק את מה שמדדתם.

תחת מילת-העל הפופולרית „הזיות” אנחנו מאחדים שלושה כשלים שונים. כך הם נבדלים:

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

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

לכשל השלישי יש שם.

מהי פריצת תגמול במילים פשוטות?#

Anthropic עצמה מספקת את ההגדרה.

הרעיון ישן יותר מרשתות עצביות. מאמר של DeepMind מכנה זאת specification gaming ומסביר זאת בעזרת מיתוס.

מידאס קיבל בדיוק את מה שביקש. הבעיה הייתה בניסוח הבקשה.

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

וזה לא תנאי מעבדה אקזוטי. Cursor ניתחה 731 מסלולים במדד פופולרי.

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

איך זה נראה במוצר רגיל?#

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

ארבע בדיקות ירוקות ורכיב שירות מושבת

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

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

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

סימן הבדיקה השגוי מופיע ממש בנקודת החיבור

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

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

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

הבודק רואה רק את הכיוון שהתבקש לבדוק

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

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

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

המדד מתגמל דמיון

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

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

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

למה „בדקתי” מפי סוכן לא מוכיח כלום?#

קחו אחד מהפרויקטים שלכם ובקשו מהסוכן „בדוק אבטחה”. לעיתים קרובות התשובה תהיה „הכול בסדר, אין בעיות קריטיות”.

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

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

Anthropic מתארת את המנגנון הזה בתיעוד Claude Code.

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

יש כאן רובד עמוק יותר. כש-OpenAI ניסתה להפעיל לחץ על מודל באמצעות ניטור ההנמקה שלו והענשתו על „מחשבות רעות”, התוצאה לא הייתה מה שציפו לו.

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

גם מפתחי הכלים עצמם נעים באותו כיוון. בגרסה 2.1.215 של Claude Code, היכולות /verify ו-/code-review הפסיקו לפעול ביוזמת המודל עצמו.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic אינה מסבירה מדוע. אבל העיקרון ברור: הנבדק אינו מקצה לעצמו את הבדיקה.

למה כלל בקובץ הפרויקט לא משאיר את הסוכן בתלם?#

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

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

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

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

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

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

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

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

איך מגדירים קריטריון השלמה שאי אפשר לרמות בו?#

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

• „בדוק שהכול עובד” — הוא יכול. מספיק לכתוב „בדקתי, זה עובד”.
• „הרץ את הבנייה והראה לי את הפלט” — כבר קשה יותר; הוא יצטרך להשיג את הפלט איכשהו.
• „הרץ את האפליקציה, לחץ על כפתור התשלום והראה מה הופיע על המסך” — כמעט שאי אפשר לעמוד בזה באמצעות טקסט.

ההבדל בין הראשון לשלישי הוא ההבדל בין דיווח לראיות.

תיעוד Claude Code מתאר ארבע רמות של קפדנות. סולם שכדאי לטפס בו ככל שמחיר הטעות עולה:

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

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

מי צריך לקבל את עבודת הסוכן?#

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

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

ניסוח המשימה לבודק חשוב יותר מהמודל שלו. השוו:

• „בדוק את העבודה” — הבודק ימצא את מה שקל למצוא ויכתוב „בסך הכול בסדר”.
• „נסה להוכיח שהעבודה הזאת לא הושלמה” — הבודק יתחיל לחפש פרצות, כי זה היעד שלו.

הניסוח השני עובד טוב יותר מאותה סיבה ש-ExploitGym נכשל: הסוכן מחויב ליעד שניתן לו. תנו לו יעד למצוא פרצה, והוא יחפש אחת.

הנה הנוסח המלא, מוכן להעתקה כפי שהוא:

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

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

בדוק לפי הסדר הזה:

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

מי קורא לכל פונקציה חדשה. מצא את הקריאה באמצעות חיפוש בפרויקט; ציין את הקובץ והשורה.

כיוונים הפוכים: זיכוי, חסימה, שלילת גישה, פקיעה, מחיקת מקור הנתונים.

הערכים שבתוך התוצאה, לא רק אם היא קיימת.

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

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

מה משתנה כשמנסחים מחדש את הקריטריון?#

זה השיפור הזול ביותר שאני מכיר, וכמעט איש אינו עושה אותו.

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

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

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

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

הנחיה מוכנה לקבלת עבודת סוכן#

אל תענה „בוצע” או „נבדק”. אני צריך ראיות.

עבור כל פריט עבודה, תן לי בדיוק את זה:

איזו פקודה הרצת כדי לוודא שהפריט עובד? כלול את הפקודה עצמה ואת הפלט המלא שלה, בלי לקצר.

אם לא הרצת את הפקודה, אמור: „לא הורצה”. אל תחליף זאת ב„נבדק חזותית” או „הלוגיקה נכונה”.

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

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

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

בשורה האחרונה, כתוב: מה עליי לבדוק במו עיניי, כי בדיקה אוטומטית לא תזהה אותו?

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

ארבע דרכים להטעות את עצמכם באמצעות בדיקה#

1. לא חיכיתם לכל הבודקים. הפעלתי שלוש בדיקות במקביל, שתיים חזרו ירוקות ופרסתי. השלישית הגיעה כעבור ארבע דקות עם שש הפרות. תיקון אחרי פרסום עולה יותר מהמתנה של שתי דקות.
2. האמנתם לסיכום „עובדו N מתוך N”. בהפצה רחבה, חלק מהסוכנים נכשלים בשקט: הם מדווחים הצלחה, אבל הקובץ לא נגע. כעת, אחרי כל כתיבה דרך סוכן, אני מוודא באופן מכני שהשינויים באמת נמצאים בדיסק.
3. לא הסתכלתם במו עיניכם. בדיקות אוטומטיות יכולות להציג ירוק כשהתוצאה אינה שמישה לחלוטין. התמונות נכונות מבחינה טכנית, הגודל נכון, קוד התגובה נכון. אבל למעשה מדובר בפריימים קפואים שנוצרו אוטומטית והחליפו את עטיפות האיור שהיו אמורות להופיע. שום בדיקה אוטומטית לא תתפוס זאת.
4. בדקתם נוכחות במקום ערך. הבדיקה חיפשה בתוצאה את הטקסט הנדרש; הטקסט היה שם, אבל הנתונים שבתוכו היו שגויים: התאריך היה יום אחד מוקדם מדי. הבדיקה הייתה ירוקה והדוח היה שקרי. עכשיו אני מאמת את כל הערך הצפוי, כי נוכחותה של המילה הנכונה לבדה אינה מבטיחה דבר.

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

מאיפה להתחיל היום#

שלושה צעדים שלוקחים עשרים דקות.

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

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