私たちが作るべきソフトウェアにもっと野心的になろう

私たちが作るべきソフトウェアにもっと野心的になろう

今年初めから、Michael Malis（pgrustの作者）は、彼が行った興味深いことや言ったことを私に示してくれています。

私たちは、私たちが作るソフトウェアにもっと野心的になるべきだ。

pgrustのようなプロジェクトには、理解できることながら、多くの懐疑論があります。なぜなら、世の中には低品質なAI生成プロジェクトが非常に多く存在するからです。もし私がMalisを知らず、それを調べなかったら、pgrustも決して機能しないような、ただの「雰囲気重視」のプロジェクトだと決めつけていたでしょう。しかし、私はMalisをよく知っているので、彼の仕事は調べなくても信頼できます。そして、少し調べてみると、pgrustのテストにおいて、彼は非常に徹底的なテストを行っており、Postgres自体の実際のバグさえも発見していることがわかります。例えば、有効なSP-GiST操作を失敗させる可能性のある数値バグ、JSONPathからの不正な結果を引き起こす可能性のあるフォーマットキャッシュバグ、後続の操作を失敗させる可能性のあるpgcryptoバグ、辞書ローダーにおける複数のメモリ安全バグ[2]、マネーオーバーフローバグなどです。

これはpgrustにバグがないと言っているわけではありません[3]が、かなりの量のテストが行われていることを示しています。たとえpgrust自体が成功しなくても、その試みを行うだけでPostgresを永続的に改善することになるでしょう。pgrustの主なセールスポイントは実際にはパフォーマンスであり、そこにこそ本当に興味深い作業が行われています。もしpgrustが失敗した場合、彼らが実証した最適化の一部がPostgresやClickhouseなどに組み込まれる可能性がありますが、それはPostgresのバグを報告して修正してもらうことよりも明らかに間接的です。

とはいえ、ニュースアグリゲーターでpgrustが議論されるたびに、ほとんどの人がそれを「雰囲気重視のゴミ」として却下するのは理解できます。なぜなら、これらの書き直しプロジェクトのほとんどすべてがゴミだからです。もし私がMalisを知らなかったら、私も同じように仮定したでしょう。なぜなら、誰がこれらのプロジェクトすべてを調べる時間があるでしょうか？私がMalisを知っているからこそ、私はそれを調べる手間を省き、彼を信頼しました（上記のバグは、この投稿の例としてpgrustを使用したいと思ったときに確認しただけです）。

ソフトウェアの消費者として、どこを見ても、作成者が高速だと主張している遅いソフトウェアが見られます。なぜなら、作成者は「雰囲気重視」のベンチマークを喧伝しているからです。例えば、昨日見た複数の例のうちの1つです。そしてもちろん、機能しない低品質なソフトウェアは、かつてないほど一般的になっています。

しかし、ソフトウェアの構築者としては、これらのプロジェクトのほとんどすべてが「雰囲気重視」であること、他の人々が大量のゴミを世に送り出し、それを金と呼んでいることは関係ありません。あなたはpgrustのようなものや、過去には実現不可能だったほど大規模なプロジェクトを構築できます。そして、テストとベンチマークを適切に行えば、それらのものは実際に使用に足る品質になる可能性があります。

もし私が書くなら、「私たちが作るソフトウェアにもっと野心的になれる」と言うでしょう。「なるべきだ」とは言いません。しかし、Malisは私とカジュアルにチャットしていたときにこれを言ったので、彼も実際の投稿では同じことを言うかもしれません。ここでは「べき」と「できる」の間に深読みしないでください。私にとって興味深いのは、能力がどのように進歩し、私たちがより多くのことができるようになったかということです。

例として、OpenAIが最先端モデルにCerebrasを使用すると聞き、単に高速だが低品質なモデル（例: 5.3-Codex-Spark）だけでなく、最先端モデルを使用した場合に私のコンピューターでの時間の使い方を調べました。もし私が最先端モデルを使用し、それが10倍から100倍高速になったら、すでにボトルネックになっていたいくつかのことがさらに悪化するでしょう。それらは以下の通りです。

1. Ripgrep
2. Rustのコンパイル
3. システムコールとファイルシステムオーバーヘッド

