בפוסט שפורסם בבלוג של n8n על ידי אופיר פרוסאק (Ophir Prusak), מומחה שצמח מעולם הנדסת התוכנה וכיום עוסק בשיווק, מוצג ניתוח מעמיק של אחד האתגרים המשמעותיים ביותר בפיתוח פתרונות בינה מלאכותית (AI) בארגונים. פרוסאק מסביר כי למרות ההתרגשות הראשונית והתחושה המלהיבה של השקת פרויקט AI חדש, בונים רבים – במיוחד אלו המגיעים מרקע שאינו טכנולוגי – נתקלים בקושי עצום כאשר המערכות שהקימו מתחילות להתרחב או לקרוס. כלי AI רבים אינם מתוכננים ללמד את המשתמשים כיצד עובדת התשתית שמאחוריהם, וכאשר דברים משתבשים, לא תמיד ברור מה קרה או מדוע. בעיה זו, שבה פרויקט פועל היטב בתחילה אך נשבר בהמשך הדרך, מכונה בעולם הנדסת התוכנה "בעיית היום השני" (Day 2 Problem).
מהי בדיוק "בעיית היום השני"?
לפי פרוסאק, "בעיות היום השני" הן האתגרים והנושאים ארוכי הטווח שצצים כאשר מנסים להרחיב ולתחזק מוצר או מערכת, לאחר ששלבי התכנון (יום 0) והבנייה הראשונית (יום 1) כבר הושלמו. הבעיות הללו אינן מתרחשות בהכרח ביום השני הקלנדרי של הפרויקט, אך הן בלתי נמנעות ככל שהמערכת פועלת לאורך זמן והדרישות ממנה משתנות.
כדי להמחיש את חומרת הבעיה ואת האופן שבו היא משפיעה על ארגונים, פרוסאק מציג את סיפורו של דייב (Dave), חבר בצוות הפיננסים בחברה המונה מעל 100 עובדים. דייב אינו מהנדס תוכנה, אך הוא בעל גישה יזמית וחובב טכנולוגיה, שהחל להדריך אחרים בארגון כיצד לבנות פתרונות באמצעות כלי בינה מלאכותית. השבוע של דייב ממחיש בצורה מושלמת כיצד פרויקט שנראה כהצלחה מסחררת ביום הראשון, הופך לסיוט מתמשך בימים הבאים.
השבוע הקשה של דייב: כרוניקה של קריסה ידועה מראש
הכול התחיל ביום שני בבוקר. הצוות של דייב כרע תחת עומס של חשבוניות מספקים שהגיעו כקובצי PDF בדואר האלקטרוני. העובדים נאלצו להקליד את הנתונים ידנית לתוך המערכת – תהליך ממושך שגרם לעיכוב של מספר שבועות בעבודה. דייב החליט לפתור את הבעיה ובנה אוטומציה בעזרת כלי AI: כאשר מגיעה חשבונית חדשה, ה-AI סורק את קובץ ה-PDF, מחלץ את נתוני המפתח ומעלה אותם למערכת, ואף מסמן אם משהו נראה חריג. המנהלת של דייב התרשמה עמוקות ואף רמזה כי פרויקט זה יסייע לו לקבל את הקידום המיוחל.
ביום שלישי בבוקר, המציאות החלה להכות. צוות החשבונות שלח לדייב הודעה דחופה: שלוש חשבוניות הוזנו למערכת עם סכומים שגויים לחלוטין. דייב ניסה לברר מה קרה – האם ה-AI קרא לא נכון את קובצי ה-PDF, או שמא חלה תקלה בהעלאת הנתונים למערכת? כאשר הוא פתח את כלי האוטומציה שלו, הוא גילה שאין לו כל דרך לדעת. המערכת לא שמרה תיעוד (Log) של פעולות ה-AI בכל שלב, אלא הציגה רק את ההודעה הסופית: "האוטומציה הושלמה". דייב ביצע כמה שינויים והתאמות קטנות במערכת, מצא את הבעיה המינורית לכאורה ותיקן אותה. אולם, כאשר הריץ בדיקה של הגרסה המעודכנת, התברר שהיא אינה עובדת כלל. כשניסה לחזור לגרסה הקודמת והיציבה, הוא גילה שאין כל מערכת לניהול גרסאות – השינוי בוצע על הגרסה היחידה שהייתה קיימת. דייב נאלץ לבזבז שעות ארוכות בבנייה מחדש של הגרסה המקורית מאפס, הוספת התיקון ובדיקה קפדנית לפני שהלך לביתו.
ביום רביעי, דייב היה תקוע בפגישות רצופות לאורך כל שעות האחר-הצהריים. בשעה 14:00, תוכנת האוטומציה דרשה איפוס (Reset) עקב שגיאה. חברו לצוות, מרקו (Marco), הציע לסייע ולטפל בבעיה, אך לא ידע מאיפה להתחיל. לא היה כל תיעוד כתוב המסביר כיצד להגיע לעורך האוטומציה. כאשר מרקו מצא לבסוף עובד אחר שהכיר את המערכת, התברר שפרטי ההתחברות משויכים לתיבת הדואר האלקטרוני האישית של דייב, עם סיסמה מורכבת שאינה ידועה לאיש. דייב ניסה לשלוח הוראות בהודעות טקסט מתחת לשולחן במהלך פגישת תכנון רבעונית, אך הניסיון נכשל והחשבוניות נותרו ללא טיפול עד שדייב התפנה בשעה 16:30.
ביום חמישי, המנהלת של דייב, שעדיין האמינה בפרויקט ובחיסכון בזמן שהוא מייצר, ביקשה להרחיב את השימוש באוטומציה גם לסניף החברה באוסטין. דייב הרגיש כיצד בטנו מתהפכת: המערכת כולה נבנתה בצורה קשיחה (Hardwired) – היא חוברה לתיבת דואר אלקטרוני אחת ספציפית, הותאמה לפורמט חשבוניות של ספקים מסוימים, וחוברה למערכת הנהלת חשבונות אחת. כדי להתאים אותה לסניף באוסטין, דייב לא יכול היה להסתפק בשינוי הגדרות פשוט, אלא נדרש לבנות את הפרויקט כמעט לחלוטין מאפס. כדי להשלים זאת, הוא נאלץ לבטל את תוכניותיו לשעות הערב.
ביום שישי נראה היה שהכול פועל כשורה, עד שבשעה 15:00 התקשר ספק והתלונן שחשבוניתו לא שולמה. דייב בדק את הנושא וגילה לתדהמתו כי האוטומציה דילגה לחלוטין על החשבונית הזו מבלי לעבד אותה. המערכת לא הצליחה לקרוא את הפורמט, ובמקום להתריע על שגיאה או לסמן את החשבונית, היא פשוט המשיכה הלאה בשתיקה. בדיקה מעמיקה יותר חשפה 11 חשבוניות נוספות שנדחו באותו אופן שקט במהלך השבוע. בזמן שדייב עסק בפתרון הבעיות הגלויות, בעיות סמויות רבות המשיכו להתרחש מתחת לרדאר.
כיצד לפתור את בעיות "היום השני"? השאלות שיש לשאול ב"יום אפס"
פרוסאק מסביר כי הבעיה האמיתית בניהול פרויקטים מסוג זה היא חוסר מודעות. רוב התקלות של דייב לא היו קשות לפתרון, אלא שהוא פשוט לא היה מודע לאפשרות קיומן עד שהן התרחשו בפועל. כדי להימנע מכך, הנדסת תוכנה מספקת פתרון ברור: יש לשאול את השאלות הנכונות עוד בשלב התכנון – ביום אפס (Day 0).
השאלה הראשונה והבסיסית ביותר נוגעת לבעלות על הפרויקט. בשנת 2006, ורנר פוגלס (Werner Vogels), סגן נשיא ומנהל הטכנולוגיות הראשי של אמזון (Amazon), טבע את העיקרון המפורסם: "אתה בנית את זה, אתה מפעיל את זה" (You build it, you run it). אם אתם בונים מערכת, עליכם להגדיר בבירור מי יהיה האחראי לתחזוקתה השוטפת.
להלן חמש השאלות המרכזיות שדייב היה צריך לשאול את עצמו ביום שני בבוקר:
- כיצד אעקוב אחר פעולות המערכת בכל שלב? דייב לא ידע אם ה-AI נכשל בקריאת ה-PDF או שההעלאה למערכת נכשלה מכיוון שלא היה לו כל תיעוד של הקלטים והפלטים לאורך התהליך. כל פרויקט פעיל דורש רמת עקיבות (Traceability). בפלטפורמת n8n, לדוגמה, סביבת העבודה הוויזואלית מאפשרת למשתמשים לראות בצורה פשוטה היכן דברים השתבשו, תוך תיעוד מפורט של כל הקלטים והפלטים בכל שלב של הריצה.
- כיצד יבוצעו שינויים במערכת, וכיצד אוכל לבטל אותם? דייב ערך את הגרסה היחידה של האוטומציה ולא יכול היה לחזור לאחור. לפני השקת פרויקט, יש להחליט היכן נשמרות גרסאות קודמות, האם ניתן לבצע שחזור (Rollback) מהיר, והאם ישנה סביבת בדיקות (Test environment) שאינה משפיעה על מערכת הייצור החיה.
- מי עוד זקוק לגישה למערכת, ומהן הרשאות הפעולה שלו? מרקו לא יכול היה לסייע מכיוון שפרטי הגישה היו משויכים ישירות לחשבונו של דייב, וכל ההיגיון הלוגי של המערכת היה שמור בראשו של דייב בלבד. יש להסדיר פרטי גישה משותפים, רמות הרשאה שונות ותיעוד בסיסי שיאפשר לאחרים לתפעל את המערכת בשעת חירום.
- כיצד המערכת עשויה להידרש לצמוח ולהתרחב? כאשר נדרש להרחיב את המערכת לסניף נוסף, דייב נאלץ לבנות אותה מחדש בשל ארכיטקטורה קשיחה. תכנון מראש הלוקח בחשבון אפשרות של צמיחה והרחבה זול משמעותית מאשר ביצוע התאמות מאוחרות (Retrofitting).
- כיצד אדע אם המערכת עובדת באופן תקין או נכשלה? האוטומציה של דייב נראתה תקינה אך דילגה בחשאי על חשבוניות רבות. מערכת הפועלת ברקע חייבת לכלול מנגנון ניטור (Monitoring) שיודע להתריע בפני גורם אנושי במקרה של שגיאה או אי-עיבוד.
היבטים נוספים מעבר לשבוע של דייב
פרוסאק מדגיש כי השבוע הקשה של דייב היה יכול להיות גרוע בהרבה, ומציג שאלות קריטיות נוספות שיש לקחת בחשבון:
- אבטחת מידע (Security): אם גורם עוין היה חודר למערכת של דייב, הייתה לו גישה ישירה לנתוני התשלומים של הספקים. כאשר מדובר במידע פיננסי, פרטי לקוחות או מידע המוגן על פי חוק, אבטחת המידע אינה יכולה להיות מחשבה משנית.
- שינויים ועדכונים במודל ה-AI: בניגוד לתוכנה מסורתית המספקת פלט זהה עבור קלט זהה כל עוד הקוד לא השתנה, מודלים של בינה מלאכותית נוטים להשתנות. עדכוני מודל מצד הספקיות עשויים לשנות את האופן שבו הנחיה (Prompt) מסוימת מיושמת, ובכך להוביל לפלטים שונים לחלוטין מאותו קלט. כדי לשמור על עקביות, יש לפתח שיטות לבדיקת התנהגות המודל לאורך זמן (תהליך המכונה בתעשייה "Evals" – מעין בקרת איכות ייעודית ל-AI).
- עלויות תפעול (Cost): אוטומציה עשויה לעלות סנטים בודדים להרצה בודדת, עלות שאינה מורגשת בשבוע הראשון. אך כאשר המערכת מתרחבת והופכת לחלק מרכזי בארגון הפועל במספר סניפים, עלויות השימוש במודלים עלולות לנסוק ולדרוש אישורי תקציב משמעותיים.
בעולם הנדסת התוכנה המקצועי, היבטים אלו מתוארים לרוב באמצעות סיומת ה-"ilities": maintainability (תחזוקתיות), scalability (יכולת הרחבה), portability (ניידות) ועוד עשרות תחומים דומים (פרוסאק מציין כי במהלך לימודיו האקדמיים בתחום מדעי המחשב לימדו אותו על לא פחות מ-61 מאפיינים כאלה). רמת ההעמקה הנדרשת תלויה באופי הפרויקט: הקמת אפליקציה פשוטה וזמנית אינה דורשת את אותה רמת תכנון קפדנית הנדרשת להקמת מערכת מורכבת ויציבה המיועדת לפעול לאורך זמן בארגון גדול.
פרוסאק מסביר כי בעוד שחלק מהאנשים מסוגלים לבנות בעצמם מחסן בחצר האחורית, הם לא ינסו לבנות בעצמם כור גרעיני או גשר תעשייתי. באותו אופן, ישנם מקרים שבהם הבאת מהנדס תוכנה מקצועי היא הצעד הנכון ביותר עבור פרויקט ה-AI הארגוני שלכם. הידע המקצועי הנדרש תלוי באופי המבנה שאתם מנסים להקים: האם מדובר במחסן פשוט, בבית בן שתי קומות, או בבניין בן עשרים קומות? אם אתם בונים אפליקציה פשוטה ומהירה, אין צורך לבצע סקירה כה מקיפה של עשרות המאפיינים. אך אם ברצונכם לבנות פתרון שיפעל באמינות גבוהה ויתמודד עם צרכים מורכבים, עליכם להיערך לכך בהתאם.
מדוע הבינה המלאכותית עצמה אינה פותרת את הבעיות הללו?
משתמשים רבים עשויים לתהות מדוע מודלי השפה הגדולים (LLMs), שאומנו על כמויות עצומות של נתוני הנדסת תוכנה, אינם פותרים את הבעיות הללו בעצמם או לפחות מציגים את השאלות הללו מראש.
פרוסאק מסביר כי מודלי השפה מותאמים לספק בדיוק את הפלט שהמשתמש מבקש מהם. אם המשתמש אינו מודע לצורך בתשתית תחזוקה ואבטחה ואינו מבקש זאת במפורש, המודל לא יניח זאת מעצמו. כאשר משתמש מבקש מה-AI "בנה לי אפליקציה שעושה X", המודל יתמקד בביצוע המשימה הספציפית, ולא יוסיף באופן אוטומטי מנגנוני ניהול הרשאות, אפשרויות הרחבה או מערכות התראה על שגיאות.
כדי להתגבר על כך, פרוסאק מציע להנחות את ה-AI באופן שיגרום לו לשאול את השאלות הנכונות. הוא מציע להשתמש בנוסח ההנחיה (Prompt) הבא: "אני אינני מפתח תוכנה מקצועי. אני רוצה לוודא שפרויקט זה עוקב אחר שיטות העבודה המומלצות של הנדסת תוכנה: דברים כמו תחזוקתיות, אבטחה, יכולת ניטור ויכולת הרחבה. אנא ראיין אותי לגבי הפרויקט שלי ועזור לי לזהות על מה עליי לחשוב לפני שאני משיק אותו."
לסיכום, כתיבת קוד ובניית תוכנה הן תהליך מתמשך ולא פרויקט חד-פעמי. מערכות ומוצרים מגיעים לשלב "היום השני" רק כאשר הם מספקים ערך ממשי שגורם למשתמשים לחזור אליהם שוב ושוב. כדי להבטיח לפרויקט ה-AI שלכם חיים ארוכים ויציבים, חשוב להיערך ליום השני כבר ביום אפס.