ToCode

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

החלק השני נוגע לזמנים. דווקא בעבודה עם סוכני קידוד עיקר הזמן שאנחנו מבזבזים על פיצ'ר הולך על תיקון הפרומפט או תיקון הקוד שנוצר כי הסוכן לא הבין אותנו מספיק טוב. ככל שהתשתית של הפרויקט שלי טובה יותר אני מצמצם משמעותית את הזמנים האלה. עבודה על תשתית גוזלת המון זמן בהתחלה אבל הזמן הזה חוזר אליכם מהר מאוד ובריבית. רק תסתכלו על הפרויקטים שיש להם תשתית AI טובה ושימו לב למהירות בה הם מתקדמים. הם לא זזים יותר מהר כי הם יודעים לכתוב פרומפטים טובים יותר או כי הם קוראים קוד יותר מהר מכם, ההתקדמות המהירה שלהם היא תוצאה ישירה של תשתית פיתוח שמאפשרת לסוכן לבנות מימוש טוב גם כשהפרומפט לא מכסה כל פרט. שאלה: אם אתה כבר יודע איזה קוד הסוכן יבנה, בשביל מה להשתמש ב AI בכלל? פה אנחנו מגיעים לחיבור לקוד ולתהייה שחוזרת שוב לגבי הערך של אותו החיבור. "בשביל מה צריך להכיר כל שורה בקוד?", "מפתחים צריכים לבנות דברים מהר", "סוכני קידוד יודעים הכי טוב לקרוא את הקוד שהם כותבים", "בני אדם יתקדמו יותר מהר אם ידברו בשפה טבעית". אולי יום אחד זה יהיה אפשרי, אבל עם הטכנולוגיה שיש לנו היום הקוד הוא עדיין החלק המרכזי בכל פרומפט. סוכני קידוד אלופים בלכתוב קוד שעובד אבל בצורה מסובכת ועם טעויות הבנה משמעותיות ואני נתקל בזה כל הזמן במערכות שלי, בפרויקטים של לקוחות ובכתבות ברשת. סוכני קידוד יוצרים באגים, בעיות ביצועים ובעיות אבטחה הרבה יותר מהר מבני אדם. רק קריאת הקוד והבנה מלאה שלו מבטיחים שאנחנו מבינים מה בנינו, ובלי לדעת מה בנינו איך נוכל לדבר על זה ולקבל החלטות? שאלה: כמה שווה להשקיע היום בעבודה מול AI, לפני שמתייאשים ועוברים לכתוב לבד? שאלה מאוד חשובה שעלתה בוובינר והמחישה את הקושי של מפתחים עם שיטת העבודה מהפרסומת. השאלה בעצם אומרת שאם אני מנסה להסביר את עצמי ל AI והוא לא מבין אז אני נתקע, אני לא יודע למה הוא לא הבין ואיך לתקן את זה ועכשיו אני נכנס ללולאה, בכל איטרציה אני מנסה לגרום ל AI לשפר את הקוד ומקבל תוצאות בינוניות. התשובה כאן היא שהשקעה היא לא לנסות עוד ועוד פרומפטים. השקעה היא להבין מה קרה ולמה קרה מה שקרה. זה קצת קשה כלי סוכני הקידוד היום עושים הכל כדי להסתיר מאתנו מידע אבל עדיין אפשרי, לדוגמה בקרסר יש לי במסך השיחה עם הסוכן אפשרות ללחוץ על כל שורה כדי לקבל את הפירוט והפלט המלא של ה AI. שיטת העבודה על פרומפט שנכשל צריכה להיות: 1. לזהות מה רציתי שיקרה, מה הקוד שאני רוצה שה AI יבנה. אני לא בונה את הקוד הזה בעצמי אבל אני כן צריך לדעת בגדול איזה מחלקות ופונקציות ייכתבו, מה החתימה שלהן, מה כל פונקציה עושה, מה תהיה זרימת המידע, איזה מידע חדש צריך בבסיס הנתונים. כל זה אלה דברים שאני צריך לדעת לפני שבכלל כתבתי את הפרומפט הביצועי הראשון. 2. לזהות מה קרה שונה ממה שרציתי. אני חשבתי שה AI יוסיף עמודה ל DB בטבלה אחת והוא הוסיף את העמודה בטבלה אחרת. עכשיו אני עובר לקרוא לא רק את הקוד אלא ממש את השיחה עם ה AI ומחפש שם רמזים, ברגע שמצאתי אותם אני מתקן גם את הפרומפט, גם את הקוד ולפעמים גם את שכבת הבדיקות. 3. מוחק הכל, מדביק את הפרומפט המתוקן ומנסה שוב. בתהליך עבודה כזה אנחנו יודעים בדיוק מה עשינו, איפה שיפרנו ומרגישים את ההתקדמות בכל הרצה. לא רק שבתהליך כזה אנחנו לא מתייאשים אלא שאנחנו גם לומדים לפרומפטים הבאים ומכירים טוב יותר את הפרויקט. מסקנות ומחשבות קדימה סך הכל יצאתי מהוובינר עם טעם של עוד. אין לי ספק שאעביר וובינרים נוספים על מודל השכבות, על החשיבות של כל שכבה ועל תהליך העבודה האיטרטיבי בשיפור קריאות הפרויקט לכלי AI. כמה דוגמאות יותר ספציפיות שאני מתכנן להראות פעם הבאה שאעביר וובינר על נושא זה: 1. תיקון בשכבה הראשונה - עשינו היום, הייתי רוצה לדבר עליו בתוך מודל השכבות ולהתמקד בחלק בפיצ'ר שברור התיקון שלו בשכבה הראשונה. בדוגמה שראינו זה היה קומפוננטה לבחירת פוסט מהבלוג. 2. תיקון בשכבה השניה - ראינו היום איך סוכן הקידוד לפעמים יוצר בעיית ביצועים (N+1 Query) ולפעמים לא. ראינו איך להתמודד עם זה באמצעות תיקון בשכבה השלישית כלומר הוספת הוראה ב AGENTS.md אבל האמת שזה לא תיקון מספיק טוב ובחלק מהמקרים למרות שיש הוראה מפורשת לסוכן לשים לב לבעיות מסוג זה הוא עדיין מפספס. פעם הבאה אראה איך אני מתקין כלי אוטומטי לזיהוי בעיות ביצועים מסוג זה ומחייב את הסוכן להשתמש בו לפני שהוא מסיים לעבוד. 3. תיקון בשכבה השלישית - כשהפרומפט מבולבל סוכן הקידוד יתבלבל איתו. הייתי רוצה להראות איך לקרוא את הפלט של ה AI, להבין מהשיחה מה לא נכון בפרומפט ולתקן.