「動作すれば良い」レベルのプロジェクトとして、これらはすべて大幅に改善できるものです。現時点ではあまり空き時間がありませんが、それでも、私が気にする特定のワークロードでは他の汎用正規表現ライブラリよりも高速になるように調整できる正規表現エンジンを構築しました。私のcodex ripgrepワークロードでより高速になるネイティブコードコンパイラを使用したripgrepのフォークも構築しました（もちろん、テキストインデックスの方が良い解決策ですが、すでにテキストインデックスに取り組んだことがありますし、これは「ただ楽しむため」のプロジェクトで、最適なことをしようとしていたわけではありません）。また、私のプロジェクトのビルドを高速化したRustも構築しました（コールドビルドでは大幅な改善、ウォームビルドでは中程度の改善、Rustコンパイラのフロントエンドをフォークすることを避けたいという制約がありました）。システムコールとファイルシステムオーバーヘッドについては、開発をMacからLinuxに切り替えるだけで大幅に改善されました。もちろん、これも同様に大幅に高速化できるものであり、特にエージェントが多数の小さなファイルシステム操作を連打する場合に顕著です（標準OSのファイルシステムインターフェースが最新のディスクパフォーマンスを考慮して設計されていないため、私のマシンがファイルシステム操作を待っているのを見ることは珍しくありません）。

正規表現、文字列マッチングアルゴリズム、コンパイラ、インタプリタなどについて何も知らない私のような人間にとって、これらのプロジェクトのセットは「動作すれば良い」品質に到達するのに1年以上かかったでしょう。代わりに、これは私の時間で数時間で済むものでした。これらのいずれかを「有用な製品またはオープンソースプロジェクト」の品質基準を満たすようにしたい場合、それはさらに多くの作業が必要になります[0]が、それでもプロセスがどれほど高速化されたかは驚くほどです。

以前言及した別のプロジェクトは、マッチした時間制御において超人的な能力を持つAzul AIでした。私がそれを（GPT-5.1/5.2で）行ったとき、AIの知識はゼロでしたが、超人的な能力を持つものを作るのに約5時間、当時の最強と思われるAIになるのに約20時間かかりました。Board Game Arenaで不正行為に使用されたAIよりも強力でした。最近、Gabriel Cangussuが私のAIを打ち負かすAIを構築しましたが、私のAIが私にかかった時間よりも大幅に短い時間で済んだようです。彼との会話から、主な違いは、Fable 5.1とOpus 5.5がボードゲームAIをはるかに良く理解していることです。私がGPT-5.1/5.2を使用したとき、彼らの提案はほとんどすべて間違っており、まともなものにするために多くの誘導が必要でした。もしGPTにコードベースや論文を読ませて論文の関連技術を実装させようとしても、失敗しました。もし私が自分で論文を読み、技術の名前を挙げると、その技術を使ったと言うのですが、私が主張されたことを実行したかどうかを確認するために、それが何であるかについて十分な知識を学ぶ必要があるため、モデルが正しいことを実行できる状態からほど遠い場合、モデルが主張したことを実行したかどうかを確認するのはかなり時間がかかります。

そのプロジェクトを行ったとき、私は友人に、現在のモデルの状態は持続しないだろうと言いました。モデルがすぐに論文を読んで技術を実装できるようになるのは不可能に思え、コードベースや論文を選んで盗むこともできるようになるはずでした。Fable 5とCangussuのFable 5.1とOpus 5.5での私の経験から、それは起こったようです。これは、ボードゲームAIについて何も知らない私のような人間にとって、大きな時間節約になります（今では少し知っていますが、実際のAI研究者よりは少ないです）[4]。

ボードゲームAIのような特定のドメインについて、「誰が気にする？ボードゲームAIは重要ではない」と言うことができます。しかし、私はこの能力の増加がかなりの数の異なるドメインで真実であることを発見しました。例えば、GPT-5.6 Solがzstdをmediumとxhighで実装した検証およびテスト技術のトイ評価を行いました。まだ書き上げる時間がありませんが、その投稿を公開したときに、GPT-6 Astraで評価を再実行しました。6 Astraは、TDD（テスト駆動開発）を使用するなど、パフォーマンスを著しく低下させる条件でも、すべての登録済みテストを99%以上の確率でパスするほど優れていました（ちなみに、zstdを実装するのに約1ドルしかかからず、より安価です）。最終的にはIMAP RFCを使用しました。これは5.6 Solでは効果的に実行できませんでしたが、Pandocも同様です。Pandocは、多くの異なるフォーマットを読み書きできる必要があるため、実装するにはかなり重要なものです[5]。

