プログラミング
開発ツールはオープンソースであるべき
Devtools must be open source (blog.exe.dev)
要約
AIエージェントの進化により、ソフトウェアのパーソナライゼーションが驚くほど容易になりました。かつてはコストが高く非現実的だったカスタムツールの開発や維持が、AIエージェントがソースコードの理解、変更、アップストリームとの同期を自動化することで、ROIが劇的に向上しました。これにより、開発者は自身のニーズに合わせてツールを柔軟にカスタマイズできるようになり、ソフトウェア開発のあり方が根本的に変化する可能性を示唆しています。
全文翻訳
5年前、私が話したほとんどのソフトウェアエンジニアは、自分で書いたプログラムを持っていませんでした。(Tailscaleがエンジニアの生活にどのように適合するかを理解しようとして、この質問をよくしていました。)一日中、毎日、エンジニアは他人が書いたプログラムを使って、他の人のためにプログラムを書いています。多くの人は、設定ファイルやプラグイン、拡張機能を通じて、使用するプログラムをカスタマイズし、自分で書いたプログラムをユーザーとして使用していました。自分で書いたものについて尋ねて、オフザシェルフの、ほとんど適切なサイズの静的サイトジェネレーターやZigbeeアプライアンスではなく、ブログやホームオートメーション、ホームラボのために書かれたカスタムソフトウェアについて知ることは、常に珍しい喜びでした。この状況は私にとって理にかなっていました。長年、私は自分で plenty のソフトウェアを書いてきましたが、そのリターンは常に疑問でした。1日に書ける量には限りがありました。常にやるべきもっと重要なこと(Something Was Wrong At Work)があり、1年後にプロジェクトに戻ってメンテナンスを行うことは常に非常に苦痛でした。私のキャリアの中で、カスタムソフトウェアをすべて捨てて、最も標準的な環境を使用してコードを生成した年もたくさんありました。Googleでのエンジニアとしての初期の頃は、個人用コンピューターすら持っていませんでした。それは過去の話です。今は違います。
ソフトウェアをパーソナライズする方法
今日、ソフトウェアをパーソナライズすることは驚くほど簡単です。これらすべてを可能にするエージェントへのプロンプトには、主に2つの一般的なカテゴリがあります。
<software> のソースをダウンロードして、ローカルで使用できるようにビルドしてください。
<whatever memory your agent uses> を変更して、このソフトウェアへの将来のすべての変更がソースの変更と現在のバージョンの置き換えを意味することを認識させてください。
変更の背後にある元の動機をバージョン管理に記録してください。
そして、より重要なこととして:
次のナイトリー cron ジョブを設定して、プロンプトを実行してください:<software> のアップストリームの変更を取得し、すべてのローカル変更をアップストリームの上にリベースしてください。
ソフトウェアが意図したとおりに機能することを確認し、現在のバージョンを置き換えてください。
これらの中核にあるのは、エージェントが特定の用途のためにコードをハックするだけでなく、アップストリームリリースとの変更の同期プロセスを自動的に管理できるという認識です。これは、エージェントがソフトウェアのカスタマイズに対するROIを2つの側面から同時に変更することを意味します。パーソナライゼーションを開始するのがはるかに簡単になり、継続するのもはるかに簡単になります。
ソフトウェアを編集するための上記の2つのプロンプトのもう1つの驚くべき点は、それらをエージェントに直接組み込めることです。エージェントがオープンソースである限り、プログラミングすら必要としません。2つのプロンプトはスキル(つまり、いくつかのテキスト指示)にロードされ、エージェントが発見できる場所に配置できます。私たちはこれをShelleyに組み込んだので、今、Shelleyを編集したい場合、前置きやタイマーの設定すら必要ありません。それはあなたのためにそれを処理します。あなたは「ShelleyのUIをハイコントラストにして」のようなプロンプトを入力するだけで、エージェントをパーソナライズできます。
パーソナライゼーションの実例:ShelleyとMeat
私は過去1ヶ月間、 idle にいじっている個人的なプロジェクトがあります:meat.dev。
原則は、エージェントがコードを書く一方で、私はそれを真剣なシステムにプッシュする前に読み続けるということです。
基盤となるモデルが改善されるにつれて、私が探すものは変化しました。
私が20年間レビューしてきた人間は、常にエッジケースに苦労してきました。エラーは有用な情報を提供するか?nilチェックは処理されているか?など。(私たちは皆それをします。コードを書くとき、私は最悪の違反者の一人です。)
レビュアーとしての私の役割の1つは、これらの詳細を探すことでした。
過去6ヶ月間、私はもはやエッジケースのようなものを読む必要がないことを発見しました。モデルは、ルーチン的な正確さにおいては人間よりもはるかに勤勉です。それらのエラーは、アーキテクチャ、予期しないユースケース、テスト環境がフィードバックしていないビジュアル出力などに限定されます。
これは、私がレビューするコードのほとんどの行があまり役に立たないことを意味します。
そこで、diffを受け取り、LLMを使用して重要でない部分を削除するツールを書きました。
私は、インポートブロック、nilチェック、またはエラー処理を見る必要がほとんどないので、画面から取り除いて、肉(meat)に集中できるようにしました。
このツールは気に入っていますが、2つの欠点があります。第一に、ターミナルではなく、良いUIを持つShelleyでdiffを読みたいです。第二に、LLMがdiffを消化して最小化するのに数分かかり、待ちたくありません。
したがって、理想的にはコマンドラインでmeatを実行するのではなく、Shelleyに組み込み、コミットが作成された瞬間にプリプロセスしたいです。
それは単一のプロンプトで実現できることがわかりました。
meat.devをShelleyに組み込んでください。
最新バージョンをPATHにインストールしてください。
Shelleyによってgitコミットが作成されたら、バックグラウンドでコミットの処理を開始してください。
Shelley Diffsビューにmeat用のトグルを追加してください。
コミットがまだ処理中の場合は、ユーザーに処理中であることを示してください。
この単一のプロンプトは、meatをShelleyに追加するだけでなく、レビューのためにセッションに戻る前にバックグラウンドでコミットを適切にプリプロセスするのに役立ち、モデルがdiffを削減するのを待つ時間を節約しました。
モデルが選択した唯一残念な点は、トグルボタンに🥩絵文字を使用したことです。
VS Code拡張機能APIにそれを接続しようとするような、複雑で苦痛な状況を想像してみてください!あるいは、vimdiffにそれを組み込もうとする場合。
それは確かに可能でしょうが、コミットが出現するとすぐにプリプロセスを開始するための仕組みは、ほぼ不可能でしょう。
ファイルシステムを監視し、カスタマイズAPIが使用できるmeatツールのキャッシュを提供する、帯域外のmeatdを実装する方が良いでしょう。なぜなら、拡張と設定のポイントが適切な形状にならないからです。
そして、それが従来の構成/カスタマイズとエージェント駆動のパーソナライゼーションの根本的な違いです。より多くのことができます。
エージェントは、ソースコードを理解し、特定のタスクに合わせて変更するという大変な作業を行います。
パーソナライゼーションにより、私たちが使用するソフトウェアははるかに強力になります。
必要なのはソースコードだけです。
パーソナライズされたソフトウェアの時代
エージェント開発前のコストにより、複雑なソフトウェアに大規模な設定ファイル、拡張システム、プラグインシステムをバンドルすることが合理的でした。
Vimのような中規模プロジェクトでさえ、コアコードは巨大で複雑であり、人間が理解するには数週間かかります。
行番号をデフォルトで表示したいと思ったときに、エンジニアがコードベースを学習して自分だけのために追加するという考えは不合理です。
他の人と共有するために設計する方が良いでしょう。これにより、多くのユーザーに償却することで、実装のコストが正当化されます。
コードベースの機能が増えるにつれて、共通の抽象化を探して、拡張機能やプラグインシステムに分解することが理にかなっています。
今や、コードを学習して変更を加えるコストは劇的に低下しました。
エージェントが重労働を行います。
単一のユーザー — プログラムが実行される非常に制約された条件を意味する — の場合、トップエンドのエージェントは通常、単一のショットで機能を追加できます。
単一ユーザーソフトウェアの場合、慎重なコードレビューの必要性は、「うまくいっているように見えるか?」で置き換えられることがよくあります。
その結果、パーソナライズ可能なソフトウェアはプラグインシステムや設定ファイルを必要としなくなります。
テキストエディタのフォントサイズを変更したいですか?エージェントにソースを与えて、それを実行するように指示してください。
ハードコードされた値であれば、それを見つけて編集します。
ハードコードされたビットマップフォントであれば、別のものをダウンロードして置き換えるか、Monobitを使用して作成します!
あなたは驚異的な能力をオンデマンドで利用できます。
ソフトウェア製品の全カテゴリが再発明される必要がある
パーソナルソフトウェアは、小規模チームにもよく適用できます。
エンジニアリングチームが、非常に設定可能なタスクマネージャー(またはCMSやCRM)を購入し、それを学習・設定するのに時間を費やし、チームをその限界にまで歪める理由は何でしょうか。共通のビルディングブロックから、望む機能だけを組み立てることができるのに。
初期の固定コストと