בכל פעם שמתחילה מהפכה טכנולוגית, מגיעה איתה אינפלציה של טייטלים. פתאום כולם מומחים או סניורים, הלינקדאין מתמלא בהגדרות חדשות, והציניות הבריאה (בדרך כלל) של אנשי הפיתוח מתחילה לעבוד שעות נוספות.
לאחרונה עולה לא מעט הדיון סביב הטייטל "AI Engineer". מצד אחד, חברות מחפשות אותם בנרות. מצד שני, מתכנתים ותיקים מסתכלים מהצד ושואלים: רגע, זה לא סתם Backend Developer עם API של OpenAI? למה צריך שם מפוצץ לכל דבר? אז בתור "זקן השבט", שראה כבר כמה באזזוורדס באות והולכות (הבלוג הזה קיים כבר 18 שנה!), ובתור מי שמוביל בשנה האחרונה פיתוח של מוצר מבוסס מולטי מודל בסייברארק ועובד ב-AI&Data Office החלטתי לנסות לעשות סדר בבלגן. האם זה אמיתי, או שזו המצאה של מחלקות משאבי אנוש?
מילת אזהרה: שימו לב שאני לא יודע מה יהיה בעתיד וגם לא יודע כל, כותב מהזווית האישית שלי.
כן, הטייטל AI Engineer קיים
בדיון בלינקדאין היו כמה סקפטיים שטוענים שמדובר ב'המצאה תקופתית' או בניסיון למתג מחדש תפקידים קיימים. אולי אתם צודקים אבל אני לא אוהב להיות דון קישוט שנלחם בטחנות רוח. אני מציע מבחן מציאות פשוט: המספרים. המספרים לא משקרים והגרפים לא משאירים מקום לספק. אנחנו רואים זינוק אקספוננציאלי במשרות תחת הטייטל הזה, ולא מדובר רק בסטארטאפים שמחפשים הייפ למשקיעים, אלא בחברות אנטרפרייז שפותחות מחלקות שלמות תחת ההגדרה הזו בדיוק. יותר מזה, תסתכלו על דרישות התפקיד ('האותיות הקטנות'). הן ספציפיות להחריד ושונות מהותית ממשרת בקאנד רגילה. אף אחד שם לא מחפש ״מתכנת שיודע להשתמש ב-ChatGPT״ הם מחפשים ניסיון מוכח בארכיטקטורת RAG, היכרות עמוקה עם Frameworks כמו LangChain או LlamaIndex, הבנה ב-Vector Databases כמו Pinecone, ויכולת מוכחת עם MLOPS. אלו לא דרישות פול סטאק קלאסי וגם לא של Data Scientist קלאסי. השוק זועק לטייטל הזה, והעובדה שחברות מוכנות לשלם פרמיות גבוהות על הטייטל הזה מוכיחה שזה לא ״קישוט לקורות חיים״, אלא צורך עסקי בוער (ויקר) של ארגונים שטובעים בים של טוקנים, עלויות ענן מטורפות ותוצאות לא מדויקות. אפשר להתווכח עם הפילוסופיה, אי אפשר להתווכח עם השוק.
מקורות:
דו״ח התעסוקה של לינקדאין שמדרג את הטייטל הזה במקום הראשון
נתונים מ-Glassdoor ב-2025 מראים שהשכר הממוצע ל-AI Engineer בארה"ב הוא גבוה וכמובן שהמשרה קיימת.
הדבר הכי חשוב: ההבדלה בין המשתמש לבין הבונה
בדיון בלינקדין, היו כמה שלא הצליחו להבין: להשתמש ב-Copilot, לכתוב קוד בעזרת Cursor, להיעזר ב-ChatGPT לדיבוג או לכתוב סקריפט ב-Claude – זה לא אומר שאתם AI Engineers. זה אומר שאתם מפתחים יעילים שמשתמשים בכלי העבודה של 2026. וזה מצוין, מעולה וחשוב מאד. מי שלא שם, נשאר מאחור. אבל יש הבדל מהותי מאד בין מי שעושה שימוש בכלי LLM לפיתוח לבין מי שמשתמש ב-ML או ב-LLM במוצרים שלו. מי שעושה את זה הוא AI Engineer זה משהו אחר לגמרי.
ההגדרה שלי, שמתגבשת תוך כדי תנועה בשטח, היא כזו: AI Engineer הוא האדם שלוקח מודל שפה (LLM), מודל ML כלשהו, או שילוב בינהם כמו מולטי מודל. בין אם זה מודל מדף סגור או מודל Open Source או אפילו מודל שה-Data Scientist שלו יצר לו (ודיברנו על יצירת מודלים גם בבלוג הזה) הופך אותו מ"דמו מגניב במחשב שלי" למוצר שעובד בפרודקשן. מה זה פרודקשן? פוגש לקוחות אמיתיים, עובד בסביבה אמיתית ואוכל באגים אמיתיים.
וכל מי שנמצא שם יודע: התהום הפעורה בין "דמו מדהים" לבין "מוצר שעובד אצל הלקוח ומקבלים עליו כסף" היא עצומה.
זה לא סתם עוד API: הנדסה בעולם לא-דטרמיניסטי
אחת התגובות המעניינות שקיבלתי בלינקדאין (תודה לרועי מיארה) טענה ובצדק מסוים: "המציאות היא שכל מה שתיארת נופל תחת ההגדרה של Software Engineer… התפקיד אולי הכי קרוב בעולם הישן הוא Applied ML".
אז כן, זה נכון לומר שהבעיות האלו היו גם בעבר עם הטמעה של ML במערכות נוכחיות. יצא לי להכניס מודל שפותח לזיהוי תמונות לתהליך אצלנו. זה אותן בעיות כמו ה-LLM אבל, וזה אבל גדול, פעם מדובר היה באמת במשהו נישתי וקטן. היום, בגלל מהפיכת ה-LLM, יש דרישה עצומה להטמעת ML וגם LLM כמובן במוצרים קיימים ומוצרים חדשים. עם היכולות היום של המודלים החדשים, נפתחות אפשרויות למוצרים חדשים שלפני 5 שנים נראו כמו מדע בדיוני. כמו למשל ניתוח לוגים וטקסטים בווליום פסיכי, ניתוח תמונות וטקסטים מתמונות, אינטראקציה קולית, You name it. אז אולי AI Engineer תמיד היה, אבל בהיקף מצומצם יחסית.
גם יש כאלו שטענו שמדובר בתכנות קלאסי. אבל רגע, בסוף, הכל זה קוד. הרי אם מפשטים את זה, אני מקבל כסף על להזיז ביטים ממקום למקום. אבל הטענה שלי היא שהשוני במהות הבעיות מצדיק את ההתמחות החדשה. הנדסת תוכנה קלאסית היא דטרמיניסטית: פונקציה מקבלת X ומחזירה Y. אם היא לא עושה את זה, זה באג. ברגע שמכניסים חלק לא דטרמיניסטי זה כאבים אחרים. כן, ההתמודדות היא עם כלים ומכניקות של הנדסה ותכנות כפי שאנחנו מכירים אותם. זה לא שאני עושה קסמים, אבל צריך להכיר את הכלים והמכניקות האלו ולא באופן תיאורטי.
אני אדגים עם כמה אתגרים שבאופן אישי התמודדתי איתם במוצרים שאני פיתחתי ומשתמשים ב-LLM או ML:
הדיוק וההזיות
במוצר שאנחנו בונים, המבוסס על מולטי-מודל שמנתח נתונים, המאבק על הדיוק הוא סיזיפי. מודל יכול להיות גאון רגע אחד, ולהזות שטויות בביטחון מלא רגע אחרי. זה לא נפתר רק בשינוי הטמפרטורה או בדיקת הקלט (אם מישהו רוצה, שיבדוק את המאמר של רועי בן יוסף שעבד איתי כתף אל כתף במוצר מסוים ושנינו התפקענו מצחוק מההזיות של המולטי מודל שהזה קרב איגרוף מפואר אבל בפועל קיבל פיקסל שחור בגלל תקלה) . יש כמה וכמה טכניקות להתמודד עם דיוק, כאלו שבדוקות יותר ופחות. מי שמכיר ועבד יוכל לפרט על כלים או טכניקות. הכי בסיסי למשל זה Structured Output, אבל יש כמובן עוד שפע.
2. המערב הפרוע של האבטחה
זו חזית חדשה ומפחידה. זה לא רק לוודא שהדאטה לא דולף החוצה. זה לוודא שהיוזר לא עושה מניפולציה על המודל (Prompt Injection) וגורם לו לפעול נגד הארגון. כשאתה מחבר LLM למערכות פנימיות – הוא הופך לוקטור תקיפה. הנדסת האבטחה כאן היא שונה בתכלית מאבטחת Web קלאסית. כתבתי המון גם בבלוג על החזית הפסיכוטית הזו. רלוונטי גם ל-LLMים אבל גם ל-ML קלאסיים!
ההרצאה שלי על מבוא לאבטחת מידע בעולם הכאוטי של LLM:
ההרצאה שלי על העולם המופלא של התקפות על ML
3. "הצנרת" (או MLOPS)
איך מנהלים Scale כשכל קריאה למודל לוקחת מאות מילי-שניות במקרה הטוב? איך מנהלים עלויות כדי שהטוקנים לא יחסלו את התקציב (ואת הבונוס השנתי)? איך עושים אורקסטרציה בין כמה מודלים שצריכים "לדבר" אחד עם השני? זה תחום שלם, אני למשל לא מבין בו המון אבל הצוות שיושב לידי מטפל בו. מי שרוצה לקרוא על חלק האתגרים יכול לקרוא את המאמר של אלי שמש על MLOPS בסביבת AWS.
4. הגיהנום של הבדיקות (Evals)
כמו שכתב יפה יראל ממן בתגובה לפוסט שלי: "רק התחום של להנדס Evals בצורה איכותית זה כבר Full time job". איך בודקים תוכנה שהתשובה שלה משתנה? איך יודעים ששינוי בפרומפט שיפר את הביצועים ב-API אחד אבל הרס אותם במקרה קצה אחר? בניית מערכות בדיקה ל-LLM זו דיסציפלינה חדשה לגמרי. אני למשל משתמש בפריימוורק שצמוד למוצר שלי, אבל משתמש גם בבנצ׳מארקים הספציפיים.
ההבדל בין Data Scientist ל-AI Engineer
בגדול איך שאני רואה וחווה את זה אצלנו, יש הבדל משמעותי. הדאטה סיינטיסט חי יותר בעולמות של סטטיסטיקה, מתמטיקה ומחקר. המטרה שלו היא לייצר ולטייב מידע, לייצר מודל אופטימלי, לאמן אותו, לנקות דאטה ולשפר מדדי דיוק. התוצר שלו הוא בדרך כלל מודל.
AI Engineer הוא קודם כל מהנדס תוכנה. הוא לוקח את המודל (שמישהו אחר אימן, או מודל מדף כמו GPT/Claude) ובונה סביבו מוצר. הוא לא מתעסק למשל בבניית הארכיטקטורה של הרשת העצבית, אלא באספקטים יותר הנדסיים: למשל הורדת העלות באמצעות caching, הצבת הגדרות של הגארדריילס, הדאגה ללוגים, בדיקת הביצועים והאיכות של האפליקציה.
אולי אפשר לומר שהדאטה סיינטיסט מתכנן את המנוע, ה-AI Engineer בונה את המכונית סביבו.
אז האם זה רק טרנד או באזז וורד?
יש שיגידו שזה Applied ML, יש שיגידו שזה Backend++. אבל ההיסטוריה מלמדת שכשהטכנולוגיה מעמיקה, ההתמחות מתחדדת.
ב-2010 אמרו על דבאופס שזה "סתם סיסאדמין עם יחסי ציבור".
לפני זה אמרו על פרונט אנד ש"מתכנת אמיתי כותב הכל מקצה לקצה".
היום ברור לכולם שאלו מקצועות נפרדים עם עומק משלהם.
המעבר ל-AI Engineer הוא דומה. הוא דורש הבנה עמוקה בארכיטקטורות של מודלים, בניהול Context Window, ב-Vector Databases ובסטטיסטיקה (כן, אי אפשר לברוח מזה לגמרי), לצד יכולות פיתוח חזקות שאמורות להיות קיימות אצל מהנדסים מנוסים. הבעיות האלו הרי נפתרות עם קוד וקוד קשוח. זה לא איזה משהו שנפתר עם קרניים קוסמיות או תפילות (אפילו שאני לפחות מתפלל המון כשהפייפליין שלי רץ בג׳נקינס).
איך נכנסים לזה? (מלכוד הביצה והתרנגולת)
הבעיה הגדולה היא איך צוברים ניסיון אם מקום העבודה הנוכחי שלכם לא נותן לכם לגעת בזה. ניר טייב כתב בתגובות משהו חכם: "דווקא זה שאין גב כלכלי של חברה יכול לעזור להתמודד עם הבעיה המהותית של עלויות ולמצוא פתרונות יצירתיים".
הוא צודק. אין כרגע קורס באוניברסיטה שיהפוך אתכם ל-AI Engineers. הדרך היחידה היא לבנות. לקחת מודלים קטנים וזולים, לנסות להרים פרויקט צד, להתמודד עם הבעיות של הדיוק והעלויות בעצמכם.
וכדי לסכם את החפירה
מי יודע מה יהיה בעולם החדש הזה של LLM שנמצא בכל מקום? תחום התכנות משתנה, אבל מן הסתם מתכנתים נשארים. מישהו צריך לבצע את האורקסטרציה של האייג׳נטים (ואם זה נשמע לכם כמו מדע בדיוני, כדאי להתחיל בפוסט שלי פה) ולוודא את הקוד גם בבעיות יותר סטנדרטיות. אבל פתאום נפתח תחום חדש – להתמודד עם האתגרים של הכנסת ML\LLM למוצרים בסקייל משוגע. אנחנו מבינים ש-LLM וגם ML הוא לא קסם, אלא רכיב הנדסי מורכב, כאוטי ויקר, שדורש אנשי מקצוע שיודעים לאלף אותו. אם אתם פותרים את הבעיות האלו והתנסיתם בזה בפועל אתם AI Engineers. ואם אתם עדיין סקפטיים לגבי הטייטל? זה בסדר גמור. אולי עוד זמן מסוים גם זה ישתנה. מי יודע מה יהיה בעתיד?