קוד ידידותי ל AI - הרהורים בעקבות הוובינר הי חברים, אתמול העברתי וובינר על פיתוח קוד ידידותי ל AI. היו המון שאלות מעניינות שעלו במהלך השיחה, לחלקן היו לי תשובות טובות בזמן אמת ועל חלקן עוד המשכתי לחשוב במהלך היום. אני מסכם פה את המסקנות המרכזיות מהשיחה. עקרון 1: שיפור הפיתוח בעזרת AI קורה בשכבות בוובינר דיברתי על ההבדל בין Prompt Engineering לשיפור הקוד כדי לקבל תוצאות טובות יותר מסוכני הקידוד. רק אחרי הוובינר הבנתי שבעצם יש פה מערכת יותר מורכבת של שכבות של מידע שמשפיעות על קצב הפיתוח ונכונות העבודה. בשכבה הנמוכה ביותר יש לנו את הקוד. כשהקוד כתוב כולו בקובץ אחד, משתמש ב APIs שכבר עברו מהעולם, תקוע עם גרסאות ישנות של ספריות וכולל בעיות אבטחה סוכן הקידוד ימשיך באותו קו. מה שיותר קשה לראות הוא שסוכני קידוד משתמשים במבנים שיש בקוד כדי לכתוב קוד חדש. אם בניתי קומפוננטה חדשה לקליטת מספר טלפון אז כל קוד חדש שסוכן הקידוד יבנה שצריך לקבל מספר טלפון ישתמש בקומפוננטה זו. אם בכל המערכת התקשורת בין השרת ללקוחות היא באמצעות Web Socket אז סוכן הקידוד ישתמש במנגנון הקיים ויוסיף הודעות לפרוטוקול. בוובינר הראיתי דוגמה לסוכן קידוד שמשתמש בקומפוננטת ברירת מחדל כדי לבחור פריט. בלי לשנות את הפרומפט הצלחנו לכתוב קומפוננטה ספציפית לבחירת פריט מהסוג הזה ואוטומטית סוכן הקידוד השתמש בקומפוננטה החדשה שבנינו רק כי היא היתה בקוד. מעל הקוד יש לנו שכבה של חיבור לעולם שמאפשרת לסוכן הקידוד להבין שיש בעיה בקוד. בשכבה הזאת אנחנו מוצאים Linters, בדיקות, כלים אוטומטיים למציאת בעיות אבטחה בקוד, כלי בדיקת ביצועים אוטומטיים. בוובינר הראיתי דוגמה של סוכן קידוד שמדי פעם יוצר בעיית ביצועים בטעות. לא היתה לי דרך טובה באמצעות שינוי קוד למנוע ממנו ליצור את בעיית הביצועים ומודל השכבות מסביר את זה - בעיית הביצועים הספציפית שהמודל יצר צריכה להיפתר דרך רכיב בשכבת הבדיקות שמוודא שהקוד לא כולל בעיות ביצועים נפוצות. שכבה שלישית היא הפרומפט, וכאן יש לנו גם את החוקים הכלליים של הפרויקט מהקובץ AGENTS.md, גם את הפרומפט עצמו שכתבנו וגם את האיטרציות וההרחבות עליו לדוגמה אם אנחנו ב Plan Mode אז התוכנית שהסוכן כתב. מודל השכבות מאפשר לראות שבעצם אנחנו לא מחפשים את הדרך האחת הנכונה או הכי טובה אלא על שילוב של רכיבים שיחד מייצרים פרויקט שיהיה קל ל AI לעבוד עליו. אומנם הוובינר התמקד בשכבת הקוד אבל בחיים אנחנו תמיד נבנה פתרונות ושיפורים בכל שלושת השכבות. שאלה: מהירות פיתוח לעומת תשתית שאלה שחזרה על עצמה הרבה בשיחה היום נגעה לקשר בין מהירות פיתוח לזמן פיתוח התשתיות. התהייה בגדול היתה "אם הסוכן יכול לבנות אינסוף קוד בכמה דקות בשביל מה לטרוח עם תשתיות? מקסימום שיכתוב יותר קוד במימוש כל פיצ'ר". גרסה אחרת של אותה תהייה היתה "אין לנו זמן לפתח תשתיות כי צריכים לבנות פיצ'רים מהר וממילא זמן העבודה על פיצ'ר בודד לא מתקצר אם בונים גם תשתית". התשובה כאן מתחלקת ל-2. תחילה נשים לב שאין פה בעיה חדשה. תמיד היה יותר קל לכתוב פיצ'ר מאשר לבנות תשתית והסיבה לבניית תשתית היתה היתרון במכפלות. כשיש לי תשתית טובה הפיצ'רים הבאים יהיו יותר יציבים ואני אוכל להכניס מפתחים חדשים יותר מהר לקוד. אותו דבר קורה עם סוכני קידוד, בדוגמה שהראיתי בוובינר דיברנו על קומפוננטה לבחירת פוסט מתוך רשימה ארוכה של פוסטים באתר. ראינו שאם נבנה את הקומפוננטה הזו בנפרד מהפיצ'ר אז סוכן הקידוד יהיה מספיק חכם כדי להשתמש בה אבל הפרדה כזו מאריכה את זמן הפיתוח של הפיצ'ר. הסיבה להפרדה היא המכפלות: אם סוכן הקידוד צריך לבנות 10 פיצ'רים עם אותה קומפוננטה והוא יממש אותה שוב ושוב יש סיכוי שב 2 מתוך הפיצ'רים הוא יממש את הקומפוננטה עם טעות קטנה. בניית הקומפוננטה פעם אחת אומרת שסוכנים יכולים להשתמש בה כמה שהם רוצים ואנחנו יכולים להיות בטוחים שהקוד נכון. בזכות בניית התשתית ה PR של הפיצ'ר קטן וכך קל יותר לקרוא כל שורה בו.

