FrontierCode、AIコード評価を「mergeできるPRか」へ寄せる新ベンチマーク
Original: FrontierCode: An eval to measure whether you would actually merge the code View original →
Cognitionが公開したFrontierCodeは、AIコーディング評価により実務的な問いを持ち込む。パッチがテストを通るかだけでなく、そのPRを実際のオープンソースmaintainerがmergeするかを見る。動作、回帰リスク、テスト品質、変更範囲、スタイル、コードベースの慣習まで評価対象に入る。
同社によると、FrontierCodeは36の主要オープンソースリポジトリのmaintainerと作られ、各タスクに40時間以上の作業が投じられた。Extendedは150問、Mainは難しい100問、Diamondは最難関50問で構成される。DiamondではClaude Opus 4.8が13.4%、GPT-5.5が6.3%、Gemini 3.1 Proが4.7%にとどまったという。
この低い数字は、AIが「それらしいコード」を書けることと、チームが保守できるコードを書くことの違いを示している。既存のテストだけでは、間違った変更が偶然通ることもある。FrontierCodeはblocker基準、rubric、scope検査、reverse-classical testなどを組み合わせ、レビューで止まる種類のパッチを検出しようとする。
Cognitionの発表とHNの議論が示すのは、AIコード評価がCI風の正誤判定だけでは足りなくなっているという現実だ。AIが本番コードに近づくほど、「動いた」よりも「引き受けて保守できる」ことが重要になる。
Related Articles
オープンweightモデルがIDOR検出でClaude Codeを超えた点に、コミュニティの関心が集まった。
HNで議論になったのはRust製TUIやACP対応だけではない。telemetry、fork、provider lock-inへの不安が、open source化の意味を大きくした。
公開モデル向けコーディングエージェントは、モデル名だけでなくハーネスとSDK互換性で差が出る段階に入った。OpenInterpreterはRust製Kimi K3ネイティブハーネス、Apacheライセンス、ACPとCodex SDK互換を示した。