(עוד) מדמ"חיסט שמחפש לשנות כיוון

[InvestingNoob]

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

מבאס שאנשים בינתיים יושבים בבתים.

 

[משה]

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

מבאס שאנשים בינתיים יושבים בבתים.

הai של היום הוא לא הai שלפני שנתיים. הכלים מתפתחים ללא הפסקה והעלויות והיכולות משתנות.

 

[Ziggity]

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

 

[YPV]

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

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

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

 

[InvestingNoob]

ניסיתי לפתח מערכת מend to end , עשה הרבה טעויות. ניסיתי את זה עם 3 מודלים כולל חדשים.
הוא עושה ממש טעויות מוזרות מבחינת תפקוד המערכת כמכלול.
וזה לא שביקשתי ממנו מערכת מורכבת יותר מדי.

יש לו גם חסרון מאוד גדול בספריות שעדיין אין הרבה שימוש בהן.

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

 

[InvestingNoob]

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

איזה מנגנוני וריפקציה?
LLM אחר?

 

[mojo]

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

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

 

[vigaror]

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

אפשר לקבל תוצאה יותר דטרמיניסטית אם מקבעים את הגרסת מודל (GPT 5.6 יכול להיות alias לכמה גרסאות שונות, מי שניגש ישירות לAPI יכול לראות שהם מגדירים לפעמים את הגרסאות לפי תאריכים כמו gpt-5.4-mini-2026-03-17) ואת הseed ועוד כמה פרמטרים שדרך הUI הרגיל לא רואים אותם.
גם הגדרה של skill יכולה לעזור, ואני מניח שגם להעלות את הeffort למרות שאת זה לא ניסיתי

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

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

The new rules of context engineering for Claude 5 generation models | Claude by Anthropic

We removed over 80% of Claude Code's system prompt for more advanced models. How to apply the lessons we learned to your own context engineering in Claude Code and with your own agents.

claude.com

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

אני גם מרגיש שאני יכול לתת לו יותר עצמאות, יותר אחריות, הוא יותר "מגדיל ראש" ופחות צריך להחזיק לו את היד ביחס למודלים שהיו לי לפני שנה וקצת - עדיין בודק אותו *תמיד* (רק אתמול הייתה לו פשלה רצינית שתפסתי לפני שיצאה החוצה, בגרסת מודל הכי חדשה שלהם על xhigh והcontext windows אפילו לא הגיע לחצי),
גם הצורת שימוש היא מאוד אישית ומתפתחת עם הזמן כי הוא יוצר זיכרונות ומבין יותר טוב לעתיד איך הוא צריך לעשות משימות ואיך אתה אוהב לראות את התשובות, וגם המפתח מבין איפה מודלים האלו יותר חלשים ומנסה לפצות על זה (מחליף מודל, מחליף effort, יצירת skill שעוזרים להכווין אותו במשימות) ואז יוצא מודל חדש (פעם בחודשיים-שלוש?), טיפה יותר חזק ועם הגדרות שונות מאחורי הקלעים וצריך לחשוב אם יש פה צורך לעדכן את הזיכרונות\סקילים\אחריות (sonnet של היום לכאורה חזק כמו opus של פעם)

 

[InvestingNoob]

אני משתמש בקרסר.
מבחינת מודלים: סונט, אופוס, גימני והיורשים שלהם.

לא משתמש כרגע בסקילים (שלהבנתי זה פשוט פרומפטים שמורים)
Effort אני לא יודע מה זה.(אלא אם הכוונה היא על הרמה, מעדיף לא לשנות את זה וברוב המקרים משאיר בדיפולט - high)

משתמש בSDD עם חלוקה לחלקים קטנים: מממש חלק קטן, עושה ריוויו, ממשיך לחלק הבא.

 

[Ziggity]

איזה מנגנוני וריפקציה?
LLM אחר?

לא, כי גם LLM אחר הוא לא דטרמיניסטי, אם כי יש אנשים שמשתמשים בכלים כאלו לCode Review.