מה זה אומר "יודע לתכנת" ראיתי את המשפט הזה באיזו פרסומת: > בעולם שבו Copilot, Cursor ו-Claude Code כותבים קוד טוב יותר מרוב האנשים, > הכוח כבר לא אצל מי שיודע לתכנת אלא אצל מי שיודע איך לגרום ל-AI לפתח עבורו. שלחתי אותו ל ChatGPT כדי שיסביר מה זה אומר וקיבלתי את סט המיומנויות הבא שלטענת ChatGPT משקף את המיומנויות הכי קריטיות למתכנתים: 1. להבין מה הבעיה האמיתית (ולא מה שנכתב בטיקט) 2. לפרק רעיון עמום ל-spec חד ובר־בדיקה 3. לבחור פשרות נכונות: ביצועים מול פשטות, מהירות מול חוב טכני 4. לזהות מתי הפתרון “נראה עובד” אבל מסוכן בקנה מידה (הוא התכוון לכתוב פה Scale, אני לא בטוח שהתרגום "קנה מידה" מדויק בהקשר הזה) 5. ולחבר קוד למוצר, לביזנס, ולמשתמשים אמיתיים אני חותם על כל מילה פה, רק שימו לב מה אין בה - אין בה MCP, אין Tools, אין Context Engineer, אין Prompt Enginnering, אין Agent Skills, אין בחירת מודלים ואפילו לא איך עובד מודל שפה גדול. מסתבר שבעולם ה"חדש" הדברים שאנחנו צריכים בשביל לשרוד הם אותם הדברים שהיינו צריכים בעולם הישן. כשחברות כמו פייסבוק ואמזון מפטרות עובדים בכמויות, מקטינות צוותים ונשענות על מפתח בודד שישתמש בכלי AI כדי לעשות עבודה של עשרה אותו מפתח בודד לא יהיה זה שיודע להתקין MCP הכי טוב או לכתוב את הפרומפטים הכי מדויקים. כן תלמדו AI אבל שימו לב לאיזון. תשעים וחמישה אחוז מהכח שלכם כמפתחים מגיע מהמיומנויות שרשמתי למעלה. כשיש לכם את זה החלק של הפרומפטים בא לבד.

מימוש Add To Chat ב vim ככל שהכלים הופכים יותר מתוחכמים ככה אנחנו מגלים שנהיה יותר קל לעבוד עם הכלים הפשוטים. בכל מקרה שיטת העבודה הנוכחית שלי עם הכלים האלה היא שילוב של: 1. לתת לסוכן שליטה מלאה, מתחילים במצב תכנון, מדברים על התוכנית ועוברים לממש. אני עובר על הקוד עם git status ו git diff אחרי שהכל מומש והבדיקות עברו. 2. לקרוא בעצמי קוד ולשאול את הסוכן שאלות קטנות או לתת לו לבנות קטעי קוד קטנים. 3. לפתוח דפדפן להצביע על דברים על המסך ולשאול את הסוכן איפה הקוד שמגדיר אותם. כשחשבתי על חיבור AI ל vim התחלתי בחיפוש תוסף שיאפשר לי לסמן קטעי קוד ולשאול עליהם שאלות. מצאתי אחד שנקרא CopilotChat אבל מאוד לא נהניתי ממנו. ואז הבנתי שבעצם סוכן שורת פקודה יכול להשתלב מצוין בתהליך העבודה. זה עובד ככה: 1. מתוך neovim פותחים split, בצד אחד מפעילים terminal ובצד השני הקוד. 2. בתוך ה terminal מפעילים את קלוד קוד או קופיילוט או קודקס. הממשק של הסוכן כבר כולל מנגנון לבחירת קבצים אם לוחצים @ מתוך הפרומפט אבל גם לקרסר וגם ל VS Code יש עוד כפתור בו אני משתמש המון שנקרא Add To Chat, כלומר מסמנים קוד בעורך לוחצים Add To Chat וזה מוסיף את קטע הקוד לשיחה עם הסוכן. מסתבר שבכלל לא מסובך לממש את זה ב neovim. זה הקוד שרשמתי בתוך init.vim:

