今日の収穫、3行で。

HNの反応は二分している。実務層は「@メンション」「/clear」「/context」を即使える節約策として評価する一方、「これはAnthropic版の『持ち方が悪い』だ」（iPhone 4のアンテナ問題を引き合いに出すコメント）という批判が上位に来た。技術的な疑問として最も具体的だったのは『なぜプレフィックスキャッシュがeffortに紐づくのか』——xhighで統計モデリングを走らせた後、その解説を低effortで往復したいのにキャッシュが壊れる、という指摘。また『1時間でキャッシュが切れるなら、離席して戻るだけでコストが倍になる』としてキャッシュを温め続けるスクリプトの可否を問う声もあった。逆に、何もしていないのにキャッシュ書き込みが400K→800K→2Mと膨らむ現象の報告には、明確な回答が付いていない。

Q. セッション途中でモデルやeffortを変えると何が起きるのか。
A. プロンプトキャッシュが無効化され、それまでの会話全体を再度キャッシュ書き込みすることになる。開始前に決めておけ、というのが記事の主張。

Q. @メンションは常に得なのか。
A. HNでは異論がある。Readなら必要箇所だけ部分読みできるが、@メンションはファイル全体を添付するため、大きいファイルでは逆効果になりうる。

同じ理屈はサブエージェント定義にも当てはまる。エージェントのdescriptionは呼び出し側モデルへのルーティング指示であって、人間向けの説明文ではない。

isolateモデルは起動が速くコールドスタートが実質無視できる一方、Node.js前提のライブラリやプロセス内キャッシュがそのままでは使えない。得られるのはレイテンシと課金効率、支払うのは既存資産の書き換えコストで、この交換が割に合うかはアプリの状態管理の重さで決まる。

依存ゼロは起動の速さ・攻撃面の小ささ・単一バイナリ配布と引き換えに、HTTPやJSONの周辺処理を自前で抱えることを意味する。MCPサーバをローカルで大量に常駐させる使い方では前者の利点が勝ちやすい。

複数ハーネス併用は、タスクごとに最適な実行環境を選べる代わりに、設定・メモリ・権限がハーネスの数だけ分散する。統一する側は運用が軽くなるが、不得手な作業を無理に押し込むコストを払うことになる。

Q. エラーの識別子と文言を分けるのはなぜか。
A. 文言はUIや多言語対応で変わりうるが、クライアントの分岐が文言に依存すると壊れる。安定した機械可読コードを別に持たせる。

HNで最も支持を集めたのは「人間でも複雑な問いは1回の検索では終わらず、2〜5往復してリンクを踏み、前提を検証する。それを高速にやるモデルは筋が良い」という評価。一方で、専用検索エージェントは（1）小型汎用モデル、（2）RAGパイプライン、と比べて何が本質的に違うのかを問う声も複数あった。記事がMixedbread Searchの説明を省いている点への不満と、命名がパロディサイトに見えるという指摘も上位に来ている。

コメント欄では検索アルゴリズムのbreadth-first searchに引っかけて「bread-first search」という駄洒落が飛び交った。社名がMixedbreadである以上、これは避けられない運命だったと言える。

HNの質問で最も鋭かったのは予算保証の実装方法だ。検索費用は事前に見積もれても、LLM側が想定より多く消費した場合にどう止めるのか——max_tokensと料金表で押さえるのか、そのときプロンプトキャッシュはどう勘定するのか、という問いには明確な回答が付いていない。また同名のtw93/Moleとの衝突を指摘するコメントが最上位に来ており、「基本的な機能の割にコード量が多い」という辛口の評もあった。

確認を強制すれば意図しない大規模変更は防げるが、自律実行の価値は失われる。設計・調査フェーズでは有効で、定型的な実装タスクでは足枷になる、という使い分けが妥当なところ。

HNでは提案の核心に賛否が割れた。「議論の文字起こし→BDD→AIのレール」という流れを『卓越しているか、自分の尾を食う蛇か、どちらかだ』と評するコメントが象徴的。肯定側からは、UIの受け入れテストにBDDを導入した実例（エンジニアリング主導の1本とvibe coding製の1本）が挙がり、非エンジニアが変更の影響をUIで確認できる利点と、DB/API/SDKの整理が副産物として進んだ効果が報告された。最も本質的な反論は『なぜ抽象化層に自然言語を選ぶのか』——ほかの抽象化は関数やクラスで書くのに、ここだけ自然言語を使う理由が非技術者の可読性しかなく、それが実際に機能した例をほとんど見たことがない、というもの。

Q. エージェント時代にBDDの価値が上がるという主張の根拠は何か。
A. 自然言語で書かれた受け入れ条件が、そのまま実行可能なテストとエージェントへの指示を兼ねるため。仕様とテストの二重管理が減る。

エージェントに書かせる量を増やすほど、レビューという人間側のボトルネックが相対的に重くなる。形式仕様やモデル検査は、その負荷をレビューから機械検査へ移す手段だが、仕様を書くコスト自体は消えない。1983年の論文が指摘したのは、自動化後に人間へ残るのが「例外時の高難度判断」だけになるという構造で、これは43年後のエージェント運用にそのまま当てはまる。

Q. 確認コード方式の何が問題なのか。
A. アプリとメールクライアントの往復が必須で離脱率に直結する上、コードの有効期限・再送・レート制限を各サービスが個別に実装している。

リンタの性能はルール数ではなくASTの走査回数で決まることが多い。ルールごとに木を舐めるか、1回の走査で全ルールを同時に評価するかで、オーダーが変わる。