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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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