העבודה של העמית נראית מושלמת, אבל משהו חסר: איך לבדוק תוצרי AI ולתת משוב בלי לריב

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

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

1. שיטת בדיקה מהירה שמבוססת על Claude ו-GPT-6 ומגיעה לממצאים ממשיים תוך 10–20 דקות, בלי קריאה מלאה ומייגעת.
2. פרומפטים מוכנים להעתקה לכל סוג תוצר: מסמך, מצגת וקוד.
3. דרך לתת משוב שמתמקדת בתוצר ולא בשאלה “זה נכתב עם AI?”, ולא מציבה אתכם בתפקיד השוטר של הצוות.

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

למה תוצרי AI “ריקים” קשים כל כך לזיהוי

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

אלה הסימנים הנפוצים של תוצר מלוטש וריק:

• טענות שמתאימות לכל ארגון. “חשוב לשים את הלקוח במרכז”, “יש לאזן בין מהירות לאיכות”. אם אפשר להעתיק את המשפט למסמך של חברה מתחרה בלי לשנות מילה, הוא לא אומר כלום.
• מספרים בלי מקור. “שיפור של 30% ביעילות”, “70% מהלקוחות מעדיפים”. מאיפה זה הגיע?
• חוסר בהחלטות ובוויתורים. מסמך אמיתי אומר “נעשה X ולכן לא נעשה Y”. מסמך ריק ממליץ לעשות הכול.
• התעלמות מההקשר המקומי. אין אזכור של המערכות, הלקוחות, התקציב או הדדליין שלכם.
• בקוד: טיפול בשגיאות שנראה מקיף אבל בולע חריגות, בדיקות שבודקות את ה-mock במקום את הלוגיקה, קריאות ל-API או לפרמטרים שלא קיימים בגרסה שבה אתם עובדים, ותיעוד שמתאר מה הקוד “אמור” לעשות ולא מה הוא עושה בפועל.

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

שלב 1: לפני שפותחים AI, שלוש דקות של הגדרת מטרה

הטעות הראשונה היא להדביק את המסמך ב-ChatGPT ולבקש “תבדוק אם זה טוב”. המודל לא יודע מה נחשב טוב אצלכם, אז הוא ימציא קריטריונים כלליים ויחזיר ביקורת כללית באותה מידה.

לפני הכול, כתבו לעצמכם שלוש שורות:

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

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

שלב 2: בדיקת השלד, מה חסר

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

פרומפט לבדיקת חוסרים במסמך או מצגת:

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

אל תסכם את המסמך ואל תשפר את הניסוח.
במקום זה:
1. כתוב אילו 5-7 שאלות מקבל החלטות היה חייב לקבל עליהן תשובה כדי לאשר או לדחות את ההצעה.
2. לכל שאלה ציין: האם המסמך עונה עליה (כן / חלקית / לא), ואם כן — צטט את המשפט הרלוונטי.
3. סמן משפטים שהם "גנריים" — כאלה שהיו מתאימים באותה מידה לכל ארגון אחר.
4. ציין אילו החלטות או ויתורים (trade-offs) המסמך נמנע מלקבל.

המסמך:
[הדבקה]

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

למצגות: אם העמית שלח קובץ PowerPoint או PDF, אפשר להעלות אותו ישירות ל-Claude, ל-ChatGPT או ל-Gemini, שכולם מקבלים קבצים. הוסיפו לפרומפט:

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

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

שלב 3: בדיקת אמת, מה הומצא

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

העיקרון: לא מבקשים מהמודל לאמת, מבקשים ממנו לחלץ. מודל שמתבקש “לבדוק אם הנתון נכון” עלול לאשר אותו בביטחון מלא. מודל שמתבקש לחלץ את כל הטענות שדורשות אימות עושה עבודה שהוא באמת טוב בה.

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

עמודות:
| הטענה (ציטוט מדויק) | סוג (נתון / מקור / ציטוט / שם) | האם המסמך מציין מקור? | רמת סיכון אם שגוי (גבוהה/בינונית/נמוכה) | איך הייתי מאמת |

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

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

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

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

לקוד, הגרסה המקבילה:

אתה סוקר קוד קפדן. הקוד הבא נכתב לפרויקט [שפה + פריימוורק + גרסה, למשל: Python 3.12, Django 5, PostgreSQL].

1. פרט כל קריאה לספרייה חיצונית או ל-API, ולכל אחת ציין: האם אתה בטוח שהפונקציה והפרמטרים קיימים בגרסה הזו? אם לא בטוח — כתוב "לבדוק" ולא לנחש.
2. מצא מקומות שבהם חריגות נבלעות (except כללי, catch ריק, החזרת None בשקט).
3. עבור כל בדיקה (test): האם היא נכשלת אם מוחקים את הלוגיקה שהיא אמורה לבדוק? אם לא — סמן אותה כ"בדיקה ריקה".
4. מצא הערות או docstrings שמתארים התנהגות שהקוד לא מממש בפועל.

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

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

