המערכת נראית מוכנה ולא עובדת? ככה מגלים קוד דמה של סוכן AI

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

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

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

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

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

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

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

מה זה קוד דמה (stub), ולמה הוא נראה כמו עבודה גמורה

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

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

יש גם אח קרוב: אינטגרציה מדומה (mock integration). זה קוד שמתנהג כאילו הוא מדבר עם שירות חיצוני, מודל תמונות, מערכת סליקה או כל API אחר, ובפועל לא שולח לשם כלום. מבחוץ אי אפשר לראות את ההבדל. מבפנים, הצינור מדבר עם עצמו.

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

הערה שאומרת דבר אחד וקוד שעושה אחר

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

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

אלה סימנים שכדאי לחפש כשקוראים קוד של סוכן, כשיטה כללית ולא רק מהמקרה שלי:

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

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

איך מגלים: בדיקה מקצה לקצה על קלט אמיתי

בדיקה מקצה לקצה (end-to-end, או QA מקצה לקצה) פירושה להכניס קלט אמיתי בצד אחד של המערכת ולבדוק את מה שיוצא בצד השני, בלי לדלג על אף שלב. היא לא בודקת אם כל חלק נראה תקין לבד. היא בודקת אם הדבר עובד.

להריץ קלט אחד אמיתי דרך כל הצינור

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

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

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

לקרוא את התוצאה ולא את הדוח של הסוכן

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

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

מה סוכן צריך להראות לפני שהוא אומר "הושלם"

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

כשיטה, אלה הדברים שכדאי לדרוש מסוכן בסוף כל משימה שיש בה שלב מרכזי:

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

את ההוראות האלה כדאי לכתוב בקובץ ההוראות הקבוע שהסוכן קורא בתחילת כל סשן, כלומר בכל פעם שעבודה חדשה נפתחת. ב-Claude Code זה קובץ CLAUDE.md. משפט אחד שם, נניח "אסור להשאיר stub בלי לסמן אותו בדוח", משנה את מה שחוזר אליך.

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

שאלות נפוצות

מה זה קוד דמה (stub) בעבודה של סוכן AI?

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

איך מגלים שמערכת שנבנתה ב-AI לא באמת עובדת?

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

אפשר לבדוק את זה בלי לדעת לקרוא קוד?

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

למה בדיקות אוטומטיות לא תופסות stub?

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

למה סוכן מזייף שלב?

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