פעם, בתחילת הדרך של עולם הראייה הממוחשבת, מודלים של AI זיהו פרות על כבישים בתור מכוניות.
למה? כי הם למדו לזהות את האספלט, לא את הרכב. הלוגיקה של המודל הייתה פשוטה להפליא: פרה על אספלט = מאזדה 3. (הגיוני סך הכל, אם אתה אלגוריתם שמעולם לא ראה טבע).
מאז עברו הרבה מים בנהר ה-GPU. תיקנו את זה, דחפנו למודלים דאטה הרבה יותר טוב, והרגשנו שניצחנו את המערכת. היום אנחנו מסתכלים על LLMs ומרגישים שהם מבינים אותנו, שהם שותפים לדרך. אבל כ-CTO או VP R&D, כדאי שתדעו שהבעיה הבסיסית לא זזה מילימטר. ה-AI הוא כלי רב עוצמה, אך כשהוא פוגש את המורכבות הייחודית של ארכיטקטורת תוכנה ודרישות פרודקשן ספציפיות, הוא נוטה לספק פתרונות גנריים, הדורשים מומחיות אנושית קריטית כדי למנוע חוב טכני וכישלונות.
ה-AI עדיין מוגבל למה שהוא בלע ב"אימון". פרה על כביש כולם יודעים לזהות היום, אבל כשאנחנו דוחפים מודלים לתחומים המורכבים של ארכיטקטורת תוכנה, לוגיקה עסקית סבוכה וביצועים תחת עומס – שם בדיוק מתחילה ה"שכונה".
הבעיה שלא זזה מילימטר: האשליה של הנתונים הגנריים
המודלים המודרניים הם רהוטים להפליא. הם יודעים לכתוב קוד Python שנראה נקי, הם יודעים להסביר למה הם בחרו ב-Design Pattern מסוים, והם עושים את זה בביטחון עצמי של ארכיטקט עם 20 שנות ניסיון. אבל מתחת למכסה המנוע, הם עדיין מחפשים את האספלט.
הבעיה היא שרוב מה שה-AI למד ב"בית ספר ל-AI" (כלומר, על הררי הקוד של GitHub) הוא הממוצע של הממוצע. הוא יודע איך לפתור בעיות גנריות בצורה סבירה. אבל הארגון שלכם לא חי על בעיות גנריות. הארגון שלכם חי על הפינות, על האופטימיזציות הספציפיות, על ה-Use Cases שמי שכתב את ה-Tutorial הממוצע באינטרנט לא חשב עליהם.
ה-AI שלכם בפרודקשן מקבל כנראה עכשיו החלטות כאלה. הוא פולט תשובות שנראות נכון כי זה מה שהוא מכיר, ואתם תגלו את זה רק במקרי קיצון – כשלקוח חשוב יתלונן, או כשהמערכת פשוט תפסיק להגיב.
המקרה של האלגוריתם והצבי: כשהקוד ה"מושלם" פוגש את המציאות
הנה משהו שקרה לי לאחרונה, המחשה חיה לפער שבין דמו למציאות. היינו צריכים אלגוריתם find-replace מורכב. ביקשנו מה-AI, והוא פלט קוד פגז. הקוד עבר טסטים, הוא היה אלגנטי, הוא עבד מושלם בסביבת הפיתוח.
אבל אז שמנו את זה ביוז-קייס הספציפי שלנו, על נפחי דאטה אמיתיים ובתוך הקונטקסט של המערכת שלנו, והדבר הזה פשוט זז לאט. ברמה של צבי עם בעיות ברכיים.
מה היה הקטע המעצבן? שה-AI קיבל מאיתנו את כל הקונטקסט. הוא ידע בדיוק מה אנחנו צריכים, מה המגבלות ומה היעדים. אבל מה שהוא למד בבית הספר לא כיסה את הפינה הספציפית הזאת. אז הוא פשוט זרק עלינו את הפתרון ה"נכון" והגנרי, כי זה מה שהיה לו במחסנית. לא היה לו איך לייצר את הפתרון הנכון לנו.
זה ההבדל בין מפתח שיודע לכתוב סינטקס לבין ארכיטקט שמבין את המשמעות של כל שורת קוד על ה-Main Loop של המערכת. ה-AI הוא מפתח סינטקס מעולה, אבל הוא ארכיטקט גרוע מאוד בסיטואציות שדורשות חשיבה מחוץ לסטטיסטיקה.
המעבר מדמו לפרודקשן: איפה שהשכונה מתחילה
מנהלי טכנולוגיה רבים נופלים במלכודת ה-Velocity המדומה. הצוות מדווח על עלייה של 40% בפרודוקטיביות, הקוד נכתב מהר יותר, ה-PRs נסגרים בקצב מסחרר. זה מרגיש כמו ניצחון.
אבל פה בדיוק טמון הסיכון. ה-AI מצטיין ביצירת ה"דמו". הוא יודע לגרום לדברים להיראות עובדים. אבל בפרודקשן, הקוד הזה הופך לחוב טכני סמוי. אם המפתחים שלכם לא מבינים למה הפתרון עבד, הם לא ידעו למה הוא יפסיק לעבוד כשהעומס יעלה פי 10.
כשאנחנו דוחפים מודלים לתחומים מורכבים – מערכות מבוזרות, ניהול זיכרון, אופטימיזציה של שאילתות – אנחנו מהמרים על כך שה-AI נתקל במקרה דומה מספיק פעמים. אבל המציאות היא שכל מערכת ארגונית היא אינדיבידואלית. פתרון שמתאים ל-Netflix לא בהכרח יתאים לסטארט-אפ ב-Series B שמריץ Kubernetes על On-prem. ה-AI לא תמיד יודע להבחין בדקויות האלה.
המומחה בחדר: האינטואיציה שאי אפשר לאמן
בגלל כל זה, היום יותר מתמיד, חייבים מומחה בחדר. מישהו שיודע להיות הסמן הימני, הבלם שמונע מהרכבת הזאת לרדת מהפסים.
אתם צריכים מישהו שיקבל חום כשהוא רואה פלט "נכון" אבל מנותק מהמציאות. בדיוק כמו שהייתם מקבלים חום אם הייתם רואים פרה שעושה רברס בחניה.
התפקיד של המומחה (ה-Bionic Expert) הוא לא להחליף את ה-AI, אלא להיות הארכיטקט שמעליו. מישהו שמכיר את הדומיין מספיק טוב כדי לזהות את הנקודות העיוורות של האלגוריתם לפני שהן מתרסקות על הלקוחות.
זה דורש סוג חדש של מנהיגות טכנולוגית: כזו שלא מתפעלת מהמהירות, אלא שואלת שאלות קשות על המהות. האם הקוד הזה באמת יעיל? האם הוא מתחשב ב-Race Conditions שקיימים רק אצלנו? האם אנחנו בונים מוצר, או שאנחנו בונים צעצוע שנראה טוב בדמו?
Takeaways
ה-AI הוא כלי עוצמתי, אולי העוצמתי ביותר שקיבלנו בעשור האחרון, אבל הוא לא תחליף לחשיבה ארכיטקטונית עמוקה. כדי לא ליפול למלכודת ה"מאזדה 3", הנה כמה נקודות למחשבה:
- אל תסתנוורו מהמהירות: פרודוקטיביות בכתיבת קוד היא לא פרודוקטיביות בבניית מוצר. תוודאו שהצוות שלכם לא מייצר חוב טכני בקצב של GPT-4.
- הקונטקסט הוא המלך: ה-AI חזק רק כמו הקונטקסט שהוא מקבל, וגם אז, הוא נוטה לפתרונות גנריים. תדרשו מהמפתחים שלכם לאתגר את ה-AI ולחפש את הפתרון שמותאם ספציפית למערכת שלכם.
- שימרו על המומחיות: אל תתנו לצוות שלכם להפוך ל"מפעילי AI". הם חייבים להמשיך ללמוד את המערכות הבסיסיות, את ה-Internals. אם הם לא יבינו איך זה עובד למטה, הם לא יוכלו לתקן את זה כשה-AI יטעה.
- ביקורת ארכיטקטונית: תנהיגו תהליכי Review שמתמקדים בנקודות התורפה של AI – יעילות, אדג' קייסים וחיבור למציאות העסקית.
בסוף, אתם לא רוצים לגלות שיש לכם פרה שעושה רברס בחניון של הפרודקשן. אתם רוצים מוצר יציב, סקלבילי ואיכותי. וזה, נכון להיום, דורש אדם ביוני שיודע מתי להגיד ל-AI: "יופי של פתרון גנרי, עכשיו בוא נכתוב את מה שבאמת צריך".