שלב 4: בדיקת התאמה, מה לא מתאים לכם

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

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

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

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

שלב 5: מממצאים למשוב, בלי להאשים

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

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

מבנה משוב שעובד:

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

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

על סמך הממצאים הבאים, נסח משוב לעמית בעברית, בהודעת Slack אחת (עד 150 מילים).

כללים:
- פתח בדבר אחד חיובי וספציפי.
- בחר רק את 3 הממצאים החשובים ביותר מבחינת ההחלטה שהמסמך אמור לאפשר.
- נסח כל ממצא כשאלה או בקשה קונקרטית ("מאיפה הגיע הנתון של 30%?" ולא "הנתון לא מבוסס").
- אל תזכיר AI, כלים, או איך המסמך נכתב.
- אל תשתמש בביטויים כמו "נראה ש..." או "אולי כדאי לשקול" — היה ישיר וחם.
- סיים בצעד הבא ברור.

הממצאים:
[הדבקת הממצאים משלבים 2-4]

דוגמה לתוצאה טובה:

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

1. הנתון על חיסכון של 30% בעלויות: מאיפה הוא? אם זה מהספק עצמו, כדאי לציין.
2. חסרה לי התייחסות למה שקרה במיגרציה ב-2024. ההנהלה תשאל על זה ראשון.
3. ההמלצה כוללת צוות DevOps ייעודי, ואין לנו כזה. אפשר להתאים את התוכנית לצוות הנוכחי? יש לך זמן לעבור על זה ביחד מחר ב-10?

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

איך לא להפוך למסננת של הצוות

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

כמה דרכים למנוע את זה:

• שתפו את הפרומפטים. הפרומפטים מהמדריך הזה הם לא סוד מקצועי. שימו אותם במסמך משותף של הצוות, ובקשו שכל אחד יריץ אותם על התוצר שלו לפני השליחה. ככה הבדיקה עוברת מכם אל הכותב.
• הגדירו “הגדרת מוכנות” (Definition of Ready) לתוצרים. למשל: כל נתון מגיע עם מקור, כל מסמך החלטה כולל פסקה של “מה לא נעשה ולמה”, כל PR כולל בדיקה שנכשלת כשמוחקים את הלוגיקה. כשיש כללים כתובים, המשוב שלכם הוא הפניה לכלל ולא דעה אישית.
• בקשו מהכותב לצרף “הצהרת בדיקה” קצרה: מה בדק בעצמו, מה לא הספיק לבדוק, ובמה הוא לא בטוח. זה לא נועד להאשים. זה נותן לכם מפה של המקומות שבהם כדאי להתמקד.
• הגבילו את עצמכם בזמן. קבעו לעצמכם 20 דקות לבדיקה. אם צריך יותר, התוצר לא בשל לריוויו ומחזירים אותו עם בקשה אחת: “תעבור עליו עם הצ’קליסט ותחזיר”.
• סובבו את תפקיד הבודק. בצוות של 5 ומעלה, כדאי שבכל שבוע אדם אחר יהיה אחראי על ריוויו. כך כולם לומדים לזהות תוצרים ריקים, ואף אחד לא נשחק.

טעויות נפוצות

1. לבקש מהמודל “לבדוק אם זה נכתב ב-AI”. מזהי AI לא אמינים, ומודלי שפה עוד פחות אמינים בשאלה הזו. חוץ מזה, התשובה לא רלוונטית. שאלו אם זה טוב, לא איך זה נוצר.

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

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

4. לסמוך על אימות של המודל. “בדקתי ב-Claude והוא אמר שהנתון נכון” זו לא בדיקה. מודל יכול לאשר נתון מומצא בביטחון מלא. אימות אמיתי הוא מקור ראשוני שאתם רואים בעיניים.

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

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

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

סיכום וצ’קליסט התחלה

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

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

צ’קליסט לבדיקה הבאה שלכם:

• כתבתי שלוש שורות: למה התוצר קיים, מה המודל לא יודע, מה בלתי קביל
• הרצתי פרומפט חוסרים עם דרישה לציטוטים, ובדקתי שהציטוטים אמיתיים
• חילצתי טבלת טענות עובדתיות ואימתי ידנית את 3–5 המסוכנות ביותר
• (בקוד) בדקתי קריאות API מול הגרסה שלנו ואיתרתי בדיקות ריקות
• הכנסתי את האילוצים שלנו ובדקתי הנחות סמויות
• הרצתי לפחות שלב אחד בשני מודלים שונים
• בחרתי עד שלוש נקודות למשוב, מנוסחות כשאלות, בלי אזכור של AI
• שקלתי אם זה מתאים להודעה או מצריך שיחה
• הוספתי את הפרומפטים למסמך המשותף של הצוות כדי שבפעם הבאה הכותב יריץ אותם בעצמו
• עמדתי ב-20 דקות, ואם לא, החזרתי את התוצר לסבב בדיקה עצמית

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