תכנות מבוסס-סוכנים: דיון שולחן עגול עם מובילים בתחום

שלום לכולם,

שמעתם הרבה מ-Googlers של Android השבוע, או ביומיים האחרונים.

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

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

אז נתחיל בלהציג את עצמנו.

קוראים לי בן, ואני עובד ב-Android DevRel.

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

שלום לכולם,

קוראים לי וינאי, ואני תומך במאמצים לפיתוח כלי AI ב-Databricks.

אני מתרגש להיות כאן.

שלום, אני לואיס ארטולה.

אני עובד במפות Google.

אני מוביל צוותים שמשתמשים ב-AI כדי ליצור חוויות של סוכנים ולשפר את מחזור פיתוח התוכנה.

היי, אני אניס דייוויס.

אני עובד בפורד.

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

שלום לכולם,

אני טיי סמית'.

אני עובד ב-Uber ותומך במפתחים שלנו.

האפשרות הזו קיימת בנייד כבר הרבה זמן.

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

שלום לכולם,

אני קאושיק גופאל.

אני עובד כמהנדס ראשי ב-Instacart, ובמקרה התחלתי את הפודקאסט הזה על פיתוח ל-Android שנקרא Fragmented.

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

טוב.

אז יש לנו 30 דקות.

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

אנחנו תמיד, אתם יודעים, ב-Android DevRel, אמרנו שאנחנו רוצים להפוך את פיתוח האפליקציות למהיר וקל יותר.

עכשיו ה-AI הגיע, ואתם יודעים, שמעתם אותנו אומרים כאן, "זה אכן כך.

אנחנו חושבים שזה מהיר וקל יותר לפתח אפליקציות".

אבל אני רוצה לשאול, האם אנחנו באמת משיקים אפליקציות מהר יותר, או שאנחנו פשוט יוצרים המון קוד שלא ממש מוביל לשום מקום?

קדימה, וינאי.

אוקיי.

כן, כולנו מסתכלים אחד על השני.

מצוין.

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

וההאצה הזו היא אמיתית מאוד.

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

אבל אני בהחלט רואה את זה בפעולה.

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

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

כי יש דרכים שונות לחשוב על זה.

אנחנו מנסים להבין איך להעלות את החציון, נכון?

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

אנחנו רואים שילוב של תפקידים.

יש אנשים שמתקדמים הרבה יותר מהר.

יש אנשים שמקבלים מאה בקשות משיכה ביום, והם עושים עבודה מדהימה.

אבל זה סוג המרחב שבו הם פועלים.

זה אולי יותר גרינפילד, או שהם יותר שולטים בכלים.

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

והשילוב של שניהם, אתם יודעים, הוא מהיר משמעותית ממה שהיה קודם, אבל אני חושב שהנושא המעניין באמת עבורנו הוא שלמרות שאנחנו שולחים יותר, האם העסק באמת שולח יותר למשתמשי הקצה?

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

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

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

אבל אני חושב שגם עכשיו, הרבה מהחשיבה היא: "איך אנחנו לוקחים את ה-AI ואת הכלי הזה שיש לנו ומשפרים את התהליכים הקיימים?"

נכון?

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

אבל אני חושב שמה שאנחנו רואים עכשיו זה שזה עובד.

אנחנו שולחים עוד.

אבל אנחנו נתקלים בכל צוואר בקבוק שבעולם הקודם לא היינו רואים, נכון?

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

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

לכן, אנחנו נתקלים באתגרים אחרים.

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

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

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

המשמעות של משלוח משתנה בהתאם למיקום שלכם, נכון?

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

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

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

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

זה קשור לתהליכים, לאנשים ולאופן שבו אפשר לשפר את זה באמצעות AI.

זה אתגר מעניין מאוד, איך לייעל את התהליך מקצה לקצה.

אחת הדרכים המעניינות שבהן אנחנו חושבים על התחום הזה היא: כמה סוכנות יש לאדם או לצוות בשליחה מלאה?

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

הם שולחים הרבה יותר מהר, נכון?

יש להם את כל הכלים להפיץ את זה ללקוחות שלהם באופן מיידי.

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

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

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

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

אני אומר את זה כבר שנים.

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

תקבלו 10 תשובות שונות.

ואז, "אוקיי.

עכשיו נתרגם את זה לפתרונות שקשורים למוצר.

עכשיו, בואו נחשוב על זה קצת.

אולי נדבר קצת על העיצוב.

תבעט לשם".

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

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

