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

"מה בעצם הבעיה?"

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

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

אבל זאת לא ההשוואה הנכונה.

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

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