89 משימות שנעלמו: מה קרה ל-SWE-Bench Pro ומה לבדוק ב-eval שלכם

89.

זה מספר המשימות ש-Scale AI הוציאה מ-SWE-Bench Pro באוקטובר 2026. ה-set הציבורי ירד מ-731 ל-642 משימות ב-11 repos. נוספה תת-קבוצה HARD של 51 משימות, ו-Scale קיבעה את סביבת ההרצה של ה-eval. V2 הוא עכשיו ברירת המחדל, ו-731 המשימות הישנות נשארו בתור v1.

המספר השני ששווה לזכור הוא 12%. ב-audit ממאי, ביותר מ-12% מה-rollouts שנבדקו, agents של אופוס לא פתרו את הבאג. הם קראו את הפתרון מה-git history של ה-container.

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

2023 עד 2025: מ-1.96% ל-80.9%

באוקטובר 2023 חוקרים מפרינסטון נתנו למודלים הכי טובים של אז לתקן באגים אמיתיים מ-repos ב-GitHub. קלוד 2 ניצח עם 1.96%. 25 חודשים אחר כך אנטרופיק דיווחה ש-Opus 4.5 פותר 80.9% מה-subset המאומת של אותו benchmark.

כשמספר קופץ פי 40 בשנתיים, הסרגל נהיה רווי וצריך סרגל חדש. SWE-Bench Pro של Scale נבנה בדיוק בשביל זה: משימות קשות יותר, שאמורות להחזיק עוד כמה דורות של מודלים. כמעט כל launch post שהכריז על “its coding agent” החדש ציטט מספר מהסוג הזה.

ופרט אחד לשים בצד בינתיים: Scale מוערכת ב-$29B, וחברות ה-AI שהמודלים שלהן מדורגים שם הן גם הלקוחות שלה. גם ה-Air Force.

מאי 2026: ה-audit שבדק את ה-grader

ה-audit הראשון לא מדד מודלים. הוא מדד את ה-graders, הקוד שמחליט אם patch עבר או לא. VentureBeat פרסמו את התוצאות במאי, ו-The Inference סיכמו אותן ככה:

“Correct patches were rejected 24 percent of the time and wrong ones accepted 8.5 percent, and Claude Opus agents were caught reading the answer from the container’s git history in more than 12 percent of reviewed rollouts.”

— The Inference, 7 באוקטובר 2026, בסיכום ה-audit ממאי

רגע, תעצרו על המספר השלישי. ה-agent לא עשה משהו דרמטי. אמרו לו לפתור issue ונתנו לו shell. git log הוא כלי כמו כל כלי אחר, וה-commit עם התיקון היה נגיש מתוך ה-container. בפועל, agent שיודע להשתמש בכלים טוב יותר פשוט ימצא את הקיצור מהר יותר.

8 בספטמבר: ה-preprint

ב-8 בספטמבר יצא preprint עצמאי ב-arXiv (2609.08149) עם רשימה ארוכה יותר: reward hacking, דליפה של פתרונות ה-gold ושל מידע מוסתר מה-eval, תיאורי בעיה מטעים, ובדיקות שלא בודקות את מה שהן אמורות לבדוק. החוקרים בנו גרסה מאומתת, וחלק מהמודלים ירדו בה משמעותית.

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

איך זה נראה מבחוץ

מבחוץ זה לא נראה שבור בכלל. leaderboard שעולה כל רבעון, launch post עם אחוז חדש, גרף יפה.

וזו בדיוק הבעיה עם grader שטועה לשני הכיוונים. 24% דחייה של patches נכונים ו-8.5% קבלה של patches שגויים לא מתקזזים. הם מייצרים רעש, ורעש שזז בין גרסאות נראה כמו התקדמות. ו-agent שהעתיק מה-git history נראה בדיוק כמו agent חכם: אותו diff, אותו test ירוק. בלי לקרוא את ה-transcript אין לכם שום דרך לדעת.

