הבלוג של ינון פרק

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

סט מיומנויות ראשון קשור לארכיטקטורה של מערכות תוכנה. ספר התכנות הראשון שהתבקשתי לקנות באוניברסיטה נקרא Structure and Interpretation of Computer Programs והוא כולו עסק בשאלות האלה, מהו המבנה הנכון של מערכות תוכנה. בשנים מאז יצא מערכות תוכנה הלכו והשתכללו, הלכו והסתבכו והשאלות לגבי המבנה הנכון שלהן רק הפכו קשות יותר. אלה שאלות שאין להן תשובה אחת נכונה והמפתח לגשת אליהן הוא לחפש את האיזונים, מה מרוויחים ומה מפסידים בכל בחירה.

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

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

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

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

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

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

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

1. אי אפשר לדעת מתי PR יאושר או מה תהיה האיכות שלו בסוף.

2. אי אפשר לדעת כמה טוקנים זה יעלה.

3. כמעט תמיד נדרשת התערבות אנושית כדי לצאת מהלופ.

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

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

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

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

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

1. מתוך paseo כל פעם שרוצים סביבה מקבילית נוספת לוחצים על יצירת סביבה.
2. פסאו יוצר worktree חדש.
3. נכנסים לסוכן בתוך הסביבה החדשה ומבקשים מ paseo שהסוכן הזה ירוץ בתוך Docker Sandbox.

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

מה צריך? בסך הכל לא הרבה.

מתקינים Docker Sandbox מכאן: https://docs.docker.com/ai/sandboxes/

מתקינים paseo מכאן: https://paseo.sh/

ומוסיפים לקובץ ההגדרות של paseo שנקרא ~/.paseo/config.json את הבלוק הבא שמגדיר סוכן שרץ בתוך ארגז חול של דוקר:

  "agents": {
    "providers": {
      "sandbox-codex": {
        "extends": "codex",
        "label": "Codex in sandbox",
        "command": [
          "bash",
          "-c",
          "set -eu; if [ -z \"${PASEO_AGENT_CWD:-}\" ]; then exec sbx exec -i paseo-codex-discovery codex \"$@\"; fi; workspace=\"$PASEO_AGENT_CWD\"; sandbox=\"paseo-$(printf '%s' \"$workspace\" | cksum | awk '{print $1}')\"; sbx run --detached --name \"$sandbox\" codex \"$workspace\" >&2; exec sbx exec -i --workdir \"$workspace\" \"$sandbox\" codex \"$@\"",
          "paseo-sandbox-codex"       
        ]
      }
    }
  }

קצת מכוער אני יודע כי כל החיבורים אצלנו אבל עובד ממש יופי.

חסרונות? גם יש:

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

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

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

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

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

לטענתם חבילת הבדיקות גדלה כמעט פי 4 מאז תחילת השנה עם קצב גידול בדיקות של 2,000 בדיקות חדשות בשבוע.

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

השאלות של פיתוח תוכנה היום הן לא איך לכתוב לולאת for או מה ה API של AWS. את כל אלה ה AI פתר ואני שמח להשתמש בכוחות העל החדשים שלנו. לעומתן השאלות האלה לא קרובות אפילו לפתרון:

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

2. איזו תשתית תתאים למערכת שאני בונה? מה התפקיד של כל רכיב בתשתית? מה העלות? איך לאזן מחירים ויתירות?

3. איך לגשת לחלקים הלא מאופיינים של המערכת? מה קורה כשזה נשבר? איך לדאוג שהמערכת תיפול על הרגליים כשהיא נופלת? כמה uptime אני דורש? כמה downtime אני מוכן לקבל?

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

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

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

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

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

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

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

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

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

עכשיו לסיפור בואו נראה מה הבעיות בו:

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

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

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

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

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

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

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

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

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

ריילסוולרלד נפתח עם הרצאת פתיחה מעוררת השראה ומפתיעה של DHH אני ממליץ לצפות בה:

https://www.youtube.com/watch?v=vDjW_dRyKXY

ואני ממליץ גם על מאמר התגובה המקיף של Jardo כאן:

https://jardo.dev/what-about-rails

עיקרי הדברים של DHH:

1. כתיבת קוד בצורה ידנית (הקלדת התווים) כבר לא כלכלית באופן גורף.

2. הרבה יותר קוד נוצר היום מאשר אי פעם בעבר. גם DHH עצמו יוצר היום (בעזרת סוכני קידוד) משמעותית יותר קוד ממה שיצר פעם.

3. המהפכה שעבר עולם התוכנה מזכירה את מהפכת הציור-צילום עם המצאת המצלמה.

4. קוד שנוצר רק בשביל שיהיה נוח למתכנתים הולך להיעלם. ב 37signals הם הולכים בדרך של שופיפיי ומחליפים את אפליקציות ה Mobile Web שלהם באפליקציות נייטיב מלאות. הוא לא רואה עתיד לפריימוורקים כמו React Native או אפילו Hotwire Native.

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

6. גם בצד השרת יש סימן שאלה גדול לגבי ספריות שכל מטרתן להקל על המתכנתים על חשבון הביצועים של המערכת. טיעון הפרודקטיביות מפסיק להיות רלוונטי כשאנחנו בונים מערכות עם AI. את Hey הם משכתבים להשתמש ב Rust API Backend במקום Rails.

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

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

אני חושב ש DHH כמו DHH עוד ישנה את דעתו לגבי חלק מהסעיפים שם. במיוחד הסיפור של ארכיטקטורת תוכנה וחוסר היכרות עם הטכנולוגיה, שני סעיפים שבניסיון שלי בעבודה הרגשתי בדיוק את ההיפך, כלומר שככל שיש לי יותר היכרות עם הכלים, עולם התוכן והיכולות אני מצליח לקבל עבודה יותר טובה ויותר פיצ'רים מהסוכן. צריך לזכור שהתחרות שלנו היא לא מול מפתחים של לפני 5 שנים אלא מול מפתחים של היום, להם יש גישה לאותם הכלים ולאותן היכולות. מישהו צריך לשים לב ש Rust ייתן Backend יעיל יותר מ Rails ועם פחות שגיאות מ C++, מישהו צריך לשים לב לצריכת הטוקנים וליחס בין טוקנים למוצר, מישהו צריך לשים לב מה קורה כשדברים נשברים והכי חשוב לקבל החלטות טכניות שקשורות לאופן העבודה של המערכת. עד היום לא ראיתי שמודלי שפה מאוד טובים בקבלת החלטות.

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

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

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

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

ולבנות כזו מערכת זה לא קשה. זוכרים ה AI יכול לכתוב את כל הקוד או ככה מספרים. תנו לו.

ועכשיו תנסו קצת Use Cases:

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

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

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

4. סוכן שיושב לבד על הלינקדאין ואוסף לידים (ובאמת מביא לידים איכותיים שממירים ללקוחות).

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

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