קל מאוד להכריז על מהפיכות בעולם, אבל בעת הזו אני מניח שיהיה לי קל לשכנע ש Agentic IDEs הם מהפכה של ממש בעולם התוכנה.
כשהגיע GitHub Co-Pilot (לפני ה coding agent) הייתה התרגשות כללית, אבל דיי מהר הבנו שזה עדיין ״לא זה״. אני ועוד רבים מעמיתי פשוט כיבינו אותו – שיפסיק ״להרעיש״.

בכמה השבועות האחרונות יצא לי ולעוד עמיתים ב NEXT לעבוד עם Cursor ו WindSurf – ומהר מאוד הבנתי שמדובר במשהו אחר, עליית מדרגה משמעותית מעל ל GitHub Co-Pilot:

• הוא יכול לערוך מספר קבצים במקביל.
• הוא מסוגל לעשות שינויים רוחביים, ולא רק Generation לפיסת קוד. למשל:
  • תיקון באג או בילד שנכשל – כשהבעיה נגרמת בכמה קבצים שונים בקוד.
  • הוא מסוגל לחפש ב code base, ולעזור להתמצא בו ולהסיק ממנו תובנות.
• הוא מסוגל לבצע פעולות ב command line ובעצם להפעיל קומפיילר, להתקין חבילות, להזיז קבצים בפרויקט וכו׳.
• והוא רק בחיתולים…

אני עובד בעיקר עם Cursor אבל יש מגוון כלים שמתרוצצים כרגע, שמציגים יכולות שלא ראינו בשנה שעברה: Loveable, CLline, V0, Base44, Claude Code, Jules – ועד שתקראו את הפוסט בוודאי יהיו עוד כמה משמעותיים.

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

חשבו איך שינו את עולם פיתוח-התוכנה האינטרנט (רפרנסים אונליין, StackOverflow), מהפכת האג׳ייל, או מהפכת הבדיקות / TDD. זה סדר הגודל המדובר (לפחות), רק שנראה שזה מתקדם מאוד מהר.

איך זה ייגמר?

שאלה מעניינת, וכמובן שאיני יודע.

• האם ארגונים יסגרו את ארגון הפיתוח, ואנשי מוצר יעבדו ישירות מול LLM בעוד המפתחים עומדים בתור לנסות ולקבל משרה במקדונלדס? – פחות סביר.
• האם תוכנות בעולם יתקדמו בקצב מסחרר ונראה פיצ׳רים חדשים משוחררים כל יום? סטארטאפים שמשיקים מוצר עם מפתח בודד? – כנראה שזה הכיוון, אבל בהגזמה גדולה.
• מפתחים יוכלו לעשות עבודה פי 10 יותר מהירה מהיום? – גם לא נראה לי.

אבל מספיק שמפתח יוכל לעשות עבודה 10% יותר מהר בממוצע מהיום – וזו כבר מהפיכה.

שפות תכנות או Frameworks חדשים, לא מצליחים לייצר כזו התקדמות בפריון. רק קפיצות המדרגה הגדולות יותר, כמו אג׳ייל או Testing – הצליחו להביא לכזו תוצאה, וזה היה תהליך של שנים עד שהוטמעו בהצלחה.

נזכיר, שכתיבת קוד היא כ 20% מהזמן של מפתחים בארגוני תוכנה בוגרים. דזיין, תקשורת, עבודה עם פרודקט – תופסים את רוב הזמן. שיפור של פי 2 בקצב כתיבת קוד = תוספת פריון ממוצע של 10% למהנדסי תוכנה, וכרגע זה לא נראה דמיוני.

בעוד ש Agentic IDEs מאיצים בצורה ניכרת את זמן כתיבת הקוד / troubleshooting, אין סיבה שכלי LLM אחרים לא יצליחו לעזור גם בשלבי הפיתוח האחרים, כמו תקשורת או עבודה עם פרודקט. אני משתמש תדיר ב ChatGPT (ולאחרונה Gemini) על משימות שוטפות – ואין סיבה שלא נראה גם כאן קפיצות מדרגה בשלב מסוים.

איך זה מתחיל?

מתקינים Agentic IDE טוב (בעת כתיבת הפוסט: Cursor נראה כמו מוביל המגמה) – ומתחילים לעבוד איתו.

להתרגל ל IDE חדש: לוקח יומיים.
לאשר לעבוד עם כלי חדש בארגון: בין שעה לחודשיים – תלוי בארגון 😅.
ההתחלה יכולה להיות דיי מהירה.

ללמוד לעבוד עם הכלי בצורה יעילה – לוקח קצת יותר זמן. הנה שלבי הלמידה כפי שאני צופה בהם:

שלב #1: להאמין ב Agent

יותר מדי פעמים, ראיתי אנשים שעובדים עם ה Agent ב Agentic IDE ונותנים לו פירורי עבודה: ״שנה את שם המשתנה״. ״הוסף פרמטר לפונקציה״. סוג של פקודת refactoring בטקסט חופשי.
זה עובד וזה נחמד, אבל כאן לא הפוטנציאל.
העזו ואתגרו את הסוכן (Agent) בדברים שלא נראה לכם שהוא יכול לעשות. ברוב הפעמים – הוא יפתיע אתכם לטובה. עד שלא תאמינו ב agent – לא תצליחו להפיק ממנו משהו שדומה לפוטנציאל.

• בסשן הראשון שלי עם הסוכן ביקשתי ממנו לעשות Refactoring ל class ולחלץ תת מחלקה החוצה.
• אח״כ ביקשתי שיקמפל את הפרויקט. הוא טעה – אבל עם טיפה הדרכה – הצליח.
• ביקשתי שיריץ בדיקות. הייתה בדיקה שנכשלה. ביקשתי שיתקן – והוא הצליח.
• אמרתי לו שיעשה commit לקוד, ויכתוב commit message מתאים – הצליח.
• העזתי, וביקשת שיפתח Pull Request בגיטאהב, וישים reviewer מסוים. הוא הסביר שהוא צריך להתקין כלי בשם GH כדי להפעיל את GitHub. התקין – ואז הצליח לפתוח PR. לא הצליח לשים reviewer.
• תיקנתי אותו בשם המשתמש של ה reviewer – והוא הצליח לשים (assign) אותו כראוי.
• אמרתי לו שיכתוב הודעה בסלאק ל reviewer שכבר יגיב ל PR!
  הוא ענה לי שאין לו גישה ל Slack – אבל כתב עבורי הודעה שאעשה לה paste.

שלב #2: לא לסמוך על ה Agent

ה Agnet (סוכן) רץ מהר ועושה שינויי קוד יפים והגיוניים. פה ושם הוא עושה שטויות, כאילו בכוונת מחבר, כדי לשמור עלינו engaged בקוד שנכתב. לפעמים אלו טעויות טיפשיות (חסר import), לפעמים כשלים לוגים גדולים (הוסיף שורת logout במקום שלא ציפיתי, ולא שמתי לב שהוסיף. התגלה רק בביקורת קוד עם מפתח אחר).

מקום שנפלתי בו, וראיתי אחרים נופלים בו בצורה דומה היא כתיבת בדיקות. עבדתי על מחלקה ללא בדיקות, ולכן הוריתי לסוכן לכתוב לה בדיקות. תוך חצי דקה היו 10-12 test cases כתובים למהדרין. עברתי על שניים-שלושה, נראו הגיוניים וכתובים יפה.

״נו, מה יכול להשתבש בבדיקות?! מקסימום הקפיד יותר מדי״ – אמרתי לעצמי. הכנסתי את הקוד רק בכדי לגלות אח״כ ש:

