הנדסת לולאות היא בדיוק הלולאה שכבר הרצתם, רק עם agent במקומכם

זו לא המצאה חדשה

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

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

ארבעה חלקים שכדאי להכיר בשם

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

אנחנו מריצים משהו קרוב מאוד לזה כל לילה. לוח backlog, agent שבונה ולוקח משימה, עושה את העבודה, ומעביר אותה ל-QA reviewer, שמעביר אותה ל-release judge לפני שמשהו יוצא לאוויר. trigger, execution שקשור ל-skills ספציפיים, שלב אימות עם רף אמיתי לעבור, ולוג שההרצה הבאה יכולה לקרוא. שום דבר מזה לא היה מובן מאליו. בנינו את זה בסדר הזה כי הגרסה הראשונה החסירה כל אחד מהחלקים האלה, והמציאות מצאה כל פער בעצמה.

מה מונע מהלולאה לבזבז לילה שלם

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

הרעיון היחיד ששווה את כל הפוסט

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

לפני שבונים לולאה

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

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