סיכוני קוד תכנות הנוצר על ידי מוצרי בינה מלאכותית

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

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

המירוץ הזה פחות מעניין אותי. אותי מעניינים הסיכונים. 

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

דוגמה מהשטח 

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

אחד המתכנתים החליט לתת למוצר AI לכתוב קוד של Firmware.

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

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

הדוגמה הזו היא חריגה מבחינת השימוש שנעשה במוצר ה-AI. 

שימוש רגיל

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

 

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

תחזוקה ופיתוח

מקצועני מחשוב אומרים שתחזוקת מערכות (ובכלל זה קוד המערכות) היא כ-70% מהתשומות של תוכנה. 

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

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

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

אלגוריתמים וקידוד

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

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

דוגמה שתבהיר את הטענה

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

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

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

את תוכנית המקור כבר לא מצאתי. נאלצתי לנתח את ה-Object Code (יצוג בשפת מכונה). 

הבעיה הייתה באלגוריתם. כל 4 שנים יש שנה מעוברת שבה יש תאריך של 29 בפברואר (נדמה לי שכל 100 שנים אין שנה מעוברת. במידת הצורך המעשי אלך לבדוק האם זה נכון). 

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

הבעיה נוצרה בדיוק 4 שנים אחרי הקבוע האחרון בתוכנית שיצג שנה.

הטיית ייצוגיות אישית

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

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

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

מסקנות

1. גם בהקשר הזה תקף המחקר של MIT על פיו ב-95% מהארגונים אין תועלות מעשיות של AI חרף ההשקעות הגדולות מאוד. 

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

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

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

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

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

גם לפני הרבה שנים היו כלי Case ומוצרי BPM שיצרו קוד. 

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

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