「このシステムをテストするために、野心的な目標を設定したんだ。ゼロからウェブブラウザを作ることさ。」先週、LLMの予測をシェアしたんだけど、その中の一つは「2029年までに、誰かが主にAI支援のコーディングを使って新しいブラウザを作るだろう、しかもそれは驚きでもない」ってことだった。https://simonwillison.net/2026/Jan/8/llm-predictions-for-202... と https://www.youtube.com/watch?v=lVDhQMiAbR8&t=3913s このCursorのプロジェクトは、今見た中で2回目の試みだよ！もう一つはこれだね： https://www.reddit.com/r/Anthropic/comments/1q4xfm0/over_chr...

同じような技術を使ってtjsを作ったんだ。[1] 世界で最も速くて正確なJSONスキーマバリデーターで、魔法のようなTypeScriptの型を持ってる。自律プログラミングについてたくさん学んだよ。gitサブツリーを使って作業を広げる「プランナー/デリゲート」パターンがすごくうまく機能することに気づいた。[2] どんな大きなソフトウェアも、確立された基準とテストスイートがあれば、コーディングエージェントによってすぐに書き直されて最適化されると思う。[1] https://github.com/sberan/tjs [2] /spawn-perf-agents claude command: https://github.com/sberan/tjs/blob/main/.claude/commands/spa...

これ、ちょっと皮肉に聞こえるかもしれないけど、マジで思ってるんだ。なんでそのPRをマージしないの？ここに暗示されてる未来は、めっちゃクールだよ。少しの監視で何でも作れるコーディングエージェントの群れ。高品質で複雑なプロジェクトに収束する長期的なプロジェクト。でも、具体例が薄い気がする。ウェブブラウザ、Excel、Windows 7は存在してるし、特にLLMのトレーニングセットに含まれてる。実際のコードに最も近いのはCursorのコードベースでやったことだけど、まだマージされてない。マージされたら連絡してって言いたくはないけど、エージェントが何百万行ものコードを生み出す能力には心配してないんだ。実世界の人間と交わる能力、つまりそのコードのユーザーやそれを基に何かを作りたい開発者との関係が心配なんだ。

これ、めっちゃ脆いコードに見えるんだけど。https://github.com/wilsonzlin/fastrender/blob/main/crates/fa... FrameState::render_placeholderって何なの？ pub fn render_placeholder(&self, frame_id: FrameId) -> Result { let (width, height) = self.viewport_css; let len = (width as usize) .checked_mul(height as usize) .and_then(|px| px.checked_mul(4)) .ok_or_else(|| "viewport size overflow".to_string())?; if len > MAX_FRAME_BYTES { return Err(format!( "requested frame buffer too large: {width}x{height} => {len} bytes" )); } // テストやデバッグでクロストークをキャッチするための決定論的なフレームごとの塗りつぶし色。 let id = frame_id.0; let url_hash = match self.navigation.as_ref() { Some(IframeNavigation::Url(url)) => Self::url_hash(url), Some(IframeNavigation::AboutBlank) => Self::url_hash("about:blank"), Some(IframeNavigation::Srcdoc { content_hash }) => { let folded = (*content_hash as u32) ^ ((*content_hash >> 32) as u32); Self::url_hash("about:srcdoc") ^ folded } None => 0, }; let r = (id as u8) ^ (url_hash as u8); let g = ((id >> 8) as u8) ^ ((url_hash >> 8) as u8); let b = ((id >> 16) as u8) ^ ((url_hash >> 16) as u8); let a = 0xFF; let mut rgba8 = vec![0u8; len]; for px in rgba8.chunks_exact_mut(4) { px[0] = r; px[1] = g; px[2] = b; px[3] = a; } Ok(FrameBuffer { width, height, rgba8, }) } } この差分で何をしてるのか？https://github.com/wilsonzlin/fastrender/commit/f4a0974594e3... 時間の経過とともにどれだけの作業や再作業があったのか、そして各追加の実際に完成したテストケースのトークン/時間コストを見てみたいな。

誰かリポジトリからテストを実行できた人いる？コードはエラーや警告だらけで、私が見た限りでは、どれも私のプラットフォーム（Linux）のせいじゃないみたい。いくつかのページのActionワークフローの履歴を見たけど、CIがしばらく失敗してるみたいだし、PRも全部CIに失敗してるのにマージされてる。これが成功例として使えるってどうやって確認されたの？それとも私が彼らの言いたいことを誤解してるのかな？スクリーンショットについて言及してるけど、彼らの目標が成功したかどうかは具体的に言ってないよね？「完全自律コーディング」のアプローチが正しいとは思えない。人間が何かを達成するために使うものとして考えた方が、もっと効果的に使える気がする。人間に運転させる方がいいと思う。品質がすぐに崩壊しちゃうから。