אז עם AI, ההאצה הכי גדולה שאני רואה היא סביב עבודת התאימות הזו.

הדברים האלה שתמיד רצינו לעשות, כמו לשדרג את XYZ או לשדרג במהירות את הגרסה של Spring Boot.

אנחנו עושים את זה כל כך מהר.

אבל לגבי התכונות עצמן, אני לא יכול להגיד שראיתי שיפור משמעותי.

אז כולכם הזכרתם את זה, שאולי צוואר הבקבוק השתנה, ואתם נתקלים בתהליכים האלה שפעם לא היו צוואר הבקבוק, אבל עכשיו הם כן.

אבל התהליכים האלה כנראה נוצרו בעקבות לקחים שהפקתם בעבר, נכון?

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

מה לדעתנו צפוי בעתיד של סקירת הקוד?

מה אנחנו עושים כרגע?

אז כן, אשמח לשמוע.

זה מחזיר אותי לנקודה שציינתי קודם.

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

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

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

יש לנו AI שכותב אותם, אז זה בסדר.

לא, אולי, אתה יודע, אתה הולך לעשות עבודה הרבה יותר טובה מהסוכן הזה?

אני לא יודע, אולי פשוט לא כדאי להשקיע זמן בבדיקה של זה.

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

זה לא אזור קריטי", ואז לנסות לדמיין מחדש.

למשל, אני לא חושב שככה אנחנו פועלים היום, נכון?

היום זה יותר כמו, "היי, יש בקשת משיכה.

אני המהנדס.

אני מתמקד בזה.

הוא יעלה.

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

לעומת זאת, אולי כדאי לחשוב מחדש על הרבה מהם.

אני מסכים לגמרי, ואני חושב על סקירת קוד כבעיית אימות. למה אני מתכוון? בעולם שבו יש לי ביטחון מלא ביכולת שלי לאמת משהו, האם עדיין הייתי סוקר 100% מהקוד של בקשות ה-Pull שלי?

כנראה שלא, נכון?

לכן, יש שתי מטרות לסקרי קוד.

האחד הוא כמובן לוודא שאנחנו עושים את הדבר הנכון, והשני הוא חינוך, נכון?

למשל, אנשים בסביבה שלכם יודעים מה אתם עושים, ולא משנה אם הם מסכימים עם ההחלטה שלכם או לא.

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

יכול להיות שזה לא נכון ב-100% מהמקרים, אבל אני חושב שזה נכון ברוב המקרים.

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

אין דרך לעקוף את זה.

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

המהירות שלכם תלויה בשלב הכי איטי בתהליך.

ובשביל הרבה צוותים, זה אומר סקרי קוד. הצוותים שמתקדמים מהר יותר הם אלה שהבינו וקיבלו את המציאות הזו.

כן, ואם נהיה כנים עם עצמנו, אני רוצה לומר ש-70% מבקשות ה-PR שראיתי נראות לי טובות.

למשל, אם היינו מחפשים בכל ה-code bases בעולם, התגובות לבקשות ה-PR היו רק "נראה לי טוב", LGTM, בכל מקום.

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

אנחנו באמת חושבים שאנחנו כבר שם.

"האם הם השתמשו בתבנית פקודה?"

לא, אנחנו פשוט אומרים, "אוקיי.

כן, זה נראה לי טוב".

אז למה אי אפשר לבקש מנציג לעשות את זה?

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

ואז צריך לוודא שהנציג מחפש את אותו הדבר.

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

למשל, אני מכיר אנשים שמשתמשים בטוויטר בימים אלה, והם אומרים את הדבר הזה, נכון?

למשל, כשמאמתים בקשת משיכה (PR), אפשר לבקש מהסוכנים להציג אותה בצורה ויזואלית אחרת, נכון?

היי, תראה לי את התמונה לפני השינוי.

אני רוצה לראות את התמונה אחרי העריכה.

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

אבל זה מאתגר את… רצית להגיד משהו, לירן?

לא, אני חושב שזה מעורר מחשבה, נכון?

כמו שאנחנו הולכים להגיע למקום שבו תרגישו ממש בנוח לאפשר ל-CL, כמו או ל-PR, לעבור בלי התערבות אנושית.

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

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

השאלה היא איך אנחנו יכולים להקל על המפתחים, נכון?

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

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

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

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

לכן, הבדיקות פחות מפריעות למפתחים.

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

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

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

למשל, האם כדאי לבדוק שורה אחר שורה בבקשת ה-Pull, או לבדוק את הכוונה שהם מנסים להשיג?

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

