איך לבנות סוכן פיתוח ב־Slack עם Kiro CLI

בקשת תיקון ב־Slack יכולה להיות נקודת הפתיחה למשימת פיתוח, ולא רק הודעה שמישהו צריך להעתיק למסוף. ב־29 בספטמבר 2026 פרסמה AWS מדריך לבניית סוכן פיתוח מתוך Slack באמצעות Kiro CLI ו־headless authentication. לצוות ישראלי שכבר מנהל בקשות עבודה בצ׳אט, היישום השימושי הוא חיבור מבוקר בין בקשה, שינוי בקוד ותוצאות בדיקה, בלי להפוך כל הודעה להרשאה להריץ פקודות.

011. הגדירו משימה קטנה ותנאי הצלחה

החידוש החדשותי הוא פרסום מדריך, לא הכרזה על יכולת חדשה של Slack או Kiro CLI. המדריך של AWS, ששמו Building a Slack-powered AI development agent with Kiro CLI and headless authentication, עוסק בביצוע משימות פיתוח מתוך הצ׳אט. כדי להפוך את הרעיון לפיילוט שימושי, התחילו במשימה שאפשר לבדוק בלי גישה ללקוחות, למפתחות ייצור או למערכות תשלום.

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

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

022. תכננו שער כניסה מ־Slack, לא מסוף פתוח

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

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

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

033. הכינו סביבת הרצה ואימות ללא כניסה ידנית

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

headless authentication מאפשר לתהליך לפעול בלי שהמפתח יבצע כניסה אינטראקטיבית בכל משימה. התחקיר אינו כולל את מנגנון האימות המדויק של Kiro CLI, ולכן אין כאן הוראות ליצירת token או דגלי הרצה. לפני ההקמה, ודאו בתיעוד הרשמי מהו מסלול האימות הנתמך, כיצד נשמרים פרטי הגישה ואיך מחדשים ומבטלים אותם. אחסנו סודות במנגנון ייעודי, לא בהודעות Slack או בקבצי המאגר.

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

044. הגדירו תוצר שאפשר לבדוק ולאשר

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

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

055. בדקו תקלות לפני שמזמינים את כל הצוות

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

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

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