לכן לא מדובר רק בשגיאה חשבונית. הבעיה הייתה סמנטית: הקוד התייחס לערך כאילו הוא כתובת שצריך ליישר, אף שבפועל הוא שימש כגבול שמציין היכן מסתיים הזיכרון הזמין. זו הסיבה שתיקון של שורה אחת היה קשה כל כך לאיתור.
טורבאלדס תיאר את התהליך כ"סשן דיבוג מהגיהינום". הוא והעוזר מבוסס ה-AI הוסיפו ושינו כלי מדידה ממוקדים, עקבו אחר חישובי הזיכרון בדרייבר והשוו בין מיקום ה-CCS כפי שדווח מהחומרה לבין הגבול שנמסר למקצה ה-VRAM.
החקירה כללה 24 גרסאות של תיקוני דיבוג ו-18 מחזורי אתחול ובדיקה של ליבת לינוקס, עד שכיוון העיגול השגוי נעשה ברור.
האתחולים החוזרים היו חיוניים: התקלה נצפתה ברמת החומרה ומערכת התצוגה, ולא רק כשורה חשודה בקוד. כל ניסוי סייע להפריד בין התנהגות מקצה הזיכרון לבין סיבות אפשריות אחרות לקריסות הגרפיות.
טורבאלדס השתמש בעוזר כשותף אינטראקטיבי לדיבוג. הוא נעזר בו כדי להציע כלי מדידה, לעקוב אחר מסלולי קוד ולנתח את תוצאות הניסויים. כך נחסכה חלק מהעבודה החזרתית הכרוכה בבדיקת השערות שונות.
אבל העוזר לא היה סמכות אמינה. לדבריו של טורבאלדס, ה-AI קבע שוב ושוב שהבעיה בלתי אפשרית או בלתי פתירה, ואף הציע להסתפק בכתיבת דוח. טורבאלדס הוא זה שבחר את הניסוי הבא, זיהה פרשנויות שגויות והבין את משמעות ההיסט בתוך מודל הזיכרון של המקצה.
זהו ההבדל החשוב במבנה העבודה: ה-AI יצר אפשרויות וטיפל במכניקה; המומחה סיפק את ההקשר, את ההתמדה, את המבחנים שניתן להפריך ואת ההכרעה הסופית.
טורבאלדס כתב והכניס את התיקון לדרייבר Intel Xe בעץ המקור של ליבת לינוקס. לפי הדיווחים הזמינים, סדרות ליבה יציבות שעדיין מתוחזקות צפויות לקבל את השינוי בתהליך ה-backport המקובל — העברת תיקונים לגרסאות נתמכות — אך המקורות שסופקו אינם מאשרים באופן אמין אילו גרסאות יציבות מדויקות ומתי ישוחררו.
לכן מוקדם מדי לנקוב במספרי גרסה ספציפיים. משתמשים בחומרה הרלוונטית צריכים להסתמך על הודעות של הפצת הלינוקס שלהם או של מתחזקי הליבה כדי לוודא שבנייה מסוימת כבר כוללת את התיקון.
המקרה הזה אינו אישור גורף לקוד ליבה שנוצר ב-AI. הוא מדגים שימוש מצומצם וזהיר יותר: מומחה יכול להיעזר ב-AI כדי להאיץ לולאת דיבוג מורכבת, תוך שמירה על האחריות להשערה, לתכנון הבדיקה, לסקירת הקוד ולתיקון הסופי.
זה שונה מאוד משליחה של תיקונים או דוחות אבטחה שנוצרו ב-AI ללא בדיקה וללא הקשר. מתחזקי ליבת לינוקס תיארו "הסתערות" של הגשות שנוצרו במכונה, ודיווחים ממתחזקי תת-מערכות staging והרשתות מתארים תסכול גובר מתיקונים בעלי ערך נמוך או כאלה שמגישיהם אינם מבינים אותם היטב.
גם את הטענה החוזרת על עלייה של 2,700% במספר ההגשות צריך לקבל בזהירות. הדיווחים שסופקו אינם מבהירים כיצד נמדד הנתון, מה הייתה תקופת ההשוואה או לאיזו קטגוריה בדיוק הוא מתייחס. המסקנה המבוססת יותר כללית: כלי AI הוזילו את העלות של יצירת קוד ודוחות, אך עלות הסקירה והמיון עדיין מוטלת על המתחזקים האנושיים.
טורבאלדס עצמו טען שלינוקס אינה מתנגדת באופן עקרוני לכלי AI, במיוחד כאשר הם משמשים למשל לסקירת קוד. סשן הדיבוג של Intel Xe מחדד את הגבול המעשי: AI יכול להיות כלי יעיל בתוך תהליך הנדסי ממושמע, אך הוא אינו מחליף היכרות עם תת-המערכת, בדיקות שניתן לשחזר ואדם שלוקח בעלות על התוצאה.
התיקון הסופי כלל שורה אחת. ההישג האמיתי היה לדעת איזו שורה לשנות — ולא להפסיק לחפש כשהעוזר קבע שאין דרך למצוא את התשובה.