מפתח מדביק לכלי AI תיאור של פיצ'ר ומקבל תוך דקה מאה וחמישים שורות קוד שנראות מצוין. הן עוברות קומפילציה, הדמו עובד, ומנהל המוצר מתרשם. שבועיים אחר כך מתברר שהקוד מניח שכל משתמש שייך לארגון אחד, מתעלם ממקרה שפג תוקף, וקורא לספרייה שהמערכת כבר מחליפה. הדקה שנחסכה הפכה לשלושה ימים של תיקונים.
כלי AI לפיתוח משנים את העבודה, אבל לא בכל מקום באותה מידה. יש פער גדול בין ההבטחות לבין מה שמקבלים בפועל, והמאמר הזה מפריד בין השניים לפי סוג המשימה.
איפה AI חוסך זמן באמת
הדפוס שחוזר: משימות עם מבנה ברור, קלט מוגדר ותוצאה שקל לבדוק.
קוד שחוזר על עצמו. מבני נתונים, ממשקי CRUD, מיפוי בין פורמטים, סקריפטים למיגרציה. העבודה מכנית, והטעויות בדרך כלל נתפסות מהר בבדיקה.
כתיבת בדיקות. כלי טוב מציע מקרי קצה שמפתח עייף לא היה חושב עליהם, ובונה שלד של בדיקות לפונקציה קיימת. חשוב לקרוא אותן, כי בדיקה שכתובה בלי הבנה של הכוונה תאשר גם התנהגות שגויה.
הבנת קוד זר. הסבר של מודול ישן, מעקב אחרי זרימה בין קבצים, זיהוי מה פונקציה עושה כשאין תיעוד. בפרויקטים שמתחילים מקוד ירושה זה חוסך שעות של קריאה.
שכתוב מכני. שינוי שם בכל המערכת, מעבר בין גרסאות של ספרייה, החלפת תבנית אחת באחרת. כל עוד מריצים את הבדיקות אחר כך, התוצאה אמינה.
טיוטות של תיעוד והודעות commit. לא חדשני, אבל מפחית את הסיבה הנפוצה לכך שתיעוד לא נכתב: עצלות.
ניתוח לוגים ושגיאות. הדבקת stack trace עם הקשר קצר חוסכת לפעמים חצי שעה של חיפוש. השיפוט מי הגורם האמיתי עדיין נשאר אצל האדם.
מבחן מהיר לפני שמאציל משימה לכלי
שלוש שאלות מספיקות. האם אפשר לתאר את התוצאה הרצויה בכמה משפטים? האם אפשר לבדוק אותה אוטומטית או בקריאה של דקות? והאם טעות במשימה הזו נתפסת לפני שהיא מגיעה למשתמש? אם התשובה לשלושתן כן, זו משימה טובה לכלי. אם אחת מהן לא, כנראה שזמן הבדיקה יאכל את החיסכון.
המבחן הזה עוזר גם לשים גבול למי שמתלהב: לא כל משימה מתאימה, ואין בזה פגם בכלי.
איפה זה רק נשמע טוב
"AI יחליף את המפתחים". מה שמשתנה הוא חלוקת הזמן בתוך המקצוע: פחות הקלדה, יותר קריאה, בדיקה והחלטה. הצורך בשיקול דעת הנדסי גדל, כי יש יותר קוד לבדוק.
הפיכת מערכת שלמה מהנחיה אחת. כלים מייצרים אב-טיפוס מרשים. המרחק בין אב-טיפוס למערכת ייצור כולל הרשאות, טיפול בשגיאות, עומסים, תאימות ואבטחה, והוא נשאר רוב הדרך.
החלטות ארכיטקטורה. הכלי יענה בביטחון על כל שאלה. הוא לא מכיר את האילוצים שלכם, את החוב הטכני, את הצוות או את ההיסטוריה של המוצר, ולכן התשובה סבירה באופן כללי ולא בהכרח נכונה אצלכם.
מספרי "פי שניים מהיר". מדידה לפי שורות קוד שנכתבו היא מטעה, כי יותר קוד זה לא יותר ערך. המדד שחשוב הוא כמה זמן עובר ממשימה ועד פיצ'ר שרץ בפרודקשן ואינו חוזר עם באגים. מי שלא מודד אותו לא יודע אם הוא חוסך.
בעבודה היומיומית שלנו, החיסכון הגדול מגיע במשימות שגרתיות: כתיבת בדיקות, המרת קוד בין פורמטים ותיעוד. הסיכון הגדול מגיע מקוד שנראה נכון ועובר את הבדיקה הראשונה, אבל לא מטפל במקרי קצה. לכן כל קוד שנוצר בעזרת AI עובר אצלנו את אותו code review כמו כל קוד אחר.
שלוש בעיות שצריך לצפות מראש
קוד שנראה נכון ואינו נכון
מודלים מייצרים קוד משכנע. הם גם ממציאים פונקציות שלא קיימות, מציעים חבילות שלא כתבו, ומשתמשים ב-API שהוחלף. בגלל השטף של התשובה קל לאשר בלי לבדוק. לכן ה-code review חשוב יותר בעידן הכלים האלה, ולא פחות.
אבטחה ומידע רגיש
קוד, מפתחות ונתוני לקוחות שמודבקים לכלי חיצוני יוצאים מהארגון. צריך להחליט מראש מה מותר לשלוח, באילו כלים ובאילו תנאים. כשהמידע רגיש במיוחד, אפשר להריץ מודלים בתשתית שלכם, ואנחנו עוסקים גם בזה: מודלים on-prem הם חלק מהעבודה שלנו בתחום ה-AI. קוד שנוצר צריך לעבור את אותן בדיקות אבטחה כמו כל קוד אחר. על הנושא הרחב יותר כתבנו במאמר על אבטחה וקניין רוחני.
חוב טכני שמצטבר בשקט
כלי שמייצר קוד מהר מאפשר לצבור אלפי שורות לפני שמישהו שואל אם הן שייכות לשם. תוצאה אפשרית: מערכת בלי סגנון אחיד, עם פתרונות כפולים לאותה בעיה. כשקוד נכתב מהר, צריך גם לבדוק מהר שהוא מתאים למבנה הקיים.
בפרויקטים שמתחילים מקוד ירושה, השילוב הזה שימושי במיוחד: קודם מבינים עם הכלי מה הקוד עושה, אחר כך כותבים בדיקות שמקבעות את ההתנהגות הקיימת, ורק אז משנים. הסדר מקטין את הסיכוי לשבור משהו בלי לשים לב.
חמישה כללים להטמעה בצוות
הכלי מגביר את מה שכבר קיים בצוות. מפתח מנוסה משתמש בו כדי לעבוד מהר על דברים שהוא מבין, ויודע לזהות מתי התשובה חשודה. מפתח חסר ניסיון מקבל קוד שהוא לא מסוגל לשפוט. זו אחת הסיבות שאנחנו לא מגייסים מפתחים עם פחות מחמש שנות ניסיון.
- מתחילים במשימות הקטנות והבדוקות מהרשימה הראשונה, ומרחיבים רק אחרי שרואים תוצאות.
- כל קוד שנוצר עובר review כמו קוד אנושי. מי שמגיש אחראי עליו כאילו כתב אותו בעצמו.
- בדיקות לפני אמון. אם אין בדיקות אוטומטיות, אין דרך לדעת אם הקוד שנוצר מתנהג כמו שצריך.
- כללי מידע כתובים: מה לא מדביקים לכלי חיצוני, ובאילו כלים מותר להשתמש.
- מודדים זמן מסוף לסוף ולא שורות קוד או שביעות רצון. משווים אותו לתקופה לפני ההטמעה.
כדאי גם לקבוע מי בצוות אחראי על לעדכן את הכללים. הכלים והמודלים משתנים תוך חודשים, וכלל שנכתב פעם אחת ונשכח הופך מהר לחסר משמעות.
ומה לגבי AI כחלק מהמוצר
זו שאלה נפרדת: להשתמש ב-AI כדי לכתוב קוד, או להכניס אותו לתוך המוצר. האפשרות השנייה כוללת החלטות אחרות לגמרי על נתונים, איכות תשובות ועלויות. נקדיש לה מאמר נפרד. אנחנו עובדים בתחום הזה בפועל, ובין היתר ב-RAG, סוכנים, ניתוח מסמכים, כוונון מודלים, מודלים on-prem, ראייה ממוחשבת ו-voice AI.
השורה התחתונה
AI חוסך זמן במשימות מוגדרות ובדוקות, ומוסיף עבודה כשמשתמשים בו כתחליף לשיקול דעת. מי שמטמיע אותו עם כללי עבודה ומדידה מקבל תועלת מתמשכת. מי שמטמיע אותו מתוך התלהבות מגלה את המחיר בשלב ה-QA.
אם אתם מחפשים מפתחים בעלי ניסיון שיודעים לעבוד גם עם הכלים האלה בצורה מבוקרת, אפשר להתחיל בהרחבת צוות.