ところで、人々が新しいモデルを使ってすべてがうまくいった、ソフトウェアは解決された、などと言ったとき、私はそれが全く真実だとは思いませんでした。新しいモデルでワンショットでできることが増え、物事が基本的にうまくいくようになったのは事実ですが、これは私がモデルがまだ苦労している、より野心的なことに取り組むようになることを意味するだけです[6]。私はより生産的になり、より速く作業できますが、私がやっていることに関しては、モデルがかなりの手助けなしに効果的に検証できることと、モデルが実装できることとのギャップが増大しているため、より能力の高いモデルごとに「うまくいくだけ」から遠ざかっています[7]。これらすべては、私たちが作るソフトウェアにもっと野心的になるべきだと言うための、長くて雄弁でない方法です。

コメント/修正/議論をしてくれたLaurence Tratt、Yossi Kreining、Alex Kolovsky、Michael Malisに感謝します。

最近の投稿にもこの注意書きを載せていますが、これもこの投稿に当てはまります。より多くの投稿を公開するために、私は30分で投稿を書き上げるように努めており、あまりレビューしていません。これは間違いなく、サポートの少ない投稿につながります。もし私が標準的なスタイルでこれを書いていたら、言及したすべてのプロジェクトについて包括的なベンチマークを用意していたでしょう。代わりに、私の好奇心を満たす簡単な比較を行い、厳密なベンチマークなしでこれを書き上げています。この投稿には、やりたいけれどまだできていないことが20〜30個あるかもしれません。

付録: 私たちはソフトウェア構築においてもっと野心的になるべきではない

Yossi Kreininからのコメントを（もちろん許可を得て）引用します。

もしあなたがこれを公開するなら、私は、ほとんどの人にとって、AIでソフトウェアを構築する際にはもっと野心的になるべきではない、さもなければ壊滅的な失敗を経験するだろうと説明する応答を公開します。多くの問題は「エージェントループ」にはあまり適していないと思います。なぜなら、明確な合格/不合格基準がないからです。そして、たとえそれがあったとしても、ほとんどの人は、制約を課すことはできるが内部を理解できない巨大なブラックボックスについて推論するのが苦手です（私もその一人です）。これはマイクロサービスに似ているかもしれません。一部の人々はそれを必要とし、それを非常にうまく使用しますが、ほとんどの人にとっては、それをあまり必要とせず、うまく使用できません。野心的であるべきで、実際にできる人たちを羨ましく思います。もちろん、全く野心的になるべきではないと言っているわけではありませんが、現在の状況を処理する上で、野心を抑えることが多くの人にとって大きな部分だと思います。

ちなみに、私は「ソフトウェアが遅い理由はない」についても同様の考えを持っています。多くの場合、AIを使ってあるフローを高速化すると、テストしたユースケースに過剰適合した、厄介なコードが追加され、ケアすべきすべてのユースケースに対してパフォーマンスが一般化せず、将来の変更に対して保守性も低くなります。あなたが何をしているのかを知っており、システムがどのように部品に分解されるべきか、そしていつ一部またはそれらが連携して動作する一部を最適化することが理にかなっているのか、そしてそれを適切にベンチマークする方法などを理解しているなら、それは素晴らしいことです。しかし、例えば、ソフトウェアが遅い理由はないと考えており、ランダムな部分を高速化するためにAIを使用するように人々をプッシュするマネージャーがいる場合…逃げてください。

私の考えでは、全体として、状況はAIが100倍または1000倍の生産性向上をもたらすと言うときの話についての議論に少し似ています。非常に大きな要因で高速化されるものがあります。そして、全く高速化されないものもあります。5年前にやっていたことをそのままAIで行っても、アムダールの法則のために、パフォーマンスの向上はかなり悪いです。しかし、一般的なケースでは、何を高速化するかを選択でき、生産的なことを探している場合、それはしばしば以前は高すぎたことを行うことになります。

