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

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

בעיית תכנון הלופ

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

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

איפה לופים באמת מצדיקים את עצמם

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

עבודה מכנית שגרתית. חשבו על המשימות שגורמות למהנדסים בכירים לרצות לפרוש: הפעלת אפליקציות ברצף ספציפי, לחיצה על ממשקי פריסה (deployment UI) כדי לאשר כל שלב, חיפוש (grep) בלוגים אחר מחרוזות שגיאה ידועות לאחר שחרור, או אימות שקובץ הגדרות נכתב לכל הצמתים (nodes) הנכונים. שלבים אלו מייגעים עבור בני אדם אך טריוויאליים לאימות. לופ יכול "לשמור" על התהליך, לבדוק נקודות קצה של בריאות המערכת (health endpoints) לאחר כל הפעלה מחדש ולבצע rollback בסימן הראשון לבעיה. האדם עדיין מגדיר את תוכנית הפריסה. הלופ פשוט מבצע אותה בסבלנות של מכונה בשתיים לפנות בוקר.

יעדי אופטימיזציה מדידים. כאשר ההצלחה נמדדת במספר, לופים הם יעילים להפליא. הפחתת שיהוי (latency) p99 מתחת ל-150 מילישניות. צמצום טביעת הרגל של הזיכרון ב-20%. הגירה של נתיב קריטי (hot path) מ-Python ל-Rust והבטחה שכל בדיקות היחידה הקיימות עדיין עוברות. הלופ יכול לייצר שינוי, לבצע לו benchmark, לשמור את הגרסה שהניבה את השיפור ולהשליך את השאר. מכיוון שהאימות הוא אוטומטי ומרחב החיפוש גדול, העלות המצטברת של סקירה ידנית הייתה הופכת את העבודה הזו לבלתי מעשית ללא לופ. המטרה קבועה. הנתיב אינו ידוע. זהו נקודת האיזון המושלמת.

ספריית פעולות תפעולית (Operational playbooks). תגובה לאירועים וכרטיסי תמיכה עוקבים לעיתים קרובות אחר דפוסים שבני אדם כבר פתרו. סוג מסוים של שגיאת ייצור תמיד דורש החלפת הרשאה (credential rotation) וניקוי מטמון (cache). קטגוריה של בקשת תמיכה יכולה להיפתר באמצעות החזר כספי כאשר מתקיימים שלושה תנאים ספציפיים. לופ יכול לעקוב אחר הטריגרים הללו ולבצע את ה-playbook, תוך הסלמה רק כאשר הדפוס משתנה. הוא לא מחליט שה-playbook נכון; הוא פשוט אוכף עקביות בקנה מידה ובמהירות שמהנדסים בתור (on-call) אינם יכולים להשתוות אליהם.

רגולטורים, לא קובעי מוסכמות

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

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

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

מאמר זה מתבסס על רעיונות שנדונו במקור על ידי Isaac Hagoel ב-“Loop Engineering Minus The Hype.”. לדיונים הנדסיים נוספים, הצטרפו לקהילת הלמידה שלנו ב-Telegram.