למה הבדיקה חשובה

עוזרי קוד מבוססי AI מאפשרים לעיתים קרובות לצוותים להניח קובץ "כללים" (rules) בתוך ה-repo ולצפות שהמודל יציית להנחיות שלו בכל בקשה. בפועל, המודל עשוי לעולם לא לראות את הקובץ, או שהוא עשוי לראות אותו אך להתעלם מתכניו. ניסוי שנערך לאחרונה עם Claude Code הראה את שתי הבעיות הללו. הכלי דילג בשקט על קובץ AGENTS.md בגודל 72KB; כאשר אותו קובץ שונה שמו ל-CLAUDE.md, העוזר טען אותו והגדיל את ספירת הטוקנים (token count) בכל בקשה. תקציב הטוקנים הנוסף הזה מנפח את השיהוי (latency), את העלות, ויכול לדחוף בקשה מעבר למגבלת המודל.

מפתחים שמניחים ש"קיום הקובץ" שווה ל"המודל פועל לפי הכללים" מסתכנים בחוסר יעילות נסתר ובפלט בלתי צפוי. הבדיקה בת שלושת השלבים מחייבת הוכחה קונקרטית בכל שלב: הגדרה (configuration), טעינה (loading), ותועלת (usefulness).

שלוש השאלות שיש לשאול

  1. Configured (מוגדר) – האם הקובץ ממוקם במקום שבו העוזר מחפש אותו? כלים שונים מקבעים (hard-code) נתיבים או מוסכמות שמות קבצים; חוסר התאמה אומר שהקובץ לעולם לא ייכנס לשרשרת ה-prompt.
  2. Loaded (נטען) – האם העוזר מציג הוכחה כלשהי לכך שהוא קיבל את הקובץ? Hash יכול לאשר את זהות הקובץ בדיסק, אך רק עקבות של מסירה (למשל, שורת לוג או ספירת טוקנים) מוכיחים שהמודל אכן הבחין בו.
  3. Useful (מועיל) – האם נוכחות הקובץ משפרת את תוצאת המשימה? קובץ שנטען ומוסיף טוקנים אך משאיר את התוצאה ללא שינוי הוא הפסד נטו.

הרצת הבדיקה

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

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

  2. בדוק את גרסת הכלי ואת המודל – פתח סשן חדש, רשום את מחרוזת הגרסה (version string) ואת מזהה המודל. גרסאות שונות עשויות לשנות את שם הקובץ שהן מזהות.

  3. בצע שתי הרצות הרצה A: השתמש בשם קובץ שהכלי לא מזהה (למש למשל, AGENTS.md). הרצה B: השתמש בשם הקובץ המקורי (native) של הכלי (למשל, CLAUDE.md).

    רשום:

    • את ה-hash המקור של הקובץ (כדי להוכיח שהתוכן בדיסק לא השתנה).
    • את הנתיב המדויק שבו נעשה שימוש.
    • כל ראיה שהעוזר תיעד לגבי טעינת הקובץ (עלייה בספירת הטוקנים, הודעה מפורשת כמו "loaded X.md", וכו').
    • את ספירת הטוקנים עבור כל בקשה.
    • את תוצאת המשימה (האם העוזר רשם בדיוק שני קבצים?).

אם הרצה B מראה שהכלל מבוצע וספירת הטוקנים עולה בכמות המצופה, הקובץ נטען וגם מועיל. אם הכלל זוכה להתעלמות למרות העלייה בטוקנים, הקובץ נקרא אך ניתוח ה-prompt של המודל משליך את ההנחיה. במקרה כזה, הוספת טקסט נוסף לקובץ לא תעזור; במקום זאת, העבר את הכלל לשער מדיניות (policy gate) מקודד או למסגרת בדיקה (test harness).

מה הנתונים חושפים

המקרה של Claude Code הדגים פער חריף בין הגדרה לטעינה. הקובץ בגודל 72KB היה קיים, בעל ה-hash הנכון וסונכרן ל-repository, ובכל זאת העוזר מעולם לא התייחס אליו. שינוי שם הקובץ ל-CLAUDE.md המקורי גרם לטעינה, אך הוסיף גם עומס טוקנים משמעותי. כל טוקן נוסף צורך מחזורי חישוב ויכול לדחוף את הבקשה מעבר למגבלות קצב (rate limits).

הבדיקה בת שלושת השלבים חושפת עלויות נסתרות כאלה לפני שהן הופכות לחוסמי ייצור (production blockers). על ידי מדידת הפרש הטוקנים (token delta), צוותים יכולים להחליט האם התועלת מהכלל עולה על המחיר שלו.

שורה תחתונה

לעולם אל תניחו שקובץ כללים מבצע עבודה רק בגלל שהוא נמצא ב-repo. השתמשו בבדיקה בת שלושת השלבים — הגדרה, טעינה, והוכחת תועלת — כדי להפוך את ההנחה הזו לראיה מדידה. כאשר ההוכחה מראה שהקובץ הוא רק "בור טוקנים" (token sink), העבירו את הלוגיקה מחוץ ל-prompt אל שער דטרמיניסטי. התוצאה היא תזרים עבודה (workflow) של כתיבת קוד ב-AI שהוא רזה יותר, מהיר יותר וצפוי יותר.