איך אני מונע מסוכני AI לדרוס אחד לשני את הקוד

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

שני שינויים תקינים יכולים לשבור את אותה גרסה

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

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

גישה לקוד אינה הרשאה לשנות אותו

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

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

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

בהעברת משימה צריך לשמור גם על הסיבה לשינוי

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

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

בסוף אני בודק את המסלול שהמשתמש עובר

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

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