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

אחת ההטיות המבלבלות של המוח האנושי היא ההרגשה שאפשר לתקן באותה מהירות שמשהו התקלקל.

לוקח דקה למחוק בסיס נתונים. במקרה הטוב להחזיר אותו מהגיבוי ייקח חצי יום.

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

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

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

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

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

נושא שני שנדבר עליו יהיה כתיבת סוכנים והוא כולל וובינר על OpenAI Agents SDK, על ChatKit של OpenAI שמאפשר להטמיע סוכן באתר שלנו, על dspy ואיך הוא עוזר לנו לארגן פרומפטים בתוך תוכנית וגם נראה איך לכתוב שרת MCP לסוכנים שלנו.

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

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

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

https://www.tocode.co.il/talking_ai

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

זה היה הפרומפט:

plan the validation
extract the logic from <file:lines> and the validation in a
common concern so we can use it from the 3 relevant controllers (automation rules, advanced webhook and
macro)
verify frontend shows the correct proper error

שתי הפקודות האלה נראות דומות ועושות משהו דומה ואולי בגלל הדמיון בתחביר הן כל כך מבלבלות:

# 1. two dots diff
git diff dev..main

# 2. three dots diff
git diff dev...main

רואים את ההבדל? נכון זו רק נקודה.

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

1. פקודת diff עם שתי נקודות תראה לי את ההבדל בין המצב העדכני ביותר בענף dev למצב העדכני ביותר בענף main.

2. פקודת diff עם שלוש נקודות תראה לי את ההבדל בין המצב העדכני ביותר בענף dev לבין הקומיט ב main ממנו הוא יצא, כלומר בלי אותם קומיטים חדשים ב main שנכתבו אחרי שהתחלתי לכתוב את הפיצ'ר.

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

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

חיפוש agentic coding benchmarks בגוגל החזיר לי די הרבה תוצאות אז בואו נסקור את הראשונות:

1. אתר דירוג ראשון נקרא LiveBench. מדד זה כולל אוסף של בעיות קידוד בהן על הסוכן לכתוב קוד שפותר בעיה ויש קוד בדיקה אוטומטי שמוודא שהבעיה נפתרה. את הבעיות כתבו מומחים של LiveBench והם ממשיכים וכותבים בעיות חדשות כל הזמן כדי שכותבי המודלים לא יוכלו לרמות את המדד. אגב לסקרנים סוכן הקוד המוביל שם הוא GPT-5.2-Codex ובמדד Agentic Coding המוביל הוא אופוס 4.5 במאמץ בינוני.

2. דירוג נוסף שקופץ גבוה הוא SWE Bench והמדד המוביל שם נקרא SWE-bench Verified. מדד זה לוקח Github Repos שיש להם מערכת בדיקות אוטומטית עם Issues שנבחרו בקפידה ושם מבקשים מהסוכן לפתור את ה Issue בצורה שתגרום לבדיקה לעבור ולא תשבור בדיקות אחרות. גם כאן אף בן אדם לא מסתכל על הקוד שהמודלים מייצרים והדבר היחיד שנמדד זה כמה אחוז מהבעיות הסוכן הצליח לפתור. אופוס 4.5 במאמץ בינוני גם כאן מדורג ראשון.

3. דירוג שלישי שקופץ הוא Aider Polyglot. בדירוג זה נתנו למודלים מובילים לפתור בעיות תכנות תחרותי מאתר Exercism והדירוג מתבסס על אחוז הבעיות שהמודלים הצליחו לפתור.

מה משותף לכל ה-3? נכון, בני אדם לא קוראים את הקוד שנכתב, הדירוג מבוסס על ביצוע משימות סגורות (עובר או לא עובר) ולא על איכות הקוד וקוד שסוכן כותב לא מגיע להתמודד עם data אמיתי.

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

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

https://www.tocode.co.il/talking_ai

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

כשמשהו מובן מאליו זה אומר שהוא מובן ללא כל הסבר נוסף או ללא כל מאמץ נוסף. אי אפשר להתכחש למובנות שלו.

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

def print_fibonacci():
    first = 0
    second = 1
    count = 2  # We already have two elements: 0 and 1

    while count < 10:
        next_num = first + second
        sequence.append(next_num)
        first, second = second, next_num
        count += 1

    print(' '.join(map(str, sequence)))

מובן לגמרי ואפילו עם הערה שעוזרת להבין למה מתחילים מ-2 אבל דורש קריאה וקצת ריכוז.

והנה מינימקס פותר את אותה בעיה:

def print_fibonacci(count=10):
    a, b = 0, 1          # start with the first two numbers
    for _ in range(count):
        print(a, end=' ')
        a, b = b, a + b # move to the next pair
    print()              # final newline

גם הוא מעמיס הערות אבל הפעם ברור שאין בהן צורך. את התבנית:

a, b = b, a + b

מכיר כל מי שכתב פיבונאצ'י בפייתון.

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

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

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

במקום לחפש "איפה ה AI פספס" נחפש "איך הקוד החדש פותר את הבעיה"

במקום לחפש "מה ה AI לא ראה" נשאל "מאיפה התבנית הזאת הגיעה?"

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

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

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

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

1. Droid
2. Opencode
3. Kilocode
4. Aider
5. Cline
6. Roo Code
7. Claude Code

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

כבר היום אני לא בטוח שכדאי לאנשים ללמוד את החשיבות של HTML סמנטי, את ההבדלים בין section ל article ומתי להשתמש ב nav במקום ב div. אם זה חשוב אנחנו מצפים ש AI ישתמש בזה כשנבקש ממנו לכתוב HTML.

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

מה לגבי node.js ואקספרס? או ראסט? או Java?

מה שמיוחד ב HTML-ים וב Shell Scripts הוא שהממשק שלהם פשוט. אפשר להוסיף עוד מהם בלי להכיר את הקיימים. קובץ HTML גרוע יכול לשבור רק את עצמו. סקריפט גרוע ישבור רק את עצמו.

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

The other half compile but introduce subtle bugs because the model doesn't understand the actual design constraints of the project.

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

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

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

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

כשהקוד הופך זול מאוד אין צורך להבין תחביר. לא צריך לדעת לקרוא מבנה של List Comprehension בפייתון או מה ההבדל בין פונקציה אנונימית לפונקציית חץ ב JavaScript.

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

הנה רובי:

def create_connection
  Bunny.new(@connection_config[:url]).tap(&:start)
end

הפונקציה פותחת חיבור ל Rabbitmq ומחזירה את החיבור שנפתח. נתעלם רגע מהשאלה אם צריך פונקציה בשביל זה (אני חושב שלא), אבל השאלה היותר חשובה היא מה ה tap עושה שם? הנה הקוד בצורה הכי מפורשת שלו:

def create_connection
  conn = Bunny.new(@connection_config[:url])
  conn.start
  return conn
end

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

def create_connection
  Bunny.new(@connection_config[:url]).start
end

אז הפונקציה היתה מחזירה את מה ש start מחזירה ואולי זה משהו אחר ממה ש new מחזירה. פה המקום לשים לב לנטיה של AI לעבוד בתבניות - קלוד לא בדק מה start מחזירה. אם הוא היה בודק הוא היה רואה שהיא מחזירה בדיוק את אוביקט החיבור כי מי שכתב את Bunny כבר חשב על מנגנון הקריאה הזה. כלומר ה tap מיותר לגמרי שם.

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