האם הסוכן הבודק שלכם הוא רק התחמקות מהחלטה?
אחת הבעיות בשימוש בסוכן נוסף כתנאי עצירה היא שהלולאה יכולה לרוץ לנצח. על הנייר זה ברור, אבל קל לפספס את זה כשבונים את המערכת. ניקח כדוגמה Code Review.
מנגנון אחד משתמש בכלים דטרמניסטיים - מריצים בדיקת אבטחה סטטית על הקוד, Linter, בדיקות אוטומטיות, מטריקות של איכות קוד, תקציב לגודל ה JavaScript, ונותנים לסוכן לרוץ בלולאה עד שה CI עובר. סוכנים אוהבים לולאות ואחרי כמה שעות יש סיכוי טוב שתקבלו קוד שעובר את כל הכללים שהגדרתם. מיטיבי לכת יגבילו את מספר הנסיונות של הסוכן כדי שלא יגמור לכם את המנוי על פיצ'ר אחד שהוא לא יודע לבנות.
מנגנון שני לוקח כלי לא דטרמניסטי, סוכן נוסף עם הוראה "תבדוק את הקומיט האחרון ותגיד אם הוא מספיק טוב לפרודקשן ואם לא מה הבעיות בו". כאן הסוכן השני יכול למצוא בעיות חדשות בכל הרצה עד אינסוף ולפעמים גם להזות בעיות. בנסיון להתחמק מהחלטה יצרנו מערכת גרועה יותר:
אי אפשר לדעת מתי PR יאושר או מה תהיה האיכות שלו בסוף.
אי אפשר לדעת כמה טוקנים זה יעלה.
כמעט תמיד נדרשת התערבות אנושית כדי לצאת מהלופ.
במקום לזרוק סוכן על כל בעיה שווה לנסות לחזור להנדסה: מה הציפיות שלי מהמוצר, איך בודקים שהמוצר עומד בתקן, מה רף הטעות. מדדים קשיחים מייצרים גשרים יציבים.