それは素晴らしい制約だね。

Claudeのコード使った？どれくらいトークン消費した？費用はどれくらい？どのモデル使ったの？

すごく印象的だね！20年でここまで来たのは驚きだ。2000年代初頭にkhtml/konquerorに（ほんの少しだけ）貢献してたけど、あの頃は半分動くエンジンを作るのですら、すごく手間がかかった。基本的なレンダリングを少しでも正しくするのに、何ヶ月もかかってたからね（当時のウェブはもっと小さかったし）。エージェントコーディングに加えて、この特定のタスクにはcss-spec/html-spec/web-platform-testsを機械可読のテストスイートとして使うのがすごく役立つと思う。エージェントは実際の仕様に対して検証できるから。昔は、オープンソースのリファレンスとしてGeckoがあったけど、実際には「標準」はIEがやってることだったから、何週間もかけて実装しても、結局はどのサイトもIEの癖に合わせてコーディングされてるのを発見することが多かった、笑。GoogleやApple、他の貢献者たちは、そういう面で規律をもたらしてくれたね。

人間とエージェントの組み合わせは絶対に大きな違いを生むと思うよ。Claudeが完全に脱線しても、適切なエージェントのセットアップで戻ってこれるのをよく見るけど、気づかないと軌道修正に時間がかかるんだ。今、Claudeが取り組んでるプロジェクトがあって、もっと自分をループから外すセットアップをテストしてるんだ。そこが難しい部分だからね。エージェントに出力を増やさせるのは「簡単」だけど、それをトークンに使う意欲に合わせてスケールさせるのは難しい。大体こんな感じになったよ（特別なことはないけど）：

• 現在の状態を評価して、複数の指標にスコアを割り当てる評価者を動かす。
• あるスコアが閾値を超えたら、自動的にテストスイートを拡張する。
• スコアが閾値を下回ったら、「リサーチエージェント」を生成して、スコアが期待に届かない理由を調査させる。
• リサーチエージェントがレポートを提出し、それが実装エージェントに渡される。
• メインエージェントがスコアリングを再実行し、指標の一つ以上で改善が見られなければ、そのコミットは破棄され、何を試みたか、なぜ失敗したかのメモが残される。正しくするには少し試行錯誤が必要だけど（例えば「テストスイートが間違ってる」って早い段階で出てきて、メインエージェントは「問題のある」テストを削除するためにテストスイートを見直すように言われそうになった）、こんな風に分けることでClaudeがもっと賢いことをしてくれるようになるんだ。コミットを捨てるのは過激に感じるけど、もしかしたらコミット -> 評価 -> 再実行を少し繰り返してから最終判断するオプションもありかも。今のところ、これがスケールしやすい気がする。無駄が少なくなるしね。こういうエージェントを開発者として扱うよりも、出力が100倍高いと考えた方がいいと思う。安価で使い捨てのコードはワークフローを変えるはずだ。だから、これはブラウザを作る良い方法のデモとしては優れているけど、面白さは少し減るね。FastRenderのようなものが可能だと示されたから、同じように野心的なプロジェクトに取り組む人が増えると思うけど、スコアリングや評価にもっと考慮が入るだろうね。コードのサイズや依存関係についても。

僕は、Embedding Shapesが自分の手で物事を進めて実際に作ったのがすごく好き。最近の例ではこれほどのスケールで証明されたことはないと思う。Hacker Newsがその中心にいるのを見るのは最高だね、笑。 > 「HTML+CSSをレンダリングするブラウザを作る」というのは、マッシブに並列なエージェントのセットアップを示すための完璧なタスクだと思った。なぜなら、数千行のコードで一人のコーディングエージェントが生産的に達成できるものではなかったから。結果的に、僕は間違ってた！未来や現在の技術者たちが、これをゴリアテ対ダビデの物語として目撃するのか気になる。2万ドルで1人と1エージェントが、500万ドルの160万行のコードのブラウザに勝つなんて、当時の巨大なAIユーザーや先駆者たちのAIの使い方に対する考え方を変えたね。最近ドキュメンタリーをいくつか見たけど、なんでかこの全体についてのドキュメンタリーが未来に作られる気がする。でも、ますますAIが完全なブラックボックスのように感じてきてる。誰もどうやってやるか分からないけど、みんなで実験してみて、何がうまくいくか見てる感じ（例えば、1人1エージェント > 多くのエージェントで人間が介在しないっていう確かな証拠があるように）。2026年に1ヶ月経った今、今年中にこのブラックボックスについてもっと知るための他の実験や証拠が出てくるかもしれない。サイモン、もし2026年の予測スレッドを毎月か四半期ごとに読んで、AIについてどれだけの人が間違ってたか、正しかったかを見れたら面白いね。

大半の人が、エンジニアリングの観点から見ると、これはCursorの「ブラウザ」よりもずっと優れているって同意すると思う。あまり多くはできないけど、うまくやってるからね。これが示しているのは、「エージェントを効果的に使う」ことが、問題にトークンを投げつけて何が出てくるか見るよりもずっと重要だということ。僕自身、いくつかの小さなバイブコーディングプロジェクトをコードを見ずに完全に削除しちゃったことがある。なぜなら、コードが生成された2日後には、間違った問題を解決しようとしていたり、間違ったアプローチを使っていることに気づくことがよくあるから。コーディングエージェントはそんなこと気にしない。おそらく、君が頼んだことを何でもやってくれるだけだから。アイデアを検証するために使う価値がある場合もあるけど、最初に間違った道に進むと、逆に自分を深い穴に追い込むことになることが多い。

ありがとう、すごく嬉しいよ。こういう記事の著者として（もしかしたらそのきっかけになったかもしれない）、自分もその罪を犯しているし、Cursorが実際に何を作ったのか、彼らが「成功」と考えているものを理解しようと深く掘り下げるにつれて、全てがますます意味をなさなくなっていったんだ。だから、ステップバックしてプロセスの中で実際に何が難しいのか、出力に何が悪いのかを見る方が追求する価値があると思ったんだ。

これは本当に基本的なブラウザだね。独立したものとして作られたというよりは、https://cursor.com/blog/scaling-agentsへの返答として作られた感じ。だから、彼らとほぼ同じことができて、行数が少なければ、目的は達成できてる :) > リンクが常に青くて下線が引かれているかどうかを評価できるんだ。そう、このブラウザには普通のブラウザのような「デフォルトスタイルシート」がないんだ。たぶんそれを追加すべきだったけど、ブラウザがウェブをどう見せるべきかというより、ウェブからウェブサイトをレンダリングすることに興味があったんだ。 > 一部のレンダリングがWindowsでサポートされていないかもしれないけど、戻るボタンは確実にそうだね。うーん、Windows 11では戻るボタンはちゃんと動くはずだよ、昨晩試したばかりだから。もしかしてWindows 10を使ってるの？自分では試してないけど、動くはずだけど、それが理由かもね。