בקצרה
מפתח מנוסה יכול לחלק משימות מוגדרות בין כמה סוכני AI ועדיין להישאר אחראי להחלטות המוצר ולאינטגרציה. מתחילים במסלול משתמש אחד, מפרידים משימות עצמאיות, מגבילים את כמות העבודה הפתוחה ומודדים שינויים שאושרו ולמידה, ולא פעילות של סוכנים.
צוות התחלתי קטן צריך אחריות ברורה
מוצר בתחילת הדרך לא תמיד דורש עובד נפרד במשרה מלאה לכל תחום. מפתח בעל ניסיון רחב יכול לשלב מימוש עם מחקר, הכנת בדיקות ותיעוד בסיוע AI. כך אפשר לעיתים לבנות גרסה ראשונה ממוקדת בצוות קטן, אבל זו אינה הוכחה שאדם אחד יכול לענות על כל צורך מקצועי.
לפני שמחליטים איזה כלי עושה מה, מגדירים תחומי אחריות: החלטות מוצר, חוויית משתמש, גישה לנתונים ואבטחה, מימוש, בדיקות ותפעול. קובעים מי אחראי לכל החלטה, גם כשבתחילה אדם אחד ממלא כמה תפקידים. נעזרים במומחים כאשר הסיכון או עומס העבודה חורגים מהידע או מהיכולת של אותו אדם.
מתכננים מסלול משתמש אחד ואז מפצלים את המשימות העצמאיות
ניקח דוגמה להמחשה: עסק בתחום השירותים רוצה שהצוות יעבור על פניות נכנסות במקום אחד. המסלול הראשון הוא קבלת פנייה, שיוך לאחראי והצגת סטטוס. תשלומים, תחזיות וסוכן אוטונומי מול לקוחות יכולים לחכות.
המפתח מגדיר את מודל הנתונים ואת תנאי הקבלה. סוכן אחד יכול לבדוק את האינטגרציה הקיימת לקליטת פניות, אחר לנסח טקסטים לממשק, ושלישי להציע בדיקות למעברי הסטטוס שסוכמו. מתחילים לממש אחרי שמסכימים על החוזה המשותף. שליחת שלושה סוכנים להמציא במקביל את אותו חוזה יוצרת עבודת אינטגרציה במקום התקדמות.
לכל משימה צריך גבול ותוצר
הבריף צריך לציין מטרה, קבצים או מערכות מותרים, הנחות, בדיקות קבלה ותוצר צפוי. דורשים מהסוכן לסמן חוסר ודאות ולא למלא אותו בכללים עסקיים מומצאים. פרטי גישה ושינויים בפרודקשן נשארים מחוץ למשימות פיתוח רגילות.
עותקי עבודה נפרדים עוזרים להפריד עריכות עצמאיות. התיעוד של Codex מבית OpenAI מתאר worktrees כעותקים נפרדים של אותו מאגר קוד לעבודה מקבילה. ההפרדה הזו נוגעת לקבצים, לא למסדי נתונים משותפים או לשירותים חיצוניים, ולכן כל משימה עדיין צריכה נתוני בדיקה והגדרות מתאימים.
- משימת מחקר: מחזירה ראיות ושאלות פתוחות, בלי לערוך קבצים.
- משימת מימוש: שינוי מוגדר בקוד ופירוט הבדיקות שבוצעו בפועל.
- משימת סקירה: בדיקת השינוי מול הדרישות המוסכמות ודיווח על כשלים קונקרטיים.
- משימת אינטגרציה: שילוב שינויים שאושרו ובדיקת המסלול השלם.
יכולת הסקירה קובעת כמה עבודה מריצים במקביל
אם המפתח לא מספיק לסקור את השינויים שהושלמו, הפעלת סוכנים נוספים רק מאריכה את התור. מגבילים את משימות המימוש הפעילות לכמות שאפשר לסקור ולשלב בזמן סביר. מסיימים חלק שימושי לפני שפותחים עוד כמה פיצ'רים חצי גמורים.
בודקים מול הדרישה המקורית, ולא רק מול ההסבר של הסוכן. בודקים את התוצאה המשולבת, כולל הרשאות ותרחישי כשל. סוכן נוסף יכול למצוא בעיות, אבל הסכמה בין שתי תשובות שנוצרו על ידי AI אינה תחליף לראיות מהמערכת.
מודדים את מחזור הלמידה ומרחיבים לפי הצורך
עוקבים אחר הזמן שעובר מבעיה של משתמש ועד שינוי שימושי, אחר הזמן שמושקע בתיקון עבודה שנוצרה על ידי AI, ואחר השאלה אם משתמשים משלימים את המסלול המתוכנן. אחרי שחרור קטן, בודקים היכן אנשים מתלבטים או זקוקים לעזרה ידנית, ונותנים לממצאים לקבוע את המשימה הבאה.
מצרפים אנשים או תמיכה מקצועית כאשר הסקירה, הידע בתחום, הכיסוי התפעולי או חקר צורכי המשתמשים הופכים לצוואר בקבוק. המודל של UVISION, מפתחים ייעודיים ופרויקטים מנוהלים עם לפחות מפתח אחד במשרה מלאה בכל פרויקט, מתאים לאחריות מתמשכת על התהליך הזה. כלי ה־AI יכולים להתחלף; עדיין צריך מי שמכיר את המוצר וממשיך לפתח אותו.
רוצים לבחון איך זה מתאים למערכות שלכם?
לשירות הרלוונטי