web-edit 0.1a1が示す、一方のモデルが計測し、もう一方が直す開発

Simon Willisonは、フォルダ内のファイルを編集するWebアプリweb-edit 0.1a1を公開した。短いリリースノートによると、GPT-6 Astraが作成したPython 3.15のプロファイリング報告をClaude Opus 5.5に与え、その結果として書かれた性能最適化が含まれる。

2つのモデルが計測とコード変更を分担した

公開された説明は、珍しいほど明確な分業を示している。GPT-6 Astraがプロファイリング報告を作り、Claude Opus 5.5がそれを基に最適化を書き、Willisonが変更を0.1a1へ取り込んだ。

ただし、情報源にはbenchmarkも具体的なhotspotも高速化の幅もない。アプリが特定の割合で速くなった、あるいはモデルが熟練開発者より優れた解決策を見つけたとは言えない。確認できるのは手順であり、性能上の成果ではない。

プロファイリングがcoding agentの仕事を絞り込む

開発チームにとって重要なのは、2番目のモデルが単にアプリを高速化せよと指示されたわけではない点だ。計測結果を材料にしたことで、調査対象をコストの高いコード経路へ絞れ、reviewerもpatchを確認する具体的な手掛かりを得られる。

万能な1つのモデルを探すより、この役割分担の方が実務的かもしれない。1つのシステムが診断し、別のシステムが変更を提案し、人間が計測と修正の妥当性を判断する。

benchmarkがなければ示せるのは工程だけだ

モデルが作ったプロファイリング報告は読み違えられる可能性があり、patchがある条件を改善しながら別の条件を悪化させることもある。リリースノートには、変更前後を測定したか、どのテストを使ったか、挙動が同じままかも書かれていない。

この点が記事の限界になる。作業の連鎖は公開されているが、性能向上を証明するデータはない。

再現可能なプロファイルとdiffが価値を決める

次に必要なのは、プロファイリング報告、正確なdiff、同一workloadでの変更前後の比較だ。この3点がそろって初めて、他の開発者もモデルが本物のhotspotを除いたか判断できる。

同種の実験ではaudit trailが最も重要になる。計測、変更案、テスト、最終benchmarkを結び付ければ、モデルの権威を信じるだけでなく、再現可能なworkflowになる。

Lilithの判定

一方のモデルがレントゲン写真を持ち込み、もう一方がメスを握り、Willisonが手術記録に署名した。処置前後の数値がなければ、患者が本当に速く走れるようになったかは分からない。