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

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

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

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

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

ועכשיו תנסו קצת Use Cases:

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

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

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

4. סוכן שיושב לבד על הלינקדאין ואוסף לידים (ובאמת מביא לידים איכותיים שממירים ללקוחות).

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

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

אצלנו 100% מהקוד נכתב על ידי AI, אבל-

1. יש בן אדם שקורא כל שורה, מנסה להבין וכל הזמן צריך לתקן.

2. יש בן אדם שצריך לשחק עם המערכת לייב כדי לראות ששום דבר לא נשבר אחרי כל שינוי.

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

4. בעיקרון AI כותב את כל הקוד אבל חייבים לתת לו הוראות מאוד מדויקות אחרת הוא כותב שטויות.

5. ברור ש AI חוסך לי המון זמן אבל כל הזמן הזה הולך על לקרוא ולהבין מה הוא עשה שם.

6. רגע לא לסגור את המסך של הלפטופ ה AI כותב שם קוד!

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

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

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

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

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

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

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

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

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

1. ביקשתי מ AI משהו
2. התוצאה לא היתה טובה
3. שיניתי את הפרומפט למשהו יותר ספציפי
4. קיבלתי תוצאה טובה יותר

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

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

https://gist.github.com/ynonp/62e0ac7eab67033bbbb14a8ed149d47d

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

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

פרומפט ראשון בפייתון:

create a python function that takes a CSV file path with customer data (assume email column) and returns a list of the customers as list of dictionaries deduplicated by email

והמימוש:

import csv


def load_customers(csv_path):
    customers = []
    seen_emails = set()

    with open(csv_path, mode="r", newline="", encoding="utf-8") as file:
        reader = csv.DictReader(file)

        if "email" not in reader.fieldnames:
            raise ValueError("CSV must contain an 'email' column")

        for row in reader:
            # Normalize email so casing/whitespace doesn't create duplicates
            email = row["email"].strip().lower()

            if email not in seen_emails:
                seen_emails.add(email)
                row["email"] = email
                customers.append(dict(row))

    return customers

כמה דברים בולטים:

1. אין טיפול ב BOM, שהוא תו נסתר בתחילת הקובץ שמציין את סדר הבתים. בלי טיפול זה אם עמודת email היא הראשונה אנחנו עלולים לקבל את הטקסט \uFEFFemail בתור שם העמודה במקום רק email וכך ההשוואה תכשל.

2. ערך email חסר בשורה מסוימת מפעיל strip על None, נכשל ומרסק את כל הפונקציה במקום לדלג על הערך החסר.

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

4. אין וולידציה או אורך מינימלי על כתובת מייל כך שעמודת email ריקה גורמת לשמירה של הנמען.

עכשיו אני מנסה פרומפט כמעט זהה, רק מחליף את השפה:

create a ruby function that takes a CSV file path with customer data (assume email column) and returns a list of the customers as list of dictionaries deduplicated by email

התוצאה:

require "csv"

def load_customers(csv_path)
  customers_by_email = {}

  CSV.foreach(csv_path, headers: true) do |row|
    customer = row.to_h
    email = customer["email"]&.strip&.downcase

    next if email.nil? || email.empty?

    # Keep the first customer found for each email
    customers_by_email[email] ||= customer
  end

  customers_by_email.values
end

כמה מאפיינים בולטים:

1. גם כאן אין טיפול ב BOM.

2. השימוש ב &. אומר שערכים חסרים לא מרסקים את הפונקציה.

3. המימוש ברובי מדלג על ערכים ריקים.

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

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

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

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

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

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

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

וגם פה AI יכול לעזור.

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

היום בוובינר דיברנו על Claude Managed Agents וראינו הדגמה של הקוד ואיך ליצור את ההדגמה הזו אצלכם. אלה עיקרי הדברים שהיו שם.

אי אפשר לתקן בעיה שלא רואים.

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

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

כלי Linter שרץ על הקוד ומוודא שהקוד כתוב לפי סטנדרט הוא התחלה.

סורק חולשות אבטחה שמוודא שהקוד לא כולל בעיות אבטחה ברורות יעזור לסוכן לראות את סעיף האבטחה.

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

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

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

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

"שמנו לב שהסוכן שלך לא מנצל מספיק את האפשרות לשמור פרומפטים ב Cache. אם תשמור Cache טוב יותר תוכל לחסוך 43% מהוצאות הטוקנים של הסוכן שלך"

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

איפה הקאץ'? אנתרופיק שומרת את המטמון ל-5 דקות וגובה מחיר גבוה יותר לטוקן בשביל להשתמש בשירות הנפלא. שווה אם הסוכן שלכם מנהל שיחות ארוכות עם לקוחות במסגרת חלון זמן של 5 דקות. אופוס למשל יעלה 5$ למיליון טוקנים או 6.25$ לאותם מיליון טוקנים כשמשתמשים ב cache של 5 דקות. מתקדמים יכולים להשתמש ב cache של שעה במחיר של 10$ לאותם מיליון טוקנים.

ההסבר המלא עם כל המחירים והקוד הרלוונטי זמין בדף שלהם כאן:

https://platform.claude.com/docs/en/build-with-claude/prompt-caching

ודוגמת קוד עם cache נראית כך:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    system="You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.",
    messages=[
        {
            "role": "user",
            "content": "Analyze the major themes in 'Pride and Prejudice'.",
        }
    ],
)
print(response.usage.model_dump_json())