📌 ארבע טעויות של AI ואיך לתפוס אותן בלי לקרוא את הקוד

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

✏ מספרים קסומים והגבלות מלאכותיות

את הקוד הזה כתב GPT 5.6 כחלק ממימוש פיצ'ר שביקשתי:

@messages = Array(client.messages_index(limit: 50, order: "-modified", search_key: @search_query)["data"])
  .select { ...}

הפיצ'ר בגדול עבד וזה לא חשוב כרגע מה הקוד עושה. מה שכן חשוב זה מספר הקסם 50.

בגלל שלא ציינתי גבול ולא ביקשתי מנגנון Pagination הסוכן החליט להגביל את השליפה ל-50 תוצאות.

הנה עוד אחד מתיאור כלי ל MCP:

limit: int("Maximum number of characters to return per part. Defaults to 4000."),

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

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

✏ מימוש מנגנון כפול

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

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

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

טיפ 2 - הריצו Code Review נוסף עם שאלה ספציפית: איזה מנגנונים נבנו בשביל הפיצ'ר ולאיזה מהם יש כבר מנגנונים מקבילים במערכת. לפעמים המנגנונים הקיימים לא מתאימים בדיוק ולכן הסוכן בחר לא להשתמש בהם; לפעמים הסוכן פשוט פספס. בכל מקרה זה משהו שכדאי להחליט בעצמכם.

✏ קוד חדש ששובר קוד או עיצוב קיים

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

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

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

✏ רציתי לונדון וקיבלתי מלחמה

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

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

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

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

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

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

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

📌 השוואת מימושים - רובי מול פייתון

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

📌 מה קשה לתת ל AI לכתוב פוסט?

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

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

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

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

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

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

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

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

📌 איך לקודד עם AI בלי לאבד שליטה על הקוד

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

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

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

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

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

✏ מה זה אומר לאבד שליטה על הקוד

מה זה אומר שמישהו "מאבד שליטה על הקוד"? הנה דוגמה מפוסט שעלה לרדיט:

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

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

כשאני כותב תוכנית JavaScript כזו:

let smallest = Infinity;

for (let i = 0; i < 10; i++) {
  let num = Number(prompt("Enter number " + (i + 1) + ":"));

  if (num < smallest) {
    smallest = num;
  }
}

console.log("The smallest number is: " + smallest);

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

אבל מה עם AI? כתבו את הפרומפט:

implement a javascript program that reads 10 numbers and print the smallest one

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

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

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

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

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

✏ למה הבן אדם שבלופ הכרחי (עדיין)

להסתכל על קוד ולהסביר אותו? זה קלאסי AI לא?

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

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

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

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

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

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

✏ טיפ 1 - מבינים את השינוי לפני כל מיזוג

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

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

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

✏ טיפ 2 - בועטים ואז חוקרים

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

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

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

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

✏ טיפ 3 - מכרסמים בפרטים בקצב שלכם

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

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

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

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

✏ טיפ 4 - מחלקים אזורים בקוד ולא פיצ'רים

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

בעולם ה AI אני לא חושב שזה רעיון טוב.

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

כשמשהו מוזר קורה ב DB יש בן אדם אחד שהוא אלוף בבסיסי נתונים ושווה לתת לו להסתכל. כשמשהו נשבר ב Front end אני אעדיף להתייעץ עם חבר צוות שמכיר טוב ריאקט במקום עם קלוד. בצורה כזאת אנחנו מחזקים את הצוות ולוקחים בחזרה את השליטה.

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

📌 את כל הקוד כותב AI אבל...

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

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

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

📌 למה לבנות לעצמכם מערכת לפיתוח סוכנים

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

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

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

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

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

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

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

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

📌 התהיות בעקבות הרצאת הפתיחה של DHH

ריילסוולרלד נפתח עם הרצאת פתיחה מעוררת השראה ומפתיעה של DHH אני ממליץ לצפות בה:

https://www.youtube.com/watch?v=vDjW_dRyKXY

ואני ממליץ גם על מאמר התגובה המקיף של Jardo כאן:

https://jardo.dev/what-about-rails

עיקרי הדברים של DHH:

1. כתיבת קוד בצורה ידנית (הקלדת התווים) כבר לא כלכלית באופן גורף.
2. הרבה יותר קוד נוצר היום מאשר אי פעם בעבר. גם DHH עצמו יוצר היום (בעזרת סוכני קידוד) משמעותית יותר קוד ממה שיצר פעם.
3. המהפכה שעבר עולם התוכנה מזכירה את מהפכת הציור-צילום עם המצאת המצלמה.
4. קוד שנוצר רק בשביל שיהיה נוח למתכנתים הולך להיעלם. ב 37signals הם הולכים בדרך של שופיפיי ומחליפים את אפליקציות ה Mobile Web שלהם באפליקציות נייטיב מלאות. הוא לא רואה עתיד לפריימוורקים כמו React Native או אפילו Hotwire Native.
5. הזמן שבילינו בכתיבת קוד ידנית הוא לא זמן מבוזבז. עלינו להיות אסירי תודה שהיינו שם, שבנינו מערכות באופן הזה. במילים שלו, "הלוואי שהייתי בתעשייה בזמן כרטיסיות הניקוב זה בטח היה מדהים". עלינו להסתכל על התקופה שכתבנו קוד ידנית כמו שאנחנו מסתכלים היום על קידוד באמצעות ניקוד חורים בכרטיסיות.
6. גם בצד השרת יש סימן שאלה גדול לגבי ספריות שכל מטרתן להקל על המתכנתים על חשבון הביצועים של המערכת. טיעון הפרודקטיביות מפסיק להיות רלוונטי כשאנחנו בונים מערכות עם AI. את Hey הם משכתבים להשתמש ב Rust API Backend במקום Rails.
7. אנחנו יכולים לפתח מוצרים טובים יותר אם נבחר טכנולוגיה שאנחנו לא מכירים ובכוונה לא נקרא את הקוד כי אז אנחנו לא מביאים את המטען והמגבלות שלנו לתוך המערכת. משקל ומגבלות שאולי כבר לא רלוונטים.
8. יש להטיל ספק בכל התיאוריה שלנו לגבי פיתוח תוכנה. פעם חשבנו שכפל קוד זה רע אבל היום עם סוכנים אולי זה לא חשוב. פעם חשבנו שאבסטרקציות עוזרות לנו לחשוב על בעיות אבל היום עם סוכנים אולי הן רק מאטות.