הראשונה היא איך אנחנו יכולים לתת למשתמש מידע רלוונטי יותר כדי שהוא יוכל להתחיל לתעדף את זה?

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

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

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

היו ההחלטות הנכונות.

למשל, שכתוב קוד של מודול חדש ל-Android באפליקציית Uber, זה יכול להיות בסדר.

האפליקציה נותנת נסיעות בחינם לכל מפתחי Android, כדאי לבדוק את הקוד.

אצטרך לבדוק את זה עם המנכ"ל שלנו.

מצטער, קאושיק.

אבל אני גם חושב שזו בעיה פתורה.

כבר יש לנו feature flags.

כבר יש לנו פריסה כחול-ירוק.

כבר יש לנו הרבה מהחלקים.

הבעיה היא שאנחנו עסוקים מדי בשביל לעשות את זה.

כבר יש לנו מעקב התנהגותי.

יש לנו את כל הנתונים האלה, אבל הם נמצאים בכל מיני מערכות שונות.

אנחנו כבר עוקבים אחרי אירועים.

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

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

כי אנחנו יודעים, אוקיי, יש לנו את זה מאחורי feature flag.

יש לנו פריסה כחולה-ירוקה.

כל יכולות התצפיתיות קיימות.

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

אם משהו משתבש, יש לנו את כל השומרים והשערים האלה לאורך הדרך.

אני חושב שגם המהירות שבה אפשר להגיב היא ממש חשובה, נכון?

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

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

אני יודע שחלק מכם עובדים על אפליקציות ענקיות, נכון?

אז מעניין אותי לדעת מה דעתך על זה?

האם זה כמו, היי, מנכ"ל, תן לי 3 חודשים, תן לי רק להכין את האפליקציה הזו ל-AI, או שאני מתכוון, אתה יודע, כמו להוסיף אותה כל יום?

כן.‏

הם אף פעם לא עושים את זה.

לא נראה לי.

רוב החברות לא יזכו לזה.

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

ואז אפילו להבין מה ההנחיה עושה, ולשפר את ההקשר.

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

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

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

הוא גם המשך שלו.

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

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

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

אבל זה אתגר לכל מי שפועל בתחום כרגע.

אני רוצה לגוון קצת.

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

אלפי בקשות משיכה, האם תשתית הבדיקות, השרתים, הכל קורס?

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

Ty?

כן.

הם פשוט מעולים.

ה-CI שלי בוכה, בוכה, בוכה לי עד שאני נרדמת כל לילה.

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

יש, אתם יודעים, התרעות אדומות.

הם רואים עלייה עצומה בנפח.

אנחנו מבצעים שינויים במבנה של הסוכנים.

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

אבל זה מאתגר מאוד.

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

ולרוב האנשים, התשובה היא כנראה לא.

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

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

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

בפועל, אנחנו מנסים למנוע הפתעות.

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

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

נכון?

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

זה בלתי נמנע.

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

שמעתי ציטוט מעניין מהמנכ"ל של Inflow.

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

ואני לא חושב שכל החברות מוכנות לתשתית פיתוח ברמה של Google.

אז בהקשר הזה, האם החברות שלכם מיישמות סוג כלשהו של מגבלת הוצאות?

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

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

אני חושב שהשנה שעברה הייתה שנת הניסויים.

לעשות את כל הדברים.

ואולי אפילו במחצית הראשונה של השנה הזו, פשוט השתמשו בו באופן סביר.

ומספטמבר, יש לנו מגבלות על מספר הטוקנים.

לכן יש לנו מגבלות על השימוש של המפתחים באסימונים.

ויש לנו גם כלים, כדי שהם יוכלו להבין, למשל, אם יש לכם סשנים טובים ובריאים.

מה זה אומר שהסשן תקין?

האם יש לכם כל כך הרבה סבבים בכל סשן?

מה זה תור?

אז אנחנו באמת מנסים להשתמש בכלים גם כדי ללמד את המפתחים.

אני חושב שזה רק הצעד הראשון.

אתם יודעים, צריך להבין שיש בעיה לפני שאפשר לפתור אותה.

אז לפחות שהם יראו שזה לא בחינם.

בעבר, באמת הייתה תחושה שה-AI הוא בחינם.

ואנשים פשוט השתמשו בו.

הייתי רוצה, "שנה את הסניף שלי", אתם יודעים, כמו, "אה, אין בעיה אניס, אני אשנה את הסניף הזה בשבילך, 5 דולר", נכון?

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

אז אני חושב שנתחיל ללמד את המהנדסים על העלות בפועל.

