לבנות תהליך כשעדיין לא יודעים מה הוא צריך להיות

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

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

קודם להזרים מים

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

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

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

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

ומה אם עוד לא ברור מה הסוכן צריך להחזיר?

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

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

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

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

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

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

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

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

איפה אפשר להתחיל אצלכם?

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

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