• הסוכן כתב שתי בדיקות לא נכונות עסקית, שעברו כרגע – אבל נפלו בשלב הבא של פיתוח הקוד, ועיכבו אותי זמן מה כי ״הבדיקה נופלת => משהו לא בסדר בקוד״.
• הסוכן כתב כמה בדיקות שהן overfit מוגזם למצב הקיים. לא בדיקות טובות.
  • גיליתי את זה כאשר הוריתי לו לתקן את הבדיקות שנפלו והוא הלך ושינה את הקוד המבצעי – כדי להעביר את הבדיקה. Big No-No!
  • הסבר: הבדיקה הייתה כתובה כל-כך Overfitted שנראה לרגע הגיוני לשנות את הקוד – ולא את הבדיקה.

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

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

מכאן הכלל המומלץ לארגונים הוא: ״!You pushed it – you own it״. לא מומלץ לקבל שיח מסוג ״האא.. זה באג של הסוכן שלא שמתי לב אליו״ בתור הנחה מקלה. הניחו שהסוכן מייצר קצב קבוע פחות או יותר של באגים.

שלב 3א – להפנים ש ״context is king״

מיומנות חשובה המשפיעה על ביצועי הסוכן היא קביעת הקשר (context) נכון.

• להבין איך ה IDE שאתם עובדים איתו קובע את ה Context (התיעוד הזה חסר, השלמנו מפורומים ובניסוי /תעיה הבנה טובה יותר איך בדיוק הוא עובד)
• להבין אילו קבצים חשוב להוסיף לו כדי שתהיה לסוכן תמונה מספיק שלמה על המשימה.
• להבין איזה טקסט מינימלי / הנחיות חשוב להוסיף מעבר לקוד – כדי שיצליח במשימה. זכרו שהקוד לא מתאר כוונה לשינוי – אלא רק מצב קיים.
  • טריק: לפני עבודה עם הסוכן הוסיפו הערות בקוד מה בכוונתכם לשנות והיכן. Cursor מגיב להערות הללו היטב.
• להבין שככל שה context גדול יותר – המיקוד על כל אלמנט ב context הוא קטן יותר. זה לא עוזר להעמיס מודל ב 2 מליון טוקנים – אם בסוף הוא יעשה עבודה פחות טובה.

שלב 3ב: להפנים שמודלים הם שונים

ב Cursor IDE, כברירת מחדל בחירת מודל ה LLM שעובדים איתו היא אוטומטית, ואין נראות לאיזה מודל נבחר. זה לא טוב.

• לא פעם, מודלים פשוטים יותר, לא מצליחים טוב במשימות. למשל, GPT-4.1 (ש Windsurf אוהב לבחור) פשוט לא טוב במשימות רוחביות. הוא טוב בעיקר לשינויים נקודתיים.
  ההבדל בין sonnet-3.5 ל sonnet-3.7 הוא משמעותי. קצת יותר ממה ש״פער של 0.2״ נשמע…
• יש מודלים יותר ״מִתְחַכְּמִים״, כמו o3 או sonnet-3.7 שיותר סביר ש״יגדילו ראש״ במקומות שלא ציפיתם להם. אני מאוד אוהב את sonnet-3.7 והוספתי לו rule ממוקד בכדי ״לרסן״ אותו.

- When responding to user queries, strictly follow the instructions provided without making unsolicited improvements to code structure or functionality. Only implement changes or suggestions explicitly requested by the user.

• Gemini-2.5-pro עושה פחות שטויות, אבל הוא קשקשן (verbose) ואם אתם עובדים איתו אתם הולכים לקרוא הרבה טקסט שהוא כותב…
• צורת האינטראקציה עם כל מודל שונה ב IDE. חלק יותר יוזמים פעולה, חלק בעיקר ממליצים. Cursor IDE מציג UI elements שונים כתגובה למודלים שונים (למשל: כפתורים עם אפשרויות – כיצד להנחות את המודל לגבי הצעד הבא)
• צצים מדריכים כיצד לבחור מודלים. הנה המאמר של Cursor על בחירת מודלים. התחברתי יותר לכוונה, ופחות לתוצאה. אני מניח שקשה להעביר את המיומנות / חוויה של עבודה עם מודלים שונים.
• אם אתם עובדים עם כמה IDEs שונים, חשוב לציין שכל IDE מוסיף system prompts ייחודים שלו למודל ה LLM. המשמעות היא ש Sonnet-3.7 על Windsurf מתנהג שונה מ Sonnet-3.7 על Cursor.
• יש עניין של עלויות שימוש במודלים שונים. כשאתם מדברים / מפעילים את הסוכן, יורד לכם credit או שאתם משלמים ל LLM API בהתאם. מתישהו תגלו שיצא יקר או שחסמו לכם קריאות מהירות למודל. הגישה שלי היא לבחור בשני מודלים שנוח לי איתם: אחד ״יקר״ (נניח sonnet-4.0-thinking) ואחד זול או חינמי (נניח gemini-2.5-flash) ולעבור בין שניהם: למשימות פשוטות להפעיל את המודל הזול, ולמשימות מורכבות להשתמש במודל היקר.

שלב 3ג: ללמוד מתי לא להשתמש ב Agent

