לשחרר את כוחם של סוכני AI לקידוד יישומים מורכבים עם סקיילינג

נכתב על ידי פרית'ווי רג'אסקרן (Prithvi Rajasekaran), חבר בצוות ה-Labs שלנו.

במהלך החודשים האחרונים עבדתי על שתי בעיות קשורות: לגרום ל-Claude לייצר עיצובי פרונטאנד (Frontend) באיכות גבוהה, ולגרום לו לבנות יישומים שלמים ללא התערבות אנושית. עבודה זו החלה ממאמצים מוקדמים סביב יכולת עיצוב הפרונטאנד של Claude Code ו-ארכיטקטורת הריסון (harness) לסוכני קידוד ארוכי טווח, שם עמיתיי ואני הצלחנו לשפר את ביצועי Claude הרבה מעבר לבסיס באמצעות הנדסת פרומפטים ועיצוב ארכיטקטורת הריסון – אך שתי הגישות הגיעו בסופו של דבר לתקרה.

כדי לפרוץ את המגבלה, חיפשתי גישות חדשניות בהנדסת AI שיעבדו על פני שני תחומים שונים למדי: האחד מוגדר על ידי טעם סובייקטיבי, והשני על ידי נכונות ושימושיות ניתנות לאימות. בהשראת רשתות יריבות יוצרות (GANs), עיצבתי מבנה מרובה סוכנים עם סוכן יוצר (generator) וסוכן מעריך (evaluator). בניית מעריך שידרג תוצאות באופן אמין – ועם 'טעם' – דרשה תחילה פיתוח סט קריטריונים שיכול להפוך שיפוטים סובייקטיביים כמו 'האם העיצוב הזה טוב?' למונחים קונקרטיים וניתנים לדירוג.

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

מדוע יישומים נאיביים לא מספיקים

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

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

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

זה שונה מ'דחיסה' (compaction), שבה חלקים קודמים של השיחה מסוכמים במקום כך שאותו סוכן יכול להמשיך לעבוד על היסטוריה מקוצרת. בעוד שדחיסה שומרת על המשכיות, היא לא מספקת לסוכן דף נקי, מה שאומר שחרדת הקשר עדיין יכולה להתמיד. איפוס מספק דף נקי, במחיר של צורך ב-Artifact העברה עם מספיק מידע כדי שהסוכן הבא יוכל להמשיך את העבודה בצורה נקייה. בבדיקות המוקדמות שלנו, מצאנו ש-Claude Sonnet 4.5 הציג חרדת הקשר בעוצמה מספקת עד כדי כך שדחיסה לבדה לא הספיקה כדי לאפשר ביצועי משימות ארוכות חזקים, ולכן איפוס הקשרים הפך חיוני לעיצוב הריסון. זה פותר את בעיית הליבה, אך מוסיף מורכבות תזמור, תקורה של טוקנים וזמן אחזור לכל הרצת ריסון.

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

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

עיצוב פרונטאנד: הפיכת איכות סובייקטיבית לניתנת לדירוג

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

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

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

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

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

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

בניתי את הלולאה על ה- Claude Agent SDK, מה ששמר על התזמור פשוט. סוכן יוצר יצר תחילה פרונטאנד HTML/CSS/JS בהתבסס על פרומפט של משתמש. נתתי למעריך את ה-Playwright MCP, שאפשר לו לקיים אינטראקציה ישירה עם העמוד החי לפני דירוג כל קריטריון וכתיבת ביקורת מפורטת. בפועל, המעריך ניווט בעמוד בעצמו, צילם מסכים ולימד בקפידה את היישום לפני שהפיק את הערכתו. משוב זה זרם בחזרה ליוצר כקלט לאיטרציה הבאה. הרצתי 5 עד 15 איטרציות לכל יצירה, כאשר כל איטרציה דחפה בדרך כלל את היוצר לכיוון ייחודי יותר כשהוא הגיב לביקורת המעריך. מכיוון שהמעריך ניווט באופן פעיל בעמוד במקום לדרג צילום מסך סטטי, כל מחזור ארך זמן שעון קיר אמיתי. הרצות מלאות נמשכו עד ארבע שעות. כמו כן, הנחיתי את היוצר לקבל החלטה אסטרטגית לאחר כל הערכה: לחדד את הכיוון הנוכחי אם הציונים היו במגמת עלייה, או לעבור לאסתטיקה שונה לחלוטין אם הגישה לא עבדה.

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

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

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

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

סקיילינג לקידוד Full-Stack

