הבלוג של ינון פרק

זוכרים את כל אלה שמסבירים שאנחנו צריכים לתת לסוכן קידוד לכתוב 100% מהקוד או שאצלם סוכני קידוד כותבים 80% או 99% מהקוד? אז השאלה שהייתי רוצה לשאול אותם היא איזה קוד הם בכל זאת כותבים לבד בלי סוכן קידוד. מה זה האחוז הנותר או ה 20% הנותרים.

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

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

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

cleanStaleFiles()
cleanStaleFiles()

אולי הוא אפילו ייתן איזו הערה שמסבירה שהפונקציה מנקה עד 20 קבצים כל הפעלה ובעולם האמיתי היא מופעלת מ cron job ולכן זה לא בעיה אבל אנחנו פה בקוד של בדיקה ושם יכולים להיות גם 30 קבצים שצריכים ניקוי אז פעמיים מבטיחות לו שיימחקו עד 40 קבצים. ב Code Review של מאות שורות זה משהו שאני בקלות יכול לסלוח עליו.

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

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

נתתם לקלוד לבנות פיצ'ר, המימוש לא היה משהו, מחקתם את מה שהוא כתב עם git restore . && git clean -f -d והמשכתם הלאה בחיים.

סוף סיפור? לא בדיוק.

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

הזכרון של קלוד קוד מוסבר בדף התיעוד הזה:

https://code.claude.com/docs/en/memory

הרבה פעמים שווה להגדיר CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 ולוותר על יצירת הזכרונות תוך כדי תנועה ובמקום זה להסתמך על קבצי הוראות.

הזכרונות עצמם נשמרים בתיקיית ~/.claude/projects//memory/. תיקייה אחת למעלה תוכלו למצוא את כל השיחות הקודמות שעשיתם עם קלוד. מדי פעם מומלץ:

1. לכתוב /memory בתוך קלוד קוד, לבקש עריכה של קובץ הזכרון ולנקות אותו.

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

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

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

אבל מה שאנחנו רואים בקלות לגבי אנגלית קשה לנו לראות לגבי תכנות.

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

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

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

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

// Create workflow in account 1
$messageIds1 = $this->createSeriesMessages(2);
$template1 = $this->generateSeriesLogicJsonTemplate(2);
$result1 = $this->createSeriesAutomationWithMessages(
    $this->accountId,
    $this->listId,
    $template1,
    array_combine(range(0, count($messageIds1) - 1), $messageIds1)
);
$workflowId1 = $result1['workflowId'];

// Add subscribers to account 1
$subscriberIds1 = array_slice($this->subscriberIds, 0, 3);
$this->seedUserEnterList($this->listId, $subscriberIds1, $this->accountId);
$this->runAutomationHandler($this->accountId);

// Create second account
$this->secondAccount = $this->createSecondAccount(5);

// Create workflow in account 2
$messageIds2 = [];
for ($i = 0; $i < 2; $i++) {
    $messageIds2[] = $this->createMessageForAccount(
        $this->secondAccount['accountId'],
        $this->secondAccount['listId'],
        $this->secondAccount['senderId'],
        "Account2 Message " . ($i + 1),
        "Account2 Subject " . ($i + 1)
    );
}
// ... skip more code ...
$workflowId2 = $responseData2['createdId'];

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

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

ראיתי את המשפט הזה באיזו פרסומת:

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

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

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 פרומפטים שהוא כתב במהלך השבוע והתוצאות שהתקבלו (אפשר לשמור פרומפט בהודעת קומיט בגיט וככה קל להיזכר במלים המדויקות ובתוצאות). בפגישה עוברים על הפרומפטים, לומדים ממה שהצליח, מעלים רעיונות איך לשפר את מה שלא נתן תוצאות מספיק טובות ואפשר גם לנסות פרומפטים חלופיים ולראות מה מקבלים. פרומפטים טובים יותר יחסכו לכם הרבה יותר משעה בשבוע.

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