Loop Engineering לא יציל אותך

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

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

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

אבל ככל שהתוצר מורכב יותר, הפער מתחיל להיפתח. השאלה היא כבר לא רק אם יש לכם loop, אלא מה ה-loop הזה יודע על העבודה האמיתית שלכם.

אז מה זה בכלל loop

בהקשר של coding agents, כשאנשים אומרים היום agentic loop או loop engineering, הם לא מתכוונים רק ל-while loop שרץ כל כמה דקות. הם מתכוונים למשהו רחב יותר: מערכת קטנה שמחליפה את המשתמש בתפקיד של מי שדוחף את ה-agent משלב לשלב.

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

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

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

הבעיה אף פעם לא הייתה ה-while loop

אפשר לקחת coding agent, לתת לו prompt, ולעטוף אותו ב-loop. כל כמה דקות הוא יבדוק CI, יקרא review comments, ינסה לתקן, יריץ tests ויחזור עם סטטוס. זה שימושי כשברור לו מה לעשות.

אבל אם הוא לא יודע מה נחשב שינוי טוב, איזה בדיקות באמת רלוונטיות, איפה יש edge cases, איזה reviewer הולך להתעקש על naming ואיזה מטריקות צריך לבדוק אחרי rollout, ה-loop לא פותר את הבעיה. הוא רק גורם ל-agent להמשיך לעבוד בתוך ערפל.

הבעיה היא לא שחסר לנו כפתור שקוראים לו loop. הבעיה היא שהרבה מה-workflow שלנו לא מוגדר בצורה ש-AI יכול לאכול.

יש כבר לופים סגורים

כלים כמו Lovable ו-Base44 הם לא בדיוק אותו loop שמדברים עליו עכשיו סביב coding agents, אבל הם כן מראים משהו חשוב: כשמישהו סוגר מאחורי הקלעים מסלול מרעיון לתוצר, המשתמש לא מחבר לבד את כל השלבים.

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

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

באנטרפרייז ה-context הוא העבודה

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

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

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

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

מה כן עוזר

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

למשל, תכנון טוב ל-agent לא אמור להיות רק:

Add support for exporting this report.

הוא צריך להגיע עם משהו יותר קרוב לזה:

Add export support for this report.
Before implementation, read the relevant skill for this area.
Inspect existing export flows under X.
Look at recent PRs that changed the same code path.
Use the same permission model as Y.
Run these tests.
Validate these user paths.
Check how similar features are monitored after rollout.
Return with summary, tests, gaps, and rollout risks.

זה עדיין לא מבטיח תוצאה מושלמת. אבל זה כבר workflow. ועכשיו יש ל-loop משהו אמיתי להריץ.

בסוף זו אותה עבודה, רק יותר חשובה

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

במקום לכתוב רק קוד, צריך להגדיר איך נראה קוד טוב. במקום לבקש “תעשה review”, צריך להגדיר מה review טוב מחפש. במקום להגיד “תריץ בדיקות”, צריך לדעת איזו ולידציה על הקוד באמת תיחשב Done.

כי אם ה-workflow שלכם לא מוגדר, ה-agent לא סוגר לופ. הוא סוגר פינה. לפעמים זה מספיק, אבל זה לא מספיק כדי שהסיפור ייסגר קצה לקצה.

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

שם נמצא הערך. לא ב-loop עצמו, אלא במה שהצלחתם להכניס לתוכו.