איך לבדוק קוד שסוכן AI כתב: מדריך בחמישה שלבים

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

נקודת המוצא היא המדריך Agentic Engineering in Python: From Vibes to Evidence, שפרסם Ben Batman ב־Real Python ב־14 בספטמבר 2026. הוא עוסק במשימה מוגבלת, בדיקות וסקירת שינויים בשיטת RECAP, באמצעות ייבוא נתונים מ־CSV. השלבים, חוזה ההתנהגות וקוד הבדיקה שלפניכם הם עיבוד מעשי שלנו לרעיון, לא העתקה של הדוגמה המקורית או פירוט של השיטה.

011. מגדירים משימה קטנה וגבולות ברורים

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

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

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

022. כותבים חוזה שאפשר לבדוק

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

• הפונקציה תיקרא load_customers, תקבל זרם טקסט ותחזיר רשימת מילונים.
• עמודות החובה הן customer_id ו־name; עמודה חסרה תגרום ל־ValueError.
• מזהה הלקוח יישאר מחרוזת, כולל אפסים מובילים.
• שם ריק או שמכיל רווחים בלבד יגרום ל־ValueError, בלי לדלג בשקט על הרשומה.
• קובץ שמכיל כותרות בלבד יחזיר רשימה ריקה; כפילויות מזהים יידחו ב־ValueError.
• הפונקציה לא תשנה קבצים, לא תכתוב למסד נתונים ולא תפנה לרשת.

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

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

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

from io import StringIO

import pytest
from importer import load_customers


def test_preserves_id_and_hebrew():
    source = StringIO("customer_id,name\n00123,נועה\n")
    assert load_customers(source) == [
        {"customer_id": "00123", "name": "נועה"}
    ]


@pytest.mark.parametrize("csv_text", [
    "customer_id\n00123\n",
    "customer_id,name\n00123,   \n",
])
def test_rejects_invalid_input(csv_text):
    with pytest.raises(ValueError):
        load_customers(StringIO(csv_text))

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

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

044. סוקרים את ה־diff ואת אמינות הבדיקות

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

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

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

055. מאשרים גרסה מסוימת עם ראיות ומגבלות

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

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

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