lua << EOF

-- Define the function globally (or locally if you prefer)
function SendContextToTerminal()
    -- 1. Get the current buffer info and selection marks
    -- Note: When triggered via ":" command from visual mode, visual mode exits
    -- automatically, populating the '< and '> marks.
    local filepath = vim.fn.expand('%:.') -- Relative path to CWD
    local start_line = vim.fn.line("'<")
    local end_line = vim.fn.line("'>")

    -- Format: path/to/file:40-59
    local context_string = string.format("%s:%d-%d ", filepath, start_line, end_line)

    -- 2. Find the terminal split
    local term_chan = nil
    local term_win = nil

    -- Iterate over all open windows to find a terminal
    for _, win in ipairs(vim.api.nvim_list_wins()) do
        local buf = vim.api.nvim_win_get_buf(win)
        if vim.bo[buf].buftype == 'terminal' then
            term_chan = vim.bo[buf].channel
            term_win = win
            break
        end
    end

    if not term_chan then
        vim.notify("No terminal split found.", vim.log.levels.WARN)
        return
    end

    -- 3. Send text to the terminal
    vim.api.nvim_chan_send(term_chan, context_string)

    -- 4. Switch to terminal window and enter Insert mode
    vim.api.nvim_set_current_win(term_win)
    vim.cmd('startinsert')
end

-- Create a user command so you can type :SendContext
vim.api.nvim_create_user_command('SendContext', SendContextToTerminal, {})

-- Set a keybinding for Visual Mode
-- We use :<C-u> to clear the range usually inserted by visual mode, 
-- then call the lua function. The : command naturally exits visual mode, setting the marks.
vim.keymap.set("v", "<leader>ai", ":<C-u>lua SendContextToTerminal()<CR>", { silent = true, desc = "Send selection context to terminal" })

EOF

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

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

username = input("הכנס את שמך: ")
print(f"ברוך הבא, {username}!")

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

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

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

def text_summary_button?
  @session.text_summary.present?
end

def text_summary_label
  I18n.t("talking_ai.download_summary")
end

def text_summary_url
  talkingai_summary_path(@session)
end

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

* ToCode Platform - Online Courses and Personal Website of Ynon Perek *
This is a Ruby on Rails project that handles the personal website of Ynon Perek, provides a blog, online courses sold through the platform and weekly webinars.

* How to parse instructions *
When reading a feature request:
1. Read \schema.rb\ to understand the different models relevant to the feature
2. Is this request the best way to approach the issue? 
3. What are the most probably next changes user is about to make? can you solve a more general problem that will also solve this request and help us in the future?
4. Push back, challenge the user and ask relevant questions on every feature request
5. When instructions create new database entities or connection explain the entity and connection and list sample data.


* Coding Standards and approaches *

1. Don't put logic in the views, only in models.

2. You can use Rails patterns and best practices when relevant, for example service objects, presenter objects.

3. When selecting data prefer JOIN with relevant columns over include. Avoid N+1 queries.

* Performance *

Performance and page load time is critical. After every change review to check for N+1 query problems and possible JOIN optimisations. Count the number of queries in the diff to verify each query added is justified.

* Backward Compatibility vs. Simplicity *
We prefer simple code over backward compatibility. When adding new features don't hesitate to remove previous implementations and do not implement code to handle "both" new and old behavior.

תוצאה: 1. מסך הניהול הסתדר - עכשיו הסוכן השתמש בקומפוננטת בחירת הפוסטים לפי ההוראות במקום בקומפוננטת select גנרית. 2. הסוכן זיהה ותיקן את בעיית השאילתות המיותרות באמצעות שליפת כל הפוסטים בשאילתה אחת מרוכזת. 3. למרות שרציתי שהסוכן ירחיב את ה Presenter לסוכן היו תוכניות אחרות והוא פשוט שינה את הפונקציה שמחזירה את ה url:

   def text_summary_url
-    talkingai_summary_path(@session)
+    if @session.blog_post.present?
+      blog_path(@session.blog_post)
+    else
+      talkingai_summary_path(@session)
+    end
   end

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

so the blog post is the text summary.

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

module TalkingAi
  class DownloadSummariesController < ApplicationController
    def show
      session = TalkingaiSession.with_downloadable_markdown.find(params[:id])

      markdown, filename = session.prepare_download_markdown
      send_data markdown,
                filename:,
                type: 'text/markdown; charset=utf-8',
                disposition: 'attachment'
    end
  end
end

5. הקוד שנוצר ב view יצא מסורבל וכלל יותר לוגיקה ממה שאני אוהב לכתוב בקבצי view ובאג ביצועים שנקרא N+1 Queries:

<% if session.has_text_summary? %>
  <% text_summary_url = session.blog_post.present? ? blog_path(session.blog_post) : talkingai_summary_path(session) %>
  <a href="<%= text_summary_url %>" class="inline-flex items-center px-3 py-2 bg-blue-600 text-white rounded-lg hover:opacity-90" data-turbo="false" title="<%= t('talking_ai.download_summary') %>"<%= ' target="_blank" rel="noopener noreferrer"' if session.blog_post.present? %>>

