[...] しかし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.

※強調は引用者

— Isaiah Granet

AIと盆栽

この記事で主張されているように、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の支援によって復帰したという話ですが、コメントで他の人が寄せているバイブコーディング事例も面白かったです。

例えば次のようなものがありました:

皆さんそれぞれのドメイン知識が生きる領域で成果を上げられているのが印象的です。

なお、ほとんどの人は完全な初心者というよりは、何らかのプログラミング経験があることには注意が必要そうです。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のエンジニアが半導体物理学について間違えれば、チップは動かない。だから私はエンジニアを信頼する。専門家がイラクの大量破壊兵器について間違えれば、長く費用のかかる戦争になり、罪のない人々が死に、そして専門家たちは一切何の責任も問われない。[...] 私が専門家を信頼するのは、彼らのインセンティブが真実と強く結びついているときだ。インセンティブが不誠実さと結びついている専門家は、まったく信頼しない

— Paul Buchheit

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.

逆説的だが、良い設計は目立たない。悪い設計のほうが、良い設計より印象的に見えることが多い。私は印象的に見えるシステムには常に疑いの目を向けている。

以前読んだ元造船技師の方の記事にも通ずるものを感じました。

If you want to be cool, go join someone else. If you want to make others cool, join Microsoft.

もしあなたがクールになりたいなら、他の会社に行くといい。他の誰かをクールにしたいなら、マイクロソフトに来るといい。

— Satya Nadella , Microsoft CEO