הקוד שה-AI לא יכתוב

אני משתמש באימות טפסים (form validation) כשאלת ראיון טכנית. זה נראה פשוט. התשובות חושפות איך אנשים חושבים.

בדקתי את הבעיה הזו ב-Claude, ChatGPT וב-Gemini. כולן הגיעו לאותן פתרונות.

רוב האנשים משתמשים בפונקציה אחת עם פרמטר מסוג (type parameter) כדי לטפל בכתובות שונות. זה עובד. אבל כל כלל חדש מוסיף ענף (branch) חדש לאותה פונקציה. ההבדלים נשארים חבויים.

התשובה האנושית החכמה ביותר שראיתי השתמשה ברקורסיה. היא עוברת על מבנה הנתונים (data shape). זה אלגנטי. אבל יש לה פגם. היא מאמתת רק שדות שקיימים. אם מפתח (key) חסר, הפונקציה לעולם לא תראה אותו. אין לה מקור אמת (source of truth).

כל שלושת ה-AIs עשו את אותה טעות. כשציינתי את הפגם, כולן הציעו סכימה (schema). גישה מונחית-סכימה (schema-driven) היא נכונה מבחינה טכנית. היא מטפלת במפתחות חסרים ומתרחבת (scales) היטב.

אבל יש דרך טובה יותר: Composition.

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

משלבים אותן כדי לבנות את המאמת (validator) שלכם.

הגישה הזו פותרת את בעיית המפתח החסר. המאמת של ה-billing תמיד בודק מספר מע"מ (VAT), גם אם המפתח חסר. זה עובד כי כתובת חיוב היא מושג עסקי אמיתי. היא לא רק תבנית (pattern) בנתונים שלכם.

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

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

ה-AI יורש את האינסטינקט הזה מנתוני האימון שלנו. הוא נותן עדיפות להכללה (generalization).

הבעיה היא לא שה-AI טועה. הבעיה היא שה-AI כמעט ולא שואל את השאלה החשובה ביותר: האם השונות הזו נמצאת בקוד שלי או בנתונים שלי?

אם סוגי הכתובות יציבים, השתמשו ב-composition. אם סוגי הכתובות משתנים באמצעות נתונים חיצוניים, השתמשו בסכימה.

הפתרון הפשוט ביותר הוא לא זה עם הכי פחות שורות קוד. הוא זה שמשקף את הדומיין העסקי (business domain) שלכם.

Source: https://dev.to/iceonfire/the-code-ai-wont-write-1ieb

קהילת למידה אופציונלית: https://t.me/GyaanSetuAi