そして、ほとんどの人がそうしない場合でも、ある種の自己チェック機能を持つシステムをセットアップできることが多いと思います。Guards of Atlantis 2の実装に関するこの議論はその例です。これはAIプロジェクトには不向きな選択です。なぜなら、公式ルールは曖昧で矛盾した英語のテキストの混乱であり（人間が最も高い割合で誤ってプレイするのを見たゲームであり、ルールはデザイナー自身がルールをそのまま読めばプレイできると常に主張しているにもかかわらず、自分のルールの意味についてしばしば考えを変えるほど混乱しています）、単純な方法で動作するルールのセットを作成しようとしても、AIはあまり役に立ちません（クリーンな仕様があれば実装は高速化できますが）。しかし、そのためには、ゲームルールの矛盾した説明すべてとの間で、ある種のぎこちない一貫性チェックのセットアップを行うことができ、かなり正確なルールのセットに近づきました（はるかに多くの人間の労力と体系的でないアプローチで他の人が行ったことと同程度）。このセットアップは、より手動なアプローチよりもトークンを多く消費しました。しかし、それは、私がゲームのクリーンな仕様、つまり実際に一貫性があり正しいルールのコピーを作成するために座って作業する時間よりも、OpenAIサブスクリプションの月200ドルで「わずか」1〜2ヶ月でした。

多くの問題は、このような問題のクラスにあると思います。人間が少量の時間を費やすことで、少なくとも部分的に自己チェックできるセットアップを構築することが可能です。これは、ソフトウェアテスト全般の状況とも似ています。コーディングエージェントが登場する前は、ファジングとプロパティベーステストが非常に効果的であることに気づきました。ほとんどのドメインで、人々は私に、この種のテストはうまくいかない理由をいくつか教えてくれましたが、人々がこれらのテクニックはうまくいかないと言ったすべてのドメインで試したとき、それらはうまく機能しました。適用するには多少手間がかかりますが、それでも適用可能であり、私が確認した限りでは、従来の単体テストを作成するよりも効率的で効果的です。

Yossiのコメントの要点は、人々がこのようなことをしていないということです。私が以前よりも多くのバグを見るようになったことを考えると、例えば、大規模なAIラボのWebチャットを開いたとき、1分以内に二桁のバグに遭遇しました。Yossiが間違っているとは言えません。しかし、その点に関して、私は依然として元の意見を持っています。他の人々がほとんど機能しないスロップを大量に生産しているからといって、あなたも同じことをしなければならないわけではありません。

付録: いくつかの「ランダム」な例

投稿本文で私が挙げた例は、私が決して行わなかったであろうツールに関するものです。私が個人的に「動作すれば良い」品質のツールを構築するのが非常に簡単になったため、他にもそのようなものがたくさんあります。生産性を超えてしまう可能性があるとも思いますが、例えば、Steve YeggeはGas Townについて、それがどれほど生産的だったかについて多くを書いていますが、次のエージェントフレームワークを構築していたとき、彼はGas TownをGas Town以外のものを構築するために成功裏に使用したことがないと指摘しました。人々はRalph Loopsにしばらく夢中でしたが、比較してみると、私が当時行っていた単純なことをするよりも悪いように思えました。つまり、コンテキストを必要に応じてクリアする通常のループであり、単一のターンが完了したという完全に任意な時点でクリアするのではなくなどです。そのため、影響が直接的なものに留まるようにしてきました。これが効果的であるという明らかな理由に加えて、モデルとハーネスの能力の劇的な変化は、構築するのに意味のあるツールの種類が非常に速く変化することを意味するため、特定のツールに多くの時間を費やすことは、せいぜい最適ではなく、おそらく3ヶ月で時代遅れになる可能性があるため、あまり意味がありません。

そして、私の個人的なツールの多くについて、AIラボがいずれ私の作ったものを時代遅れにするだろうと想定しています。非常にくだらない例として、GPT-5.6 Solのリリース以来役立っている、メモリリークを見つけるとコードネームを再起動するツールがあります。おそらく、OpenAIはいずれこれを修正し、このツールは無価値になるでしょう。もう少しくだらない例としては、エージェントに構築させたRustインタプリタがあります。トークン予算の理由から、非常に高性能なインタプリタのために行うべき多くのことが行われていません。

例えば、インタプリタは実際のRustフロントエンドコンパイラを変更して、アップデートを簡単に受け取れるようにしていません。Rustフロントエンドに変更を加えるだけでパフォーマンスは大幅に向上しますが、Rustコンパイラのフロントエンドをフォークして維持するトークン予算がありません。しかし、これはOpenAIにとっては問題ないはずです。OpenAIは、Cerebrasへのアクセスを得るために100億ドル以上を費やし、同時にAnthropicがアクセスできないようにしました。

