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

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

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

עכשיו לשאלה - האם זה באג?

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

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