סקריפטי Oracle SQL המופקים על ידי סוכני מודלי שפה גדולים (LLM) יכולים להיראות ללא רבב על הנייר ועדיין "להתפוצץ" בסביבת הייצור (production). בבסיס קוד ישן (legacy) בן 2.3 מיליון שורות, סוכן מבוסס AI החליק באופן קבוע מזהים (identifiers) שלא היו קיימים – למשל, שימוש ב-POLICY_STATUS במקום בעמודת STATUS_CD האמיתית, או התייחסות לטבלת CUSTOMERS שאינה קיימת במקום ל-CUSTOMER.
הרצת הסקריפט כדי לתפוס את שגיאת ההקלדה אינה אפשרות עבור פקודות UPDATE או DELETE. ביצוען על סט נתונים הדומה לייצור גורם לנעילות (locks), צורך במספרי רצף (sequence numbers) ועלול להפעיל השפעות לוואי שרשרתיות. מפתחים זקוקים לדרך לאמת שמות ותחביר מבלי לגעת בנתונים כלשהם. התשובה, הפשוטה להפליא, היא פקודת ה-EXPLAIN PLAN של Oracle – שמשמשת כאן כשלב linting.
איך EXPLAIN PLAN עובד כמתקף (validator) מהיר
כאשר Oracle מקבלת פקודה, היא קודם כל מנתחת אותה (parsing). ה-parsing בודק שכל טבלה, עמודה והרשאה (privilege) שמוזכרים אכן קיימים, לאחר מכן בונה תוכנית ביצוע וכותבת את התוכנית לטבלת מערכת. הפקודה לעולם אינה מריצה את הפקודה: אף שורה אינה משתנה, אף טריגר אינו מופעל, ואף נעילה אינה נלקחת. אם המנתח (parser) נתקל באובייקט לא ידוע, הוא זורק שגיאה תוך שבריר שנייה.
התנהגות זו הופכת את EXPLAIN PLAN לבדיקת pre-flight מושלמת עבור SQL שנוצר על ידי AI. טבלה או עמודה חסרה מדווחות באופן מיידי, מה שמאפשר ללולאת היצירה לתקן את הטעות לפני שבני אדם רואים את הסקריפט.
תהליך העבודה שחיברתי לצינור ה-CI שלי
- פצל את הסקריפט הנכנס לפקודות בודדות.
- הרץ
EXPLAIN PLAN FOR <statement>מול סכימת פיתוח (development schema). - אסוף כל שגיאת parsing ש-Oracle מחזירה.
- הזן את השגיאות חזרה ל-LLM לצורך ניסיון חוזר.
בפועל, ניסיון חוזר אחד פותר את רוב שגיאות השמות. ה-AI לומד את הסכימה הנכונה ומתאים את הפלט שלו באופן אוטומטי. אני גם נועל את הסוכן למצב קריאה בלבד (read-only): הוא יכול להוציא פקודות SELECT וקריאות EXPLAIN PLAN, אך פקודות DDL, DML ו-COMMIT חסומות. ארגז החול (sandbox) הזה מבטיח שמאגר הנתונים יישאר ללא שינוי בזמן שה-AI בוחן את המבנה שלו.
מעבר לבדיקות שמות, התוכנית שנוצרת חושפת "דגלים אדומים" ברורים של ביצועים. אם פקודה תגרום לסריקה מלאה של טבלה (full-table scan) בטבלה עצומה, התוכנית תראה זאת לפני שנוגעים בשורות כלשהן, מה שנותן למפתחים הזדמנות להציע אינדקסים או לשכתב את התנאי (predicate).
מגבלות הגישה
- נכונות לוגית אינה מאומתת. פקודה המתייחסת לעמודות הנכונות אך מחילה מסנן (filter) שגוי עדיין תעבור את ה-lint.
- בלוקים של PL/SQL אינם בתחום. המנתח מטפל רק בפקודות SQL בודדות; קוד פרוצדורלי דורש נתיב אימות נפרד.
- חסרה אימות ברמת הנתונים. ה-lint לא יכול לומר לך אם ערך ליטרלי תואם לדומיין של עמודה או אם הפניה למפתח זר (foreign-key) קיימת בפועל.
- סכימת פיתוח בלבד. שגיאות שמופיעות רק בייצור – למשל, טבלה שקיימת בפיתוח אך שמה שונה בייצור – נותרות בלתי נראות עד מאוחר יותר.
הפערים הללו אינם מפחיתים מהתועלת של השיטה; הם פשוט מגדירים את ההיקף שלה. עבור רוב סקריפטי ה-DML שנוצרו על ידי LLM, מצב הכשל הנפוץ ביותר הוא שגיאת הקלדה או שם אובייקט שגוי, וזה בדיוק מה ש-EXPLAIN PLAN תופס.
ניידות למנועי בסיסי נתונים אחרים
אותו עיקרון תקף גם מעבר ל-Oracle. פקודת PREPARE או EXPLAIN של PostgreSQL יכולות לנתח שאילתה ללא ביצוע. SQL Server מציע את SET PARSEONLY ON, שמאלץ את המנוע לאמת תחביר ושמות אובייקטים תוך דילוג על העיבוד בפועל. כל RDBMS שמפריד בין parsing לביצוע יכול להפוך לשער linting קל משקל.
שורה תחתונה
הרצת EXPLAIN PLAN (או המקבילה לו) על כל פקודת SQL שנוצרה על ידי AI הופכת את מנתח בסיס הנתונים לשער linting זול ונטול סיכון. הוא תופס את שגיאות השמות והתחביר השכיחות ביותר לפני שכל נתון זז, מה ששומר על יציבות מערכות legacy תוך מתן אפשרות למפתחים ליהנות מזינוק בפריון של כתיבת קוד בסיוע LLM.