面白いことに、コーディングに関しては、多くのタスクで、実際の最先端モデルを使用し、Anthropicから得られるものと比較すると、Rustのコンパイルなどの時間のため、実際の速度向上はそれほど大きくありません。彼らがこれに100億ドル以上をコミットする用意があったことを考えると、彼らは最終的に、AIラボの外で誰かが現実的にできるよりも、関連ツールを高速化する上でより良い仕事をするだろうと推測できます。そのため、これにあまり多くの労力を費やす意味はあまりありません（非コーディングタスクが近い将来のOpenAIの収益を完全に支配すると予想される場合、これは議論の余地があるかもしれませんが、トークンに対する彼らの支払いと私が支払うものを考えると、私がラボの外でできることを考えると、彼らがこれらの多くを高速化することは依然として理にかなっているように思えます。おそらく、彼らの使用データにアクセスできるというような議論があるかもしれませんが、このボトルネックはそれほど重要ではないため、優先順位をつける必要はないかもしれませんが、それでも彼らにとってはいつか意味があるはずです。たとえそれがCerebras対応コーディングエージェントのトップ100のボトルネックに入らないとしても）。

野心的とは言えないかもしれませんが、可能なことの種類を示す別の種類のものは、私が作ったゲームです。私が考えたが、一般的に十分に楽しいとは思えず、実際のオーディエンスには意味がないゲームがありますが、私はプレイしたかったのです。例えば、90年代にDavid GerroldのStar Wolfの本を読んで以来、私は本に描かれているような戦闘、つまり潜水艦戦闘のようなものを実装したゲームをプレイしたいと思っていました。少なくとも現実的な戦争ゲームの中では、このジャンルは非常にニッチです。なぜなら、ほとんどの人が海戦を退屈だと感じ、潜水艦戦闘は海戦ゲームの特に退屈なサブジャンルだからです。そのため、これは金儲けゲームとしてはあまり意味がありませんが、ゲームを実装するのは非常に簡単なので、エージェントにゲームを実装させて、1〜2時間プレイできるようにしました。1〜2時間プレイするためにゲームを実装するのに10〜20時間費やすことは決してありませんでしたが、5分なら費やします。また、以前にScoutと同じルールでゲームを実装したことやGuards of Atlantis 2についても言及しました。私たちは対面で集まることができない機会に友人と遊ぶために、これらのゲームを手作業で実装する時間を決して取るつもりはありませんでしたが、LLMがこれらのものを素早く作成してくれるのは嬉しいです。そしてもちろん、より広いオーディエンスを持つゲームを作りたい人にとっては、コーディングエージェントのおかげで、現在ゲームのルネッサンスが起きています。プログラミングスキルとそれらを活用する時間があれば、ゲーム作成のボトルネックがなくなったため、現在作られている興味深く創造的なゲームの数は驚くほどです。

データ分析は、生産性乗数が非常に高く、私がこれまで決してやらなかったようなあらゆる種類のことを行えるもう一つの分野です。過去の多くの投稿で言及したように、これらのプロジェクトが多すぎて、非常に速く書こうとしても、投稿を書き上げることはできません。1件あたり30分で書き上げるとしてもです。

人々が作成したワンオフツールについて話したとき、人々がやった楽しいことがたくさんあります。例えば、Peter Geogheganが1〜2ヶ月前に言及したことです。

彼はFableに、私の非常に具体的な好みに従ってコードをフォーマットするカスタムNeovim Lua関数を実装させました。これは、自分でメンテナンスしたくないものであり、本質的にルーブ・ゴールドバーグ・マシンです。理論的には、clang-formatをパッチすることで同様の結果を原理的に達成できますが、私の要件は非常に正確であるため、そのアプローチでは決して満足できないと思います。

私たちはpgindentというツールを使用しています。これはbsd_indentのフォークです。clang-formatを使用して同様のフォーマットルールを近似できますが、それは十分ではありません。pgindentに従って完全にフォーマット/インデントされていないものをコミットすると、CIで失敗し、迅速に修正することが期待されます。これは避けたいことです。

実際には、コードの誤ったインデントに関するメール通知を回避する、clang-formatスタイルの洗練されたフォーマットを実現するには、完全なアーキテクチャ上の混乱が必要です（原理的なアプローチを開発する時間もかけたくありませんが、それは実際には別の問題です）。この関数により、clang-format LSP統合と同様に、Neovimからコードのブロックを簡単にフォーマットできます。私はここで不当にうるさいですが、LLMのおかげでツーリングに対してこれほど厳格になれると感じています。

