# How to Judge if AI Code Is Actually Good: המדריך לשפוט אם קוד שה-AI כתב באמת טוב

> ביוני 2026 פרסמה Anthropic מחקר שניתח בערך 400,000 שיחות אמיתיות עם Claude Code. הם בדקו מי מצליח לפתור משימות תכנות, ולפי הסיווג של העיסוק שלהם.

מאת קווין ליאקס. פורסם 2026-06-21. נושא: Claude ו-Claude Code.
העמוד המלא: https://kevinliaks.ai/guides/judging-ai-code

## מבוא: למה הכישור הכי חשוב היום זה לשפוט קוד, לא לכתוב אותו

ביוני 2026 פרסמה Anthropic מחקר שניתח בערך 400,000 שיחות אמיתיות עם Claude Code. הם בדקו מי מצליח לפתור משימות תכנות, ולפי הסיווג של העיסוק שלהם. התוצאה הפתיעה הרבה אנשים בתעשייה.

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

![מתוך המחקר של Anthropic: שיעור ההצלחה במשימות קוד דומה מאוד בין מהנדסי תוכנה לבין כל שאר העיסוקים.](https://kevinliaks.ai/_astro/01.CSnvRsgA.png)

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

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

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

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

## 7 הקריטריונים לשיפוט קוד שה-AI כתב

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

### 1. נכונות ו-edge cases

השאלה הראשונה היא פשוטה: האם הקוד באמת עושה את מה שביקשת? לא מה שכתוב בהערות, אלא מה שקורה כשמריצים אותו. הבעיה הכי נפוצה היא שהקוד עובד על המקרה ה"נקי" ונשבר על המקרים הקיצוניים.

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

### 2. קריאות ותחזוקתיות

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

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

### 3. אבטחה

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

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

### 4. טיפול בשגיאות

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

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

### 5. ביצועים

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

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

### 6. בדיקות

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

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

### 7. תלויות ומורכבות מיותרת

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

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

## השאלות שתמיד כדאי לשאול את ה-AI אחרי שהוא כותב קוד

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

| השאלה לשאול | מה זה חושף |
|---|---|
| **תעבור על הקוד שורה-שורה ותסביר לי מה כל חלק עושה** | מאתר שורות שהמודל עצמו לא באמת יודע להצדיק |
| **מה ה-edge cases שלא טיפלת בהם?** | מוציא את המקרים הקיצוניים שנפלו בין הכיסאות |
| **איפה הקוד הזה יכול להישבר בפרודקשן?** | מכריח את המודל לחשוב על עומס, רשת וכשלים |
| **כתוב לי טסטים שמכסים את מקרי הקצה** | בודק את הקוד ומשאיר רשת ביטחון לעתיד |
| **האם יש פה בעיית אבטחה?** | חושף מפתחות חשופים, קלט לא מאומת והזרקות |

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

## דוגמה מעשית: לפני ואחרי

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

### לפני: הקוד שהמודל החזיר

```
function average(numbers) {
  let sum = 0;
  for (const n of numbers) {
    sum += n;
  }
  return sum / numbers.length;
}
```

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

### אחרי: הקוד אחרי שיפוט ותיקון

```
function average(numbers) {
  if (!Array.isArray(numbers) || numbers.length === 0) {
    throw new Error('average: expected a non-empty array');
  }
  const sum = numbers.reduce((acc, n) => acc + n, 0);
  return sum / numbers.length;
}
```

**ההבדל הוא לא בכמות הקוד. ההבדל הוא שעכשיו מקרה הקצה מטופל במפורש, השגיאה ברורה במקום להחזיר NaN בשקט, והקוד אומר לך בדיוק מה השתבש. כל מה שהיה צריך זה לשאול שאלה אחת: מה ה-edge cases שלא טיפלת בהם?**

## צ'קליסט מהיר

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

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

## טיפים

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

## לינקים

![המחקר המלא של Anthropic על תכנות עם סוכני AI וההחזר המתמשך למומחיות.](https://kevinliaks.ai/_astro/02.nK3l7Y9G.png)

*המחקר המלא של Anthropic על תכנות עם סוכני AI וההחזר המתמשך למומחיות.*

- המחקר של Anthropic: [anthropic.com/research/claude-code-expertise](https://www.anthropic.com/research/claude-code-expertise)
- האתר של Anthropic: [anthropic.com](https://www.anthropic.com)

---
קווין ליאקס מעביר סדנאות AI, הרצאות והטמעה לארגונים: https://kevinliaks.ai/workshops