איך ה-AI הורסת את הקוד וכיצד אפשר לתקן את זה?

84% מהמפתחים כבר משתמשים בכלי AI לכתיבת קוד – כך עולה מסקר של סטאק אוברפלואו. בפועל, כנראה שמדובר באחוז גבוה אפילו יותר. כלים כמו GitHub Copilot ו-Cursor כבר הפכו לנחלת הכלל, ומנהלים בענקיות הטכנולוגיה דוחפים את העובדים שלהם להשתמש בהם ביום יום.

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

למה זה קורה, וחשוב מכך – איך אפשר למנוע את זה?

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

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

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

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

קידוד בסיוע AI – בעיות ופתרונן. צילום: ShutterStock

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

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

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

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

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

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

הלקח: לבנות נכון, לא רק מהר

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

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

הכותבת הינה מדענית ראשית ב-bit.cloud.