知の暗黒森林 (via) AI時代の世界がどうなっていくかについての、とても『三体』的なエッセイ（思考実験）でした。
かつてのウェブは「アイデアは安いが、実行は難しい。そして世界はチャンスに満ちている」もので、公開共有が合理的な行動だった。しかしウェブが統合され、AIによって実行コストが劇的に下がると、知の暗黒森林が出現する（そして皆が抵抗しようとするが、何らかの代償が伴う）、というようなことが書かれています。
また、ここでいう脅威は「森のどこかにある他の文明」ではなく「森そのもの」だというようなことも書かれています。（関連する自己回帰的なオチも面白いです）
私自身は1人の商人あるいは作り手として、今日も生き残りの道を探り戦々恐々としていますが、単にアイデアを喋ったり書いたりするだけで即座に森に還元されるのだとしたら、ある意味でそれは究極のインターネットであるようにも思います。
[...] しかしFDEは、ただこの問題を解決しているだけではない。FDEは別の問いを立てている — 次に同じ問題を抱える顧客が、自分を必要としなくて済むようにするには、この問題をどう解決すればいいか？
[...] FDEは単に顧客のために働いているのではない。FDEは顧客を通じてプロダクトに働きかけているのだ。
[...] これが指数関数的成長の姿だ。人間のアウトプットは、その人の稼働時間に制約されない。人間のアウトプットは、彼らが学んだことをプロダクトが吸収する能力によって制約されるのだ。
微分はプロダクトである。
[...] But the FDE isn’t just solving this problem. The FDE is asking a different question: how do I solve this problem in a way that means the next customer with this problem doesn’t need me?
[...] The FDE isn’t just working for the customer. The FDE is working on the product through the customer.
[...] This is what exponential looks like. The human’s output isn’t bounded by their hours. The human’s output is bounded by the product’s ability to absorb what they learn.
The derivative is the product.
※強調は引用者
この記事で主張されているように、AGIは既に達成されていると思います。汎用的(General)なAIを、私たちはほとんど誰もが利用することができます。
AIは既に自己改善的なループを回すことができます。AI自身で何度も検討を繰り返すことで、自律的に課題を見つけ、改善案を作り、検証することを繰り返すことができます。
にも関わらず、真の意味で自立成長するシステムが実現できない最大の原因は、AIがオーナー（人間）の目的や思想、判断基準を完全には知らないからであり、それはそもそも人間自身が自分の考えを言語化できなかったり、自分が本当に欲しいものを知らない（できたものを見てみないと想像できない）からではないかと思います。
そのため、私たちは時折ループの中に介入し、自分の理解を深め、判断の解像度を上げ、ループが正しい方向に進むように調整する、といったことをやっています。
実はこのパターンは私たちが既に直感的に理解していることだと思います。例えば:
（他にもっと良い比喩があるかもしれません）
「調整さえすればループの中身は信頼できる」という状態まで達したのは、個人的には比較的最近のこと（昨年末、Opus 4.5などが出てきた頃）だと感じていますが、AIのことを、盆栽における「木の成長」やウイスキーにおける「化学反応」ともはや同じようなものだと考えられるようになったと思うと、それはやはり物凄い変化であると感じます。
インターネットアーカイブの忘却との戦い 誰もが1度は見たことがある（かもしれない）インターネットアーカイブ（Wayback Machineで知られる）の「物理的な」姿をはじめて見ました。まさに図書館そのものです。
※写真: Beatrice Murch
私たちはインターネットを、地理も質量も持たない、はかない雲のようなものだと考えがちだ。しかしこの建物では、インターネットには重さがある。熱がある。電力が必要であり、メンテナンスが必要であり、熱力学第二法則との絶え間ない戦いが求められる。
現在は1兆を超えるウェブページを保管しており、容量にすると99ペタバイト（バックアップを含めると212ペタバイト以上）にものぼるとのこと。
創設者のブリュースター・ケール氏は元々検索エンジンを開発されていましたが（WAISはAOLに売却、AlexaはAmazonに売却）、ケール氏は「非営利の方が明らかに営利企業よりも長生きする」（出典）として意図的に現在の形態を選ばれたそうです。
効率性のパラドックス: ソフトウェア開発を容易にするたびに、私たちは指数関数的により多くのソフトウェアを書くようになった Addy Osmani氏（Google Cloud AIディレクター）による記事。「効率化すると需要が減ると予測しがちだが、実際には潜在需要が顕在化する」「ソフトウェアの歴史は抽象化レベルの上昇であり、今もその延長線上にいる」といった主張が見事に言語化されていました。
前者（需要はむしろ増える）については、例えば次のように語られています。
下がっているのは「コードを速く書けるようになる」という障壁だけではない。「ソフトウェアで解決することが経済的に割に合う問題の種類」が変わりつつあるのだ。 [...] そのコストを10分の1に下げれば、採算の取れるプロジェクトが爆発的に増える。
私自身もこのブログや個人的なツールをバイブコーディングするようになったのは、まさに「潜在需要が顕在化」したと言えます。
後者（抽象化）については、例えば次のように語られています。
私たちは同じ光景を以前にも見たことがある。ただ、もっと小さな領域での話だった。アセンブリからC、Pythonへ、そしてフレームワーク、ローコードへ。あらゆる抽象化レイヤーが同じパターンをたどってきた。どれも「これで開発者の数は減る」と言われた。だが実際には、どれもがより多くのソフトウェアを生み出すことを可能にしただけだった。
私がプログラミングに入門した2000年代でも、既に高度に抽象化されていました。抽象化レベルのかなり上の方から入門した私は、基礎が弱いことへの不安があると同時に、そのことがかえって野心的な挑戦をしやすくもしていました。これは現在のバイブコーディングでも似たようなことが起こっていると思います。
最後の方で、私たちが問うべきはこうであると語られていました。
本当の問いは、ボトルネックが「これを作れるか？」から「これを作るべきか？」へと移行した世界に、私たちが準備できているかどうかだ。それは根本的に異なる問題空間であり、根本的に異なるスキルを必要とする。
Show HN: I quit coding years ago. AI brought me back かつてプログラミングを諦めた人がAIの支援によって復帰したという話ですが、コメントで他の人が寄せているバイブコーディング事例も面白かったです。
例えば次のようなものがありました:
| 投稿者 | 背景 | 成果 |
|---|---|---|
| ivcatcher | 元プログラマー → エンジェルファンドの投資アソシエイト | 複利計算や住宅ローンなどの計算機 |
| ikidd | 元ネットワークエンジニア兼プロジェクトリード → 農家 | 土壌サンプル位置追跡、水分モニタリング、農場特有のタスク・スケジュール管理 |
| meetingthrower | 2000年代に技術PM → プライベートエクイティ投資家 | 請求書レビュー自動化、データダッシュボード |
皆さんそれぞれのドメイン知識が生きる領域で成果を上げられているのが印象的です。
なお、ほとんどの人は完全な初心者というよりは、何らかのプログラミング経験があることには注意が必要そうです。meetingthrower氏も次のように書いていました。
正直に言うと、私がやっている小さなアプリでさえ、フロントエンドとバックエンドがどう動くべきか、リレーショナルデータベースとは何か、といった背景知識がなければ作れなかっただろう。
スレッド全体は賛否両論が飛び交っており、現役エンジニアからは「AIがコーディングの楽しさを奪っている」「スキルの低下が心配」といった声も多く上がっていました。
My approach to running a link blog 年末年始にSimon Willison氏のこの記事を読み、自分のブログを再構築することを決意しました。彼のブログは今やHacker Newsで最も引用されるものであり(私も毎日読んでいます)、私のブログが彼のブログのようになれるとは思っていません。しかし、この部分に勇気づけられました。
[...] blogging doesn’t have to be about unique insights. The value is in writing frequently and having something to show for it over time—worthwhile even if you don’t attract much of an audience (or any audience at all).
[...] ブログは独自の洞察を披露する場である必要はないということです。価値があるのは、頻繁に書き続け、時間とともに成果を積み重ねることです。たとえ読者があまりいなくても（あるいは全くいなくても）価値があります。
彼のブログでは引用が多用されますが、「クレジットを表記すること」と「元記事とセットで読まれることでより充実した体験となるように付加価値を加えること」が重視されています。私もそれに倣っていこうと思います。
彼のブログのソースコードは公開されているので、Claude Codeと共にその仕様を調べました。基本的な構造は彼のアイデアに従っているので、見た目もかなり似ていると思います。
基本的な構造ができたら、SNS（主にX）等過去に書いたもののデータをエクスポートして、いくつかピックアップしてこのブログに転載しました。例えば2010年2月の投稿は元々TumblrとTwitterにあったものですが、15年以上昔に自分が興味を持っていたものを振り返るのは楽しい体験でした。
I sell onions on the Internet (via) 思いがけず落札してしまったドメイン名を元に玉ねぎのオンライン販売を始める話です。
Web開発者が野菜の直売をはじめるのは並大抵の行動力ではなしえなさそうですが、「ドメインを買っちゃったからやってみる」というのは良いきっかけ作りで、勇気づけられるストーリーだと思いました。（いつの時代もビジネスをはじめるのに完璧なタイミングなどないですからね）
ちなみに、創業から3年くらい経った頃にこんな話もあったそうです。
During a phone order one season – 2018 I believe – a customer shared this story where he smuggled some Vidalias onto his vacation cruise ship, and during each meal, would instruct the server to ‘take this onion to the back, chop it up, and add it onto my salad ‘. That story made me smile.
ある年の電話注文のときのことです。確か2018年だったと思いますが、あるお客さんがこんな話を聞かせてくれました。バケーションで乗ったクルーズ船にビダリアオニオンをこっそり持ち込み、毎食ごとにウェイターに「このオニオンを厨房に持っていって、刻んで、私のサラダにのせてくれ」とお願いしていたというのです。この話には思わず笑みがこぼれました。
Incentives are everything. [...] If a pilot is wrong, they might die in a crash. I trust pilots. If an engineer at TSMC is wrong about semiconductor physics, the chips won't work. I trust engineers. If an expert is wrong about Iraq having WMDs, we get into a long and costly war, innocent people die, and the experts face absolutely no consequences. [...] I trust experts when their incentives are strongly aligned with the truth. I completely distrust experts when their incentives are aligned with dishonesty
インセンティブがすべてだ。[...] パイロットが間違えれば、墜落で死ぬかもしれない。だから私はパイロットを信頼する。TSMCのエンジニアが半導体物理学について間違えれば、チップは動かない。だから私はエンジニアを信頼する。専門家がイラクの大量破壊兵器について間違えれば、長く費用のかかる戦争になり、罪のない人々が死に、そして専門家たちは一切何の責任も問われない。[...] 私が専門家を信頼するのは、彼らのインセンティブが真実と強く結びついているときだ。インセンティブが不誠実さと結びついている専門家は、まったく信頼しない
Everything I know about good system design (via) GitHubのエンジニアの方が書かれた秀逸な記事でした。
good system design is not about clever tricks, it's about knowing how to use boring, well-tested components in the right place
良いシステム設計とは、巧妙なトリックのことではない。退屈で、実績のあるコンポーネントを適切な場所で使う方法を知ることだ。
Paradoxically, good design is self-effacing: bad design is often more impressive than good. I'm always suspicious of impressive-looking systems.
逆説的だが、良い設計は目立たない。悪い設計のほうが、良い設計より印象的に見えることが多い。私は印象的に見えるシステムには常に疑いの目を向けている。
以前読んだ元造船技師の方の記事にも通ずるものを感じました。
オープンソースプロジェクトのメンテナンスもAIのおかげで随分と楽になったが、誰もが自前で同じ機能を簡単に作れる以上、残るものはメンテナーのビジョンやプロジェクトの「信頼と実績」くらいではないかとも思う。
「同じ機能を簡単に作れる」は議論の余地があるところだが、良くも悪くも、ほとんどのプロジェクトは重要な資産であるテストコードも公開されている。テストがあればAIが同品質のコードを書くチャンスはグッと高まる。
TIL: どんなURLでも先頭に r.jina.ai をつけるとコンテンツをテキスト化してくれるJina Readerは無料枠が豊富（500 RPM）。ちょっと前にElastic社に買収されてたみたい。
男はなぜ孤独死するのか 涙なしには読めない…そう、成人期の友情は「努力の結晶である」。一方で、最近は意図的に友人の近くで暮らそうとする人たちも増えているようなので、関連リンクを見つけたらぶら下げる。
※オリジナル: X
AI第一人者のひとりKarpathyさん、年齢も近くて最近のブログは庶民的な（？）ネタを分かりやすく書いているので勝手に親近感を持っていたけど、起業家向けのキーノートを見ると具体と抽象を縦横無尽に行き来しながら話しててそれだけでびびった🙃
※オリジナル: X