בעיית הביצועים כאן נובעת מהפקודה:

blog_path(sesison.blog_post)

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

  # ToCode Platform - Online Courses and Personal Website of Ynon Perek
  This is a Ruby on Rails project that handles the personal website of Ynon Perek, provides a blog, online courses sold through the platform and weekly webinars.
  
  ## How to parse instructions
  When reading a feature request:
  1. Read \schema.rb\ to understand the different models relevant to the feature
  2. Is this request the best way to approach the issue? 
  3. What are the most probably next changes user is about to make? can you solve a more general problem that will also solve this request and help us in the future?
  4. Push back, challenge the user and ask relevant questions on every feature request
  
  ## Coding Standards and approaches
  1. Backward compatibility is not that important, simple and beautiful code is. Don't leave behind dead code.
  
  2. Don't put logic in the views, only in models.
  
  3. You can use Rails patterns and best practices when relevant, for example service objects, presenter objects.
  
  4. When selecting data prefer JOIN with relevant columns over include. Avoid N+1 queries.

הגרסה מנסה לתת מענה לבעיות המרכזיות בקוד: היא מבקשת מהסוכן לחשוב על ביצועים וכמות השאילתות, על כמות הלוגיקה בקוד ה view ועל תאימות לאחור והקוד המיותר שנכתב רק בשביל להתמודד עם משתמשים שאולי יצרו סימניה מקישור הורדת ה Markdown. התוצאה: 1. מסך ה admin עדיין מראה תיבת select. זה הגיוני, לא התיחסנו לנושא הזה בקובץ ההוראות. 2. הסוכן החליט להוציא לוגיקה מה view ולכן כתב פונקציה חדשה בשם text_summary_url במודל:

def text_summary_url
  return blog_path(blog_post) if blog_post.present?
  return talkingai_summary_path(self) if text_summary.present?
  nil
end

זה רעיון יפה! הבעיה שעכשיו ה view יצא יותר גרוע:

<% if session.has_text_summary? %>
  <a href="<%= session.text_summary_url %>" class="inline-flex items-center px-3 py-2 bg-blue-600 text-white rounded-lg hover:opacity-90" data-turbo="false" title="<%= t('talking_ai.text_summary') %>">
    <%= t('talking_ai.text_summary') %>

הקוד הזה יותר גרוע מהגרסה הקודמת כי עדיין יש פה את בעיית השאילתות המיותרות אבל קשה יותר לראות אותה כי השאילתות עברו למודל. 3. תאימות אחורה עדיין ממומשת ושוב אנשים שנכנסים לקישור להורדת קובץ Markdown יקבלו קישור לפוסט אם קישור כזה מוגדר. 4. הסוכן החליט שכל פוסט יכול להיות מקושר רק בתור סיכום של וובינר אחד, למרות שבעולם האמיתי אפשר לדמיין שארצה להעביר כמה מפגשים על אותו נושא עם אותו פוסט סיכום. זאת החלטה שהסוכן עשה על דעת עצמו ולא מופיעה בפרומפט. 5. הסוכן שינה את הטקסט גם למצב "הורדת סיכום" וגם למצב "קישור לסיכום" למשפט "קישור לסיכום טקסט". נסיון שלישי הצעד הבא היה לבנות תשתיות בקוד שיעזרו לסוכן לקבל החלטות טובות יותר: 1. יצרתי קומפוננטה שנקראת BlogPostSelector עם תיעוד שמסביר איך להשתמש בה ממסך הניהול כדי להוסיף שדה לבחירת פוסט.