この関数は複数のパスを実行します。最初のフォーマットパスはclang-format/clangdを使用し、別のフォーマットパスはpgindentを使用します。clang-formatがpgindentが見落とす一部のケースを正しく処理するため、両方を行う必要があります。これは壊れやすいです。なぜなら、パッチによって追加されたコードの範囲内でのみフォーマットしたいからです（選択した行の範囲外のコードにclang-formatを実行したくありません）。これはpgindentの設計と競合します。pgindentはCファイルを全体としてしかフォーマットできません。

バッファ内の影響を受ける正確なC AST要素に直接マッピングされない、一時的な全体ファイルバッファの関連部分の正確なサブセットをワーキングバッファにコピーバックする方法を特定するのは簡単ではありません。最初に選択した行の範囲は、影響を受けるC AST要素に直接マッピングされません。そのため、この関数はツリーシッターを使用して、一時的にインデントされたCコードの正確なサブセットを区別します。ルールは、同じコードブロックにまたがる選択の場合に、正確に正しい方法で曖昧である必要があります。エッジケースが多数あります。

さらに複雑な要因として、pgindentは型を識別するためにobjdumpを使用して生成されたtypedefファイルに依存しています。そのファイルがないと、フォーマットは奇妙に見えます。フォーマット関数は、そのファイルのためだけにclangdから追加のtypedefを動的に生成します。そのため、古いtypedefファイルについて心配する必要はありません（フォーマットツールを実行する数秒前に新しい構造を作成した可能性があります。毎回Postgresバイナリ全体をobjdumpを実行するのは、レイテンシが爆発するため、やりたくありません）。

これは完璧に機能するようです。レイテンシは完全に許容範囲内です。しかし、これがどのように機能するのかについては、漠然とした理解しかありません。Luaさえ知りません。これは、bsd_indentのフォークに加えられたさらなる変更によってコードのフォーマット方法が多少変更されたとしても、おそらく機能し続けるでしょう。これは時々起こります。

SaaSocalypseについては懐疑的ですが、LLMが、他の方法では書くのが非常に非経済的だったであろう多くの有用なソフトウェアを書いているとは思います。人間がメンテナンスするのが不可能に面倒であり、それが生み出す価値と比較して、非常に小さいサブセットのソフトウェアがあります。

この投稿を執筆中にMalisとも話しましたが、彼がやっている多くの楽しいことを知りました。それを詳細に書き出すだけで別の投稿になるほどですが、面白いことの一つは、前回pgrustの検証について彼と話したとき、彼はコードの一部を検証するためにKaniを使用したことに言及しました。彼はその後Leanに切り替え、Kaniでは複雑すぎるものをLeanで検証しています。これも別の投稿のトピックになるでしょうが、なぜ人々は一般的にLLM駆動の証明のためにLean（例えばACL2ではなく）を採用しているのか疑問に思います。Leanがこの定理証明器比較の更新版でどのように見えるか、あるいは誰かがこの言語評価に類似した定理証明器評価を実行した場合どうなるか疑問に思います。

もちろん、AIラボの外にも多くの例を考えることができます。例えば、中規模チームのAnthropicは5ヶ月でGitHubの内部代替品といくつかの他のツールを構築しました。

7人のチームが、ScionとAntique（コードレビューツールで、別のブログ記事全体を費やすこともできます）の両方を構築し、さらに半ダースの関連システムを構築し、5ヶ月で完全に移行しました。

これらの例は興味深く、遠くない未来の業界の方向性を示していますが、無制限のトークンを使用して、他の無制限のトークンで構築されたインフラストラクチャとツールに依存してできることは、今日の無制限の資金なしで達成できることについてはあまり教えてくれません。pgrustのようなプロジェクトや、私が知っている人々が余暇に行っているプロジェクト（私が言及したのはおそらく1%に過ぎません。非常に多くのプロジェクトがあります。例えば、David Turnerが、彼が見つけられるどんなものよりも優れた「動作すれば良い」品質のポッドキャストスキッパーを作成したこと、Dennis Snellがここで言及した余暇プロジェクトなど）は、今日できることのより代表的なものです。

---

