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

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

אני כאן כדי לכבות קצת.

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

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

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

אז מה זה בכלל loop

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

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

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

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

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

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

ה-loop prompt יודע להגיד ל-agent “תמשיך”. הוא לא יודע להגיד לו “פה אצלנו אסור להמשיך לבד”.

וזה ההבדל הגדול בין demo לבין מוצר אמיתי.

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

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

במקרה כזה ה-loop באמת מחליף חלק מהעבודה המעצבנת: ללחוץ Enter שוב, להזכיר להריץ בדיקות, לבקש תיקון, לקרוא summary, לפתוח עוד prompt. אבל במוצר גדול הערך הוא לא בלחיצה על Enter. הערך הוא לדעת מתי לעצור.

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

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

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

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

וזו רק ההתחלה. אחר כך מגיעים הדברים שבדרך כלל לא כתובים בשום מקום מסודר: feature flags, tenants שונים, הרשאות, secrets, API חיצוני שנופל בדיוק בזמן הלא נכון, לקוח גדול שקיבל התנהגות מיוחדת לפני שנתיים, migration שאסור להריץ פעמיים, ו-backward compatibility מול גרסה ישנה של client.

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

הוא לא מכיר את המוצר שלכם. הוא לא יודע איפה הידע שבעל פה. הוא לא יודע איזה שינוי קטן נראה תמים אבל יעלה הון ב-billing. הוא לא יודע מתי security חייבים לראות את ה-PR, או איזה reviewer יעצור הכל בגלל boundary לא נכון בין מודולים.

הוא יכול לנחש. ולפעמים הוא ינחש יפה. עד שהוא לא.

מה כן עוזר

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

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

זה יכול להיות skill לשינוי API, שמסביר איפה לעדכן types, איך לבדוק backward compatibility, ואיזה consumer tests להריץ. זה יכול להיות skill ל-review, שרץ מקונטקסט נקי על ה-diff ושואל שאלות אחרות מה-agent שכתב את הקוד. זה יכול להיות skill לבדיקות, שלא מסתפק ב-npm test, אלא יודע איזה env צריך ואיזה UI flow לבדוק ידנית.

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

אייג׳נטים לא קוראים מחשבות

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

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

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

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