FrontierCode Diamond: ‏13.4% תיקונים ראויים למיזוג ב-50 משימות קשות (יוני 2026)

חומרים נוספים על הגדרת כלים מופיעים בתיעוד של Ailoot.

מהו FrontierCode, ולמה הוא חשוב?#

Cognition היא החברה שמאחורי Devin (מהנדס ה-AI האוטונומי הראשון, מרץ 2024) ו-Windsurf (נרכשה ביולי 2025). החברה גם מפתחת קו מודלים משלה, SWE-1.x. המדד פורסם בבלוג הציבורי בכתובת cognition.com/blog/frontier-code.

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

למדד שלוש רמות קושי: Extended (150 משימות, הסט המלא), Main (100 הקשות ביותר, כולל Diamond), ו-Diamond (50 משימות קשות במיוחד). Cognition השאירה בכוונה את Diamond ״רחוק במידה רבה מרוויה״ — אפילו המודל הטוב ביותר פותר פחות מ-15%. המטרה היא להשאיר למדד מרווח התקדמות לשנה ולמנוע ממנו להגיע לרוויה בתוך חודש, כפי שקרה ל-HumanEval.

מה FrontierCode מודד: ״האם המתחזק היה ממזג את ה-PR הזה?״#

ששת צירי ההערכה (מתוך הבלוג הרשמי של Cognition):

1. נכונות התנהגותית — האם התיקון פותר את המשימה?
2. בטיחות מפני רגרסיות — האם הוא נמנע משבירת קוד קיים?
3. תקינות מכנית — האם הוא עובר את בדיקות build, lint וסגנון?
4. תקינות הבדיקות — האם הבדיקות שהסוכן כתב תקינות (בדיקות שעוברות על כל קוד אינן נחשבות)?
5. היקף — האם התיקון נמנע מנגיעה בקבצים שלא התבקשו?
6. איכות הקוד — האם הקוד פועל לפי המוסכמות של הפרויקט, והאם הוא קריא?

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

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

Cognition הציגה שלוש שיטות דירוג חדשות:

• Reverse-Classical: בדיקה שנכתבה בידי סוכן חייבת להיכשל בגרסה פגומה של הקוד. אחרת, הבדיקה אינה אמיתית.
• Code Scope: בודק אוטומטי מוודא שהתיקון נשאר בתוך הקבצים ומספר השורות שסוכמו למשימה.
• Adaptive Classical Grading: כלי ה-LLM בשם ״mutagent״ מתאים בדיקות מחמירות לגרסאות תקינות של פתרונות.

למה המדדים הישנים כבר לא עובדים?#

סוכני AI כבר הגיעו להישגים גבוהים ב-HumanEval עד 2024. המצב ב-SWE-bench Verified דומה מאוד: באוגוסט 2025 הודתה OpenAI בפומבי בבעיית זיהום הנתונים (המודלים ״ראו״ את מערך הנתונים במהלך האימון). המדדים איבדו את יכולתם להבחין בין המודלים המובילים.

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

המחקר כלל:

• נבחרו 4 מתחזקים פעילים מ-3 מאגרים (scikit-learn, Sphinx, pytest).
• הם העריכו 296 בקשות מיזוג שנוצרו ב-AI מתוך SWE-bench Verified — כל הבקשות האלה עברו בדיקות אוטומטיות.
• החלטות המתחזקים הושוו להחלטות המעריך האוטומטי.

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

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

FrontierCode נותן צורה רשמית בדיוק לבעיה הזאת. Cognition לקחה את הרעיון הזה והרחיבה אותו למדד מלא עם יותר מ-20 מתחזקים במקום 4.

מסמר נוסף בארון הקבורה הוא מחקר מדצמבר 2025 על האבטחה של תיקונים שנוצרו ב-AI.

במחקר זה, 61% מהפתרונות של SWE-Agent עם Claude 4 Sonnet היו נכונים מבחינה פונקציונלית, אבל רק 10.5% מהם היו בטוחים.

