ארמין רונכר על harness מינימלי, אמון, והממשק שאף אחד עדיין לא פתר

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

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

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

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

למה Pi בעצם תפס

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

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

בעיית הממשק, ולמה זו בכלל לא בעיה של AI

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

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

למה לאוטונומיה מלאה יש תקרה אמיתית

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

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

הגדרה שמרנית להפתיע ביום-יום

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

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

הוצאות AI בארגונים מול מה שאנשים בפועל בונים

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

שופטים קוד פתוח רק בדיעבד

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

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

מה לוקחים מזה

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