הדוגמא הכי בסיסית היא טסטים. אני עובד עם קודקס ויש לו הנחיה תמיד להריץ טסטים וכלים של ניתוח קוד (Type Checking, Linting, Formatting) בכל פעם שהוא עושה משהו. אם למשל יש באג, אני יכול להוסיף טסט שבודק שהבאג לא קורה ופשוט לתת לקודקס להסתכל על הלוגים בעצמו ולעבוד עד שכל הטסטים עוברים. איכות הקוד עלולה להיות נמוכה בסוף התהליך אבל לכל הפחות אדע שהבעיה תוקנה ושהוא כנראה לא דפק שום דבר אם הטסטים עברו, ואחר כך אפשר ללטש במידת הצורך.

 

[ינשוף חסכני]

הדוגמא הכי בסיסית היא טסטים. אני עובד עם קודקס ויש לו הנחיה תמיד להריץ טסטים וכלים של ניתוח קוד (Type Checking, Linting, Formatting) בכל פעם שהוא עושה משהו. אם למשל יש באג, אני יכול להוסיף טסט שבודק שהבאג לא קורה ופשוט לתת לקודקס להסתכל על הלוגים בעצמו ולעבוד עד שכל הטסטים עוברים. איכות הקוד עלולה להיות נמוכה בסוף התהליך אבל לכל הפחות אדע שהבעיה תוקנה ושהוא כנראה לא דפק שום דבר אם הטסטים עברו, ואחר כך אפשר ללטש במידת הצורך

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

 

[vigaror]

לא משתמש כרגע בסקילים (שלהבנתי זה פשוט פרומפטים שמורים)

זה סוג של פרומטים שמורים, אבל הם הרבה יותר מפורטים, מדוייקים, ספציפים. . .

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

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

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

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

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

מבחינת מודלים: סונט, אופוס, גימני והיורשים שלהם.

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

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

אני משתמש בקרסר.

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

Effort אני לא יודע מה זה.(אלא אם הכוונה היא על הרמה, מעדיף לא לשנות את זה וברוב המקרים משאיר בדיפולט - high)

זה הרמה, high זה סבבה

משתמש בSDD עם חלוקה לחלקים קטנים: מממש חלק קטן, עושה ריוויו, ממשיך לחלק הבא.

בהרבה משימות היום אני פחות מרגיש שיש צורך לפרק לחלקים קטנים, אפשר לתת לו את התמונה הגדולה יותר ומשימה גדולה\כמה משימות קשורות

 

[Ziggity]

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

שים לב שרשמתי שאני מוסיף את הטסט =]
Units הם לא חסרי חשיבות אבל קצת יותר משעממים זה נכון. אבל אני כותב את הטסטים שלי כExecutable Spec של איך המערכת אמורה להתנהג. ברמה של של סרוויס יחיד זו בעיקר לוגיקה, זה נכון. אבל בשביל זה יש גם Security Tests, Load Tests וכו' ברמת הCI CD Pipeline. וזה נכון שלבעיות הקשות יותר זה פחות מתאים, אבל זה היופי, שאייג'נטים יכולים לקצר דרמטית את הזמן שמושקע בפתרון הבאגים הטריוויאליים (כמות הפעמים שהלכו לי שעות על איזו שגיאת אינדנטציה מטופשת בפייתון) ומפנה את הזמן שלי להתעסק בבעיות המעניינות בקצה.

 

[איניגו מונטויה]

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

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

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

לא מצליח למצוא את זה כרגע,
אבל קראתי לאחרונה טור דעה (אולי בTheMarker?) שדיבר על זה שבבוקר מנכ"ל של חברת SaaS נפגש עם משקיעים ומסביר להם למה AI לא יכול להוות תחליף מוצלח למוצר שאנשים מפתחים כדי שיעמוד בדרישות scale ואחרות, ולוקחים עליו אחריות.
ובערב אותו מנכ"ל נפגש עם מנהלים בחברה ולוחץ לייעל תהליכים ע"י פיטורין של עובדים והחלפתם בתוצרי AI גם אם האיכות שלהם נמוכה והם פוגעים בטווח ארוך בארגון.