אני חושב ש DHH כמו DHH עוד ישנה את דעתו לגבי חלק מהסעיפים שם. במיוחד הסיפור של ארכיטקטורת תוכנה וחוסר היכרות עם הטכנולוגיה, שני סעיפים שבניסיון שלי בעבודה הרגשתי בדיוק את ההיפך, כלומר שככל שיש לי יותר היכרות עם הכלים, עולם התוכן והיכולות אני מצליח לקבל עבודה יותר טובה ויותר פיצ'רים מהסוכן. צריך לזכור שהתחרות שלנו היא לא מול מפתחים של לפני 5 שנים אלא מול מפתחים של היום, להם יש גישה לאותם הכלים ולאותן היכולות. מישהו צריך לשים לב ש Rust ייתן Backend יעיל יותר מ Rails ועם פחות שגיאות מ C++, מישהו צריך לשים לב לצריכת הטוקנים וליחס בין טוקנים למוצר, מישהו צריך לשים לב מה קורה כשדברים נשברים והכי חשוב לקבל החלטות טכניות שקשורות לאופן העבודה של המערכת. עד היום לא ראיתי שמודלי שפה מאוד טובים בקבלת החלטות.

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

📌 הסוכן כותב אני רק שומר

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

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

עכשיו לסיפור בואו נראה מה הבעיות בו:

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

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

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

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

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

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

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

📌 להצביע על הבעיה

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

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

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

📌 בואו נזהה באגים בקוד פייתון אסינכרוני

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

✏ באג 1

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

async def dashboard(user_id):
    user     = await get_user(user_id)
    orders   = await get_orders(user_id)
    invoices = await get_invoices(user_id)

רואים איפה זה שבור?

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

async def dashboard(user_id):
    user, orders, invoices = await asyncio.gather(
        get_user(user_id),
        get_orders(user_id),
        get_invoices(user_id),
    )

    return user, orders, invoices

✏ באג 2

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

async def user_orders(uid):
    return [await get_order(uid, i) for i in range(3)]

await asyncio.gather(*(user_orders(u) for u in users))

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

async def user_orders(uid):
    return await asyncio.gather(
        *(get_order(uid, i) for i in range(3))
    )

results = await asyncio.gather(
    *(user_orders(u) for u in users)
)

✏ באג 3

אוקיי אוקיי עכשיו ה gather מתאים למספר הלולאות:

for i in range(0, len(urls), 10):
    await asyncio.gather(*(fetch(u) for u in urls[i:i+10]))

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

בשביל לראות את זה אל תחשבו על המהירות של כל מנה בנפרד אלא של הרשימה כולה. אם יש שני URL-ים איטיים במנה מסוימת עדיין משתלם להוריד במקביל 8 נוספים במקום ה-8 שהסתיימו. בעצם הבחירה לחכות כל פעם למנה של עשר כתובות היא הטעות. פתרון טוב יותר יהיה להחזיק Semaphore של 10 בקשות פעילות:

sem = asyncio.Semaphore(10)

async def limited_fetch(url):
    async with sem:
        return await fetch(url)

results = await asyncio.gather(
    *(limited_fetch(u) for u in urls)
)

והאמת גם הקוד כולו יצא יותר קריא.

✏ באג 4

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

lock = asyncio.Lock()
cache = {}

async def get_cached(key):
    async with lock:
        if key not in cache:
            cache[key] = await complex_calculation(key)
        return cache[key]

# the caller
await asyncio.gather(*(get_cached(k) for k in ["a", "b", "c", "d", "e", "a", "a"]))

המטרה היא ש complex_calculation תופעל רק על הערכים השונים וכל ה a-ים יחכו לחישוב שפועל, כלומר שהיא לא תופעל 3 פעמים עבור שלושת המופעים של a.

אבל זה לא מה שקורה.

בגלל שהנעילה מכסה גם את הכתיבה למילון וגם את הפעלת החישוב כל אחד מהערכים מחושב בנפרד בצורה סדרתית. החישוב של a חוסם גם את b, c, d ו e.

מה עושים? משתמשים ב task ומפרידים בין החישוב לבין הנעילה:

lock = asyncio.Lock()
cache = {}

async def get_cached(key):
    async with lock:
        task = cache.get(key)

        if task is None:
            task = asyncio.create_task(complex_calculation(key))
            cache[key] = task

    return await task