עם ממצאים אלה ביד, יישמתי את התבנית בהשראת GAN על פיתוח Full-Stack. לולאת היוצר-מעריך ממפה באופן טבעי למחזור חיי פיתוח התוכנה, שבו ביקורת קוד ובדיקות QA ממלאות את אותו תפקיד מבני כמו מעריך העיצוב.

הארכיטקטורה

בארכיטקטורת הריסון ארוכת הטווח הקודמת שלנו, פתרנו את נושא הקידוד הקוהרנטי מרובה הסשנים באמצעות סוכן אתחול, סוכן קידוד שעבד תכונה אחת בכל פעם, ואיפוס הקשרים בין סשנים. איפוס הקשרים היה צעד מרכזי: הריסון השתמש ב-Sonnet 4.5, שהציג את הנטייה ל"חרדת הקשר" שהוזכרה קודם לכן. יצירת ריסון שעבד היטב על פני איפוס הקשרים הייתה המפתח לשמירה על המודל במשימה. Opus 4.5 הסיר במידה רבה את ההתנהגות הזו בעצמו, ולכן יכולתי להשמיט לחלוטין את איפוס הקשרים מהריסון הזה. הסוכנים הופעלו כסשן רציף אחד על פני כל הבנייה, כאשר הדחיסה האוטומטית של ה-Claude Agent SDK טיפלה בגדילת ההקשר לאורך הדרך.

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

מתכנן: ריסון ארוך הטווח הקודם שלנו דרש מהמשתמש לספק מפרט מפורט מראש. רציתי להפוך את השלב הזה לאוטומטי, ולכן יצרתי סוכן מתכנן שלקח פרומפט פשוט של 1-4 משפטים והרחיב אותו למפרט מוצר מלא. הנחיתי אותו להיות שאפתני לגבי היקף ולהישאר ממוקד בהקשר המוצר ובתכנון טכני ברמה גבוהה יותר, ולא ביישום טכני מפורט. דגש זה נבע מהחשש שאם המתכנן ינסה לציין פרטים טכניים גרעיניים מראש ויטעה במשהו, השגיאות במפרט יתגלגלו ליישום בהמשך. נראה היה חכם יותר להגביל את הסוכנים על התוצרים שיופקו ולתת להם להבין את הדרך תוך כדי עבודה. ביקשתי מהמתכנן גם למצוא הזדמנויות לשלב תכונות AI במפרטי המוצר. (ראו דוגמה בנספח למטה.)

יוצר: גישת ה"תכונה-אחת-בכל-פעם" מהריסון המוקדם יותר עבדה היטב לניהול היקף. יישמתי מודל דומה כאן, והנחיתי את היוצר לעבוד בספרינטים, לקחת תכונה אחת בכל פעם מהמפרט. כל ספרינט יישם את האפליקציה עם ערימת React, Vite, FastAPI ו-SQLite (מאוחר יותר PostgreSQL), והיוצר הונחה להעריך את עבודתו בעצמו בסיום כל ספרינט לפני העברה ל-QA. היה לו גם Git לבקרת גרסאות.

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

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

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

הרצת ארכיטקטורת הריסון

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

כתבתי את הפרומפט הבא כדי לייצר כלי ליצירת משחקי וידאו רטרו:

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

הטבלה למטה מציגה את סוג הריסון, משך ההרצה והעלות הכוללת.

הריסון היה יקר פי 20, אך ההבדל באיכות הפלט היה מיידי.

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

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

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

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

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

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

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

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

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

איטרציה על ארכיטקטורת הריסון

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

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

בזמן שעברתי על מחזורי איטרציה אלה, שחררנו גם את Opus 4.6, מה שסיפק מוטיבציה נוספת להפחתת מורכבות הריסון. הייתה סיבה טובה לצפות ש-4.6 יזדקק לפחות פיגומים מ-4.5. מבלוג ההשקה שלנו: "[Opus 4.6] מתכנן בקפידה רבה יותר, מקיים משימות סוכני למשך זמן רב יותר, יכול לפעול באופן אמין יותר בבסיסי קוד גדולים יותר, ובעל יכולות טובות יותר לביקורת קוד ולניפוי באגים כדי לתפוס את שגיאותיו שלו." הוא גם השתפר משמעותית בשליפה בהקשר ארוך. כל אלה היו יכולות שהריסון נבנה כדי להשלים.

הסרת מבנה הספרינט

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

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

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

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

תוצאות מריסון מעודכן

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

בנה DAW עם תכונות מלאות בדפדפן באמצעות ה-Web Audio API.

ההרצה עדיין הייתה ארוכה ויקרה, כ-4 שעות ועלויות טוקנים בסך 124 דולר.