כשמתחילים לעבוד עם Agentic IDE מומלץ מאוד לעשות הכל בעזרת ה Agent chat (ראה שלב #1): פעולות rename, לעשות commit, להריץ בדיקות – הכל. להתרגל שה IDE הפך להיות ממשק דומה ל Google Search שבו יש תיבת קלט אחת: chat עם הסוכן.

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

• Refactoring ב IDE – אמין יותר מהתוצאה של סוכן, שלפעמים מפספס מופעים.
• פעולות גיט – נוח לי להקליד פקודת gcam (קרי: git commit+message) לטרמינל מאשר לכתוב לסוכן ״commit the changes and write a proper commit message״. היו פעמים שהסוכן בחר לעשות commit והודעה לכל קובץ פתוח בנפרד – ממש מרגיז. לא פעם הייתי צריך לדייק אותו על ההודעה.
• קומפילציה / הרצת בדיקות – פחות לחיצות על המקלדת דרך ה IDE, אם הסוכן יכול לגשת אח״כ בקלות לתוצאות (תלוי ב IDE).
• נ.ב. Cursor הוא fork של VSCode ולכן התמיכה שלו בקוטלין / ג׳אווה דיי עלובה
  (בצד ה IDE). אני עובד כרגע side by side עם Cursor לעבודה עם הסוכן, ו IntelliJ כדי לבדוק מה הוא עשה. זו לא תצורה נוחה – אבל היא עדיפה על כמה אלטרנטיבות אחרות.

שלב #4 – ללמוד לדבר אל הסוכן בשפתו

זה שלב טריקי, שלוקח משמעותית יותר זמן מהשלבים הקודמים.

יש בבירור אנשים שמצליחים להוציא מהסוכן יותר מאנשים אחרים: יותר מהר, פשוט, פחות תקלות. לא מצאתי שום תיעוד לדבר הזה, אבל עשיתי לא מעט pair programming עם אנשים שונים+סוכן – וראיתי שזה עובד אחרת.

ראיתי בגדול שתי גישות שעובדות טוב:

• להסביר במדויק, מה שנקרא Technical communication טוב, להשתמש במונחים הנכונים, בסדר הנכון, להסביר תמונה רחבה ופרטים קטנים. זו מיומנות שיש לאנשים מסוימים יותר מאנשים אחרים.
  • הסברים לא מדויקים, במינוח לא טוב יגרמו לזה שתחשבו שהטכנולוגיה של Agentic IDE ״לא בשלה עדיין״
• לעבוד עם דוגמאות טובות, סוכנים הם מעתיקנים מצויינים. בהרבה מקרים, או כי הנושא סבוך וקשה להסבר, או כי הדובר פחות רהוט / מדויק – דווקא להשתמש בדוגמאות היא דרך פעולה מוצלחת. צרפו קבצים דומים / מימושים דומים ל context ובקשו מהסוכן לכתוב קוד כמו הקובץ או inspired by – והתוצאות יכולות להיות טובות מאוד, ממש תחליף להסבר תמציתי ומדויק.

בניתי לעצמי סדר תקשורת שעובד לי עם סוכנים:

1. Smalltalk – אם המשימה מורכבת (קשה לי להסביר, אני בעצמי לא בטוח מה אני רוצה, מנגנון עסקי מורכב) אני מתחיל בשיחה קלילה עם הסוכן:
   • ״מצא באיזה קובץ עושים X״
   • תאר לי את ה flow?
   • ״למה עושים א ולא ב״, או ״הסבר לי את הפונקציה״
   • חשוב להשתמש בשלב הזה לדייק את הסוכן מתי שהוא טועה. יש איזו דינמיקה שהתקשורת עם סוכן היא או ״משדרים על אותו גל״ או ״התדרדרות מהירה״. כשהסוכן בונה תמונת עולם שגויה ומתחיל להתחפר בה – קשה להוציא אותו מזה. אני מעדיף להתחיל context חדש ולהתחיל מאפס, מאשר לנסות ״לחלץ״ סוכן שנתקע. זה יותר יעיל.
   • אחת מההנאות שלי מה Agentic IDE הוא לשוחח עם הסוכן על קוד קיים. הוא סורק קוד מהר, ולא פעם מגלה תובנות מעניינות. בונוס ענק על פני כלים כמו GitHub Co-Pilot שלא התקרבו לזה.
2. עבודה הדרגתית בשלבים – כשהמשימה מורכבת, חשוב ללכת עם הסוכן צעד צעד. להנחות אותו. אתם ה supervisor והוא המתלמד. יש לכם מתלמד חרוץ מאוד וידען מאוד (הרבה פעמים – יותר מכם), אבל עם זיכרון של דג ליצן (הוא לא זוכר מה קרה היום בבוקר) ואפס היכרות עם הארגון ובסיס הקוד.
   • עם הזמן תפתחו יותר אינטואיציה מהו גודל הצעד הנכון: לא קטן מדי, ולא גדול מדי.
   • אם הסוכן מסתבך – נסו להחזיר אותו למסלול. Git Revert + new context/chat – היא לפעמים הדרך הקצרה להמשיך להתקדם.
3. הפעילו ביקורות – לא רק שלכם, אלא גם של כלים והסוכן עצמו
   • ״check yourself״ – prompt סתמי כזה לא פעם מצא לי באגים.
   • ״compile and test״ – רוב המודלים יתחילו לתקן ברגע שתתגלה שגיאה. חלקם לא.
   • ״simplify the code״ – המודל יכול לשפר מאוד את הקוד, אבל לא יעשה את זה – עד שלא תנחו אותו.
   • ביקורות מתוחכמות יותר כמו מודל ששינה SQL ושהתבקש ״וודא שמספר הרשומות והעמודות נשאר זהה לאחר השינוי״ ענה ב״אוי, סליחה! בעצם יהיו יותר פחות רשומות כי הוספתי <פילטר מטופש שלא ביקשת בכלל>״.

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

שלב #5 – לקבל סגנון אחר
כבר הזכרתי שלסוכנים / מדלי LLM יש זיכרון מוגבל? הקוד שהסוכנים עומדים לכתוב יהיה שונה מהסגנון שאתם כותבים בעצמכם.

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

למי שרגיל לקונבנציות קוד מוקפדות – זה עשוי להיות דיי מרגיז: הסוכן משתמש לרוב בקונבנציות קוד מוקפדות – אבל שונות מאלו שלכם.

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

1. זה גוזל זמן. הרבה.
2. להגיע ל 100% סגנון רצוי עשויה להיות השקעת עבודה גדולה פי 2-3 מלהגיע ל 80% סגנון רצוי.

כמה זה משנה? כמה תשקיעו כדי לדייק את הסגנון?

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

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

השיח עם הסוכן, הוא לפעמים הזדמנות ללמידה. מִכָּל־תַּלְמִידַי הִשְׂכַּלְתִּי (השינוי מכוון).

אתם בוודאי יודעים של Agentic IDEs מאפשרים לכתוב AI Rules הנוספים ל context ומנחים את הסוכן כיצד לעבוד. מאוד שימושי ללמד אותו דברים בעזרת ה rules ולחסוך זמן, מדוע לא ״להעביר אותו בית מדרש – וללמד אותו לכתוב בקונבנציות המדויקות של הצוות״?

• ה rules הם לא מדע מדויק. גם rules שהעברתי כמה איטרציות של שיפור דיוק (גם בעזרת LLM) – לא תמיד השיגו את התוצאה הרצויה. נראה ש rules טובים משיגים תוצאה רק 90% מהפעמים.
• ככל שתתנו לסוכן יותר rules – יהיה פחות משקל לכל rule. אני מאמין בלתת לסוכן לא יותר מ 10-20 חוקים חשובים – ובשאר לקבל את הסגנון השונה שלו. זו נראית לי כרגע הגישה הפרגמטית.
• שינויים במודל ו/או system prompts מתרחשים כל הזמן, ומשפיעים על דיוק הביצוע של ה rules. כמה עבודה אתם מסכימים להשקיע בכדי לתחזק את ה rules עובדים לכל המודלים, ולאורך זמן?

לא דמיוני בעיני להחליף ספריות, סגנון קוד, או אולי אפילו שפת תכנות בארגון (בקוד חדש) – לכזה שעובד טוב יותר עם מודלי ה LLM העדכניים. זה אומר לא-פעם להיות יותר סטנדרטיים לתעשייה. היתרונות בעבודה חלקה עם Agentic IDEs יכולה להצדיק לא שינויים הנובעים מה״היסטוריה״ של הארגון.

שלב #6 – להפנים שלסוכן אין רגשות, אבל למפתחים יש

מעבר להתלהבות הראשונית, הופעתי לראות כמה רגשות ורתיעה, כלי Agentic IDE יכולים להוציא מאנשים. במחשבה נוספת, זה דיי הגיוני:

• יש הבדל גדול בין לקרוא בעיתון על מישהו רחוק ואחר, מאשר להרגיש חוסר-ודאות לעתיד על בשרנו.
  • בתגובה לכתבה על עובדים שפוטרו או הוזזו מתפקידם בעקבות תוכנת אוטומציה חדשה אנחנו יכולים להגיב: ״זו הקדמה, אין מה לעשות״ או ״שיחשבו הלאה וימצאו מקצוע אחר״
  • כשהעתיד שלנו פתאום לא ברור – זה נראה אחרת. זה אנושי והגיוני למדי.
• במשך שנים התרגלנו לסגנון קוד מסוים, לדרך כתיבה מסוימת, להקפדה על הפרטים והערכה רבה להקפדה על הפרטים. לומר ביום אחד ״טוב, סגנון קוד לא כזה משנה״ – זה סוג של זעזוע. איך? למה? מתי זה קרה?! ״האם אין לנו יותר ערכים״?
• ״תחשוב שקיבלת לחנוך בוגר אוניברסיטה מבריק וחרוץ. אתה לא אמור לכתוב כמעט קוד, אתה אמור בעיקר להנחות אותו״ – הסברתי למישהו את הרעיון של עבודה עם Agentic IDE.
  • ״אבל אני לא רוצה לחנוך בוגר אוניברסיטה. אני אוהב לכתוב את הקוד בעצמי. אני טוב בזה ונהנה מזה. אם הייתי רוצה לחלק הנחיות – הייתי הולך לנהל״.
• ״מה יוצא לי מזה?״ – ישאל במודע או לא במודע המפתח. לדלוור 10% יותר פ׳יצרים זה נחמד – אבל זה לא באמת מה שיוצר מוטיבציה אצל מפתחים. יותר מעניין לכתוב קוד טוב יותר, איכותי ונקי. לעשות עבודה מקצועית להתגאות בה.
  • האם שימוש ב Agentic IDE עומד לשפר את הערכים המקצועיים של המפתחים? או אולי בעצם הוא יאלץ את המפתח לשנות סגנון התנהלות – ולעשות לפעמים פחות ממה שהוא אוהב, וטוב בו?
  • האם, למשל, ארגון יקצה חלק משיפור התפוקה שהושגה בעזרת Agentic IDE כדי להקדיש יותר זמן לשיפור איכות קוד? או שכל השיפור ״ישרת״ רק את הגדלת הרווחים?

זוכרים את ימי אימוץ האג׳ייל, כאשר הסברנו (או מישהו אחר הסביר) לראשי צוותים שהם הופכים ל Scrum Masters – וזה רק לטובה? אלו לא היו ימים פשוטים. אני זוכר הרבה ראשי צוותים מודאגים, ובדיעבד – היה הרבה בדאגה שלהם.

אני מאמין שאנחנו פה בשינוי דומה, רגשי, של ערכים וקדימויות. שינוי שאינו קל לאנשים – וארגון חכם יכיל את הקשיים ויעזור לאנשים להתמודד איתם, ולא יצא בהצהרות כמו ״עברו לעבוד ל Agentic IDE – או לכו הביתה״.

שלב #7 – להפנים שכולנו עדיין Juniors בעולם הזה

השינוי עוד בחיתוליו.

בני אדם נוטים להעריך יתר שינוי בטווח הקצר – ולהעריך הערכת חסר שינויים בטווח הארוך.

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

לעבוד עם Agentic IDE זו אינה חווית פרמיום בימים אלו – זו חלוציות. אבל כל הסימנים מעידים שהחוויה תשתפר, ובקצב דיי גבוה.

אני מאמין שעבודה עם ה Agentic IDE תהפוך מהר מאוד להיות ה Premium Skill הכי חשוב והכי משמעותי בתעשיית פיתוח-התוכנה בזמן הקרוב. אני ממליץ להתחיל ולרכוש את ה skill הזה – כבר עכשיו.

לא הייתי נקשר יותר מדי ל IDE מסוים, למודל מסוים, או אפילו ל Flow עבודה מסוים – כי פרטים רבים עשויים עוד להשתנות. לחוש ולתמרן בתוך השינוי.

ה Juniors הכי גדולים עומדים להיות המנהלים. אלו שהיו פעם אנשי המקצוע החדים ביותר – כרגע צוברים הכי מעט שעות עם ה Agentic IDE. נראה שכרגע רוב המנהלים ניזונים בעיקר מסרטוני תדמית וסיפור הצלחה – וזה גורם לשטחיות בהבנה. אני ממליץ בחום לכל המנהלים להקצות את הזמן, להפשיל שרוולים, ולעבוד עם Agentic IDE בעבודה משמעותית. זה לא עוד שינוי של מה-בכך.

• יש הבדל מאוד גדול בחוויה בעבודה עם Agentic IDE למשך יום או למשך שבועיים. הסוכן מייצר גם תסכולים, ואי-הצלחות. קל לראות את ה case-studies הטובים – ולפספס את התמונה הגדולה והמורכבת יותר.
• מנהל שיפנה לעובדים שלו ויצהיר ״אני מצפה מהיום, מכל אחד מכם, לשיפור תפוקה של 50% לפחות״ – הוא בור. תצאו מנהלים טובים יותר אם תבינו על מה אתם מדברים, לפני שאתם דורשים מהעובדים. אלו כלים יש לכם לעזור לעובדים שמתקשים להסתגל למגמה החדשה, טכנית או רגשית – מלבד לשלוח אותם לעמיתים או להפעיל לחץ? אני מאמין ששווה שיהיה לכם סט כלים מעט יותר גדול מזה. בעת שינויים עמוקים דרושה מנהיגות שמבינה את ההתרחשות באמת.

סיכום

כרגיל, אני יכול להמשיך ולהאריך בדברים – אבל הגיע הזמן לסכם.

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

עולות גם הרבה שאלות פתוחות:

• מה קורה עם מפתחים חדשים? האם צריך ״למנוע״ מהם עבודה עם Agentic IDE כדי שיוכלו לפתח מיומנויות בסיסיות (אינסטינקטים, troubleshooting)?
  • ליאור: אני מאמין שלא. אני מאמין שאפשר תוך כדי עבודה עם סוכן ללמוד המון. אולי יותר מבעבר, אם כי בדרך קצת אחרת.
• האם איכות הקוד עומדת לרדת? האם הקוד נכתב מהר יותר עכשיו – אבל עוד שנה המערכת תהיה סבוכה יותר וקשה יותר לעבודה – כך שבסוף הכנסת Agentic IDE תפגע בסה״כ הפריון?
  • ליאור: אני בטוח שזו אפשרות. אני חושב שזה בעיקר עניין של תרבות ארגונית והקפדה על ערכים של הנדסת תוכנה. הצלחתי לעשות בעזרת סוכן כל מיני שיפורי קוד שלא הייתי מספיק לעשות (מבחינת לו״ז) – בלעדיו. הצלחתי – כי היה לי חשוב לשפר את הקוד.
• האם המפתחים המוצלחים של היום, יהיו גם המפתחים המוצלחים של מחר, או האם יש פה שינוי של המיומנות החשובות – ובעצם קבוצת אנשים ״תרד במעמד״ וקבוצה אחרת ״תעלה״?
  • ליאור: לא יודע. אשמח לענות עוד שנתיים-שלוש, ולטעון בדיעבד שתמיד ידעתי את התשובה.

אם אתם קוראים את הפוסט הזה ב 2026, והארגון שאתם עובדים בו סגור בפני אימוץ של Agentic IDEs – אני חושב שזה זמן ללחוץ יותר חזק על הארגון להיפתח, או לשקול לגוון ארגון. אני מאמין שקורה פה אירוע בלתי-חוזר. משהו משתנה בעולם פיתוח התוכנה – לתמיד.

שיהיה בהצלחה!

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

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

נתחיל בדוגמה בסיסית

ברמה הבסיסית ביותר, מערכת המשתמשת ב LLM נראית כך:

• המערכת שלנו שולחת prompt (טקסט) למודל LLM. המודל יכול להיות SaaS (כמו OpenAI) או מנוהל ב self-hosting כמו מודלי open source שונים.
• ה LLM יְעַבֵּד את ה prompt – ויחזיר תשובה טקסטואלית.

כמובן, שאם לא עשינו שום דבר מיוחד עם ה prompt, בעצם יצרנו עוד אפליקציית צ׳ט נוסח chatGPT או Gemini. נוכל להוסיף UI נחמד יותר, או צלצולים ברגעים הנכונים – אבל בבסיס יש פה עוד אפליקציית Chat. לא משהו חדש.

כפי שכתבתי בפוסט קודם בנושא, יש ארבע דרכים עקרוניות להשפיע על מודל LLM – כדי לאפשר יכולות חדשות (מסומנות בתרשים בגווני כחול):

אימון מודל חדש, ו fine-tuning למודל קיים הם מאמצים הדורשים משאבים ומומחיות רבה. עשרות אלפי דולרים ל fine tune של מודל קטן עד מיליונים רבים מאוד לאימון מודל גדול חדש.

נראה שכ 99% מהפתרונות מבוססי-ה LLM מתבססים על שתי הפרקטיקות הפשוטות והזמינות: Prompt Engineering ו RAG – בהם נתמקד בפוסט. אלו טכניקות זולות מאוד, שניתן להפעיל בהשקעה קטנה וללא התעמקות בקרביים של מודלי LLM.

Agentic workflows הם שורה של Patterns של שימוש ב Prompt Engineering ו RAG על מנת להשיג תוצאות טובות יותר. נדון בהם בהמשך.

נתחיל בתיאור פתרון מינימלי מבוסס-LLM, כזה שמפתח בודד יכול לפתח, ובזמן קצר. נעשה זאת בעזרת הכלי הבסיסי ביותר- Prompt Engineering. שימו לב ל Prompt template הבא:

prompt_template = """You are a teacher grading a question. 
You are given a question, the student's answer, and the true answer, 
and are asked to score the student answer as either Correct or Incorrect.

Grade the student answers based ONLY on their factual accuracy. 
Ignore differences in punctuation and phrasing between the student answer and true answer. 
It is OK if the student answer contains more information than the true answer, 
as long as it does not contain any conflicting statements. 
If the student answers that there is no specific information provided in the context, 
then the answer is Incorrect. Begin! 

QUESTION: {question}
STUDENT ANSWER: {studentAnswer}
TRUE ANSWER: {trueAnswer}
GRADE:

Your response should be as follows:

GRADE: (Correct or Incorrect)
(line break)
JUSTIFICATION: (Without mentioning the student/teacher framing of this prompt, 
explain why the STUDENT ANSWER is Correct or Incorrect. Use up to five sentences maximum. 
Keep the answer as concise as possible.)
"""

מקור
אם נציב במקומות הנכונים ערכים לפרמטרים question, studentAnswer ו trueAnser ונשלח ל LLM לעבד את התשובה – הוא יחזיר לנו ניתוח האם התשובה נכונה או לא, והסבר למה.

בפועל: יצרנו פונקציה ממוקדת ושימושית, שלא הייתה קיימת קודם לכן – בדיקת נכונות של שאלה.

עבור שאלה בהיסטוריה, בנוסח ״מנה את הגורמים העיקריים לפריצת מלחמת העולם הראשונה״ – נוכל לקבל במאמץ קטן מערכת שתפתור בעיה הנדסית שבתכנות אימפרטיבי – לא סביר לפתור. ניתוח הטקסט, הבנת משמעות והתאמה שלו לטקסט לדוגמה (התשובה הנכונה) הוא דבר קשה מאוד ליישם בעזרת שפת תכנות כמו ג׳אווה, וללא מומחיות עמוקה בטכניקות של NLP (קרי: Natural Language Procesing).

בעזרת LLM ומעט prompt engineering – זו משימה פשוטה.

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

שימו לב שאנחנו לא מסתמכים פה על הידע של LLM בהיסטוריה (ידע שדווקא יש לו) אלא את היכולת להשוות בין תשובת תלמיד לתשובה שהגדרנו כנכונה, בצורה סמנטית ומעמיקה. זה גם מאפשר לנו לקבע מהי התשובה הנכונה מבחינתנו וגם מאפשר לנו לעסוק בנושאים בהם אין ל LLM ידע מספיק (למשל: חוקי העזר העירוניים של עיריית ת״א). ה LLM משמש פה בעיקר כמומחה לשפה ופחות כמקור הידע. את הידע הזה אנחנו מזריקים לו כחלק מה prompt בדמות התשובה לדוגמה.

נקודה חשובה: אם אנו רוצים להשתמש ב prmopt הנ״ל על לבדוק את התשובה על לשאלה ״באיזו שנה הוקמה מדינת ישראל?״ – אנחנו כנראה עושים כאן עוול. אין צורך ב LLM לבדוק כזו שאלה. LLM הוא יקר לשימוש (כמות ה compute, זמן חישוב ארוך), אינו דטרמניסטי, ודורש תחזוקה על מנת לשמר אותו מ drifts בתוצאות לאורך זמן. עדיף לעשות pattern matching פשוט בקוד כדי לבדוק תשובה לכזו שאלה.

לסיכום

השתמשנו ב LLM לייצר פונקציה שימושית שיכולה להשתלב במערכת קיימת. פונקציה שאם היינו מנסים לפתח בלי LLM – ספק אם היינו מצליחים באותה איכות ובזמן פיתוח דומה. עד כאן זו איננה מערכת LLM אלא מערכת שיש בה פונקציה של LLM, למשל: מערכת לבדיקת וניהול ציונים.

LLM Agents

היכולת לשלב פונקציות מועצמות-LLM במערכות קיימות ולספק ערך חדש ונוסף – היא מלהיבה בפני עצמה, וראוי שנעשה בה שימוש רחב בכל מקום בה היא מועילה.

LLM פותח בפנינו הזדמנויות גדולות יותר מאשר כתיבת פונקציות חכמות יותר, כמו לתת ל LLM לנהל תהליכים שלמים ומורכבים. העולם מדבר עכשיו על Agents – סוכנים חכמים שיידעו לבצע מגוון פעולות הדומות לבעל מקצוע המתמחה בתחום מסוים. למשל סוכן שהוא עו״ד בתחום הנדל״ן (A real estate attorney agent).

להזכיר: מודל שפה מאומנים על כמות גדולה של מידע ציבורי מהאינטרנט (כמו וויקיפדיה), ועוד מאגרי צד-שלישי או מאגרים פרטיים שזמינים למאמני המודל. הם מכילים ידע רחב מאוד, אך לרוב לא מתמחים לעומק בנושאים ספציפיים. ChatGPT יוכל לענות על תשובות כלליות בנושאי חוק ונדל״ן – אך הוא רחוק להיות שקול לעו״ד מנוסה בתחום. את הפערים האלו אפשר לצמצם בעזרת כלים מסוימים, כמו RAG.

RAG מאפשר לי ״להזריק״ למודל עוד מידע רלוונטי שלא קיים במודל (קרי: המודל לא אומן עליו) בצורה דינמית ומותאמת לשימוש הספציפי. RAG יכול להפוך צ׳ט גנרי מבוסס LLM – לצ׳ט שמצליח לענות בצורה טובה על שאלות מעמיקות בתחום מסוים (נניח: נדל״ן).

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

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

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

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

בפועל, אלו רעיונות שעדיין לא הוכיחו את עצמם ב scale. ייתכן שיצוץ משהו דומה בעתיד אולי בארכיטקטורה של Multi-Agents ואולי בארכיטקטורה אחרת – עוד מוקדם מדי לומר.

Retrieval Augmented Generation (RAG)

על הנושא הזה כבר כתבתי, אבל הוא חשוב מספיק כדי שאסכם אותו שוב. נניח אני בונה צ׳ט לאתר שעוסק במסעדות – ואני רוצה לענות ללקוחות על שאלות מסוימות. למשל:

ל LLM, כמודל, אין ידע מספיק כדי לענות על השאלה:

• הוא לא יודע מי המשתמש, והיכן הוא גר. באיזה סניף מדובר.
• הוא לא מכיר את רשת המסעדות ״בורגר סאלון״ – זה לא היה כלול במידע האימון שלו. בכל זאת, הוא הצליח להבין מהשם את ההקשר, ולענות תשובה הגיונית – שזה מרשים!
• הוא לא יודע מה שעות הפתיחה של המסעדה הספציפית – מידע שיכול להתעדכן כל הזמן.
• הוא לא יודע מה התאריך הנוכחי, קרי אפילו אם יידע מה שעות הפתיחה של המסעדה – הוא לא יוכל לספק תשובה טבעית כמו ״היום הם פתוחים עד 20:00, אבל מחר מתשע בבוקר עד חצות״ – מה שכן הייתי רוצה לקבל מצ׳ט אנושי.

יכולנו בעזרת prompt engineering להוסיף context ל prompt שיוסיף עוד מידע. למשל: שעות הפעילות של כל המסעדות שאנחנו מכירים. זה היה עוזר אבל:

• ה prompt היה גדול ומכאן יקר לעיבוד (זמן, כסף)
• ככל שה prompt גדול יותר ה attention של ה LLM נפגע – וייתכן שהוא יתבלבל – ויספק פרטים של מסעדה אחרת.

מכאן השלב הבלתי נמנע הוא לספק prompt דינאמי – עם מידע ממוקד לשאלה הספציפית. זהו תהליך ה RAG:

1. אנחנו מקבלים את ה prompt מהמשתמש
2. אנחנו מעבירים אותו לתהליך ה RAG בכדי לנסות ולשפר אותו (להעשיר את ה context)
3. אנחנו מחפשים מילות מפתח ב prompt, למשל את השם ״בורגר סאלון״.
4. אנחנו שולפים מבסיס הנתונים (נקרא בעולם הזה: Knowledge Base) שהכנו מראש, מידע ואת שעות הפעילות העדכניים של בורגר סאלון.
5. אנחנו מעשירים את ה prompt ב context רלוונטי:
   • תאריך של היום
   • מיקום של המשתמש (שלפנו geoLocation מהדפדפן)
   • מידע כללי על מסעדת בורגר סאלון ושעות פתיחה עדכניות
6. נשלח את ה prompt המשופר ל LLM – על מנת לקבל תשובה איכותית, שלא היינו יכולים לקבל ללא תהליך ה RAG

ה prompt המשופר יכול להראות כך:

INFORMATION:
current time is {datetime}
the user current location is {address}
Information about the restaurant:
{restaurant_general_info}
{restaurant_opening_hours}

QUERY:
{user_query}

INSTRUCTIONS:
You are a helpful agent providing information about restaurants.
Answer the users QUERY using the INFORMATION text above. 
Keep your answer ground in the facts of the INFORMATION. 
If the INFORMATION doesn’t contain the facts to answer 
the QUERY answer you don't know.

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

RAG הוא עולם בפני עצמו, הכולל טכניקות שונות כיצד לבחור איזה מידע לשלוף, כיצד לבחור כמה מידע לשלוף, כיצד למיין אותו ב prompt, כיצד לאנדקס את המידע, וכיצד לנטר ולשפר את תהליך ה Retrieval. קצרה היריעה מלדון בכל הנושאים הללו.

Tools Use

בואו נחזור למערכת בדיקת המבחנים שיצרנו, ונראה מצב שבו LLM הוא לא רק יקר יותר – אלא הרבה פחות מוצלח בתוצאה. למשל: בדיקת פתרון בעיה מתמטית.

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

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

היום, אם תלכו ל chatGPT ותתנו לו לפתור בעיה מתמטית עם מספר רב ספרות – סיכוי טוב שהוא יענה תשובה מדויקת:

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

הכלי עצמו, לא משתמש ב LLM. זהו כלי שפותח בעזרת קוד אימפרטיבי – כזה שקל לו לבצע חישובים מתמטים מדויקים, ובמהירות. הוא פיצוי למודל – בנקודות שבוא המודל הוא חלש. לעתים קרובות, הפיצוי הזה מאוד מוצלח.

אנחנו רואים כיצד LLM הוא אינו ״קליע כסף״ לכל בעיה, אלא השילוב שלו עם כלים קלאסיים (קוד אימפרטיבי, קרי פונקציה בג׳אווה / פייטון / וכו׳) מקדמים אותנו לעבר החזון של סוכן LLM חכם ורב-יכולות.

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

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

system_prompt = """You are an assistant that has access to 
the following set of tools. 
Here are the names and descriptions for each tool:

{rendered_tools}

None - if the query require none of the tools above.

Given the user input, return the name of the most appropaite 
tool to respond to the query effectively."""

במקום של {rendered_tools} נשתול מפה המתארת את שמות ה Tools ואת התיאורים המילוליים של מה כל Tool עושה ומתי נכון להשתמש בו. יש פה עניין של prompt engineering, בחירת מילים המובילה לתוצאות טובות.

בשלב הבא, נבדוק אלו arguments ה tool שנבחר זקוק – ונפרסר את ה query של המשתמש כדי לשלוף את הארגומנט הנכון מהשיחה עם המשתמש. למשל: המספר לו אנו רוצים לחשב את השורש. גם הפעולה הזו יכולה להתבצע בעזרת LLM.

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

כלים יכולים לספק מגוון השלמות דינאמיות למגבלות של ה LLM. למשל: RAG. במקום להבין מראש איזה מידע חסר – ולהזין אותו כ context על ה prompt, לפעמים יעיל יותר לתת ל LLM להסיק בעצמו איזה מידע חסר לו – ושהוא יבקש אותו, בעזרת פנייה ל Tool המתאים. למשל: Tool המספק שעות פעולה של מסעדה.

כלים אחרים הם כאלו שמבצעים פעולות. למשל: LLM הוא מודל סגור ולא יכול לבצע הזמנה למסעדה. מצד שני הוא יכול להסיק שהלקוח מבקש לבצע הזמנה, ואז להפעיל Tool שפונה ל API של המסעדה, עם פרטי ההזמנה הרצויים שה LLM שלף מהשיחה – ולבצע את ההזמנה בפועל.

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

לסיכום

LLM הוא ״סוג של קסם״, המהווה פריצת דרך ביכולות שלנו לפתור בעיות בעזרת תוכנה. למרות שהמודלים הולכים ומשתפרים, LLM בצורה גנרית יפתור מעט מאוד בעיות. על מנת לפתור בעיות מגוונות אנחנו צריכים לבצע עבודה הנדסית (prompt engineering, RAG, tools) מה שמאפשר לנו באמת לבנות פתרונות מגוונים מבוססי LLM.

החזון המדובר היום הוא LLM Agents שיחליפו מומחים בתחומם, לפחות חלקית. הדרך לשם – היא עקב לצד אגודל – בניית עוד יכולת ועוד יכולת, ושיפור היכולות. ההתקדמות בתחום הזה היא לא פחות ממדהימה, הן בהיבט המודלים שהולכים ומשתפרים (דיוק, עלויות), והן ברמת הטכניקות ההנדסיות המאפשרות לרתום את המודלים והפיכתם לפתרונות לבעיות עסקיות.

לאחר שעסקתי קצת בנושא בחודשים האחרונים, אני ממליץ פחות לתכנן מערכות Multi-Agents ויותר לבנות יכולות עסקיות אחת-אחת ולראות להיכן צומחים משם. כמו כן, ניתן לפתור המון בעיות בעזרת LLM – וזה דיי מגניב, אבל לא תמיד משתלם. פונקציות המבוססות על LLM, במיוחד המורכבות שבהן, דורשות ניטור ותחזוק שוטפים לא מובטלים. המודל הוא סטוכסטי ולא תמיד צפוי או הגיוני. את זה צריך לנטר, ו to mitigate כל הזמן. גם בעקבות שינויים שלא היינו מצפים שישפיעו (עדכנו מעט את ה prompt, יש נתונים נוספים ב knowledge base, עברנו להשתמש במודל מתקדם יותר).

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

שיהיה בהצלחה!

עקרון ה YAGNI (קרי: ״You Ain’t Gonna Need It״) נזכר לראשונה בסדרת הספרים של Extreme Programming (בקיצור: XP) מהמחברים רון ג’פריס וקנט בק.

באחד הספרים הראשונים, רון מתאר דילמה שבו הוא צריך לכתוב אפליקציה שצריכה לשמור (persist) נתון מסוים. הוא מתלבט בין לכתוב את הנתונים לקובץ (הכי מהיר / פשוט) או להשתמש בבסיס נתונים (הגישה המקובלת). תחת עיקרון ה YAGNI הוא מחליט להשתמש במערכת קבצים – כי לא צריך יותר מזה בשלב הזה. אם יהיה צורך מורכב יותר – הוא יעשה Refactoring ויעבור לעבוד עם בסיס נתונים.

אני זוכר שהדוגמה הזו נראתה לי מוגזמת מדי. הרבה רעיונות בספרים של XP היו מוגזמים – באופן מוצהר ומכוון. בסיס נתונים הוא דבר דיי פשוט וקל לקנפוג – למה לעזאזל שאעבוד עם מערכת קבצים כשברור לי שהצורך בבסיס נתונים הוא ״מעבר לפינה?״ הרי ״ברור״ שאגיע לשם.

YAGNI הוא עיקרון נהדר, כי בתעשיית התוכנה אנחנו מגיעים לעשות הרבה Over-Engineering (הנדסת-יתר). החיסרון שלו, כמובן, שהוא עלול להוביל אותנו ל Under-Engineering (הנדסת-חסר), לפתרונות תוכנה פשטניים, שלא יעמדו במבחן הזמן ויאלצו אותנו להשקיע הרבה עבודה על מנת להביא את המערכת בחזרה לאיזון טוב בין הנדסת-יתר וחסר. מה שפעם נקרא ״code and fix״, קדד מהר – תקן בהמשך.

ברור לנו שגם הנדסת-חסר וגם הנדסת-יתר – אינם טובים.

התכונה המעניינת שמחזקת את עקרון ה YAGNI, היא שבעוד הנדסת-יתר ניתן לעשות עד אינסוף (כלומר: הסטייה האפשרית היא בטווח עצום / בלתי-נגמר), הסטייה האפשרית בהנדסת-חסר היא קטנה יותר: אם נחסיר יותר מדי – המערכת תפסיק לעבוד. יש לנו boundary ברור שיעצור אותנו מלהמשיך.

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

סטארט-אפים ישראלים מפנימים את המסר הזה דיי מהר: אין להם זמן לאבד, הסיכוי להסתבכויות של הנדסת-יתר עשויה להיות מכת מוות לסטארט-אפ שלא עומד ב milestones חשובים – ולכן כדאי להעדיף את הנדסת-החסר (בדמות קבלה שיטתית של עקרון ה YAGNI) על פני ״האלטרנטיבה השנייה״.

אַלְיָה – וקוץ בה

רגע של עברית: אַלְיָה היא רקמת שומן בזנבם של חלק ממיני הכבשים. ה"קוץ" הוא חלק פגום בנתח הבשר או לפי פירוש אחר: קוצים שדבקו לפרוות הזנב ומקשים על מלאכת הגֵּז.

הנה סיפור קצר: עבדתי בחברת הזנק שהייתה צריכה לבנות ממשק משתמש לאיש התמיכה הראשון. רבות מהפעולות היו חיפושים בבסיס הנתונים, ולכן החליטו שאין צורך לבנות כרגע UI. איש התמיכה ילמד SQL ויבצע את השאליתות שלו ישירות מעל בסיס הנתונים בפרודקשיין. So far – so Good.

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

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

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

אם היינו בוחרים בהנדסת-יתר היינו עשויים לשבת עם קוד מיותר / חסר-שימוש, שהשארתו איננו נזק מתמשך למערכת. הנדסת-חסר נוטה לכאוב לנו יותר בשוטף.

חשוב לציין: גם בהנדסת-יתר, יש מצבים בהם השארות הקוד היא כאב מתמשך. זה קיים, אך פחות נפוץ.

מציאת איזונים נכונים

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

Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify.

אני שם את הדיונים האלו בצד. בסוף, ביומיום של חברת סטארטאפ, יש לחץ אמיתי להתמקד בתוצאות מיידיות המשפיע על כל רוחב הארגון. בד״כ לא קוראים לזה בשם ״YAGNI״ – פשוט רוצים לעמוד ביעדים העסקיים. גם את הניתוח המדוקדק: ״האם אני מצמצם יכולת למשתמש או קלות לשינוי-התוכנה בעתיד״ – לא ממש עושים. אנו רואים דרך לחסוך עבודה שעדיין משיגה את התוצאה העסקית – ועושים אותה.

נפתח בכמה הנחות-יסוד:

• גדיעת הנדסת-יתר, היא פעולה חשובה. באמת יש אינספור דרכים לסבך את התוכנה שלנו מתוך רצון טוב – אך בצורה איומה.
• העתיד בתוכנה איננו ברור, במיוחד בחברות סטארט-אפ. לא פעם יבואו אנשי המוצר וילהיבו בחזון לשנה הבאה, המהנדסים יתכוננו לקראתו בדזיינים וקוד – רק כדי להיווכח שהעתיד הזה מבושש להגיע – או בכלל השתנה, ואיננו רלוונטי עוד.
• הנדסת-חסר יכולה להיות הרסנית: חסכון השבועיים עכשיו – עלול לגרום לחודשי עבודה נוספים בעוד שנה.
• אסתכן, בלי ניתוח מעמיק, להעריך שבסטארט-אפים ישראלים מדובר בנטייה ברורה להנדסת-חסר, וסה״כ: טוב שכך. תראו את ההייטק היפני, שבו יש נטייה תרבותית להנדסת-יתר (מתוך: תרבות של מצוינות ודיוק). כמה חברות תוכנה יפניות מצליחות אתם מכירים?

מה באמת אפשר לעשות?

אנסה להציע כמה קווים מנחים, שיעזרו לנו לאזן בצורה טובה יותר בין הסיכון להנדסת-יתר והסיכון להנדסת-חסר. נקודות ההחלטה העלו יעלו מתוך Design או מתוך דיון / דילמה מקצועית.

• קודם כל, עלינו להציג מספר חלופות אפשריות. אם אנו דנים בחלופה יחידה – בהכרח אנו פועלים עם ״שטח מת״ משמעותי. זה עקרון בסיסי של תכנון תוכנה.
  • למשל: הדילמה האם להשתמש באפליקציה בבסיס-נתונים, או במערכת קבצים.
  • כאשר יהיו לנו מספר חלופות, לא פעם הן יפלו לקטלוג אוטומטי של ״פתרון זול/פשוט ופחות טוב״ מול ״פתרון טוב אך יקר״. זה השלב שנרצה להפעיל את השאלה ״Do we Gonna need it״? (להלן DWGNI)
  • התרבות הכווינה אותנו לחשוב ש "you get what your pay for״, קרי: יקר יותר = טוב יותר. חשוב שנשתחרר מההטיה הפסיכולוגית הזו ונבחן את האלטרנטיבות מבחנים אחרים.
• אילו מבחנים ניתן להפעיל:
  • מבחן הדחייה, מה יקרה אם נדחה את ההחלטה? כמה יקר יותר יהיה לבצע את ההחלטה בעתיד (נניח: עוד שנה) ולא עכשיו? בארכיטקטורת תוכנה – נהיה חכמים יותר ככל שהזמן עובר, ולכן כדאי לדחות החלטות כאשר אפשר, ואפילו שווה לשלם על זה קצת.
  • מבחן מחיר ההחלטה השגויה לאורך זמן, מה צפוי להיות המשמעות של בחירה באופציה א׳ או באופציה ב׳ לאורך זמן? נניח: שלוש שנים. קל לומר: ״גישה ב׳ תיצור קוד קל יותר לתחזוקה״ ולרוץ לבחור באופציה ״הטובה יותר״. כמה זה טוב יותר? אולי זה לא שווה את ההשקעה? בואו ננסה לכמת את הערך. לא פעם, בעקבות בחינה עמוקה, אנחנו מגלים שהערך הוא שולי ולא שווה את ההשקעה.

דוגמה

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

דילמה: האם לחלק את הפיצ׳ר למיקרו-שירות אחד או שניים.

אנו מזהים בשירות שתי אחריויות. נניח: A. להריץ workflow ו B. לאסוף נתונים ממקורות שונים. ע״פ גישת המיקרו-שירותים טבעי שנחלק את הפונקציה לשני שירותים מובחנים. זה ייתן לנו יותר הפרדה בין השירותים ויקשה על הקוד שלנו להסתבך.

מצד שני, אפשר באמת ליצור שירות אחד ולחסוך זמן. כרגע לא ידוע על מקרה שבו אחריות B תהיה בשימוש שלא בצמוד לאחריות A. לא צריך יותר משירות אחד, וזה יותר פשוט למימוש. כל קריאה בין אחריות A לאחריות B תהיה קריאה של פונקציה (קל) ולא קריאה של API ברשת (עוד עבודה).

מה עדיף? בואו נבחן ע״פ הקריטריונים.

מה המחיר לדחות את ההחלטה בשנה? נתחיל עם האופציה הזולה למימוש (שירות אחד) ונתקדם משם.

• כמה מהר השירותים הללו עומדים להתפתח? מפתח יעבוד עליהם חודש, או כמה מפתחים יעבדו עליהם רבעון? פיצול של שירות לשניים עשויה להיות עבודה לא קטנה – וגודלה בקשר ישיר לכמות הקוד שכבר נכתב.
• יש הבדל בין להעביר קוד בלבד, מול להעביר קוד + נתונים. אם אחריות B (השירות שאולי נפצל) כוללת בתוכה נתונים, במיוחד כאלו שמתעדכנים כל הזמן – המחיר לפיצול שירותים הופך להיות יקר הרבה יותר.

בקיצור: התשובה עשויה שונה ממקרה למקרה. אם אנחנו מרגישים שמחיר ההחלטה בעוד שנה הוא קטן (נניח: שבוע-שבועיים עבודה) – ייתכן ונרצה לדחות אותה ולהחליט בעתיד, כאשר נהיה חכמים יותר. אם המחיר יקר – כנראה שנרצה להתאמץ עוד ולקבל החלטה עכשיו.

מה מחיר ההחלטה השגויה לאורך זמן?

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

נניח שבחרנו בשירות אחד, זו הייתה טעות, והמשכנו כך לאורך שלוש שנים. מה המחיר?

• הקוד של אחריות A ואחריות B עלולים להתערבב (כי אין הפרדה טבעית ביניהם), ויהיה קשה יותר לתחזק ולהפריד ביניהם.
• השירות המשותף עלול לנהל תלויות של שתי אחריויות ולא אחת – יותר תלויות אם שירותים שאולי לא רצינו בהם. יהיה קשה להבחין אם תלות נוצרה בגלל אחריות A או אחריות B.
• אם כמות הקוד גדלה והסתבכה – כנראה ההפרדה בשלב הזה בין אחריות A ואחריות B תהיה מאמץ משמעותי וגדול. יהיה עלינו לפנות הרבה זמן כדי להפוך את ההחלטה. האם זה ישתלם לנו, או שנמשיך ״לסבול״ כי ״מחיר השנוי הוא גבוה מדי בכדי להצדיקו בשלב הזה״?

כמובן שבראייה הזו, ניתן לעשות צמצום-נזקים (mitigation) לחלק מהסעיפים. נניח לנהל את אחריות A ו B כמודולים נפרדים בשירות שבניהם יש הפרדה נוקשה – אם יש לכם כלים כאלו בארגון.

נניח שבחרנו בשני שירותים, זו הייתה טעות, והמשכנו כך לאורך שלוש שנים. מה המחיר?

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

• כל קריאה חדשה בין אחריות A לאחריות B כוללת יצירה של API חדש – תקורה ברורה בעבודה.
• גילינו שבעצם יש קשר הדוק בין A ל B ולא היה נכון לראות בהן אחריויות שונות – ואנו עובדים קשה על התיאום בין שירות A לשירות B.
• הביצועים של המערכת נפגעו קשות מההפרדה בין A ל B, או אולי היכולת לעשות troubleshooting מורכבת יותר.

בתסריט שבו התברר שההפרדה היא הנדסת-יתר כי הקוד פשוט למדי, הנזק גם אינו גדול. יש לנו תקורה, אך היא במכפלה של בסיס-קוד קטן.

התסריט של קשר הדוק בין A ל B שלא היה נכון להפריד ביניהם יותר קשה. אם רק שילוב של אחרית A ו B באותו שירות יפתור את התקורה, ייתכן ונרצה לשלב ביניהם בחזרה. לרוב קשיים כאלו הם קשיים שניתן למתן (mitigate) במאמץ נקודתי: שיפורי ביצועים או שיפור ה API.

ניתוח שכזה עוזר גם לנהל סיכונים בלי קשר. אולי למשל, אם עשויות להיות הרבה קריאות בין אחריות A ו B אולי עדיף שנגדיר API גנרי בין שני השירותים, שיכול לטפל במגוון המקרים, בלי להוסיף APIs נוספים כל פעם. למשל:

fun collectData (type: DataType): List<DataItem>

סיכום

בחזרה לשאלתנו: האם סטארט-אפים זקוקים לעקרון ה YAGNI?

כן, הם זקוקים לו, כי הסיכון מהנדסת-יתר הוא ממשי ומשמעותי. יש מהנדסים שאם תתנו להם ״לשפר תשתיות״, הם לעולם לא יסיימו. אנשים טובים ואיכותיים.

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

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

כמו כן, נכון ״לכייל״ את המערכת. אם הגענו למסקנה שיש לנו נטייה מוגזמת לאחד הכיוונים (הנדסת-יתר או הנדסת-חסר) – להעלות את זה למודעות ולדרוש מאנשים ״להטות לתיקון״. כמובן שיותר קל לומר את זה מאשר לעשות 🙂

שיהיה בהצלחה!