הקוד עובר את הבדיקה, ובכל זאת אחד מכל שני תיקונים יוצר פרצת אבטחה. אי אפשר לראות את זה כלל במדדים של SWE-bench — הם אינם מודדים אבטחה. FrontierCode לפחות מנסה לתפוס את זה באמצעות צירי ״תקינות מכנית״ ו״איכות קוד״.

דירוג המודלים: Opus 4.8 עם 13.4%, GPT-5.5 עם 6.3%#

מה בולט בטבלה:

• מוביל ברור אחד. Opus 4.8 של Anthropic מקדים בערך פי שניים את המתחרה הקרוב ביותר. הפער שהיה קשה להבחין בו ב-SWE-bench בולט בבירור ב-FrontierCode.
• המודלים הפתוחים עדיין לא הדביקו את הפער. Kimi K2.6 — מודל הקוד הפתוח הטוב ביותר — מקבל 3.8% ב-Diamond. זה נמוך פי 3–4 מ-Opus 4.8. Cognition לא פרסמה טבלה מלאה של Kimi K2.6 עבור Main ו-Extended, ולכן עדיין אין השוואה על פני הסט המלא.
• Cognition הציבה בכנות את המודל שלה בחלק התחתון של הטבלה.

תת-הקבוצה Diamond הושארה בכוונה ״לא רוויה״. Cognition בנתה מרווח ביטחון לשנים הבאות. אם מדדים קודמים הגיעו לרוויה בתוך 12–18 חודשים, FrontierCode תוכנן עם תקרה גבוהה יותר.

מה פירוש ״13% ראויים למיזוג״ עבור מפתח vibe coding שמשתמש ב-Claude Code?#

ראשית, חשוב למסגר מחדש: סט Diamond של FrontierCode קשה במכוון במיוחד. במשימות רגילות בפרויקט סטארט-אפ חדש, בלי ארבעים מודולים תלויים, סוכן AI מצליח יותר באופן ניכר. אותו Opus 4.8 מקבל 51.8% קוד הראוי למיזוג ב-Extended (150 משימות, הסט המלא). זו תמונה שונה לחלוטין.

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

מה זה אומר למפתח vibe coding שדוחף קוד לייצור:

• בדיקה ירוקה כבר לא פירושה ״מוכן למיזוג״. בדיקות שה-AI עצמו כתב עלולות להיות חסרות ערך — הן עוברות על כל קוד. FrontierCode מודד זאת ישירות באמצעות Reverse-Classical: אם בדיקה אינה נכשלת על גרסה פגומה, היא לא נחשבת.
• סגנון המאגר והמוסכמות חשובים. אם לפרויקט יש דפוס קיים וה-AI לא פועל לפיו, שותף אמיתי לא יקבל את השינוי. בפרויקטים אישיים בלי כללים זה לא עניין גדול. בצוות זו הבעיה הראשונה במעלה.
• בדיקות אינן פותרות אבטחה. זכרו את הנתון שלמעלה: רק 10.5% מהתיקונים בטוחים, אף ש-61% מהם נכונים. צריך לבדוק זאת בנפרד, בעזרת כלים שמאתרים אסימונים, קובצי .env וסיסמאות ברירת מחדל.
• חריגה מגבולות המשימה היא טעות AI טיפוסית. מבקשים ממנו לתקן פונקציית הרשאות, ומקבלים תיקון ששכתב גם את השכבה הפנימית ואת הרישום ליומן. זהו אחד מ-6 הצירים של FrontierCode.

אילו 6 קטגוריות של טעויות AI עושה במשימות קשות?#

נעבור על כל ציר בשפה פשוטה:

1. נכונות התנהגותית — האם התיקון פותר את המשימה?

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

2. בטיחות מפני רגרסיות — האם התיקון נמנע משבירת קוד סמוך?

AI משנה מודול אחד, וכעת מודול אחר אינו עובד. המקרה הנפוץ ביותר: סוכן AI משנה חתימה של פונקציה ושוכח שקוראים לה מ-17 מקומות אחרים. אי אפשר לראות זאת ב-SWE-bench — שם מריצים בדיקות לקובץ אחד בלבד. ב-FrontierCode מריצים את כל חבילת הבדיקות של המאגר.