1. この投稿では、「ambitious」という言葉を、私にとって一貫性があると感じられる方法で使用しますが、過負荷であると主張することもできます。私はこれを、一般的に、以前よりも多くのことを行うという意味で使用しています。以前は合理的に実行可能だったよりも大きなプロジェクトを構築することと、以前は実行可能だったが構築する価値がなかっただけの超特殊なツールを構築することとの違いがあると言う人もいるかもしれません。これらは非常に異なるものですが、どちらも同じこと（ソフトウェアの生成がはるかに容易になったこと）から派生していると思います。そのため、この議論の余地のある定義にかなり満足しています。［戻る］
2. Alex Kolovskyは、これらはバグとは見なされないと指摘しました。セキュリティの観点からの議論は理解できますが、Postgresに関する具体的な意見を述べるには十分な文脈がありません。しかし、私が取り組んだプロジェクトでは、このような問題を取り除くことを好みました。なぜなら、コードをこのような問題からクリーンにしようとすると、実際のバグを見つけやすくなるからです。［戻る］
3. Malisを信頼する理由の1つは、彼が典型的な創業者よりも、自分の主張についてずっと慎重であることです。例えば、pgrust Discordに参加して人々が何を言っているか確認したとき、Malisからのメッセージを見ました（1ヶ月前、2026-09-17、エージェントコーディングの世界では永遠ですが）。生産データベースとしての使用準備について尋ねられた人への返信です。

今日、それを主要な本番データベースとして使用することは推奨しません。現在、ある企業のために本番環境へのデプロイメントを設定していますが、ほとんどの人よりも本番データベースのダウンタイムに対して寛容な企業です。彼らがそれを実行し始めたら、pgrustの信頼性について良い経験的証拠が得られるでしょう。

Malisは、多くの有名なプロジェクトがそうしてきたように、明らかに準備ができていないものを本番準備ができていると主張するような人物ではないようです。そして、彼はそうしていません。

このドラフトを公開の1週間前に書きましたが、公開する時間がありませんでした。それ以来、pgrust Clickhouseベンチマーク論争がありました。これを調べたところ、悪意のある不正行為の告発は偽であるように見え、ベンチマークにpgrustのプレビューを提出するのが時期尚早だったという告発は、Malisが認めたものです。これは、プロジェクトが決して忘れられない種類のことであり、真実に関わらず、人々は何年も後でこれを持ち出すだろうと思います。この特定の論争に関する議論で、Ed Zitronの予測実績を見たときやKurzwilのような未来予測者を見たときと同様に、実際に何が起こったかを見る人はほとんどおらず、人々は感覚に基づいた誤った声明を無期限に繰り返します。

Malisを信頼する理由のすべての証拠を提示することはできないと思います（技術的には可能ですが、それは簡単に20,000語以上の投稿になるでしょう）。しかし、彼がpgrustをどのように議論しているかを見ると、典型的なデータベース創業者が新しいDBプロジェクトをマーケティングする方法とは劇的に異なっているように思えます。もちろん、MongoDBのような極端な例もあります。Kyle Kingsburyがデータ破損に関する逸話を繰り返し示していたにもかかわらず、長年その正確性の問題を争っていました。より典型的な例として、友人がデータベーススタートアップの初期従業員として働いていました。彼らのウェブページは、膨大な数のQPSを誇っていました。それをテストしたところ、友人はその主張が桁違いにずれていることを発見し、ウェブページを変更することを提案しました。創業者は、パフォーマンスの数値に到達するつもりだったので、まだ真実の主張だと同意しませんでした。数年間のパフォーマンス改善の後、会社は最終的に主張を1桁減らし、それでも非常に複雑で非現実的なワークロードでのみその数値を達成できます。これは残念ながら、パフォーマンスに基づいた製品を売り込んでいる会社にとってはかなり普通のことです。対照的に、pgrust Discordを見てMalisがパフォーマンスについて何を言っているかを見ると、彼の最新のメッセージは次のとおりです。

現在、最も役立つ方法は、0.4-betaでバグやパフォーマンスの問題を見つけることです。新しいクエリエンジンは一部のワークロードでは非常に高速ですが、他のワークロードではパフォーマンスの低下を引き起こし、より複雑なクエリの一部をサポートしていません。Postgresよりも遅いものやエラーが発生するものをすべて追跡しようとしています。実行できるクエリの巨大な範囲を考えると、簡単なことではありません。

0.4-betaの一般リリース前にこれらの問題を修正したいと考えています。思いつく限りでは、非常に高速なクエリで大きなパフォーマンス低下がありました。これは、新しいクエリエンジンを主に大規模なOLAPライクなワークロードのために最適化したためです。非常に遅いクエリを修正するための最適化作業を行っています。新しいエンジンが、高速クエリに関しては以前のものよりも遅くなる根本的な理由はないと思います。