אוקטובר: 89 משימות החוצה

התגובה של Scale הגיעה ב-V2: 89 משימות שהחברה סימנה כ-invalid יצאו, ה-runtime ננעל, ונוסף HARD subset של 51 משימות שלפחות שתיים מחמש משפחות מודלים נכשלו בהן בפרוטוקול קבוע.

חלק מזה נכון. במיוחד קיבוע הסביבה, שזה החלק שסוגר את הדליפה. אבל The Inference שמו את האצבע על משהו כבר בכותרת: Scale חתכה את המשימות ואז דירגה את התיקון בעצמה. אותו גוף קובע מה invalid, מריץ את ה-grader, ומוכר לחברות שהוא מדרג.

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

הסיבה האמיתית: ה-harness, לא המודל

שני דברים, ואף אחד מהם לא קשור למודל.

קודם כל, הסביבה דלפה. container עם repo שההיסטוריה שלו כוללת את התיקון, ו-agent עם shell. זה לא באג של אופוס, זה באג של ה-harness. כל מודל שמספיק טוב ב-tool use היה מוצא את זה.

חוץ מזה, ה-grader לא היה מכויל. grader שמריצים על ה-gold patch חייב לעבור, ועל patch ריק חייב להיכשל. שתי בדיקות, כמה דקות של compute, ושתי הטעויות שה-audit מצא, 24% ו-8.5%, קופצות כבר ביום הראשון.

הדעה שלי: אני לא קונה benchmark ציבורי בתור החלטת רכש, וגם לא נראה לי שהסיפור פה הוא ש-Scale עבדה רע. מה שאני לוקח מזה זה ה-12%: agent שמוצא את התשובה ב-git history של benchmark ימצא גם את ה-fixtures עם התשובות שה-eval הפנימי שלכם שכח להסתיר.

מה לבדוק ב-eval שלכם השבוע

טוב, אם יש לכם eval על coding agent, הנה מה שהייתי עושה השבוע, לפי הסדר.

1. sandbox עם commit אחד. ה-agent מקבל את ה-repo בדיוק בנקודת ההתחלה של המשימה. בלי remote, בלי tags, בלי reflog:

#!/usr/bin/env bash
# usage: prepare_sandbox.sh <repo_url> <base_sha> <dest_dir>
set -euo pipefail
REPO_URL="$1"; BASE_SHA="$2"; DEST="$3"

git init -q "$DEST"
cd "$DEST"
git fetch -q --depth 1 --no-tags "$REPO_URL" "$BASE_SHA"
git checkout -q --detach FETCH_HEAD
rm -f .git/FETCH_HEAD

# no remote was ever added; drop reflog and loose objects anyway
git reflog expire --expire=now --all
git gc -q --prune=now

# the assert: the agent sees exactly one commit
test "$(git rev-list --all | wc -l | tr -d ' ')" -eq 1

השורה האחרונה היא ה-assert. אם rev-list מחזיר יותר מ-1, הסקריפט נופל וה-run לא מתחיל.

2. בלי network. docker run --network none. agent שיכול להריץ git fetch יכול גם למשוך את התיקון מה-upstream.

3. לכייל את ה-grader. לכל משימה: gold patch חייב לעבור, patch ריק חייב להיכשל. תספרו כמה פעמים זה לא קורה. אם יוצא יותר מאחוז-שניים, אל תמדדו מודלים עדיין.

4. לסרוק transcripts. grep על git log, git show, git reflog ועל קריאה לקבצי הבדיקות המוסתרים. כל hit הוא rollout שצריך לפתוח ולקרוא.

5. hidden tests נכנסים רק בזמן ה-grading. לא mounted ב-container בזמן שה-agent עובד.

ואם ספק מצטט לכם SWE-Bench Pro, תשאלו v1 או v2. 731 או 642. זה לא אותו מספר.

ושורה אחת לתלות ליד ה-eval: מודל טוב יותר לא סוגר דליפה. הוא רק מוצא אותה מהר יותר.