確かに一見シンプルなスクリーンショットに見えるけど、ブラウザをゼロから作るのはめっちゃ難しいよ。 > 別の実験として、CursorのコードベースでSolidからReactへのインプレースマイグレーションをやったんだ。それには3週間以上かかって、+266K/-193Kの編集があったよ。変更のテストを始めたところだけど、この変更をマージできる可能性があると思ってる。私の見解では、この投稿は真剣な議論をするには十分な詳細やニュアンスが欠けてるし、情報が少ないことは主に失敗を示唆してる、特にブラウザのケースではね。ブラウザのリポジトリが「何かしらできる」ってのはすごいけど、それ以上の注目すべき点があったら、30Kのコミットや1MのLoCみたいなボリュームメトリクス以上の詳細を説明すると思う。例えば、表示されている全機能が他のライブラリに委譲される数行に制約される可能性もあるし、リグレッションを避ける変更はマージ「可能」だけど、私たちの仕事の大半は「次の変更をマージすることは可能か？」って問いかけるんだよね。そして次の、100番目の変更もね。もし彼らがMRをマージしたら、実際にやってることになる。ブラウザの分析をもっと提示すれば、話す価値がある（「レンダリングする」以上に精査しなかったら、あんまり役に立たないテストだけど）。それまでは、コンパイルできる謎のエージェント出力の山で、未発見のメカニズムでapple.comのスクリーンショットを撮る実行経路が含まれてるんだ。

試してみたくてリポジトリをダウンロードしてビルドを実行したんだけど、100以上のコンパイルエラーが出たんだ。そこでGitHubのコミット履歴を見たら、少なくとも数ページ前から最近のコミットはCIで失敗してるのがわかった。どのコミットを選べば宣伝されてる半分動くバージョンが手に入るのかも不明だったし。とりあえずCargo.tomlを見て、プロジェクトがどう構成されてるのかを把握しようとしたんだけど、投稿の印象とは裏腹に、ほとんどのコアコンポーネントがオープンソースのライブラリから引っ張ってきたものだってわかった。quickjsエンジン、wgpuグラフィックス、winitウィンドウ＆入力、eguiでUI、HTMLパースなど、挙げればキリがない。TwitterではCEOが「カスタムJS VM」を使ってるって明言してたけど、これが特に誤解を招く表現だと思った。既存のコンポーネントを統合するのは、自律的にやるにはすごいことだけど、印象的なことをやった後にこんなに誤解を招く必要があるのか、正直戸惑ってる。リーダーシップに対する信頼はかなり減ったけど、もしかしたら自分のカスタムカーソルを生成できる日が近いと思うと少しホッとしてるかも。

ここにいるみんながこんなにネガティブで懐疑的なのはちょっと驚きだよ。ブラウザエンジンを作るなんて、ある意味信じられないことだと思う。多少は動くウェブサイトレンダラーに近づくなんてさ。最も悲観的な解釈をしても（人間の操作が多すぎる、既存のライブラリに依存している、コードの質が雑なところがある、全バージョンがコンパイルできないなど）それでも驚きだよ。

個人的に今考えてみると、あんまり好きじゃないのは、彼らが段階的にスケールアップしなかったことだな。ソフトウェアの複雑さの階段があるとしたら、シンプルなReact CRUDアプリから始まって、Paintのクローンみたいなもっと複雑なもの、さらにファイルマネージャーみたいなもっと複雑なものへと進んで、最終的にはウェブブラウザみたいな最も複雑なソフトウェアにたどり着く感じ。最初のタスクを100%達成して、次のタスクも素晴らしい結果を出して、3つ目は頑張って、最後にはまだ使えないけど期待できるものを作るようなシステムが見たいな。そうすれば、難易度のスケールアップが品質の徐々に低下につながることがわかるし、今どこにいて、どこに向かっているのかをちゃんと測れると思う。

今、opus 4.5を使ってるんだけど、これが彼らのベストモデルと言えるかも。多くの作業にはすごく良いけど、監視なしで放置すると微妙なエラーや不一致が出てくるんだよね。複雑な要求には曖昧さを取り除くためのプロンプトが全然足りないから、数日や数週間放置したらコードベースにどうなるか想像もつかない。