זה יותר כמו, לא הייתי פשוט מפעיל מכונות ECS ופשוט בורח מהן.

אולי כשה-AWS יצא לראשונה, אמרנו לעצמנו, "כן, אני יכול להוציא מכונה משלי".

והיינו פשוט כמו עלות לחברה כל כך הרבה כסף.

אני חושב שאותו דבר קורה עכשיו עם הטוקנים.

לדעתי, מגבלות מעשיות גם מציגות הזדמנויות מעניינות מאוד, נכון?

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

הם היו בוחנים את הקוד, מבינים מה קורה ועושים קסמים, נכון?

אבל זה לא היה בחינם.

ואנחנו באמת אמיתיים – אתם יודעים, התעשייה מבינה את זה.

וזה בעצם מאלץ את המפתחים והארגונים לחשוב איך אפשר לייעל את זה, נכון?

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

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

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

אבל אני חושב שהמטרה היא לא בהכרח להגביל את השימוש ב-AI, אלא להביא סוג של היגיינה, או כמו שאתה אומר, התבוננות פנימית, נכון?

למשל, מתי כדאי להשתמש במודלים מסוימים ולא במודלים אחרים.

אתם יודעים, כנראה שלא צריך את Fable או את Astra כדי לדעת מה השעה או כדי לשנות ענף ב-Git.

נכון?

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

ככה לא מבזבזים טוקנים.

נכון?

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

נכון?

אהבתי את מה שאמרת, השנה שעברה הרגישה כמו שנת הניסויים.

השנה, השאלה היא איך משתמשים בדבר הזה בצורה יעילה.

כן.‏

גם אנחנו מזדהים מאוד עם הסיפורים שכאן.

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

ההשקעות האלה מגיעות ממגוון מקורות.

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

כמו שאניס דיברה על העלות והמידע של הסשן הפעיל.

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

ולתת דין וחשבון על העלויות שהם מוציאים.

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

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

אז אם יש עבודה נהדרת שמתבצעת, אנחנו רוצים שהם יעברו את זה.

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

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

האם זה המשקל הנכון?

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

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

ובטווח הארוך, להסיר מהם את ההחלטה הזו לחלוטין.

נכון?

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

אבל בינתיים, זה מצב תקין.

כן.‏

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

אבל צריך גם להגדיר את הטריגרים הנכונים.

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

אנחנו לא רוצים לחסום את המפתח.

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

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

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

השליטה בידיים שלי".

נכון?

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

אז זה מאוד הגיוני.

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

אבל לקטגוריית המודלים הזו יצרנו תקציב ייעודי.

לכן, יש תקציב חודשי.

הוא גבוה מספיק.

אתם לא חסומים.

אם אתם צריכים לבטל את החסימה, יש תהליך חריג.

מועבר למנהל שלכם.

זה רגע שבו אתם מתארים מה אתם עושים.

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

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

והסיבה שזה עובד היא שבסופו של דבר, זה הופך את התהליך לצפוי.

נכון?

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

אתה יודע מה הכי מעניין אותי בשיחות האלה?

אני חושב שזה בגלל שכולנו עובדים בחברות.

וכך גם ארגונים.

לכן אנחנו צריכים לשלם על כל טוקן.

נכון?

אבל יש חלק שלם באינטרנט שבו אנשים משלמים על מינוי.

ולכן, מבחינתם זה חישוב שונה לגמרי.

נכון?

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

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

או שאתם עובדים במעבדה מתקדמת עם תקציב בלתי מוגבל.

ואז פשוט ממשיכים לפעול ויוצרים הרבה מהדרכים המרגשות האלה לעבודה עם AI, כמו אלה שרואים בכל מקום ב-X.

כל החברות שלנו רוצות לשקף את זה, אבל הן לא חושבות שהן רוצות להוציא את הטוקנים ש…

יש לנו כאן אנשים שעובדים ב-Google.

אני מאוד סקרן.

איך זה עובד?

מה התקציב ש-Google נותנת?

רוצה לענות, לואיס?

אני לא חושב שאני האדם הנכון לדבר איתו על ההיבטים הכלכליים של זה.

‫Google היא חברה גדולה מאוד עם הרבה ארגונים שונים.

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

זה היה נוח.

ניצלתם ברגע האחרון.

זה ניהול קהילה ברמה גבוהה.

אנשי יחסי הציבור הם…

אז בכל מקרה, תודה לפאנל שלנו, וכן, תודה שהגעתם ל-ADS.