מהפיכת ה Agentic IDEs

קל מאוד להכריז על מהפיכות בעולם, אבל בעת הזו אני מניח שיהיה לי קל לשכנע ש 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 – אני חושב שזה זמן ללחוץ יותר חזק על הארגון להיפתח, או לשקול לגוון ארגון. אני מאמין שקורה פה אירוע בלתי-חוזר. משהו משתנה בעולם פיתוח התוכנה – לתמיד.

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