גרסה 19 של Postgres נדחתה: כלי AI לסקירת קוד מוצאים יותר באגים ממה שהמפתחים מספיקים לתקן
קבוצת הפיתוח של PostgreSQL דחתה את גרסה 19 של מסד הנתונים לסביבות 19 בנובמבר, והוציאה ממנה בין שמונה לעשר יכולות משמעותיות. לדברי המפתח הבכיר פיטר אייזנטראוט, אחת הסיבות היא סקירת קוד בעזרת LLM: היא מאתרת עשרות תקלות קטנות שאין לצוות זמן לטפל בכולן לפני ההשקה.
קבוצת הפיתוח העולמית של PostgreSQL (PostgreSQL Global Development Group) דחתה את השקת PostgreSQL 19, הגרסה הבאה של מסד הנתונים הפופולרי בקוד פתוח, כך מדווח The Register. ההשקה תוכננה לסוף ספטמבר או לתחילת אוקטובר, ועכשיו היא צפויה בסביבות 19 בנובמבר. בנוסף הוצאו מהגרסה בין שמונה לעשר יכולות משמעותיות, שיידחו ככל הנראה ל-PostgreSQL 20, הגרסה של השנה הבאה.
הסיבה, לפחות בחלקה, אינה קוד גרוע. דווקא הכלים שבודקים אותו השתפרו.
ארבעים דוחות תקלה, שלוש שורות בממוצע לתיקון
פיטר אייזנטראוט, סגן נשיא בחברת EDB שמספקת תמיכה וייעוץ ל-PostgreSQL ואחד ה-committers הבולטים בפרויקט (מפתחים שמורשים להכניס קוד למאגר הראשי), הסביר בפוסט בבלוג שלו את המספר החריג של היכולות שהוסרו. לדבריו, בחלק מהן נמצאו פגמים ארכיטקטוניים משמעותיים שהיה קשה לתקן "מהר ובמהלך הבטא".
אבל לצד הבעיות הגדולות האלה, סקירת קוד בסיוע LLM (מודל שפה גדול) חשפה גם "זנב ארוך" של "בעיות לא מזיקות יחסית במקרי קצה שונים". בעבר, הוא כתב, בעיות כאלה היו מתגלות הרבה יותר מאוחר, וככל הנראה מתוקנות בעדכונים במהלך חמש השנים שאחרי ההשקה.
"עם סקירת קוד בסיוע LLM, דברים כאלה מתגלים הרבה יותר מהר, ואז אתה מסתכל על רשימה של ארבעים דוחות תקלה", כתב אייזנטראוט. "גם אם כל אחד מהם דורש בממוצע רק תיקון של שלוש שורות, יש תקורה קבועה בטיפול בכל אחד, ואז נגמר לך הזמן".
כאן נמצא לב העניין: כלי ה-AI מוצאים בעיות מהר, אבל כל ממצא עדיין צריך מישהו שיבין אותו, יאמת אותו, יכתוב תיקון, יבדוק אותו ויעביר אותו סקירה. את החלק הזה עושים בני אדם, ובפרויקט קוד פתוח מספרם מוגבל.
הרף עלה אחרי שהקוד כבר נכתב
לפי אייזנטראוט, כשהיכולות הגדולות של גרסה 19 נכתבו, סקירת קוד בסיוע LLM עוד לא הייתה שימושית כמו היום. בחודשים שלפני ההשקה המפתחים למדו להשתמש בה, והיא הפכה ליעילה יותר. "רף האיכות בפועל עלה אחרי שהיכולת נכתבה ונכנסה לקוד", כתב. "אלא אם היכולות של סקירת קוד בסיוע LLM ימשיכו להשתפר בקצב הנוכחי, המצב הזה אמור להסתדר במחזורי הפיתוח הבאים".
הוא גם הקפיד להבהיר שההסרות לא נבעו מ"vibe coding", כלומר כתיבת קוד שמבוססת על הנחיות למודל AI, כי השיטה הזו לא הייתה זמינה כשרוב היכולות החדשות נכתבו.
אחת היכולות שהוסרו היא תמיכה ב-SQL Property Graph Queries (SQL/PGQ), שנכנסה לתקן SQL ב-2023 ומאפשרת לשאול שאילתות על קשרים בין צמתים שמחוברים בקשתות, כמו בגרף. היא הוסרה בגלל בעיות שלא נפתרו. המפתח טום ליין הזהיר בזמנו: "בשלב הזה הייתי מוכן להתערב על ארוחת ערב שאם נשיק את זה ב-v19, יתגלו באגים אחרי ההשקה שאי אפשר יהיה לתקן עד v20".
למה זה חשוב
PostgreSQL, שמקורו בפרויקט Postgres שהציע מייקל סטונבריקר ב-1986, הוא היום מסד הנתונים הפופולרי ביותר בקרב מפתחים מקצועיים. חלק גדול מהפופולריות נובע מהשירותים ששלוש ספקיות הענן הגדולות בנו עליו, וממערכות מבוזרות רבות שתואמות לו ברמת הפרוטוקול. לכן עיכוב בגרסה שלו מגיע הרחק מעבר לקהילת המפתחים.
המקרה ממחיש מחיר שלא תמיד מדברים עליו כשמאמצים כלי AI לפיתוח. בדיקת קוד הפכה לזולה, אבל תיקון קוד לא. סביר להניח שפרויקטים שמתוחזקים על ידי מתנדבים ועובדי חברות בקצב מוגבל יצטרכו להחליט אילו ממצאים לתקן, אילו לדחות, ומתי להקפיא יכולות.
לפחות בטווח הקצר יש גם תמורה. אייזנטראוט מבטיח ש-PostgreSQL 19 תהיה "גרסה מצוינת", כולל REPACK CONCURRENTLY, שמאפשר לפנות שטח דיסק בלי פעולת VACUUM FULL, שנועלת את הטבלה. "והיא תהיה חסינה מאוד, אחרי כל הבדיקה הנוספת", הוסיף.
גם לוח הזמנים של PostgreSQL 20 השתנה. לפני כמה חודשים המפתחים העריכו שהיא לא תכלול יכולות חדשות בכלל, רק תיקוני באגים. עכשיו היא צפויה לקבל את היכולות שנדחו מגרסה 19.