今日の収穫、3行で。

「ハーネスに投資すればモデル間の性能差をかなり埋められる」という楽観（eda_sann氏の検証）と、「ガードのないループは失敗を高速に量産するだけ」という慎重論が対になっている。共通の難所として挙がるのはループの停止条件——何をもって「完了」とし、いつ人間に戻すかの設計で、ここを曖昧にすると自律性がそのまま事故になるという認識は一致している。

Q. なぜSkillの評価が急に論点になっているのか？
A. Skillが数十個規模に増えると、発火しないSkill・逆効果のSkillが混ざっても気づけない。導入effort < 効果の検証effortという逆転が起き始めたため。

Q. 評価ツールは何を測る？
A. 主にSkillの発火精度（意図した場面で使われるか）と、Skillあり/なしでの成果物の品質差。ベンチマーク的な自動評価と、実タスクでのA/B比較の両方のアプローチがある。

64並列という規模は、Bunのように網羅的なテストスイートと専任チームが揃ったコードベースだから成立したという冷静な見方が本命。一方で、タスクを独立に分割し検証を機械化してからエージェントに並列で流すという型自体は、2〜3並列の個人開発でもそのまま縮小コピーできるという実践派の読みもある。

実測派の結論はおおむね「役割分担は品質をほぼ落とさずコストを数分の一にできる」だが、分担の境界設計（どこまでを顧問の判断に上げるか）を誤ると、往復のオーバーヘッドで単一モデルより遅く高くなるという注意点も共有されている。

Wasmは「小さく検証しやすいサンドボックス」という性質から、ブラウザ以外でも自動車ECUや産業制御など安全性重視の分野で採用が進んでいる。宇宙機の場合、地上から送るシーケンスを機上で安全に実行し直せる（誤ったコマンドが機体全体を巻き込まない）ことが決定的に重要で、インタプリタ方式の採用もその文脈にある。

HNでは「これぞハッカースピリット」という称賛が基調で、antirezの類似実験に触発されたのではという指摘も。実用面では「1トークン/秒でも夜間に放置するジョブなら使える」という擁護と、0.05トークン/秒では厳しいという冷静な線引きが並ぶ。READMEにも明記されたSSD摩耗への懸念（はんだ付けSSDのマシンでは避けるべき）、mmap化やMedusa/MTPによる高速化を狙う類似プロジェクト（flash-moe、thinfer、hypura）の共有など、追試の動きが早い。

HNコメントは少数だが、simonw氏が「記事に日付が無く『去年の11月からAIを使っている』といった記述はすぐ古びる」と指摘している（sitemap上は2026年の記事）。ランダム化テストをLLMに任せるくだりは「勧めると大抵うまく始められる」という追認もあった。

「LoCを誇り始めた時点で疑わしい」「メトリクスに最適化すれば成果ではなくメトリクスで勝つだけ」という批判が大勢。一方で「コードが汚いことは示せても、それがビジネス上問題になることまでは示せていない」「本番コードベースには似た無駄がいくらでもある」と記事側の論証の弱さを突く声も目立つ。「意見の効いたエージェントハーネスがあればこの種の問題は概ね直せる」という実践派の指摘が興味深い。

HNでは「DBへの書き込み権限を奪われても署名検証で弾ける」という設計に対し、それよりDBアクセス層の抽象化と監査に投資したほうがよいという反論や、ユーザー名をソルトとして混ぜる素朴な代案も出た。ゼロダウンタイムのクライアントキーローテーションを実装まで語る記事は貴重だという評価が付いている。

「子供保護の名の下に自由が一つずつ削られる」という定番の懸念に加え、反対多数でも否決できない採決手続きそのものへの批判が集中した。「EUの『強力なプライバシー保護』を二度と聞きたくない」という失望、真のP2Pメッセンジャーを求める動き、「E2E暗号化は今回も対象外」という冷静な整理、そして不人気法案をEUに肩代わりさせる「blame-laundering」だという構造批判まで、論点は広範囲に及ぶ。