אוטומציה טובה יודעת מה היא לא יכולה לבדוק

הודעה בשעה 23:47

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

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

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

קודם מוכיחים, ואז מעבירים

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

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

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

התקלה שאף אחד לא מזהיר עליה

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

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

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

הבעיה שחוזרת

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

מאיפה כדאי להתחיל

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

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