"המודלים מתו": פורסטן בול, מהנדס מייסד ב-AMP, על סוף עידן הניהול הצמוד של סוכני קוד

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

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

"המודלים מתו" - וזה לא אומר מה שזה נשמע

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

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

גרפים של תרומות מתים, וקוד נהיה זול

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

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

תפסיקו לחנות באגים ב-backlog - הפעילו סוכן במקום

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

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

סלופ הוא בעיה אנושית, לא בעיה של AI

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

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

איך הוא בפועל כותב פרומפט

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

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

Orbs: לארוז את הסוכן, ההקשר, והשינוי בקישור אחד

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

החלק שהוא רואה בו משהו באמת חדש: החישוב שיצר שינוי, ההקשר שעיצב אותו, והדיף שנוצר - כולם חיים מאחורי קישור אחד שאפשר לשתף. השוו את זה למודל הישן של branch מקומי, בנוסף לפייפליין CI נפרד, בנוסף לתיאור PR שמסביר רק חלקית למה השינוי נעשה. עמית לצוות יכול לפתוח את הקישור, לראות את כל שרשרת ההיגיון, ולקחת על עצמו את ה-10% האחרונים בעצמו.

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

מה זה אומר אם בונים משהו חדש

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

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

התובנה המרכזית

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