מהדפדפן בחזרה לברזל — האם AI יחזיר אותנו לתוכנה יעילה באמת?

רציתי לבנות משהו פשוט: מסך מגע, מוזיקה ורמקול Bluetooth. הבסיס היה Compute Module 4 של Raspberry Pi, מודול מחשב קטן עם 2GB של זיכרון עבודה ו־8GB של אחסון מובנה מסוג eMMC, לצד מסך ברזולוציה של 1024×600. בפועל הצטברו סביב המשימה Debian, סביבת שולחן עבודה, Chromium, נגן Spotify בדפדפן ומערכות התצוגה והשמע של לינוקס. התחושה הייתה שמערכת שלמה מתאמצת כדי לבצע פעולה שהייתי מצפה ממכשיר ייעודי לעשות בלי דרמה. מכאן הגיעה השאלה: כמה מהעבודה נחוצה למוזיקה, וכמה נחוצה כדי להחזיק את הדרך שבחרתי להגיע אליה?

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

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

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

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

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

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

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

ב־Spotify ההפרדה בין הממשק למנגנון הניגון חשובה במיוחד. ספריית Web Playback SDK הרשמית מיועדת לנגן בתוך דפדפן; ציור כפתור ניגון ב־LVGL אינו מחליף אותה. Spotify מפרסמת גם מסלול למוצרי חומרה מסחריים, עם ערכת תוכנה ייעודית, הסכם רישוי והסמכת המוצר. נוסף על כך צריך לטפל בחיבור לשירות, בפענוח השמע ובהעברה לרמקול. לכן מעבר לממשק קטן יותר יכול להיות חלק מהפתרון, אבל הוא אינו מוכיח שכבר נמצא מסלול מלא ונתמך לניגון באותו מכשיר.

כדי להבין היכן מסתתרים המשאבים, כדאי להתחיל דווקא מתמונה אחת. במסך של 1024×600 יש 614,400 פיקסלים. אם שומרים לכל פיקסל ארבעה בתים, מאגר תמונה מלא דורש 2,457,600 בתים: כ־2.46MB, או כ־2.34MiB ביחידות המבוססות על חזקות של שתיים. שני מאגרים, כדי להכין תמונה בזמן שקודמתה מוצגת, תופסים כ־4.92MB עוד לפני תמונות רקע, גופנים או קוד. זה חישוב לפי הרזולוציה ופורמט הצבע, ולא מדידה של הפרויקט; ריפוד שורות ודרישות החומרה יכולים להוסיף עליו.

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

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

בלינוקס, הדרך המסודרת לנהל את המשאבים האלה עוברת בין היתר דרך DRM, קיצור של Direct Rendering Manager. כאן אלה ראשי תיבות של מערכת הגרפיקה, ולא של ניהול זכויות דיגיטליות, שגם הוא מכונה DRM בעולם התוכן. בתוך מערכת הגרפיקה נמצא KMS, מנגנון שמאפשר לקבוע מצבי תצוגה ולחבר מאגרי תמונה למשאבי בקר התצוגה. אפשר לחשוב עליו כאחראי שמקבל תמונה מוכנה והוראות היכן ומתי להציג אותה. הוא מטפל גם במשטחי תצוגה שהחומרה עשויה לשלב, המכונים planes. האפליקציה משתמשת בממשקי לינוקס ובדרייבר; היא אינה מקבלת רשות לכתוב באופן חופשי לכל כתובת בזיכרון הגרפי.

בתיעוד LVGL 9.4 כבר מתואר מסלול שמציג ממשק באמצעות DRM/KMS בלי מנהל חלונות של X11 או Wayland. כך אפשר להחזיק את יכולות הרשת, הקבצים והדרייברים של לינוקס, ולהריץ מעליה יישום יחיד למסך של המוצר. זאת אפשרות מעניינת למחשב קטן ממשפחת Raspberry Pi, או ללוח עם מעבד יישומים ממשפחות STM32MP ו־i.MX, בתנאי שהלוח והדרייברים המסוימים תומכים במסלול הנדרש. הסרת מנהל החלונות גם מעבירה אחריות ליישום: גישה להתקן, קלט, בחירת מצב מסך והתאוששות מתקלות. ההתאמה ללוח מסוים דורשת בדיקה, ולא נובעת מעצם הופעת שם המשפחה ברשימת אפשרויות.

גם האצה גרפית אינה שמורה ל־Qt או לדפדפן. בתיעוד LVGL 9.5 מפרידים בין רכיב שמציג את התוצאה לבין יחידת הציור שמייצרת אותה. OpenGL ES הוא ממשק לפקודות גרפיות המתאים גם למערכות משובצות, ו־EGL מחבר את סביבת העבודה הגרפית למשאבי הפלטפורמה. אפשר לשמור רכיבים שכבר צוירו כתמונות בזיכרון הגרפי ולשלב אותם בעזרת ה־GPU, וכך להימנע מציור חוזר שלהם. זה עשוי לעזור מאוד במסך שחלקים גדולים ממנו קבועים, אך דורש זיכרון לשמירה הזאת ועוזר פחות כשהכול משתנה. התיעוד כולל גם מסלול NanoVG לציור וקטורי מואץ; עצם הפעלת OpenGL אינה מבטיחה שכל פעולת ציור עברה ל־GPU.