רוב הזמן הוקדש לבונה, שרץ באופן קוהרנטי למעלה משעתיים ללא פירוק הספרינט ש-Opus 4.5 נזקק לו.

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

עם זאת, סוכן ה-QA עדיין תפס פערים אמיתיים. במשוב הסיבוב הראשון שלו, הוא ציין:

זו אפליקציה חזקה עם נאמנות עיצובית מצוינת, סוכן AI מוצק ובקאנד טוב. נקודת הכשל העיקרית היא שלמות התכונות – בעוד שהאפליקציה נראית מרשימה ושילוב ה-AI עובד היטב, מספר תכונות DAW ליבתיות הן תצוגה בלבד ללא עומק אינטראקטיבי: קליפים לא ניתנים לגרירה/הזזה על ציר הזמן, אין לוחות UI של כלי נגינה (כפתורי סינתסייזר, פדים של תופים), ואין עורכי אפקטים ויזואליים (עקומות EQ, מדי קומפרסור). אלו אינם מקרי קצה – אלו האינטראקציות הליבתיות שהופכות DAW לשימושי, והמפרט דורש אותן במפורש.

במשוב הסיבוב השני שלו, הוא שוב תפס מספר פערי פונקציונליות:

פערים שנותרו:
- הקלטת אודיו עדיין היא רק "פאנל" (הכפתור נדלק/כבה אך אין לכידת מיקרופון)
- שינוי גודל קליפ באמצעות גרירה בקצה ופיצול קליפים אינם מיושמים
- הדמיות אפקטים הן סליידרים מספריים, לא גרפיים (אין עקומת EQ)

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

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

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

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

מה הלאה

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

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

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

תודות

תודה מיוחדת למייק קריגר (Mike Krieger), מייקל אגבי (Michael Agaby), ג'סטין יאנג (Justin Young), ג'רמי הדפילד (Jeremy Hadfield), דיוויד הרשי (David Hershey), ג'וליוס טארנג (Julius Tarng), שיאויי ג'אנג (Xiaoyi Zhang), בארי ג'אנג (Barry Zhang), אורוואה סידקר (Orowa Sidker), מייקל טינגלי (Michael Tingley), איברהים מדאה (Ibrahim Madha), מרטינה לונג (Martina Long) וקניון רובינס (Canyon Robbins) על תרומתם לעבודה זו.

תודה גם לג'ייק איטון (Jake Eaton), אליסה ליאונרד (Alyssa Leonard) וסטף סקווירה (Stef Sequeira) על עזרתם בעיצוב הפוסט.

נספח

דוגמה לתוכנית שנוצרה על ידי סוכן מתכנן.

RetroForge - 2D Retro Game Maker

Overview
RetroForge is a web-based creative studio for designing and building 2D retro-style video games. It combines the nostalgic charm of classic 8-bit and 16-bit game aesthetics with modern, intuitive editing tools—enabling anyone from hobbyist creators to indie developers to bring their game ideas to life without writing traditional code.

The platform provides four integrated creative modules: a tile-based Level Editor for designing game worlds, a pixel-art Sprite Editor for crafting visual assets, a visual Entity Behavior system for defining game logic, and an instant Playable Test Mode for real-time gameplay testing. By weaving AI assistance throughout (powered by Claude), RetroForge accelerates the creative process—helping users generate sprites, design levels, and configure behaviors through natural language interaction.

RetroForge targets creators who love retro gaming aesthetics but want modern conveniences. Whether recreating the platformers, RPGs, or action games of their childhood, or inventing entirely new experiences within retro constraints, users can prototype rapidly, iterate visually, and share their creations with others.

Features
1. Project Dashboard & Management
The Project Dashboard is the home base for all creative work in RetroForge. Users need a clear, organized way to manage their game projects—creating new ones, returning to works-in-progress, and understanding what each project contains at a glance.

User Stories: As a user, I want to:

- Create a new game project with a name and description, so that I can begin designing my game
- See all my existing projects displayed as visual cards showing the project name, last modified date, and a thumbnail preview, so that I can quickly find and continue my work
- Open any project to enter the full game editor workspace, so that I can work on my game
- Delete projects I no longer need, with a confirmation dialog to prevent accidents, so that I can keep my workspace organized
- Duplicate an existing project as a starting point for a new game, so that I can reuse my previous work

Project Data Model: Each project contains:

Project metadata (name, description, created/modified timestamps)
Canvas settings (resolution: e.g., 256x224, 320x240, or 160x144)
Tile size configuration (8x8, 16x16, or 32x32 pixels)
Color palette selection 
All associated sprites, tilesets, levels, and entity definitions

...