בניית משחק full-stack דרך pipeline אוטונומי של סוכנים

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

הבעיה

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

הקשר

משחק Battleship מרובה משתתפים (frontend ב-React ו-TypeScript, backend ב-Spring Boot) שנבנה במיוחד כדי להפעיל את ה-pipeline הזה: מציבים ספינות, משחקים נגד יריב ממוחשב או נגד שחקן אנושי שני באמצעות קוד משחק שאפשר לשתף, משחזרים session שהופסק, ומשהים וממשיכים. המשחק עצמו הוא מוצר אמיתי שעובד, אבל מטרתו בפועל הייתה לשמש דוגמה מרכזית ל-pipeline האספקה שנבנה סביבו.

אילוצים

• ה-pipeline היה צריך לרוץ בלי שאדם יכתוב קוד מימוש ביד בין קליטת הדרישה ל-PR.
• המצב היה צריך להיות נכון בתנאי multiplayer אמיתיים: שני sessions עצמאיים, חיבור מחדש אחרי רענון, והוכחת בעלות על המושב בכל פעולה, ולא רק משחק לשחקן יחיד.
• האימות היה צריך להיות אמיתי ולא מדומה: בדיקות יחידה של ממש (JUnit, Vitest), בדיקות end-to-end של ממש בדפדפן (Playwright), ו-PR אמיתי שנפתח דרך ה-CLI של GitHub.

התפקיד שלי

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

ארכיטקטורה וגישה

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

החלטות מרכזיות

• שלבי pipeline עם אחריות נפרדת, ולא סוכן אחד שעושה הכול. הפרדה בין תכנון, מימוש, בדיקות וסקירה אפשרה לאמת כל שלב בנפרד, במקום לסמוך על מעבר יחיד שיעשה הכול נכון בבת אחת.
• שערי אימות אמיתיים, ולא דיווח עצמי על השלמה. ה-pipeline מריץ סטים אמיתיים של בדיקות (JUnit, Vitest, Playwright), ואינו רואה באמירה "הסוכן אמר שסיים" סימן להשלמה.
• נכונות של session באמצעות טוקן לכל מושב, ולא אמון בצד הלקוח. כל פעולה שמשפיעה על הלוח נבדקת מול טוקן שהשרת הנפיק ושקשור למושב הזה, וזה מה שהופך את מצב ה-multiplayer לאמין גם אחרי חיבור מחדש.
• HTTP polling כרגע, WebSockets נדחו. סנכרון המצב משתמש כרגע ב-polling בכל שנייה. זו פשרה מפורשת וידועה, מתועדת כשיפור עתידי שאינו דורש שינויים בדומיין ה-backend, ולא משהו מוסתר או שנשלח במקרה.

שיקולים ופשרות

הרצת האספקה דרך pipeline של סוכנים מקצה לקצה לוקחת יותר זמן להקמה מאשר לפתוח עורך ולכתוב את הפיצ'ר ישירות. הערך הוא במה שזה חושף על המקומות שבהם pipeline אוטומטי צריך מעקות אמיתיים (גבולות הרשאה, שערי אימות, פלט מפורש שאדם יכול לסקור), ולא במהירות פיתוח גולמית בפרויקט בגודל כזה. הבחירה ב-polling במקום בסנכרון מבוסס push הייתה פשוטה יותר, אך מתאימה פחות להתרחבות. היא נעשתה במכוון בהתאם להיקף הפרויקט. נתיב השדרוג כבר מוגדר ולא נדחה ל"נבין את זה אחר כך".

תוצאות ואימות

משחק מרובה משתתפים עובד (משחק יחיד נגד יריב ממוחשב, שני שחקנים באמצעות קוד משחק משותף, שחזור session, והשהיה והמשך) שסופק דרך pipeline שעובר מדרישה ל-PR שנסקר בלי צעדי מימוש ידניים באמצע, ומגובה בכיסוי אמיתי של בדיקות יחידה ובדיקות end-to-end.

מה למדתי

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