מתכנתים בעידן ה AI לעומת מפעילי AI דרך דוגמת קוד משקרים לנו. בפרסומות, ברשתות החברתיות, באתרי החדשות ואפילו בעיתון, כולם מדברים על סוכני הקידוד ושילובם בעולם הפיתוח אבל מספרים רק חצי מהסיפור. כשאמג'ד מסד מנכ"ל רפליט מספר שעוד רגע סוכני קידוד יכתבו אפליקציות הוא לא מתכוון שסוכני קידוד יכתבו את רפליט. הוא יודע כמה עבודה ומחשבה הושקעה בקוד של רפליט כדי שסוכן הקידוד שלהם יוכל להגיע לתוצאות טובות בבניית מערכות. מה שהוא היה צריך לספר זה שהמפתחים שהיום כותבים תוכנה יתחלקו לשני תפקידים בעולם ה AI העתידני: יהיו מפעילי AI שיכתבו פרומפטים כדי לייצר קוד ואולי קצת יתקנו את הקוד שיוצא, ויהיו מפתחי תשתיות שיבצעו שינויים מבניים בקוד המערכות כדי שסוכני ה AI יוכלו להמשיך להיות פרודוקטיביים. בפוסט הדוגמה הזה ובוובינר שאעביר עליו ביום חמישי אדבר על החיים של מתכנתים בעידן ה AI. על המשמעות של חשיבה מערכתית, של שינויי קוד שמאפשרים ל AI לעבוד ואיך לפתור בעיות בתוצרי AI לפני שהן קורות באמצעות הבנה מעמיקה של עולם התוכן. המצאת הצנרת הביאה לעולם אינסטלטורים שפותחים סתימות ומהנדסים שקובעים את השיפועים כדי שהסתימות לא יווצרו מראש. אנחנו המהנדסים. צורת החשיבה של מהנדסי AI המהנדסים לא עובדים ברמת הפרומפט. כשמאור שלמה כתב את base44 הוא הבין שהמשתמשים שלו יכולים לכתוב כל פרומפט שירצו. המערכת צריכה להצליח לייצר קוד עובד מכל דרישה של משתמשים. כשאנחנו לוקחים גישה של מהנדסי AI אנחנו נתבונן בפרויקט ובפרומפט ספציפי: 1. נפעיל את הפרומפט וניתן ל AI לבנות מה שיבנה. 2. אם התוצאה לא מספיק טובה במקום לתקן את הפרומפט נלך לתקן את הפרויקט: נוסיף הערות, קבצי הוראות לסוכן, נשנה שמות של פונקציות, נזיז קוד ממקום למקום, ניצור קוד גנרי או נפרק היררכיות ירושה. 3. נחזור על השינויים באיטרציה עד שנקבל מערכת שיודעת לבנות תוצאה מדויקת לפרומפט שהעברנו. האתגר כמו בכל פיתוח תוכנה הוא לבנות את המערכת בלי לשבור את הדברים הטובים שכתבנו לפרומפטים קודמים ולהמשיך לשפר ולנקות את הקוד תוך כדי תנועה. דוגמה: חיבור פוסטים מהבלוג בתור סיכומים לוובינר אני רוצה להראות את ההבדל בין מהנדס AI למפעיל AI דרך מימוש פיצ'ר פה לאתר - אפשרות להגדרת פוסט מהבלוג בתור סיכום של וובינר. כרגע בדף הוובינרים באתר יש רשימה של וובינרים קודמים שעשינו ולכל וובינר יש אפשרות לחבר קישור לוידאו לסיכום הוובינר או לקובץ סיכום בפורמט Markdown. אלה שני הפורמטים המרכזיים בהם הפצתי סיכומים עד לא מזמן. בשבועות האחרונים התחלתי לכתוב לכל וובינר פוסט מסודר עם הדוגמה של הוובינר וכל ההסברים. לפעמים זה היה אחרי הוובינר לטובת אנשים שפספסו והרבה פעמים, כמו הפוסט הזה, אלה פוסטים שאני כותב לפני הוובינר כדי שאנשים יוכלו לקרוא ולבוא מוכנים. ועכשיו צריך להוסיף קישור מוובינר בדף הוובינרים הקודמים לפוסט הסיכום שלו. בלי לחשוב יותר מדי כתבתי את הפרומפט הבא ונתתי ל AI לרוץ עם הפיתוח:

Add blog post as summary feature

In talking_ai page we can see previous webinars. Each previous webinar
can have a link to video summary and/or fulltext markdown summary

Modify the app and add a way to connect a previous webinar to a blog
post, so the blog post is the text summary.
A connected webinar will have a the "Text Summary" link lead to that
blog post

הפרומפט הזה לא טוב ובסוף הפוסט אסביר למה ונתקן אותו, אבל לפני שניגש לשם בואו נראה כמה רחוק אפשר להגיע בלי לשנות את הפרומפט כלל. נסיון ראשון סוכני קידוד יודעים לכתוב קוד על זה אין ויכוח והסוכן באמת מימש את הפיצ'ר אבל בגלל היעדר תשתית הוא היה מאוד רגיש לטעויות שהיו בפרומפט. המימוש כלל את הבעיות הבאות: 1. במסך הניהול של המערכת בדף עריכת פרטי וובינר נוספה תיבת Select ממנה אפשר לבחור פוסט מהבלוג שיתאים לוובינר. זה רעיון יפה הבעיה שאני כותב יותר מדי ותיבת Select היא לא הממשק הטוב ביותר כדי לבחור פוסט. 2. הסוכן החליט לשנות את הטקסט של התיבה לצירוף קובץ סיכום בפורמט Markdown בלי שביקשתי. 3. הסוכן מימש "תאימות אחורה" בנתיב הורדת ה Markdown, כלומר אם מישהו לוחץ "הורדת קובץ סיכום ב Markdown" לוובינר שמוגדר לו סיכום בתור פוסט הוא יופנה לפוסט הסיכום ולא יקבל את קובץ ה Markdown. 4. הסוכן הגדיר תלות בין פוסטים למפגשי וובינרים כך שאם יש מפגש וובינר שמחובר לו פוסט סיכום ואני מוחק את הפוסט אז תתאפס הגדרת פוסט הסיכום. זה לא רע פשוט לא משהו שביקשתי.

