שישי שמח! אמנם קמתי מוקדם כמו מידי יום שישי, אבל הפעם כדי להשתתף בריצת חצי מרתון. זו הסיבה שהמהדורה מתפרסמת היום באיחור, והטון שלי אולי יהיה מלא אדרנלין יותר מהרגיל.
השבוע בבלוג שלי באנגלית, פרסמתי פוסט שטען שמה שבעיקר אפשר ללמוד מההיסטוריה של האינטרנט, הוא שמעברי פרדיגמה מתעצבים בדרכים מאד מפתיעות, שקשה לצפות מראש. חברות עם יתרונות חזקים עלולות להיכשל בלתרגם אותם לעולם החדש, ותחזיות מוקדמות מדי לגבי ההצלחה שלהן עלולות להיכשל. אפשר לקרוא אותו כאן.
קדימה -
פיתוח תוכנה ומעברי פרדיגמה
שמעתי שאתה אולי עומד לעשות משהו עם מחשבים. אם אתה הולך להיכנס לזה, רק תוודא שאתה באמת אוהב את זה. ויהיה לך כיף ומעניין להתעסק בזה גם מחוץ לעבודה.
זו העצה שקיבלתי מחבר של ההורים שלי, כשהייתי בתיכון והתמיינתי למסלולים שונים בצבא בתחילת שנות האלפיים. הוא בעצמו עבד במחשבים (אני אפילו לא בטוח באיזה תפקיד), ועשור קודם לכן היה זה שהכיר לי את מערכת ההפעלה ווינדוס (3.1!) ואיך להשתמש בעכבר. הוא צחק שהבן שלו תפס את זה יותר מהר מאשר חלק מהאנשים אצלו בעבודה.
בשלב הזה, עם זאת, הוא הסביר שכדי להצליח במקצוע הזה, צריכים לחזור הביתה מיום שלם של עבודה ולבלות זמן בערב בללמוד טכנולוגיות חדשות. הוא שם לב שזה מה שעושים האנשים סביבו שמצליחים ומתקדמים. אבל הוא רצה לחזור הביתה מהעבודה ולראות ספורט. לא לקרוא ספרים על האינטרנט, ופרוטוקולי תקשורת, ובניית אתרים. והוא אכן החליף מקצוע כמה שנים לאחר מכן.
תמיד החשבתי את עצמי בר-מזל על התזמון שבו הקריירה שלי החלה. המערכות הראשונות שבניתי נועדו להיות מותקנות on-premise, אצל הלקוח. אז למדתי איך הפרדיגמה הזו עבדה. אבל עדיין הייתי קצת מעל גיל 20 כשהחל עידן הקלאוד, והייתי גמיש מחשבתית מספיק כדי להתלהב מללמוד על התשתיות והארכיטקטורות ומתודולוגיות העבודה שפותחו עבורו. אג׳ייל וסקראם וטסטים ו continuous deployment, איטרציות מהירות ואנליטיקס ומיקרו-שירותים ודאטהבייסים לא רילציוניים עם סקייל אינסופי.
קצת ריחמתי על האנשים בעבודה שהיו אז מעל גיל 40; כאלה שנחשבו למתכנתים תותחים בעידן של ניהול זיכרון ב-C ועבודה עם ה kernel של מערכת ההפעלה. וידעו איך להוציא גרסה, כזו שיהיה אפשר להתקין על שרת ולשלוח בקונטיינר פיזי (לא kubernetes) לאתר של הלקוח, ולהיות בטוחים שהיא תרוץ ללא תקלות. ופתאום אמרו להם שהם צריכים ללמוד מחדש איך לתכנת. ועוד ממישהו שצעיר מהם בעשרים שנה.
אמנם הזכרתי חלק מהדברים האלה בפרקים 3 ו-4 של אופטיקאסט על הקלאוד, אבל כמעט ולא כתבתי כאן על פיתוח תוכנה במהלך 141 המהדורות הקודמות. וכנראה שעל מתודולוגיות הפיתוח של עידן ה-SaaS כבר לא אכתוב, כי העידן הזה מגיע לסיומו.
עם מעבר הפרדיגמה הנוכחי ל-AI, אני בצד השני, של המתכנתים המבוגרים, שהניסיון הרב שצברו עומד להפוך ללא רלוונטי. אולי אפילו למעמסה. כי ההרגלים ודרכי החשיבה הישנות – שהיו רלוונטיים לעידן הקלאוד והמובייל – מושרשים עמוק.
ראיתי כמה קשה זה היה למתכנתים הותיקים במעבר הפרדיגמה הקודם. מהמתכנתים הכי חזקים בחברה, הם הפכו לאיטיים. הם התעכבו כי לא סמכו על ניהול הזיכרון או האופטימיזציות של ה-JVM. בזמן שהמתכנתים הצעירים יכלו לעשות איטרציות מהירות ולהשיק קוד שנכתב לרף של שרת production שניתן להמשיך לעדכן בו גרסאות (לא כזה שעולה על אוניה ויהיה קשה מאד לעדכן).
וזה לא היה קשה רק למהנדסים; בחברה שעבדתי בה בזמנו, שמכרה מערכות תוכנה on-premise והתנהלה במודל Waterfall עם מיקרו-מנג׳מנט קפדני למתכנתים – הכריזו יום אחד על מעבר לסקראם. לצורך כך נשכר יועץ, שהעביר קורסים לכל צוותי הפיתוח, הבטיח שהפרוייקטים יסתיימו מהר יותר ועם פחות לחץ, ובהמשך ליווה את התהליך. מאד שמחתי כמובן, כי קראתי במשך שנים על מתודולוגיות אג׳ייל שונות, ועוד קודם לכן יישמתי סקראם בצוות שלי. אלא שמהר מאד הבנתי שההתנהלות לא השתנתה, היא רק לבשה עטיפה של סקראם; הפרוייקט חולק לספרינטים של שלושה שבועות, אבל התכולה של כל הספרינטים, ומה יוצג בדמו של סוף כל ספרינט, תוכנן מראש לחצי שנה קדימה. מדי בוקר עשינו פגישת סטטוס בעמידה שבה עברנו על משימות שנכתבו על פתקים צהובים, אבל היא הייתה יכולה להימשך גם קרוב לשעה אם אחד המשתתפים היה מדווח שמשימה התעכבה בחצי יום (ומנהלים היו מוזעקים לבצע התאמות בתכנית העבודה).
זה כמו עיקרון פולחן המטען (Cargo Cult), שאמיל ואני הזכרנו גם בהקשר של אפל אחרי סטיב ג׳ובס (אופטיקאסט פרק 61): לאחר שראו מטוסים צבאיים מביאים אספקה לחיילים אמריקאיים שהוצבו באיים באוקיינוס השקט במהלך מלחמת העולם השניה, התושבים הילידים החלו לבנות מסלולי נחיתה ולערוך מצעדים צבאיים – גם לאחר שהמלחמה הסתיימה והחיילים עזבו – מתוך הנחה שזה יגרום למטוסי אספקה להופיע. באופן דומה, ההנהלה באותה חברה הניחה שאם תשכור יועצים והמהנדסים ידברו בעמידה על משימות שכתובות על פתקים צהובים, הפרוייקט יסתיים יותר מהר. זה כמובן לא קרה. ודבר דומה כנראה קרה בהרבה חברות: לאנשים קל לאמץ טקסים ומנהגים, אבל קשה הרבה יותר להבין לעומק את הפילוסופיה שמאחוריהם ולשנות תרבות והרגלים.
הדבר הנכון הוא – עד כמה שזה קשה – למחוק את ההרגלים הישנים. לשכוח מהם. לאפס את ה context window. ולבחון בראש פתוח וסקרן איך תוכנה צריכה להיבנות בעידן ה-AI. ומהם הרגלי העבודה והכלים והתשתיות הנכונות כדי לעשות את זה.
דמיינו ארגון תוכנה קלאסי בלי שום כלים מבוססי AI. יהיו לכם, אתם יודעים, 50 אנשים שעושים דברים וסגנון האינטראקציה שלהם עומד באופן טבעי להיות מאד היררכי [...]
אבל אם יהיו לכם, אתם יודעים, חמישה אנשים שכל אחד מנהל 50 סוכנים וירטואליים, אולי הם יוכלו שתהיה להם תקשורת הרבה יותר גבוהה בין חמשת האנשים האלה.
זה המהנדס האגדי ג׳ף דין, שהיום ממלא את תפקיד המדען הראשי של גוגל, כשהתארח לאחרונה בפודקאסט. אם אתם לא מכירים אותו, הוא הצטרף לחברה בשנת 1999 בתור אחד המהנדסים הראשונים, וידוע בתור מי שבנה את התשתית בסקייל אינסופי, שהייתה נחוצה בשביל מנוע חיפוש שיאנדקס את כל האינטרנט ויחזיר תוצאות בתוך שברירי שניה. (וכן, זה הנושא שהבטחתי לכסות בפרק הבא של אופטיקאסט, ואני יודע שהוא מתעכב. התאזרו בסבלנות). תשתיות כמו MapReduce או BigTable או Spanner, שהיו חלק ממה שהפך מהנדסים בגוגל לעשרות מונים יותר פרודוקטיביים מאשר מתכנתים מחוץ לגוגל בתחילת שנות האלפיים. זה גם מה שאיפשר לחברה – לצד מנוע החיפוש שהמשיך להשתפר – להדהים עם סדרת מוצרים כמו ג׳ימייל ו Maps ודרייב ויוטיוב2, שהיו פורצי דרך בזמנו, והרבה מעבר למה שאנשים האמינו שאפשר לעשות עם אפליקציה שרצה בדפדפן. ובהמשך כמובן, את כרום עצמו.
עם השנים גוגל פרסמה מאמרים לגבי המערכות האלה, נבנו מימושים בקוד פתוח, ובהמשך גם קמו חברות תשתית – בהרבה מקרים על ידי פאונדרים יוצאי גוגל – ששאבו השראה מהמערכות הפנימיות בחברה. הידע והכלים חלחלו לשאר התעשיה, ובסופו של דבר הפער בפרודוקטיביות שהיה קיים בתחילת שנות ה-2000, נסגר במהלך שנות ה-2010, ככל שהעננים הפומביים הלכו והתקדמו.
חזרה לג׳ף דין – בתוך גוגל הוא נחשב למהנדס כה נערץ, עד כדי כך שיש מסמך פנימי של ״עובדות״ לגביו, בסגנון צ׳אק נוריס. דברים כמו “ג׳ף דין מריץ בדיקות לפני שהוא דוחף את הקוד שלו, אבל רק כדי לוודא שאין באגים בקומפיילר״, או ״בתחילת שנות האלפיים, שרתי האינדקס קרסו וג׳ף דין ענה ידנית על שאילתות של יוזרים במשך כמה שעות. מדד האיכות הראה שיפור של חמש נקודות״.
הזכרתי אותו במהדורה 95, שעסקה בהיסטוריה של מהפיכת ה-AI הנוכחית, וספציפית איך ג׳ף דין חבר לג׳ופרי הינטון בהובלת מאמצי הבינה המלאכותית של גוגל. הוא גם יזם את פרוייקט ה-TPU, שבב האצת ה-AI שגוגל פיתחה לעצמה. ומכל הסיבות האלה, חשבתי שיהיה מעניין להתעכב על מה שיש לו לומר, בפתחו של סייקל נוסף של מעבר פרדיגמה טכנולוגי. כשפערים שוב נוצרים בין אלו שמפצחים מוקדם איך למנף את הטכנולוגיה החדשה, לבין אלו שמתמהמהים. סביר להניח שבמעבדות ה-AI הגדולות נהנים מגישה למודלים פנימיים, כלים שטרם שוחררו, וכמות בלתי מוגבלת של טוקנים, שמאפשרת למהנדסים שם להיות הרבה יותר פרודוקטיביים.
משהו שג׳ף דין הזכיר הוא החשיבות הגוברת של כתיבת specification ברורים, מאחר ואנגלית הפכה לשפת התכנות החדשה:
כשלימדו אנשים איך לכתוב תוכנה, לימדו אותם שזה מאד חשוב לכתוב מסמכים מאד ברורים, אבל אף אחד לא באמת האמין בזה. זה היה כאילו, כן, וואטאבר. אני לא צריך לעשות את זה. לכתוב את המסמכים בשפה האנגלית אף פעם לא היה תוצר שבאמת נתנו לו הרבה תשומת לב. כלומר, זה היה חשוב, אבל זה לא היה מסוג הדברים שדחפו תהליך יצירתי אמיתי.
אם אתם מגדירים תוכנה שאתם רוצים שהסוכן יבנה עבורכם, כדאי שתהיו מאד זהירים לגבי איך אתם מגדירים את זה כי זה הולך להכתיב את האיכות של התוצר. אם לא תזכירו שזה צריך לטפל גם בדבר הזה, או שזה מקרה קצה ממש חשוב, או שאכפת לכם מאד מהביצועים של החלק הזה – זה אולי לא יעשה את מה שאתם רוצים [...]
אחד הדברים שאני חושב שאנשים ישתפרו בו זה להיות ממש טובים בלהגדיר דברים ולא להשאיר מקום לעמימות.
וטיפ אחרון, על החשיבות של מסמכים שמגדירים עקרונות כלליים לפיתוח תוכנה:
אני חושב שמדריכים כתובים היטב של איך לעשות הנדסת תוכנה טובה עומדים להיות שימושיים, כי הם יוכלו לשמש כקלט למודל, וגם מפתחים יוכלו לקרוא אותם כדי שהפרומפטים שלהם יהיו ברורים יותר לגבי מה מערכת התוכנה צריכה לעשות.
[...] אפשר לדמיין אחד בשביל מערכות מבוזרות: תחשוב על כשלונות מהסוגים האלה, והנה טכניקות להתמודדות עם כשלונות, כמו להחזיק רפליקה או לשלוח את אותה בקשה לשתי מקומות כשצריך שרק אחד מהם יחזור. תיאור קצר של 20 טכניקות מהסוג הזה לבניית מערכות מבוזרות כנראה יעזרו מאד לאייג׳נט להיות מסוגל להרכיב מערכות יותר עמידות ואמינות.
חברה שמדהימה את העולם עם השקות והכרזות על בסיס יומי לאחרונה, במובן שאולי מזכיר את גוגל של תחילת שנות ה-2000, היא אנת׳רופיק. הזכרתי לפני שבועיים את מודל מח-הכוורת ומדורת-השבט שבו הם עובדים. זה דומה למה שג׳ף דין תיאר למעלה, חמישה מהנדסים שכל אחד מריץ עשרות אייג׳נטים, ומדברים הרבה ביניהם. נראה שגם באנת׳רופיק המהנדסים נמצאים בחזית הפרודוקטיביות של פיתוח עם AI, וסביר שהם גם כבר חיים בעתיד, עם גישה לכלים ופרקטיקות שעדיין לא זמינים באופן נרחב.
בוריס צ׳רני, המפתח שבנה את קלוד קוד, התארח לאחרונה בפודקאסט של Y Combinator, וסיפר שם על הפיתוח של קלוד Cowork, המוצר שמתקדם בקצב מרהיב (וכנראה ראוי שנרחיב עליו במהדורות עתידיות):
קלוד כתב את קו-וורק. אנחנו בני האדם נפגשים פנים-אל-פנים כדי לדבר על ההחלטות המהותיות בקשר לארכיטקטורה והמוצר, אבל כל אחד מאיתנו המתכנתים מנהל איפשהו בין 3 ל-8 instances של קלוד שמממשים פיצ׳רים, מתקנים באגים, או חוקרים פתרונות אפשריים.
אבל איך אפשר להגיע למצב שה-AI מייצר לבד קוד שאפשר להרגיש בנח לדחוף לפרודקשן?
מפעל לייצור תוכנה
אם אתם רק משתמשים ב-ChatGPT לכתוב את ה regex שלכם, אתם לא באמת מקבלים את היתרונות של הירידה בעלות כתיבת הקוד. אתם סתם מקלידים יותר מהר.
ראיתי כבר עשרות חברות מתקשות לתת ל-AI לכתוב קוד, וכל אחת מהן עברה דרך חמש שלבים ברורים של אוטומציה.
רמה אפס היא עבודה ידנית (״הוולוו של ההורים שלכם, אולי עם גיר אוטומטי״). אתם אולי משתמשים ב-AI כתחליף ל stack overflow, או מדי פעם לוחצים טאב בשביל לקבל השלמה אוטומטית. אבל הקוד הוא לגמרי שלכם.
ברמה אחד אתם מתייחסים ל-AI כמו ל intern. מתכנת במשרת סטודנט. המקבילה של שמירה על נתיב או cruise control. אתם עדיין כותבים את כל הדברים החשובים, אבל מעבירים משימות קטנות וברורות לסטודנט-AI שלכם. כמו לכתוב טסט או להוסיף תיעוד מעל הפונקציה. אתם מהירים יותר, אבל העבודה שלכם לא השתנתה.
זה הזכיר לי את מה שבן אוונס כינה בתור ״חשיבת לגאסי״ ב-2023, כש ChatGPT רק הגיע והדבר העיקרי שאנשים הצליחו לעשות איתו היה לנסח אימיילים טוב יותר, או מהצד השני – לסכם אותם:
בכל פעם שאנחנו מקבלים כלי חדש, אנחנו מתחילים בלהכריח אותו להתאים לדרכי העבודה הנוכחיות שלנו, ואז עם הזמן אנחנו משנים את העבודה כדי להתאים לכלי החדש. אנחנו מנסים להתייחס ל-ChatGPT כאילו שזה גוגל או דאטהבייס במקום לשאול למה זה שימושי. איך אנחנו יכולים לשנות את העבודה כדי לנצל את זה?
כדי להתקדם הלאה בסולם, העבודה עצמה – וזה כולל גם את התהליכים והתרבות הארגונית – צריכים להשתנות.
ברמה שתיים, יש לכם נהיגה עצמאית בכביש המהיר. יש לכם מתכנת צעיר שאפשר לתת לו לעשות בשבילכם את כל הדברים המשעממים. כאן נמצאים 90% מהמתכנתים שהם ״AI-native״ כרגע. אתם הרבה יותר פרודוקטיביים משאי פעם הייתם. כבר לא עושים קופי-פייסט מחלון צ׳אט, אלא משתמשים בכלי AI-coding נייטיבי. הסכנה כאן (ובשלבים הבאים) היא שזה מרגיש כאילו כבר סיימתם. אבל אתם עדיין לא סיימתם.
רמה שלוש היא וויימו עם נהג בטיחות. אתם כבר לא מפתח סניור, כי זו עכשיו העבודה של ה-AI. אתם… המנהלים שלו. Human in the loop. יש לכם coding agent שתמיד מריץ כמה טאבים במקביל. אתם בעיקר עושים code review. החיים שלכם הם diffs. זה השלב שבו הרבה אנשים מרגישים שהמצב נהיה גרוע יותר. ופה כמעט כולם נתקעים.
רמה ארבע היא רובוטקסי, שמאפשר לכם לעשות משהו אחר בזמן שהוא נוהג. אתם לא מפתחים. אתם לא מנהלי פיתוח. הפכתם למנהלי מוצר. אתם כותבים spec, מייצרים skills (בקלוד קוד, הכלי שאיתו נראה שמרבית מפתחי רמה 4 בוחרים לעבוד). מתכננים לו״חות זמנים, עוברים על התכניות. הולכים הביתה בערב, חוזרים למחרת בבוקר, ובודקים האם הטסטים עוברים.
שפירו (מחבר הפוסט) טוען שזו הרמה שבה הוא נמצא.
ברמה חמש – המקבילה של אוטונומיות מלאה – זו כבר אפילו לא מכונית. אתם לא חלק מתהליך של פיתוח תוכנה. זה הפך לקופסא שחורה, שהופכת spec למערכת ופיצ׳רים. הוא קורא לזה ״מפעל חשוך לתוכנה״, בהשראת רעיון ה-dark factory בייצור, מפעל שבו רובוטים מפעילים את כל תהליך הייצור ללא מעורבות אנושית (ולכן הוא יכול לעבוד ללא תאורה):
אני מכיר מעט אנשים שעושים את זה. הם צוותים קטנים, פחות מחמישה אנשים. והם עושים את מה שהוא כמעט בלתי אפשרי – וזה כנראה יהיה העתיד שלנו.
אני אסתייג ואומר שהחזון הזה עדיין כנראה רחוק; לפי מנהל התשתיות של OpenAI, שהתארח לפני חודשיים בפודקאסט של לני, קודקס כבר כתב את הרוב המוחלט של הקוד בחברה, אבל לא את כולו. ומרבית ה-review מתבצע באופן אנושי. כלומר גם ב-OpenAI, מרבית המפתחים עדיין איפשהו בין רמה 3 ל-4 (נכון לחודש דצמבר האחרון).
הרעיון גם מעלה סקפטיות: איך אפשר לסמוך על המערכות שנבנות במפעל התוכנה הזו? מה לגבי אבטחה, רגולציה, יציבות, אמינות? איזו חברה רצינית תסכים להשתמש במערכת שנבנתה על ידי ״מפעל תוכנה״ כזה? אלו שאלות שעלו גם בימים הראשונים של הקלאוד (זה רק לסטארטאפים, אף חברה רצינית לא תריץ מערכות ותשמור דאטה על שרתים של חברה אחרת), ולמעשה בכל המהפכות הקודמות. זה לקח הרבה זמן לסמוך על קומפיילרים שיתרגמו קוד שנכתב בשפה עילית לאסמבלי, או על הממשק של מערכת ההפעלה שיכתוב ויקרא מידע מהדיסק או הזיכרון, או על מערכת דאטהבייס שתנהל מידע רגיש בעצמה ותחזיר תוצאות אמינות לשאילתות.
אז כמו כל טכנולוגיה שהיא דיסראפטיב, זה כנראה ייקח זמן עד שהתשתיות והכלים ילוטשו. ועד שהמודל הזה יחצה את הקאזם, והמיינסטרים של השוק ירגיש איתו בנח. כנראה שאם פשוט נמתין, זה גם יהיה הרבה יותר קל להתחיל, כשהכל כבר יהיה עטוף היטב. אבל יכולים גם להיות יתרונות ללהתנסות מוקדם. וזה גם די מעניין. הנה דוגמא לצוות כזה שמנסה:
בנינו מפעל תוכנה: פיתוח ללא אינטראציה שבו specs + scenarios מניעים אייג׳נטים שכותבים קוד, מריצים harnesses, ומתכנסים ללא review אנושי [...]
המנטרה:
למה אני עושה את זה? (רמז: המודל צריך לעשות את זה במקומכם)
החוקים:
אסור שקוד ייכתב על ידי בני אדם.
אסור ש-review לקוד יתבצע על ידי בני אדם.
ובפרקטיקה:
אם לא הוצאתם לפחות 1,000 דולר על טוקנים פר מהנדס אנושי היום, למפעל התוכנה שלכם יש לאן להשתפר.
המונח harness הוא חשוב בהקשר הזה; בעברית זה אומר ״לרתום״, כמו שעושים עם רצועות שרותמים על סוס. הן נועדו גם להגביל את החופש שלו ולמנוע ממנו להתפרע, וגם לאלץ אותו לבצע משימה עבורנו (לגרור עגלה במקרה הזה). StrongDM כתבו על טכניקה מעניינת בהקשר הזה; כמובן שדרושים הרבה טסטים אוטומטיים כדי להרגיש בנח עם קוד שבני אנוש לא כתבו ואפילו לא עברו עליו. טסטים ששמורים יחד עם הקוד, עם זאת, מאפשרים לאייג׳נט עצלן לשנות אותם. הם שמו לב שה-AI לקח קיצורי דרך, כמו לצמצם את כמות הבדיקות בטסטים, או אפילו להחליף אותם ב״return true״ בחלק מהמקרים.
הפיתרון שהגיעו אליו הוא לבצע בדיקות לפי scenarios (תרחישים), שהמודל לא נחשף אליהם בזמן הפיתוח:
השימוש שלנו במילה תרחיש מייצג יוזר סטורי מקצה-לקצה, שלרוב שמור מחוץ לבסיס הקוד (כמו דאטהסט ״holdout״ באימון מודלים), שניתן להבנה אינטואיטיבית ואפשר לוודא אותו בגמישות על ידי מודל שפה גדול.
בגלל שהרבה מהתוכנה שאנחנו מגדלים בעצמה מכילה רכיב אייג׳נטי, עברנו מהגדרה בוליאנית של הצלחה (״הטסטים ירוקים״) להגדרה אמפירית והסתברותית. אנחנו משתמשים במונח שביעות רצון כדי לכמת את הולידציה: מתוך כל המסלולים שנצפו במהלך כל התרחישים, איזה אחוז מהם סביר שהשביע את רצונו של היוזר?
זה רעיון מרתק להתייחס לתרחישים כמו שמתייחסים ל holdout set באימון מודלים – חלק של הדאטה שנשמר בצד ולא משתמשים בו במהלך האימון – ולא לאפשר לאייג׳נטים לראות אותם במהלך כתיבת הקוד. זו מעין אוטומציה לביצוע בדיקות מערכת על ידי צוות QA חיצוני.
מה שמוביל לעוד קונספט מעניין: Digital Twin Universe (DTU) – סימון ווילסון ציין שהתוכנה שהם בונים עוזרת לנהל הרשאות של משתמשים על פני סוויטה של שירותים מחוברים. זה כלשעצמו מעניין, כי תוכנת אבטחה היא הדבר האחרון שהייתם מצפים שייבנה באמצעות קוד LLM ללא review!
מרחב תאום דיגיטלי הוא העתקים שמתנהגים כמו שירותי צד-שלישי שהתוכנה שלנו תלויה בהם. בנינו תאומים דיגיטליים של אוקטה, ג׳ירה, סלאק, גוגל דוקס, גוגל דרייב, וגוגל שיטס, שמשכפלים את ה APIs, מקרי הקצה וההתנהגויות שלהם.
עם DTU, אנחנו יכולים לוודא בנפחים וקצבים הרבה יותר גבוהים ממה שמערכות פרודקשן מגבילות. אנחנו יכולים לבחון מקרי כישלון שיהיה מסוכן או בלתי אפשרי לבדוק כנגד שירותים רצים. אנחנו יכולים להריץ אלפי תרחישים בשעה בלי להגיע ל rate limits, להפעיל abuse detection, או לצבור עלויות שימוש ב-API.
איך משכפלים את כל השירותים האלה? עם אייג׳נט כמובן! שכנראה מקבל כקלט את מסמכי ה-API של כל אחד מהשירותים, ובונה מימוש שלהם. מעל זה הם גורמים לאייג׳נט לבנות UI רזה לצורך השלמת הסימולציה.
עוד נקודה להתעכב עליה היא המשפט למעלה, אם לא הוצאתם לפחות 1,000 דולר על טוקנים פר מהנדס אנושי היום, למפעל התוכנה שלכם יש לאן להשתפר. אני לא בטוח אם מדובר על כל יום (כלומר 30 אלף דולר בחודש לכל מהנדס) או רק ימי עבודה (ואז זה רק משהו כמו 21 אלף), אבל זה בכל מקרה תקציב ענק, שמציב כרגע רף די גבוה לגבי מודלים עסקיים שיוכלו להצדיק את הטכניקה הזו. עד שתימצא דרך להוזיל את העלות של להריץ swarm אוטומטי של אנשי QA.
ועלולה להיווצר תופעה של cargo cult, בקרב חברות שישאבו מכך השראה, וינסו ליישם את המודל בלי להבין אותו לעומק. אם מנהלי פיתוח פשוט יתחילו למדוד את כמות הטוקנים שהמהנדסים שלהם משתמשים בהם בכל יום. כמו בסיפור שהזכרתי למעלה, על כך שרק להשתמש בפתקים צהובים לא קיצר זמנים של פרוייקטים, לשרוף טוקנים בצורה עיוורת לא יהפוך צוות פיתוח ליותר פרודוקטיבי.
בכל מקרה, זו דרך ממש מעניינת לעבוד, ושווה להכיר אותה גם אם החברה שלכם לא מתכננת להקצות 1,000 דולר של טוקנים ביום לכל מהנדס. ובהקשר לחלק למעלה שעסק בגוגל ואנת׳רופיק, זה מעלה את השאלה האם זו כמות הטוקנים שהם מקצים למהנדסים שלהם, או שיש להם דרכים יעילות יותר לוודא בצורה אוטומטית ומהירה את הקוד שאייג׳נטים מייצרים.
תשישות
אשתו של מנהל מערכות המחשוב של בנק גדול מספרת שכשהיא פגשה לראשונה את בן זוגה, הוא היה אדם חם ורגיש. היום אין לו חברים קרובים ופעילות הפנאי היחידה שלו היא צפיה בטלוויזיה. כבר אין לו סבלנות לשיחות קלילות ולא רשמיות. לילה אחד, היא ביקשה ממנו להאט בעודם הולכים הביתה.
״תלכי מהר יותר,״ הוא השיב.
״אני לא יכולה ללכת מהר יותר. הרגליים שלי קצרות משלך.״
״זה לא תירוץ,״ הוא אמר. ״את חייבת ללמוד ללכת יותר ביעילות.״
הסיפור הזה מופיע על הכריכה האחורית של ספר בשם טכנו-סטרס, שסוקר את המחיר האנושי של מהפיכת ה-AI.
סליחה, טעות שלי.
הספר הזה התפרסם ב-1984, וסוקר את ההשלכות של מהפיכת המחשוב.
אנחנו מעריצים את התכונות של המחשב: מהירות, יעילות, צייתנות, דיוק, נאמנות. בלי לשים לב, התרגלנו לצפות מאנשים את המושלמות, הדיוק והמהירות שאליהם התרגלנו בגלל המחשבים [...] אלו שלא יצטרפו למהפכה, אומרים לנו, יהפכו לשרידים של תרבות מפגרת [...] בחברה שכבר נגועה במחלות שנובעות ממתח, ייתכן שטכנו-סטרס תהיה המחלה הגורלית ביותר שאי פעם היינו צריכים להתמודד איתה.
זה כנראה גם חלק ממה שקורה בשלב המוקדם של מהפיכה טכנולוגית; המונח הנוכחי הוא AI Fatigue, תשישות שנובעת מבינה מלאכותית. מפתח תוכנה בשם סידהאנת קארה כתב החודש בלוג פוסט על הפרדוקס בכך ש-AI עושה אותו פרודקטיבי יותר, ועם זאת הוא מרגיש עייף מתמיד:
דילוורתי יותר קוד ברבעון האחרון מאשר כל רבעון בקריירה שלי. הרגשתי גם יותר סחוט מאשר בכל רבעון בקריירה שלי. שתי העובדות האלה לא בלתי-קשורות.
[...] הנה מה ששבר לי את המח לזמן מה: AI מאיץ משימות בודדות. זה לא שקר. מה שהיה לוקח לי 3 שעות עכשיו לוקח 45 דקות. טיוטה של מסמך דיזיין, בניה של שירות חדש, לכתוב טסטים, לחקור API לא מוכר. הכל קורה יותר מהר.
אבל הימים שלי נהיו קשים יותר. לא קלים יותר. קשים יותר.
הסיבה היא פשוטה ברגע שרואים אותה, אבל לקח לי חודשים להבין. כשכל משימה חדשה לוקחת פחות זמן, לא עושים פחות משימות. עושים יותר משימות. הקיבולת שלכם מתרחבת, אז העבודה מתרחבת כדי למלא אותה. ואז עוד קצת. המנהל שלכם רואה שאתם מדלוורים יותר מהר, אז הציפיות מתאימות את עצמן [...]
לפני AI, הייתי יכול לבלות יום שלם על בעיית דיזיין אחת. הייתי מצייר על דף, חושב במקלחת, יוצא להליכה, וחוזר עם תובנה. הקצב היה איטי אבל יכולתי להתמודד עם העומס הקוגניטיבי. בעיה אחת. יום אחד. ריכוז עמוק.
עכשיו? אני לפעמים נוגע בשש בעיות שונות ביום אחד. כל אחת ״לוקחת רק שעה אחת עם AI״. אבל context-switching בין שש בעיות שונות הוא יקר בצורה ברוטאלית למח האנושי. ה-AI לא מתעייף כשעוברים בין בעיות. אני כן.
זה הפרדוקס: AI מפחית את עלות היצירה אבל מגביר את עלות התיאום, review, וקבלת-החלטות. והעלויות האלה נופלות כולן על בני האדם.
זה למעשה הצד השני של פרדוקס ג׳בונס: כשמהנדסי תוכנה נהיים יעילים יותר, הביקוש לתוכנה עולה, לא יורד. אבל המשמעות היא, שהם הרבה יותר תשושים. לפחות בשלב המוקדם שבו הם עדיין לא התרגלו לצורת העבודה החדשה. למעשה, אנחנו אפילו לא הבנו עד הסוף איך היא צריכה להיראות. והארגונים עצמם עדיין לא הותאמו אליה.
קארה סוקר עוד סיבות לתשישות, כולל תחושת FOMO שדוחפת מהנדסים לעקוב אחרי כל כלי חדש שיוצא, או כל פוסט בלינקדאין שמזהיר שאם אתם עדיין לא מריצים אייג׳נט שמנהל להקה של סאב-אייג׳נטים, אתם כבר מאחור. כמו גם התסכול מאורך החיים הקצר של ידע בעולם שמתקדם כל כך מהר – קארה סיפר על סדרת טמפלייטים לפרומפטים שליטש לעצמו במשך שבועיים בתחילת 2025, ואיבדו רלוונטיות כשיצאה גרסת מודל חדשה.
זה כנראה ימשיך להיות המצב בעתיד הנראה לעין.
בימים המוקדמים של הקלאוד, זה לקח הרבה עבודה להרים מונגו DB עם nodes על כמה שרתים ולהתחיל לעבוד; כמה שנים לאחר מכן כבר היה אפשר לעשות את זה בכמה קליקים במסך האדמין. וזה אפילו לא היה ברור מהו הדאטהבייס הנכון – בזמנו ניסיתי לבנות גרסה של אותה מערכת שעובדת מול מונגו, קסנדרה, HBase, וסדרה של תשתיות שנראו בהתחלה כמו הדבר הענק הבא, אבל איבדו מהר רלוונטיות. רובי און ריילס היה נראה כמו דבר מדהים כשאיפשר להרים מערכות ווב מאפס בתוך ימים בודדים, אבל בסוף התגמד בפופולריות של מול שפות שהתבססו על ג׳אווה סקריפט. בשלב מסויים זה היה נראה שכל כמה חודשים יוצאת חבילת frontend חדשה עם סיומת .js, וצוותי פיתוח פצחו בפרוייקטים של להעביר את ה-UI שלהם מתשתית אחת לאחרת. אבל בסופו של דבר, המתודולוגיה של פיתוח SaaS ומובייל התבגרה.
גם ב-AI, הרעש, הלחץ, והתשישות שהם גורמים לה, כנראה יירגעו עם הזמן. בשלב מסויים הדברים יתייצבו: המודלים יתבגרו, תשתיות ייבנו, נפצח את שיטות העבודה הנכונות, סטארטאפים ייבנו אחרת, חברות ותיקות יותר יתאימו את עצמן. העבודה של מהנדסי התוכנה תיראה אחרת לגמרי ממה שהיא הייתה לפני AI, אבל זה כבר יהיה ברור איך. הציפיות יהיו ברורות יותר. תהיה פחות חרדה, פחות דחף לקרוא כל פוסט בלינקדאין, או להישאר ערים בלילה כדי לשחק עם כל כלי חדש שיוצא.
אבל זה יכול לקחת כמה שנים עד שנגיע לשם.
בינתיים, העצה שקיבלתי בתחילת שנות האלפיים נראית רלוונטית מתמידֿ: אם אתם מתכוונים להיכנס (או להישאר) בתחום, כדאי שתוודאו שאתם באמת אוהבים ונהנים מזה.
תודה שקראת את הרהורי יום שישי השבוע! למהדורה אפשר להאזין גם בתור פודקאסט.
אתם מוזמנים גם לעקוב אחריי בלינקדאין, וואטסאפ, טוויטר או פייסבוק, ואם עדיין לא נרשמתם לבלוג - אפשר לעשות את זה כאן כדי לקבל את הניוזלטר בכל יום שישי בבוקר ישירות למייל:
תזכורת: הבלוג הזה הוא למטרות לימודיות בלבד. אין לראות באמור לעיל ייעוץ השקעות. מסחר במניות מלווה בסיכונים רבים. אנא קראו את הדיסקליימר המלא כאן.
אני מרגיש צורך להסתייג ולומר שמזה מעל שנתיים אני לא מוביל בעצמי צוותי פיתוח או אחראי על מערכות שרצות בפרודקשן. כתיבת הקוד שלי בתקופה הנוכחית היא בעיקר לצרכים אישיים. מה שכתבתי עליו היום מבוסס על מקורות חיצוניים.
