Piのミニマリズムはその利点である

Piのミニマリズムとその利点 AIはコードを安価にし、その結果として多くの企業がより良いパフォーマンスを求めてより大きなツールを構築しています。より大きなプロンプト、より多くのオーケストレーション、より多くのレイヤー、より多くの複雑さ。これにより、これらのツールの使用コストも本質的に高くなります。Piは反対のアプローチを取ります。Piは、意図的にミニマリズムを選択したコーディングハーネスです。標準でわずか4つのツールしか搭載しておらず、システムプロンプトとツール定義は1,000トークン未満です。その考え方は、ほとんどの作業は基本的なもので行うことができ、もしさらに多くの機能が必要なら、自分で構築すればよいというものです。Piの設計が単にクリーンであるだけでなく、より安価でパフォーマンスが高いという証拠が増えています。ユーザーは、Piに拡張機能を追加してユーザー固有のワークフローやニーズに合わせる前から、バニラPiが業界をリードする結果を生み出していることに気づいています。DatabricksとShopifyの事例研究で見るように、Piは両社にとって理想的な成果をもたらしました。 事例研究 Databricksスタディ：タスクあたりのコスト Databricksは最近、「Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase」という調査結果を共有しました。彼らの研究の目的は、どのコーディングエージェントが実際のコーディングタスクで最高のパフォーマンスを提供するか、そしてタスクパフォーマンスが価格によってどのように変化するかを理解することでした。過飽和状態になった外部ベンチマークからのバイアスを避けるため、彼らはチームのエンジニアが日常的に行うタスクに基づいて独自のベンチマークを作成しました。結果は私たちが予想する通りですが、業界の多くの人が驚いたかもしれません。彼らの言葉を借りれば、「...モデルが呼び出されるハーネスは、コストと品質に劇的な影響を与え」、「多くの場合、Piのようなシンプルなハーネスが私たちのワークロードで最良のパフォーマンスを発揮しました」。Databricksが作成した図。 Opus 4.8、xhighと組み合わせると、PiはClaude CodeやCodexよりも大幅に低いコストで、全体的なパスレートが最も高くなりました。 ミニマルハーネス、測定可能な効果 Piが輝くのは、モデルを多くのデフォルト設定や指示でラップしようとせず、それらが指示階層の中で失われることがないからです。代わりに、Piはモデルの邪魔をせず、チームはワークフローに必要なものだけを追加できます。Databricksの研究は、モデルとハーネスを分離しているため洞察に富んでいます。彼らは、同じモデルを同じ思考努力で異なるハーネスで実行したところ、「タスクあたりのコストは大幅に異なり（場合によっては2倍以上）、品質は同じままでした」と報告しています。私たちはこれをPiの「コンテキスト規律」と呼んでいます。「Piはターンごとに約3分の1のコンテキストしか送信しませんでした。コンテキストをより良く管理し、よりタイトなワーキングセットを維持し、より少ない実行回数でタスクを完了しました。」 私たちは、トークンあたりの価格だけでなく、エンドツーエンドのエンジニアリング経済性を考慮する必要があることに同意します。そしてこれはモデルレベルでも同様です。例えば、複雑なワークフローをHaiku 4.5で実行すると、特にコード実行が関わる場合、エージェントがタスクを正常に完了するために多くのターンを必要としたため、Sonnet 4.6よりも高価になることがよくありました。今、私たちはハーネスレベルでもこれを見ています。パフォーマンスの高いハーネスを持つ、より強力で高価なモデルは、その逆よりも安価になる可能性があります。 ShopifyはPi Autoresearchを構築：拡張性が肥大化に勝る ミニマリズムはPiのコア哲学の一部です。これが機能する理由は、ミニマルであることが柔軟でないことを意味しないからです。実際、これは拡張性と自己編集のために作成された、広く使用されている最初のエージェントインフラストラクチャです。Piの設計に対するもう一つの洞察に富んだ外部検証は、Shopifyからのものです。Shopify Engineeringのこの投稿で、David Cortésは、単に「Pi、[に] Autoresearchのための拡張機能を作成して...」と尋ねるだけで、Pi拡張機能としてpi-autoresearchを直接構築したと説明しています。Piは自身の拡張機能ドキュメントを読み込み、そこから新しいワークフローの構築を開始します。Autoresearchは、コーディングエージェントによる最適化のための自律ループです。変更を要求すると、何が機能し、何が後退を引き起こすかを見つけるために実験を実行します。ターゲットが測定可能である限り、これらの後退を排除し、自己改善を続けることができます。Shopifyやその他の企業にとって、Autoresearch拡張機能はすぐに真剣な内部生産性ツールとなりました。Shopifyは、ユニットテストが「300倍高速」になったり、Reactコンポーネントのマウントが「20%高速」になったり、複数のプロジェクトでビルド時間が短縮されたり、pnpmのパフォーマンスが向上したりする事例を報告しています。Shopifyのpi-autoresearch GitHubリポジトリからの画像。 ここで重要なのは、Piはこれらのツールのいずれも標準で出荷していないということです。代わりに、それらを構築することを非常に簡単にしています。ベンダーがあなたのワークフローを知っていると仮定して、あらゆるツールを出荷しようとするのではなく、Piはあなたが最良を知っていると仮定し、あなたのワークフローを操作して作成するための拡張性をあなたに与えます。 なぜ今ミニマルが勝つのか 約1年前、モデルがそれらの周りに構築されていたため、ネイティブハーネスが他のすべてのハーネスに対して構造的な利点があるという議論が成り立ちました。しかし、この議論は弱まっています。フロンティアモデルは現在、ターミナル（またはターミナル風）のコーディング環境を理解し、その中で行動することに非常に長けています。Anthropicが最近Claude Codeのシステムプロンプトを80%削減したことは、その明確な兆候です。したがって、問題はハーネスのネイティブ性よりも、コンテキストをどのように処理して冗長性を回避し、クリーンなプリミティブで行動するかになってきています。モデルは環境へのクリーンなインターフェースと、コンテキストを無駄にしないハーネスを必要としています。Piはこれを実現します：プロンプトのオーバーヘッドと繰り返しのコンテキストが少なく、実行コストが低く、不要な抽象化が少ないです。拡張性があるため、パワーを失うことはなく、選択性が増します。複雑さは「その価値がある」場合にのみ追加されます。私たちはまた、ローカルモデルが急速に発展しているのを見ており、Earendilではそれらを非常に有望だと考えています。Piのコンテキスト規律は、特にここで資産となります。ローカルモデルは通常、コンテキストウィンドウが小さく、プリフィルに時間がかかるため、安定したプロンプトプレフィックスを維持することが重要です。コンテキスト規律とは、ユーザーが明示的に要求しない限りコンテキストを変更しないことを意味し、数分かかる再プリフィリングを回避します。最小限のデフォルトシステムプロンプトとツールセットと組み合わせることで、Piはローカルモデルにとって理想的なハーネスとなります。Piはすべてを管理できることを証明しています。より安価で、ミニマルで、そしてパフォーマンスが高くなるように。