לא הכל צריך AI: מתי עדיף להישאר עם "סתם" אוטומציה או קוד רגיל (Rule-Based)
מאת: אילון אוריאל, ארכיטקט פתרונות AI ומייסד NeuralBridge Solutions
התקציר למנהלים (Executive Summary)
אני מתפרנס מהטמעת בינה מלאכותית. זה המקצוע שלי, התשוקה שלי, והסיבה שאני קם בבוקר. ובכל זאת, ב-50% מהפגישות שלי עם לקוחות, העצה הראשונה שלי היא: "אל תשתמשו ב-AI לזה".
אנחנו נמצאים בשיא ההייפ. מנכ"לים ומנהלי מוצר רוצים "לדחוף" AI לכל פינה במוצר, מתוך פחד לפספס את הרכבת. התוצאה? מערכות איטיות, יקרות, לא אמינות וקשות לתחזוקה. האמת הכואבת היא ש-GenAI (בינה מלאכותית יוצרת) הוא פטיש מדהים, אבל לא כל בעיה היא מסמר.
ההחלטה מתי להשתמש ב-AI ומתי להישאר עם קוד דטרמיניסטי "משעמם" (Rule-Based) היא ההחלטה הארכיטקטונית החשובה ביותר שתקבלו השנה. במאמר הזה נפרק את ההבדל היסודי בין מערכות הסתברותיות (AI) למערכות דטרמיניסטיות (קוד), נבין למה "סתם אוטומציה" היא לעיתים קרובות מהירה פי 100 וזולה פי 1,000, ונלמד איך לבנות מערכות היברידיות שלוקחות את הטוב משני העולמות.
ההבדל היסודי: דטרמיניסטי מול הסתברותי
כדי להבין מתי לא להשתמש ב-AI, צריך להבין מהו בעצם מודל שפה (LLM). למרות שהם נראים אינטליגנטיים, מודלים כמו GPT-4 או Claude הם בסופו של דבר מנועים סטטיסטיים לחיזוי המילה הבאה. הם פועלים בעולם הסתברותי.
מה זה אומר? זה אומר שאם תשאלו מודל את אותה שאלה פעמיים, ייתכן שתקבלו שתי תשובות שונות (אלא אם קיבעתם את ה-Temperature ל-0, וגם אז יש ניואנסים). זה מצוין ליצירתיות, לכתיבת שירים, או לסיכום טקסטים מעורפלים.
לעומת זאת, קוד רגיל (Python, Java, SQL) פועל בעולם דטרמיניסטי.
בקוד רגיל, הפקודה if x > 5 תמיד תיתן את אותה תוצאה, ב-100% מהמקרים, במיליונית השנייה, ובעלות אפסית.
הכלל הראשון של הארכיטקטורה:
לעולם אל תשתמשו במנוע הסתברותי כדי לפתור בעיה דטרמיניסטית. זה כמו לנסות לחתוך לחם עם מסור חשמלי תעשייתי. זה יעבוד, אבל זה יקר, רועש, מסוכן, והתוצאה תהיה פחות מדויקת מאשר עם סכין פשוטה.
למה קוד רגיל מנצח את ה-AI (כשזה מתאים)
ישנם ארבעה פרמטרים שבהם קוד מסורתי מביס את ה-AI בנוקאאוט: עלות, מהירות, אמינות ודיבאגינג.
- עלות (Cost & Tokenomics)
קריאה ל-API של OpenAI או אנתרופיק עולה כסף עבור כל טוקן (קלט ופלט). זה נשמע מעט (סנטים בודדים), אבל כשמכפילים את זה במיליון משתמשים או באלפי תהליכים ביום, החשבונית מתנפחת.
לעומת זאת, הרצת סקריפט Python של 50 שורות על שרת AWS זול (או אפילו ב-Lambda Function) עולה שברירי שברירים של סנט. הפער בעלויות יכול להגיע לפי 1,000 או יותר. אם הלוגיקה פשוטה, ה-AI הוא פשוט שריפת כסף.
- מהירות (Latency)
מודלים של שפה הם איטיים. כדי לייצר תשובה, המודל צריך לבצע חישובים מתמטיים עצומים (Matrix Multiplications) עבור כל מילה ומילה. זמן תגובה ממוצע יכול לנוע בין חצי שנייה לכמה שניות.
בעולם ה-Real Time, שניות הן נצח. ביטוי רגולרי (Regex) שבודק אם כתובת מייל היא תקינה רץ בננו-שניות. לחכות ש-GPT יגיד לכם אם המייל תקין זה בזבוז זמן משווע של המשתמש.
- אמינות וחיזוי (Predictability)
במערכות בנקאיות, רפואיות או תעשייתיות, 99% הצלחה זה כישלון. אם אתם בונים מערכת שמחשבת ריבית על משכנתא, אתם לא יכולים להרשות לעצמכם שפעם אחת ב-100 מקרים המודל "יזייף" מספר. קוד רגיל לא הוזה. קוד רגיל עושה בדיוק מה שאמרו לו.
- יכולת ניטור ותיקון (Debuggability)
כשקוד רגיל נכשל, הוא זורק שגיאה (Exception) עם מספר שורה וסיבה מדויקת ("Division by zero").
כש-AI נכשל, הוא פשוט נותן תשובה לא נכונה בביטחון מלא. לכו תבינו למה הרשת הנוירונית החליטה ש-2+2=5 בהקשר מסוים. לתקן ("לדבג") פרומפטים זה תהליך מתסכל, ארוך ולא מובטח, לעומת תיקון באג בקוד.
רשימת ה"אל תעשה": מתי אסור להשתמש ב-AI
מתוך הניסיון שלי בליווי עשרות חברות, הנה המקרים הקלאסיים שבהם אני רואה שימוש לרעה ב-AI, והאלטרנטיבה הנכונה:
חישובים מתמטיים
מודלי שפה הם גרועים במתמטיקה. הם לא "מחשבים", הם משלימים טקסט. הם ראו המון תרגילי חשבון באימון, אז הם יודעים את התשובה לרוב התרגילים הפשוטים, אבל בתרגילים מורכבים הם נוטים לטעות.
הפתרון: תנו ל-AI לכתוב את הקוד שמבצע את החישוב, אבל אל תתנו לו לבצע את החישוב בעצמו.
אימות מבנה ופורמט (Validation)
לבדוק אם תאריך הוא בפורמט DD/MM/YYYY או אם מספר טלפון הוא ישראלי.
הפתרון: ספריות קוד סטנדרטיות (כמו Pydantic ב-Python) או Regex. זה מהיר, בחינם, ומדויק ב-100%.
שליפת מידע מדויקת מתוך בסיס נתונים (SQL)
למרות שמודלים יודעים לכתוב שאילתות SQL (Text-to-SQL), לתת להם גישה ישירה ויד חופשית למסד הנתונים זה מסוכן. הם עלולים לכתוב שאילתה לא יעילה שתפיל את ה-DB, או גרוע מכך – שאילתה שחושפת מידע רגיש בטעות.
הפתרון: השתמשו ב-AI כדי לנתח את כוונת המשתמש ("הראה לי את המכירות של אתמול"), ומפו את הכוונה לפונקציות קוד מוגדרות מראש ומוגנות.
תהליכי זרימת עבודה קשיחים (State Machines)
אם יש לכם תהליך עסקי ברור: שלב א' -> אם כן, עבור ל-ב', אם לא, עבור ל-ג'.
הפתרון: כתבו את הלוגיקה הזו בקוד (Hard-Coded). השתמשו ב-AI רק בתוך השלבים עצמם, אם צריך ניתוח טקסט, אבל אל תתנו ל-AI לנהל את הלוגיקה של המעברים (Routing) אם היא ידועה מראש.
נקודה למחשבה: פרדוקס ה-RPA
לפני עשור, העולם התלהב מ-RPA (Robotic Process Automation) – בוטים "טיפשים" שמבצעים פעולות חזרתיות. היום כולם מזלזלים בזה ורוצים "AI Agents".
אבל האמת היא ש-RPA הוא פתרון מדהים לבעיות מוגדרות היטב. אם הבוט צריך כל בוקר להיכנס לאתר ממשלתי, להוריד קובץ Excel ולשמור אותו בתיקייה – סקריפט פשוט ב-Python עם Selenium יעשה את זה מושלם לנצח. סוכן AI שינסה "להביט" במסך ולהבין מה לעשות, יעלה פי 100 וייכשל בכל פעם שהאתר ישנה את הפונט או את הצבע של הכפתור.
המסקנה: אם המשימה היא מכנית וחוזרת על עצמה בדיוק רב – ותרו על האינטליגנציה.
המודל ההיברידי: העתיד שייך לשילובים
אז האם אני אומר לזרוק את ה-AI לפח? חלילה. הארכיטקטורה המנצחת היא שילוב: AI בתור "המוח" וקוד בתור "הידיים".
זה נקרא Tool Use (או Function Calling).
במודל הזה, ה-AI מנהל את השיחה עם המשתמש ומבין מה הוא רוצה. אבל כשהוא צריך לבצע פעולה דטרמיניסטית (לחשב, לשלוף דאטה, לפרמט), הוא לא עושה את זה בעצמו. הוא קורא לפונקציית קוד שכתבתם מראש.
דוגמה מהשטח: בוט לשירות לקוחות בבנק
הגישה השגויה (Pure AI):
המשתמש שואל: "כמה יתרה יש לי ומה הריבית על המינוס?"
המודל מנסה "לנחש" או לחפש בטקסטים כלליים, ומייצר תשובה שנשמעת אמינה אבל אולי שגויה מספרית. אסון.
הגישה הנכונה (Hybrid):
- המשתמש שואל את השאלה.
- מודל ה-AI מנתח את השאלה ומבין: "המשתמש רוצה לדעת יתרה (Action A) וריבית (Action B)".
- המודל מוציא פקודה (JSON) למערכת: "הפעל פונקציה get_balance(user_id) והפעל פונקציה get_interest_rate(user_type)".
- קוד רגיל רץ, מתחבר ל-Mainframe של הבנק, שולף את המספרים המדויקים ומחזיר אותם למודל.
- המודל מקבל את המספרים ("יתרה: 5000, ריבית: 8%") ומשתמש בהם כדי לנסח תשובה יפה ואנושית למשתמש.
בשיטה הזו, קיבלנו את הגמישות של ה-AI בהבנת שפה טבעית, יחד עם הדיוק והאמינות של קוד מסורתי.
"הנדסת יתר" (Over-Engineering): המחלה של 2026
כמהנדסי תוכנה, יש לנו נטייה להשתמש בכלים הכי חדשים ומגניבים. זה נקרא Resume Driven Development (פיתוח מונחה קורות חיים). אבל בתור מנהלים או יזמים, האחריות שלנו היא למוצר ולעסק.
שימוש ב-AI במקום שבו סקריפט פשוט היה מספיק הוא סוג של חוב טכני (Technical Debt) שאתם מכניסים למערכת ביום הראשון. אתם מכניסים תלות בצד שלישי (OpenAI/Google), אתם מכניסים אי-ודאות, ואתם מכניסים עלויות משתנות.
מבחן ה"למה לא":
לפני כל פיצ'ר חדש, שאלו את הצוות שלכם: "למה לא לכתוב את זה ב-If/Else?".
התשובה צריכה להיות משכנעת. למשל: "כי יש אינסוף וריאציות של קלט שהמשתמש יכול לכתוב, ואי אפשר לכסות את כולן ב-If/Else". זו סיבה מצוינת ל-AI.
אבל אם התשובה היא: "כי זה יותר קל מלכתוב את הלוגיקה", או "כי זה מגניב" – תעצרו מיד. קוד הוא נכס. AI הוא הוצאה שוטפת.
שאלות ותשובות נפוצות בנושא AI vs Code
שאלה: האם לא כדאי להשתמש ב-AI כדי לחסוך זמן פיתוח, גם אם זה פחות יעיל?
תשובה: בטווח הקצר, אולי. בטווח הארוך, זה בומרנג. קוד שנכתב על ידי AI (או לוגיקה שמוחלפת על ידי קריאת API) הוא קל ליישום, אבל קשה מאוד לתחזוקה כשדברים משתבשים. אם הלוגיקה היא ליבת העסק שלכם, עדיף להשקיע את הזמן ולכתוב אותה כמו שצריך. השתמשו ב-AI (כמו GitHub Copilot) כדי לכתוב את הקוד, אבל אל תהפכו את ה-AI למריץ של הקוד בזמן אמת.
שאלה: מתי נכון להחליף מערכת Rule-Based קיימת ב-AI?
תשובה: כאשר המערכת הקיימת הגיעה ל"תקרת זכוכית" של ביצועים ושום אופטימיזציה נוספת לא עוזרת. למשל, במערכות לזיהוי הונאות (Fraud Detection), מערכות מבוססות חוקים תופסות את המקרים הברורים, אבל מפספסות דפוסים מתוחכמים וחדשים. במקרה כזה, הוספת שכבת AI מעל החוקים הקיימים היא מהלך נכון.
שאלה: מה לגבי חווית משתמש? AI הוא לא תמיד יותר טוב?
תשובה: לא בהכרח. לפעמים כפתור פשוט הוא ממשק משתמש (UI) הרבה יותר טוב מצ'אט. אם אני רוצה להזמין פיצה, ללחוץ על "מרגריטה" ו-"הזמן" לוקח 5 שניות. לנהל שיחה עם בוט על התוספות יכול לקחת 2 דקות. אל תכריחו את המשתמשים "לדבר" אם פעולה פשוטה פותרת את הבעיה מהר יותר.
סיכום: היו פרגמטיים, לא פנאטיים
הטכנולוגיה נועדה לשרת את העסק, ולא להיפך. בתור ארכיטקטים ומנהלים, התפקיד שלנו הוא לבחור את הכלי הנכון למשימה. לפעמים הכלי הזה הוא רשת נוירונים עם 175 מיליארד פרמטרים, ולפעמים הכלי הזה הוא משפט if פשוט וטוב.
אל תתביישו להיות אלו שאומרים בחדר הישיבות: "חברים, אפשר לעשות את זה עם סקריפט של 20 שורות, בחינם, וזה יעבוד יותר מהר". זה לא הופך אתכם לטכנופובים. זה הופך אתכם למקצוענים שמבינים שלפעמים, הפתרון הכי פשוט הוא גם הפתרון הכי חכם.
בעולם של 2026, החוכמה היא לא לדעת איך להשתמש ב-AI, אלא לדעת מתי לעצור ולהגיד: "כאן עובר הגבול. מכאן והלאה – קוד".