איך אתם מתקשרים עם ה AI אנתרופיק פרסמו מחקר חשוב על איך אנחנו מתקשרים עם סוכני קידוד ואיך האינטרקציה משפיעה על רמת המיומנות של מפתחים. בניסוי הם נתנו למפתחים לבנות משהו עם ספריית פייתון ואז בחנו כמה אנשים מצליחים לענות על שאלות על הקוד שהם הרגע כתבו. הם מיפו 6 סוגי אינטרקציות עם AI: 1. נותנים ל AI לעשות את העבודה - מפתחים קיבלו משימה, ביקשו מה AI שיפתור והמשיכו הלאה. 2. מתחילים בבירור פרטים ואז מעבירים ל AI את המושכות. 3. מתחילים לבד ונותנים ל AI לדבג ולתקן את הטעויות שהם עשו. 4. נותנים ל AI לכתוב בחלון נפרד, מעתיקים לתוך סביבת הפיתוח בעצמם ואחרי שהקוד עובד ממשיכים שיחה עם ה AI כדי להבין מה קורה בקוד. 5. נותנים ל AI ליצור קוד ולהסביר כל צעד מה הוא עושה. לפי ההסברים המשיכו את השיחה וייצור הקוד. 6. שואלים את ה AI שאלות הבנה והולכים לכתוב לבד. כשנתקעים אפשר לחזור ל AI לעוד שאלות הבנה ועם הידע החדש פותרים בעיות. לא מפתיע לגלות שמפתחים משלושת הקבוצות האחרונות למדו הרבה יותר במהלך העבודה ממפתחים משלושת הקבוצות הראשונות. גם לא מפתיע שמפתחים מהקבוצה הראשונה סיימו הכי מהר את המשימה אבל הבינו ממנה הכי מעט. מה שאותי הפתיע הוא שהקבוצה במקום השני הכי מהיר היתה האחרונה, כלומר אנשים שהתעקשו להשתמש ב AI רק כדי להבין ואת הקוד לכתוב בעצמם. ובאיזה קבוצה אתם?

הרבה פעמים אנחנו יודעים על העולם ועל הלקוחות שלנו יותר ממה שקרסר יודע. אצלנו במערכת אחרי כל שעור יש תרגול, אצלנו במערכת כשלקוח מבטל תור שקבע מראש הוא יקבל את הכסף חזרה רק אם ביטל 48 שעות לפני התור, אצלנו במערכת אזור הזמן הוא ישראל. הידע הזה מאפשר לנו ולסוכני הקידוד לכתוב קוד ממוקד יותר, כמובן בהנחה שסוכני הקידוד גם יוכלו לגשת לכל הידע הרלוונטי. כשאנחנו מזהים שסוכן קידוד לא יצר קוד נכון כי הוא פספס הנחת עבודה או שיטת עבודה שאנחנו לוקחים כמובן מאליו נרצה להוסיף את הנחת העבודה הזאת לפרומפט. נגדיר בפרויקט קובץ AGENTS.md ונכתוב בו את כל הנחות העבודה האלה על העולם שאנחנו יודעים ומצפים שהסוכן גם יכיר בעת כתיבת הקוד. חיבור למידע רלוונטי חלק מהנחות העבודה שלכם מבוססות על מידע שנמצא ברשת או בבסיסי נתונים. במיוחד בתיקונים אבל גם בשינויים חשוב לתת לקרסר גישה למקורות מידע אלה: 1. חברו את קרסר לבסיס הנתונים באמצעות MCP ותנו לו אפשרות לקרוא נתונים רלוונטים. אם אי אפשר להתחבר לבסיס הנתונים האמיתי צרו אצלכם בסיס נתונים דמה עם נתונים דומים לפרודקשן. 2. חברו את קרסר לשירותי רשת מהם אתם מושכים מידע. 3. אם יש פעולות שאתם יודעים לעשות באמצעות סקריפטים, הגדירו Skills כדי לאפשר לקרסר להפעיל סקריפטים אלה בעצמו. 4. חברו את קרסר לדפדפן כדי שיוכל "להשתמש" במערכת שלכם ולגלות דברים חדשים. בדיקת העבודה של הסוכן אחרי שסוכן מסיים לעשות את העבודה חשוב לאפשר לו לבדוק את התוצאות: 1. הגדירו סט בדיקות אוטומטיות שסוכן קידוד יכול להריץ ולהבין בזמן סביר אם הקוד שהוא כתב נכון ולא שובר דברים קיימים. 2. חברו את הסוכן לדפדפן כדי שהוא יוכל ממש להשתמש במערכת ולראות מה עובד. הדבר החשוב הוא להסתכל על החיבור לסוכן קידוד בתור תהליך. זה לא "להתקין ולראות מה עובד" אלא יותר להתקין, לראות איך הסוכן מתנהג עם הקוד שלכם ואז בתהליך איטרטיבי לשפר את הקוד ואת החיבור לסוכן כדי לקבל תוצאות יותר ויותר טובות. סוכני קידוד היום מאוד טובים בלהבין הוראות ובלכתוב קוד שמתאים לכללים. הם עדיין צריכים אותנו כדי שנגדיר את ההוראות והכללים.

