DIY、メイカー運動、インディー、パンク、オープンソースはすべて産業化、資本主義、消費主義への反論なのに、その限界を乗り越える方法が消費主義を受け入れることだなんて。

バイブコーディングが消費フレームにふさわしいという点には同意します。最近流行していたTemu買い、Ali買い（https://asiae.co.kr/article/…
ただ、消費フレームがメイカー運動の失敗を繰り返さない方法だというのなら、HNのコメントのようにいろいろな面で同意できませんね。

バイブコーディングは、市民開発者の歴史的な流れを受け継いでいる。
バイブコーディングは今や、コーディングをまるで電気のように、簡単で速く、不可欠な存在へと進めていると思う。
すでに多くの企業の天才的なプログラマーたちも、コードを1行も書かずに、プロンプトとエージェントでコーディングを続けている。
これを過小評価しようとする人たちもいるが、アンドレイ・カルパシーのバイブコーディングがコンピュータ史に一線を画す出来事であることは、反論しがたいと思う。

良い質問です。実際、私たちの実験における「ハイブリッド」条件は、まさにその方向でした。つまり、整理された要約に生の経験ログをあわせて提供する構成です。

結果として、ハイブリッドが4.95/5.0で最も高くなりました。要約だけだと2.65ですが、そこに「失敗した」「原因不明」といった過程の記録を付け加えると、むしろ要約の弱点が補われることが分かりました。

したがって結論は、「要約そのものが悪いのではなく、過程と不確実性を一緒に含める必要がある」ということです。

ただし N=1 なので、さまざまなユーザー層に対して汎用的に使える内容かどうかは、今後の研究が必要です。

では、合成メモリにそうした作業のプロセス、失敗、成功の内容を含めるように構成すれば、少しは変わるのでしょうか？

その通りです。私も最初は、合成メモリは少なくともベースラインよりは良いだろうと予想していましたが、結果を見て驚きました。

分析してみると、核心は「不確実性の保持」でした。生のログには「これを試したがうまくいかなかった」「原因はわからない」といった痕跡が残っているので、エージェントはわからないことにはわからないと答えるのですが、要約版ではそうした文脈がすべて消えてしまい、かえって間違った答えを自信満々に出すようだったのです。

経験的にある程度そう感じてはいたけれど、合成メモリは自分の考え以上にあまりにも悲惨ですね

試してみようと思ったんですが、Gemini 2.5までしか対応していないんですね……対応モデルのリストもバイブコーディングで作ったんですかね

興味深いですが、単に自分たちのトークンを多く使って、コストを多く取れる方向に進化しただけなのではないかという気もしますし、実際ある程度のライブラリはAIが学習してそのまま作っているのではないかとも思います。
エージェントの選好によって特定のライブラリだけが発展していくことを考えると、少し複雑な気持ちにもなります。

結局、米国防総省がAnthropicを見限ってOpenAIを選んだ形ですが、いわゆる言い回しの違いがありますね。

OpenAIは、技術的な安全装置の構築、FDE（現場エンジニア）の投入、クラウド専用デプロイといった具体的な履行メカニズムをあわせて提案
Anthropicは利用規約レベルの例外条項を求めた

国防総省の立場では、**「民間企業が個別のユースケースに拒否権を行使する」**と受け止めて、見せしめのように発表したと。

この合意は、Anthropicがサプライチェーンリスクに指定されてからまもなく発表されたのですが、
Axiosの記事を見ると、国防総省はAnthropicとの対立を他のAI企業との交渉でトーン設定に使い、
OpenAIはその圧力の中で、国防総省が受け入れられる形で合意をまとめたわけですね。

公式見解の表現の違いも大きいですね。

Sam Altmanは**「国防総省は安全に深い敬意を示した」と言い、
Anthropic側は最後まで「国防総省の要求には良心に照らして同意できない」**というトーンでした。

同じ原則でも、国防総省に面子を立てるかどうかの違いが大きかったように見えますが、
結果的にはOpenAIが受け入れたことでAnthropicだけが不格好に見える構図になったので、
サム・アルトマンが最後に「この条件をすべてのAI企業に同じように提案してほしい」と付け加えて、
Anthropicへの措置を緩和してほしいという迂回的なメッセージを送ったようにも見えますね.

ただミニマルなままでいてくれないかな……？
それか、ワードパッドがなくなったんだから、新しくもっと軽いものを出してくれるとか……

ソロ開発者として7つのプロジェクトを運営しているのですが、この記事は痛いほど身にしみます。

AIコーディングツールのおかげで初期開発のスピードは狂ったように速くなりましたが、テストなしで急いで積み上げたコードは、結局リファクタリング地獄になるんですよね。特に複数のサービスを同時に運営していると、テストのないプロジェクトは機能を1つ触るたびに他のところが壊れるのではないかと怖くて、手を入れるのが恐ろしくなります。

「テスト = moat」というたとえは正確です。競合がコードをコピーすることはできても、数千ものエッジケースをカバーするテストスイートまで複製するのは難しいでしょう。特にAIはコード生成は得意でも、意味のあるテストシナリオを作るのは、まだ人間のドメイン知識が必要な領域だという点で、なおさらそうです。

開発者のみなさんにお聞きしたいのですが、なぜ最近はほとんどのプロジェクトがGolangよりもRustで開発されることが多いのでしょうか？ 最大の理由は、GCの有無なのでしょうか？

これ、かなり良かったです

興味深い研究ですね。特に「Build vs Buy」で 12/20 のカテゴリが DIY だという点が印象的です。

私たちも AIエージェントのペルソナ標準（Soul Spec）を作りながら似たような観察をしましたが、Claude Code に CLAUDE.md や AGENTS.md でツールを明示しないと、自分流に実装する傾向がかなり強いです。

この研究の「Recency Gradient」が示唆しているのは、新しいツールが Claude の基本スタックに入るには、学習データで十分に露出しているか、プロジェクトのコンテキストファイルに明示的に指定する必要がある、ということだと思います。結局、Context Engineering がツール選択まで左右するわけですね。

元のデータセットも公開されていて良いですね: https://github.com/amplifying-ai/claude-code-picks

米合“中国”

Assistive agent optimization (AAO) と呼ぶそうです。

開発者向けツールは、これからはエージェントたちに好まれる製品になることが重要になりました。
エージェントが話題にもしなければ、だんだん遠ざかっていきます

Ralph loopも少し前に追加されましたし、Financial skillも追加されたのを見ると、ただ待っていれば3rd partyツールにあったものがすぐに取り込まれてくる感じですね

Astro*

個性で翻訳することもできるでしょう