איך לתת לסוכן התכנות ה-AI שלכם 'הגדרת סיום' ברורה

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

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

קריטריוני קבלה מול הגדרת סיום

שני רעיונות קשורים, שכדאי להפריד ביניהם:

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

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

הפכו את זה לבר-בדיקה, לא לשאיפתי

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

• שליחת פרטי התחברות תקינים מנתבת אל /dashboard בתוך 500ms
• שליחת סיסמה שגויה מציגה שגיאה מוטבעת ואינה מנווטת הלאה
• שליחת שדה ריק נחסמת בצד הלקוח לפני כל בקשת רשת
• התחברויות שנכשלו מוגבלות בקצב ל-5 ניסיונות לדקה לכל IP

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

דוגמה קונקרטית

השוו בין שני הפרומפטים האלה לאותה משימה.

מעורפל:

הוסף דרך למשתמשים לאפס את הסיסמה שלהם.

עם הגדרת סיום:

הוסף תהליך איפוס סיסמה. סיום פירושו:

• נקודת קצה POST /auth/reset-request מקבלת אימייל ותמיד מחזירה 200 (לעולם אל תחשוף אם האימייל קיים)
• טוקן חתום, לשימוש חד-פעמי, בתוקף לשעה, נשלח באימייל דרך ה-mailer הקיים ב-src/lib/mail.ts
• POST /auth/reset-confirm מאמת את הטוקן, אוכף את מדיניות הסיסמאות הנוכחית, ומבטל את הטוקן לאחר השימוש
• בדיקות מכסות: איפוס תקין, טוקן שפג תוקפו, טוקן שנעשה בו שימוש חוזר, אימייל לא ידוע
• אין תלויות חדשות מבלי לסמן אותן קודם

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

חברו את ה'סיום' ללולאת הסוכן

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

לכן אל תסתפקו בתיאור הסיום — תנו לסוכן דרך לבדוק אותו:

• הפנו אותו לפקודת הבדיקה (npm test, pytest) ואמרו לו שהפיצ'ר אינו גמור עד שהן עוברות.
• לדברים שקשה לוודא בקוד — קריאוּת, עמידה בדפוס קיים — השתמשו במעבר של LLM-as-a-judge: פרומפט שני שסוקר את הפלט מול רף האיכות שלכם. Anthropic ואחרים מצאו שזה אפקטיבי לבדיקות סובייקטיביות.
• שמרו אבטחה ו"אין קוד placeholder/mock" בהגדרת הסיום הכלל-פרויקטלית שלכם כך שזה יחול על כל שינוי, לא רק על אלה שאתם זוכרים להזכיר.

שימו את זה במקום שהסוכן יראה

כתבו את הגדרת הסיום הכלל-פרויקטלית שלכם פעם אחת, בקובץ שהסוכן קורא באופן אוטומטי — AGENTS.md או CLAUDE.md בשורש המאגר. קריטריוני קבלה ספציפיים לפיצ'ר נכנסים לפרומפט המשימה עצמו. כך "הסטנדרט שלנו" תמיד נמצא בהקשר, ואתם צריכים לפרט רק את מה שייחודי לעבודה של היום.

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