彼は以前、成功したスタートアップの創業者兼役員であったにもかかわらず、ほとんどの創業者が持つような、何でも言えて信じられるような考え方には決して陥りませんでした。これは低い基準だと言う人もいるでしょうし、私も同意しますが、それでも珍しいと思います。そして、それが私が彼がpgrustについて言っていることを調べずに信頼した理由であり、また、調べたときに彼の主張が現実によって裏付けられているように見えた理由でもあります。［戻る］
4. オンラインでの不正行為の増加に関するこのコメントは現実のものとなりました。私が書いた実際のコメントを読み直すと、不正行為の増加が避けられないように思えるということを明示的に書いていませんでしたが、それらを組み合わせることで推測できます。私は公の場で（Discordなど）そのように発言してきました。

オンラインゲームシーンはフォローしていませんが、Azul（BGAで最も人気のあるゲーム、モダンボードゲームの最大のオンラインボードゲームプラットフォーム）では、前シーズンのトップ10の順位のうち3つが不正行為者によって占められたと聞いています。また、過去に他の場所で指摘したように、BGAはほとんどどのレベルでも合理的なポリシー決定を行う能力がないようです。Eloレーティングアルゴリズムのメカニズム、ゲームシーズンの構造、談合に対抗するポリシー、不正行為に対抗するポリシーなど、すべてが最も単純な直接的な解決策よりも劣っています。そのため、予想通り、合理的なポリシーがありません。最も人気のあるゲームのトップランクは不正行為者で溢れており、これは他のゲームにも広がるはずです。AIによる害としては、これはかなり無害なものです。単に、先週見た二桁の例のうちの1つに過ぎず、人々が作るソフトウェアでもっと野心的になっているというものです。これを挙げているのは、定量化しやすいためと、私がこれが起こると予測し、何が起こったかを確認するのは合理的であるためです。

［戻る］
5. Pandocは、{html, docx, xlsx, pptx, csv, markdown, gfm, commonmark, commonmark_x, markdown_strict, markdown_mmd, markdown_phpextra, markdown_github, rtf, epub, odt, tsv, latex, ipynb, mediawiki, rst, asciidoc, bibtex, biblatex, org, typst, jira, docbook, endnotexml, ris, opml, dokuwiki, textile, man, mdoc, jats, csljson, fb2, pod, vimwiki, djot, creole, tikiwiki, twiki, t2t, haddock, muse, json, xml, native}を入力フォーマットとして、{pdf, html, html4, docx, plain, pptx, markdown, gfm, commonmark, commonmark_x, markdown_strict, markdown_mmd, markdown_phpextra, markdown_github, rtf, epub, epub2, odt, latex, ipynb, mediawiki, rst, asciidoc, asciidoc_legacy, bibtex, biblatex, org, typst, bbcode, bbcode_phpbb, bbcode_steam, bbcode_xenforo, bbcode_fluxbb, bbcode_hubzilla, jira, docbook, docbook4, revealjs, beamer, opml, dokuwiki, textile, man, texinfo, context, jats, jats_publishing, jats_articleauthoring, tei, icml, opendocument, csljson, fb2, ansi, chunkedhtml, djot, xwiki, zimwiki, vimdoc, haddock, markua, muse, ms, slidy, s5, dzslides, slideous, json, xml, native}を出力フォーマットとしてサポートしています（nativeはPandocのASTのシリアライズバージョンです）。［戻る］
6. ところで、これは多くのユースケースにおいて公開評価をあまり意味のないものにします。なぜなら、私やモデルを使用している他のプログラマーがしばしば気にするのは、モデルが人間のガイダンスを必要とするタスクでどれほど優れているかであり、モデルにとって些細なタスクでどれほど優れているかではないからです。［戻る］
7. これは未来に関する主張ではありません。おそらく、私が持っているソフトウェアスキルのほとんどすべて、あるいはすべてが近い将来無関係になるでしょう。しかし、私たちはまだそこには到達していません。現時点では、プログラミングスキルはこれまで以上に高いレバレッジを持っているように思えます。現在の瞬間には少し面白いことがあります。モデルが置き換えているスキルを持っている人が、モデルをスキルなしで使用しようとする人よりもはるかに効果的であるように見えるということです。Max Bittkerのフレーミングが好きです。モデルは偽造品を作るのが非常に得意であり、偽造品と本物を見分けるのに必要な専門知識のレベルは、モデルの改善とともに増加しています。［戻る］