3. תקינות מכנית — האם התיקון עובר את בדיקות build, lint וסגנון?

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

4. תקינות הבדיקות — האם הבדיקות ש-AI כתב תקינות?

הציר המתוחכם ביותר. AI כותב בדיקה שעוברת. אבל היא עוברת על כל קוד, גם על קוד פגום. ראיתי זאת פעמים רבות: הבדיקה בודקת ״האם הסקריפט קרס?״ אבל לא ״האם הוא החזיר את התוצאה הנכונה?״ Reverse-Classical של FrontierCode תופס בדיוק את המקרה הזה.

5. היקף — האם התיקון נמנע מנגיעה בקבצים לא קשורים?

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

6. איכות הקוד — האם הקוד פועל לפי המוסכמות של המאגר?

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

איך לבדוק קוד AI לפני דחיפה: 5 שלבים#

1. הריצו את כל חבילת הבדיקות, לא רק בדיקות שקשורות לשינוי

   AI משנה לעיתים קרובות קוד מעבר למשימה. הבעיה תופיע בבדיקות סמוכות. אני מריץ את כל חבילת הבדיקות (באמצעות הפקודה היחידה npm test, בלי נתיב), ולא רק בדיקות לקובץ מסוים. בפרויקטים גדולים נוח לעשות זאת במקביל באמצעות git worktree (ראו Git worktree in Claude Code).

2. הריצו בדיקות lint, סגנון וטיפוסים

   שלוש פקודות לפי הסדר: eslint .,‏ prettier --check .,‏ tsc --noEmit. סוכן AI עלול לפספס גם טאבים וגם רווח מיותר בסוף שורה. אם לפרויקט יש בדיקות מחמירות, הריצו אותן מקומית לפני השחרור.

3. בדקו את הבדיקה עצמה

   החשובה ביותר מבין 5 הבדיקות. אני יוצר ״שבר״ קטן בקוד (משנה return true ל-return false). הבדיקה אמורה להיכשל. אם היא אינה נכשלת, AI כתב אותה רק למראית עין והיא חסרת תועלת. אני מוחק את הבדיקה ומבקש מ-AI לכתוב אותה מחדש עם תנאי מחייב: הבדיקה חייבת להיכשל בגרסה הפגומה.

4. בדקו באילו קבצים AI נגע

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

5. הריצו בדיקת אבטחה באמצעות מיומנות מוכנה

   בדיקות אינן תופסות הזרקות SQL או סיסמאות שהוטמעו בקוד. אני משתמש במיומנות אבטחה מוכנה ל-Claude Code (ראו 754 מיומנויות אבטחה מוכנות). לכל הפחות, חפשו ידנית בקוד הפרויקט את המילים “password,” “secret,” ו-“key”, ובדקו ש-.env.example מלא.

כל 5 השלבים מכסים 5 מתוך 6 הצירים של FrontierCode (1–5). הציר השישי — איכות הקוד — נבדק אוטומטית באמצעות lint ובסקירה אנושית.

מה באמת משפר את הסיכוי לקבל קוד ראוי למיזוג?#

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

מה צריך לעשות כדי להפוך את 13% למשהו שאפשר באמת לדחוף לסביבת ייצור:

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

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

2. מפת הפרויקט — תיקייה שמתארת את הפרויקט.

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

3. הנדסת הקשר — ניהול מה שה-AI רואה לפני הבקשה.

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

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

שכבה נוספת היא סוכני סקירה:

• Cursor Bugbot — מבצע סקירה בכל PR. לפי Cursor, הכלי מעבד כ-2 מיליון PR בחודש.
• סוכני משנה מקוננים ב-Claude Code v2.1.172 — סוכן אחד כותב את הקוד, שני סוקר אותו ושלישי מריץ בדיקות. זה אותו רעיון כמו ב-FrontierCode: הפרדת התפקידים של ״כותב״ ו״מוביל טכני״.

ראו גם: אבטחה ב-Vibe Coding, איך להגדיר את Claude Code כדי שלא ישבור את הפרויקט שלכם בלילה, והנדסת הקשר כמושג.

לחומרים נוספים על עבודה עם כלים, ראו את תיעוד Ailoot.