מה זה אומר קוד ידידותי ל AI חבר שואל - "נתתי לקרסר לסדר דברים בפרויקט שלי והוא לא הצליח לעשות כלום. איך כולם מתלהבים מה AI הזה כשאצלי בקוד הוא כמעט חסר ערך?" זו שאלה מצוינת שנוגעת באופן שבו סוכני קידוד עובדים ובשיטת העבודה שעלינו לאמץ בעבודה איתם. כשאנחנו מגייסים מתכנתים אנושיים אנחנו מחפשים לגייס את הבן אדם הכי מוכשר שנוכל למצוא, הכי יצירתי, שהכי יצליח להסתדר בכל מקום. סוכני AI לא עובדים ככה, אי אפשר לחפש את "המודל הכי טוב" ולדמיין שהמודל הכי טוב יצליח לעבוד בכל סביבה. הביצועים של סוכני קידוד מאוד מושפעים מאיכות הקוד שלכם ומסביבת העבודה בה הם יכולים לעבוד. הנה כמה נקודות שכדאי לשפר כשרוצים לקבל ביצועים טובים יותר מסוכני קידוד: איתור קוד רלוונטי הפעילו את קרסר (או קלוד קוד, או קופיילוט, או לא משנה מה), בקשו שיעשה משהו ואז הסתכלו איזה קבצים הוא קורא בשביל להצליח לבצע את הפעולה או לענות על השאלה שלכם. שאלו את עצמכם - האם ה AI בכלל מסתכל במקום הנכון? אם ה AI לא מצליח למצוא את הקבצים בהם נדרש השינוי ברור שאין לו סיכוי להבין את הבעיה ולבצע את התיקון או השינוי שלכם. הנה כמה דברים שכדאי לעשות כדי לעזור ל AI למצוא את הקבצים הנכונים: 1. ציינו את הקבצים בפרומפט (כן אני יודע, הייתם רוצים שזה יקרה לבד, אבל צריך להתחיל עם משהו). 2. כתבו קובץ אינדקס שמסביר איזה קבצים רלוונטים לכל משימה. הוסיפו את קובץ האינדקס הזה לפרומפט (ידנית או בצורה אוטומטית באמצעות Rule בקרסר). 3. אם ה AI מצליח למצוא נקודת התחלה טובה אבל לא מצליח להמשיך ממנה לקבצים אחרים שרלוונטים לאותו שינוי עדכנו את הקוד והפכו את התלות למפורשת, או על ידי מחיקת אבסטרקציות או על ידי הוספת הערות. 4. אם ה AI טוען קבצים שנראים נכונים אבל הם לא, למשל כי יש שני קבצי CSS למערכת אחד ישן ואחד חדש וה AI מוצא את הישן שכבר לא נמצא בשימוש - מחקו את הקובץ הישן שכבר לא בשימוש. 5. אם ה AI לא מוצא את קבצי המקור כי אתם משתמשים בספריית צד שלישי שנמצאת בתיקייה אחרת ומועתקת לפרויקט רק בזמן הבניה אז העתיקו את הגדרות הספריה גם לזמן הפיתוח. כמה קל לעשות את השינוי אחרי שהגענו לקוד הרלוונטי נרצה לשאול כמה קל לעשות את השינוי שאנחנו מצפים שה AI יעשה. אם יש לי קובץ CSS שמגדיר שמרחק בין שני כפתורים הוא 10 פיקסלים ואני מבקש לשנות את המרחק הזה ל 20 פיקסלים יהיה ל AI מאוד קל לעשות את השינוי. אם קובץ ה CSS מגדיר את כל הגדלים בפיקסלים ואני צריך שהאתר יהיה ריספוסיבי זה כבר שינוי שיהיה ל AI הרבה יותר קשה. נזכור שסוכני קידוד שואפים לשנות כמה שפחות קוד ולשמר כמה שיותר את ההתנהגות הקיימת. בחירה זו משפיעה בצורה מפתיעה לרעה על הביצועים לדוגמה אם יש לי שני אלמנטים בעמוד שיש להם את אותו קלאס ועכשיו צריך שינוי בעיצוב הרבה יותר סביר שסוכן הקידוד יעשה את השינוי בעיצוב בשני האלמנטים כי הוא ישנה את העיצוב בקלאס ולא ישים לב שזה משפיע על מספר אלמנטים. כשמדובר בקוד צד שרת לסוכן יש את אותן הטיות: יהיה לו הרבה יותר קל לקרוא לפונקציה קיימת בפרויקט מאשר לכתוב מימוש משלו, יהיה לו יותר קל לשכפל פונקציה מאשר להוסיף פרמטר או לשנות התנהגות של פונקציה קיימת, יהיה לו הרבה יותר קל לשנות לוגיקה מאשר לשנות ארכיטקטורה, והוא ישנה ארכיטקטורה לפני שהוא ישנה מבנה טבלאות בבסיס הנתונים. בשביל לקבל תוצאות יותר טובות מסוכני קידוד עלינו לנטר את התהליך ולשפר אותו: 1. נשים לב מה הפרומפט שאנחנו או החברים לצוות כותבים. 2. נשים לב איזה קטעי קוד הקרסר צירף לפרומפט. 3. נשים לב מה התיקון או השינוי שקרסר מציע ונשווה לאופן בו אנחנו היינו מבצעים את השינוי או התיקון. כשיש הבדל בין התיקון שקרסר מציע לתיקון שמתכנתים היו רוצים לעשות נשחק עם המנגנון כדי לקבל מקרסר את הפתרון שאנחנו רוצים ואז "נקבע" את מה שלמדנו, לדוגמה: 1. אם גילינו שפרומפט אחר גורם לקרסר לעשות את השינוי טוב יותר נוכל להוסיף Rule שיצורף אוטומטית לכל פרומפט. 2. אם גילינו שמבנה מחלקות אחר בקוד גורם לקרסר לעשות את השינוי כמו שרצינו נוכל לסדר את הקוד, למשל לצמצם שרשראות ירושות ארוכות, לכתוב דברים בצורה יותר מפורשת, לסדר שמות של פונקציות ומשתנים, להוסיף עמודות לבסיס הנתונים. 3. אם גילינו שאזכור קבצי קוד מסוימים בפרומפט גורם לקרסר לכתוב פתרון טוב יותר ננסה להפוך את קטעי הקוד האלה ליותר נגישים, או על ידי יצירת קבצי תיעוד מתאימים או באמצעות הפניות בקוד. הכנסת הנחות עבודה רלוונטיות