אתגר ראשון: סוכן בלי גבולות

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

התרחיש מגדיר מצב ללמידה

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

שדה חובה משאיר החלטות פתוחות

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

הגבול כולל הסבר ושמירת קלט

הצורך שנבחר הוא לאפשר לנטע להוסיף תאריך לפני שהיא שולחת. מכאן נגזור גבול שינוי: מטפלים בניסיון שליחה כאשר התאריך חסר. הטיפול כולל הסבר שאפשר להבין ושמירה של המידע שכבר הוזן. מילוי תאריך בשם נטע אינו נכלל בשינוי; זה נושא שנשאר מחוץ לשינוי (Non-goals). כך יש לנו יעד מוגדר שאפשר לדון בו ולבדוק אותו.

רעיון המשך אינו חלק מהשינוי הנוכחי

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

האחריות המוצרית נשארת אצלכם

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

גישה לקוד אינה הכרעה מוצרית

הנחיות GitHub לסוכן שלה ממליצות להגדיר משימה מצומצמת ולתאר את הבעיה. מקור: Best practices for using GitHub Copilot to work on tasks (GitHub Docs), https://docs.github.com/en/copilot/how-tos/agents/copilot-coding-agent/best-practices-for-using-copilot-to-work-on-tasks, ניגש בתאריך 19 באוקטובר 2026. הן מבקשות גם תוצאות שלפיהן בוחנים את העבודה, תנאי קבלה (acceptance criteria). ניישם כאן את הרעיון לתת למבצע מטרה שאפשר לבדוק. קריאת קוד אינה מכריעה שאלה על מדיניות המוצר. גישה לקבצים אינה מגלה מה בעלי המוצר מעדיפים.

תנאי קבלה מתארים תוצאה נראית

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

טיוטה חסרה חייבת להישאר אפשרית

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

הרחבת הסיכון דורשת החלטה נפרדת

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

אפשר לברר מימוש בלי להכריע מדיניות

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

החלטה ממוקדת מחוברת לצורך

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