מול LVGL, אפשר להסתכל על Qt כעל סביבת יישום רחבה יותר. Qt Quick, יחד עם QML לתיאור הממשק, מארגן את התוכן במבנה שנקרא scene graph: תיאור של הפריטים שצריך לצייר והקשרים ביניהם. היכרות עם התמונה כולה מאפשרת לאחד פעולות דומות ולחסוך פקודות ציור. גם Qt יכול לרוץ בלינוקס בלי סביבת חלונות, למשל באמצעות מסלול EGLFS, ולכן אין בסיס להשוואה שבה רק LVGL רשאי להתקרב למסך. ההבדל המעשי הוא כמה שירותים וכלים מקבלים מראש, וכמה מהם המוצר צריך. חבילה גדולה יותר יכולה לחסוך הרבה עבודת אינטגרציה, ולעיתים גם לבצע אותה ביעילות רבה יותר ממימוש קטן וחפוז.

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

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

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

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

מחקר Magellan, שפרסמו חוקרים מ־Google, מ־Google DeepMind ומ־Cornell בינואר 2026, מדגים כיוון מעניין במיוחד. המערכת השתמשה ב־AlphaEvolve כדי לחפש כללי החלטה עבור LLVM, תשתית של מהדרים. אחת ההחלטות היא מתי לשלב גוף של פונקציה במקום הקריאה אליה, פעולה שנקראת inlining: לפעמים היא מאפשרת לפשט את הקוד, ולפעמים היא משכפלת אותו ומגדילה את התוכנה. Magellan ייצרה כללי החלטה ב־C++, בזמן שבדיקות החוקיות נשארו אצל המהדר. כלומר, אפשר לשנות את איכות התרגום למכונה בלי לדרוש מכל מפתח לכתוב את היישום ברמת הוראות המעבד.

ביותר מעשרה קובצי תוכנה ממערכות ייצור, החוקרים דיווחו על הקטנת גודל ממוצעת של 8.79% ביחס למדיניות ברירת המחדל של LLVM שנבדקה. כדי להבין את המספר צריך לראות גם את ההשוואה הנוספת: מדיניות קודמת המבוססת על רשת עצבית כבר השיגה 8.52%. בניסוי נפרד שניסה לשפר את זמן הריצה של clang, מהדר ממשפחת LLVM, השיפור הטוב ביותר היה 0.61%. אלה תוצאות מעניינות, אבל הקטנת קובץ אינה זהה להקטנת זיכרון העבודה או להאצת כל פעולה. הממצא הוא שאפשר לשפר החלטות תרגום מוגדרות ולמדוד את התוצאה; הוא אינו מבטיח שתוכנה שלמה תהיה קטנה ומהירה בתשעה אחוזים.

יש גם תקדים לעבודה ממש קרוב להוראות המכונה. ב־2023 הציגה DeepMind את AlphaDev, שחיפשה רצפי הוראות יעילים לשגרות מיון קטנות, בעיקר של שלושה עד חמישה פריטים. התוצאות תורגמו ל־C++ ושולבו בספרייה של LLVM. זה מסלול סביר יותר מחזרה גורפת לכתיבת יישומים ב־Assembly: מזהים פעולה קטנה שחוזרת פעמים רבות, משפרים אותה ומאפשרים לתוכנות רבות ליהנות דרך הספרייה. באותו אופן, אפשר לבחון הוראות שמבצעות פעולה על כמה נתונים במקביל, המכונות SIMD, רק במקום שבו המדידה מראה שהן מועילות. גם כאן המחיר עשוי להיות תלות במעבד מסוים ויותר גרסאות לבדיקה.

במחקר AlphaEvolve מ־2025 מופיעה דוגמה שמחדדת את ההבדל בין שיפור מקומי לתוצאה כוללת. המערכת חיפשה דרך טובה יותר לחלק פעולות כפל מטריצות, חישובים מרכזיים באימון מודלי AI, לבלוקים שמתאימים למאיץ ולזיכרון שלו. לפי החוקרים, חלוקת העבודה שנמצאה האיצה את גרעיני החישוב שנבדקו ב־23% בממוצע מול כלל חלוקה שתכננו מומחים. זמן האימון הכולל התקצר בכ־1%, משום שהאימון עושה גם עבודות אחרות. המסקנה שימושית גם לנגן קטן: אם רוב ההמתנה נמצאת ברשת, שיפור גדול בציור הכפתור ישנה רק מעט את זמן ההמתנה הכולל.

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

זמן הפיתוח הוא מדד אחר, והראיות בו מחייבות זהירות. בניסוי אקראי שפרסם METR ביולי 2025, 16 מפתחים מנוסים ביצעו 246 משימות במאגרים שהכירו, וגישה לכלי AI של אותה תקופה האריכה את זמן העבודה בממוצע ב־19%. בפברואר 2026 פרסמו החוקרים עדכון: הנתונים החדשים רמזו על האצה, אבל ברירת משתתפים ומשימות, לצד קשיי מדידת העבודה, הקשו להעריך אותה באופן אמין. המחקר הישן אינו פסק דין על הכלים הנוכחיים, והחדש אינו בסיס לאחוז חיסכון מובטח. מבחינת צוות פיתוח, צריך לספור גם זמן סקירה, תיקונים, בדיקות והמתנה לכלים, לצד הזמן שנחסך בהקלדה.

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

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

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

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

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

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