ClaudeがThree.jsなしで3Dシーンを再構築し、ブラウザを低コストな実験場にした

Simon WillisonはThree.jsでFabergéの卵を思わせる3Dオブジェクトを作り、同じchatでClaude Opus 5.5 MediumにVanilla JSとWebGLへの移植を依頼した。元のファイルは77 KB、新版は98 KBだった。どちらも動くが、見た目は同一ではない。

Claudeが省いたのはライブラリでありWebGLの複雑さではない

この実験は、ブラウザが巨大なアプリ基盤であり、LLMが未知の機能へ入るコストを下げるというPaul Fordの議論を具体化する。FordはWeb Crypto、WebAssembly、WebGL、Web Audioを挙げる。TinyLittleOfficeはアクセス急増後もCloudflareのhosting費が0ドルだった。

Willisonは既存のThree.jsシーンをClaudeに書き換えさせた。本人はThree.js版の方が少し読みやすいと感じ、出力差の理由を完全には理解していないとも述べた。

prototypeは速くなってもコードの責任は後から付いてくる

安価な配布と、専門知識が必要だったAPIへの安価な入口が組み合わさった。App Storeや大規模チームなしでwebファイルとして案を試せる。LLMはpromptを書いた人が普段扱わないgraphics codeも生成する。

変わるのは主に開発の初期だ。product担当者は大きな投資前に操作を試せる。一方、後で開発者が、作者自身も説明できないcodeを引き継ぐ可能性がある。prototypeの速さと保守性は別の指標だ。

似た二つのシーンだけでは忠実な移植を証明できない

Willisonは出力が異なると明記した。性能、browser互換性、accessibility、保守性の試験はない。98 KBという大きさだけでも品質は判断できない。

LLMはWebGLを消したのではなく、interface作業の一部を肩代わりした。描画不具合、memory leak、端末差が出れば、rendering pipelineを理解する人が必要になる。完成度の高いdemoはこの境界を隠しやすい。

次の試験では変更と故障と人への引き継ぎを測るべきだ

より強い材料は、何度か修正されたprojectから得られる。modelが見た目を保ち、選択を説明し、複数のbrowserとgraphics chip向けのtestを用意できるかが重要だ。

Fordの主張は特定のlibraryの勝敗に依存しない。能力は以前からブラウザにあった。安くなったのは探索だ。次は、その実験が保守できるsoftwareへ育つかを見る段階になる。

Lilithの判定

ブラウザの中には以前から工場全体があった。Claudeが廊下の灯りをつけただけで、最初の故障が配電盤を開けられる人を明らかにする。