קוד שנכתב מהר מדי: איך AI הפך את ה-CI לצוואר הבקבוק של לינר
חברת התוכנה לינר (Linear) חשפה כיצד שכתבה מחדש את מערכת ה-CI (בדיקות אינטגרציה רציפות) שלה אחרי שקידוד מבוסס-סוכני AI האיץ את קצב כתיבת הקוד מהר יותר משהתשתית להרצת בדיקות הצליחה לעמוד בו. למרות שסוויטת הבדיקות כמעט התרבתה פי ארבעה מתחילת השנה, הצוות קיצר את זמן ההמתנה לבקשות משיכה (PR) מיותר מ-6 דקות לכ-5 דקות בלבד, וחתך את זמן הריצה למחשב לכל בדיקה בכמחצית.
חברת ניהול הפרויקטים לינר (Linear) פרסמה רשומת בלוג טכנית המתארת כיצד שיפצה את תשתית ה-CI שלה — מערכת הבדיקות האוטומטיות שרצה על כל שינוי קוד לפני שהוא מתמזג — אחרי שזו הפכה לצוואר בקבוק בעקבות קצב הפיתוח המואץ שמאפשרים סוכני AI.
לפי הכתבה, מהנדס בשם מופיז אמג'אד (Mufeez Amjad) קיבל בתחילת השנה משימה מה-CTO של לינר, טואומאס (Tuomas), תחת הכותרת "עלויות ה-CI גבוהות" — ולצדה בקשה נוספת להאיץ גם את מהירות הריצה. הרציונל, כפי שמתואר במקור: סוכני AI הפכו את כתיבת הקוד למהירה משמעותית, אבל תהליך האימות שלו — בדיקות, טיפוסים (typing) ולינטינג — לא התקדם באותו הקצב, וכל בקשת משיכה עדיין חייבת לעבור את אותו שרשור בדיקות.
ארבעה כיווני שיפור
הצוות בלינר מיפה ארבע חזיתות עבודה:
שדרוג תשתית וכלים — מעבר מ-GitHub Actions לרצי (runners) של צד שלישי עם מעבדים מהירים יותר ואחסון וקאשינג משופרים הניב, בהשוואה של יומיים לפני ואחרי המעבר, ריצות מהירות ב-34% בממוצע, כאשר בדיקת ה-tsc (בודק הטיפוסים של TypeScript) הצטמצמה ב-52%. מעבר נוסף ל-tsgo, מהדר TypeScript מקורי (native), קיצץ את החציון השבועי של בדיקת ה-tsc ב-73%, עד כדי כך שבדיקת הטיפוסים חדלה להיות הגורם המעכב המרכזי.
לינטינג בלי בודק הטיפוסים — חלק מכללי הלינט המותאמים אישית בלינר הסתמכו על מידע טיפוסים של TypeScript, מה שחייב בניית "גרף טיפוסים" מלא בכל ריצה — תהליך כבד זיכרון. הצוות כתב מחדש את הכללים כך שיפעלו על ניתוח סטטי של עץ התחביר (AST) בלבד, ללא תלות בטיפוסים. השינוי צמצם את זמן הלינט ל-API ב-68% ואת זמן הלינט על כל המאגר ב-55%, והוריד משמעותית גם את צריכת הזיכרון. אותו שינוי גם פתח את הדלת למעבר לכלי בשם Oxlint, שכן כללים המבוססים על תחביר בלבד קלים יותר להעברה.
ייעול המשימות ה"שוערות" — כל ריצת CI מתחילה בבדיקה אילו קבצים השתנו ואם הבדיקות כבר רצו בעבור על אותו קלט. משימות אלו קטנות אך יושבות בראש שרשרת התלויות: אף אחד משמונת ה-shards (פיצולי בדיקות מקבילים) של בדיקות ה-API לא יכול להתחיל עד שהן מסתיימות, כך שעיכוב קטן בהן משפיע באופן לא פרופורציונלי על הזמן הכולל.
צמצום הכנה חוזרת — משימות זיהוי שינויים (למשל בדיקה אם דיף כולל מיגרציית מסד נתונים) ביצעו עד כה checkout מלא של עץ הקוד, למרות שנזקקו רק לחלק קטן ממנו; הגבלת עומק ה-fetch צמצמה את הזמן הזה. המקור נקטע בשלב זה ולא פירט את שאר הפרטים הטכניים של הצעד.
למה זה חשוב
הסיפור של לינר משקף, ככל הנראה, תופעה רחבה יותר בתעשיית התוכנה: ברגע שסוכני AI מייצרים קוד בקצב גבוה משמעותית מבעבר, שלבי האימות — CI, code review, בדיקות אבטחה — הופכים בהדרגה לגורם המגביל את קצב השחרור, ולא כתיבת הקוד עצמה. המשמעות עבור צוותי פיתוח אחרים היא כנראה שהשקעה בתשתיות בדיקה ותהליכי אימות עשויה להפוך לצורך דחוף לא פחות מהשקעה בכלי הקידוד עצמם.