今さらですが、Cline紹介（ほぼ自分の記録用）
はじめに
長期インターン先の部署で、Clineについて紹介する機会があったので（勝手に自分でまとめてみただけですが...）、せっかくだから自分の記録としても残しておこうと思い、書いてみました。内容はほとんどそのまま反映しています。
Clineとは？
Clineは、VSCodeなどのIDE上やCLIで動作する自律型のAIコーディングエージェントです。複雑なソフトウェア開発タスクを段階的に処理する能力を持っています。VSCodeの拡張機能としても提供されています。
まずは、Clineを知る上で、個人的に最初に読んでほしいコンテンツを紹介します。おすすめの資料は2つです。
おすすめコンテンツ1：CLINEに全部賭けろ
Cline関連の記事で、一番バズってると思います。
中身を見ると、まず下記のブログ記事を読んでほしいとのこと。
オライリーメディアの創立者、ティム・オライリーさんが書いていて、重みがありますね。
一応、この記事の全文和訳（by Claude）は、本ブログの最後に載せています。
記事の要約はそのままコピペしてしまいますが、
- Steve Yegge 氏は、置き換えられるのはジュニアおよび中級レベルのプログラマーではなく、新しいプログラミング ツールやパラダイムを受け入れず過去に固執するプログラマーであると指摘しています。
- これはプログラミングの終わりではありません。最新の再発明の始まりです
ところで、優れたコーディング等で絶賛されているClineですが、苦手なことがあります。それは、コンテキストの保持です。
一定の長さを超えると前の話を忘れやすいです。モデルにもよりますが、claude-3.7-sonnetを選択した場合、Context Windowは200kトークンが上限です。複雑なプロジェクトではすぐにこの上限に達し、重要な前提事項を「忘れる」ことになりがちです。Clineのメモリーバンク機能は、この忘却問題を解決するための仕組みです。詳細は、後ほど紹介するメモリーバンクの項目をご参照ください。
おすすめコンテンツ2：エンジニアに許された特別な時間の終わり
こちらもバズった資料。とても読みやすいです。
Clineは「自律的にコーディング・デバッグ・設計といったタスクをこなしてくれる」と言われますが、「自律的に」とはどういうことか分かりやすいです。特に、LLM ChatとCline（を含むAIエージェント）の違いですね。
Clineruleとは？
Clineの動作を、プロジェクト固有の要件に合わせてカスタマイズするための設定ファイル（.clinerules）です。どのように応答するかを制御するためのルールや設定を記述します。
メモリーバンクとは？
メモリーバンク（Memory Bank）は、Clineのコンテキストウィンドウの制約を克服するための機能です。AI言語モデルにはコンテキストウィンドウ（AIが一度に理解し、記憶できるテキストの長さ）に制限があるため、大規模なプロジェクトやコードベースを扱う際に課題となります。
（参考：モデルごとのコンテキストウィンドウ）
メモリーバンクを使うことで、重要な情報や頻繁に参照される知識をClineが記憶することができ、コンテキストウィンドウの制限を超えた情報の保持と活用が可能になります。タスクを実行する前にメモリーバンクの中身（memory_bank内のファイル群）を読ませることで、AI自身で書いた「プロジェクト手帳」を毎回開いて復習するような動きをさせることができます。
メモリーバンクへの書き込み（更新）は基本的にCline自身が行います。タスクの完了時などに、Clineはそのタスクで生じた重要な情報（例えば新しく決まった仕様や修正内容）を対応するファイルに追記・修正します。メモリーバンクの主要な6つのマークダウンは以下の通りです。
イラストは、こちらの記事から引用させて頂きました。
インターン先の部署で、Clineの初期設定を投入したときは、上記で紹介されているマークダウンに加えて、databaseSchema.mdも生成されました。このファイルには、DBスキーマ設計パターンや、テーブル間の関係性などが含まれています。
インターン先で今後やりたいこと
clineruleの改修を行いたいです。
- まずは、「主要なテーブル」から見直したいです。Cline自身にどんなテーブルを「主要」なテーブルと見なしているか聞いたところ、選定理由がかなり曖昧だったので、人力で修正する必要がありそうです。
- 今後clineruleをフォルダ化して、アクティブルールと非アクティブルールに分けて運用するのも良さそうです。
メモリーバンク関連の参考資料
補足
2点だけ補足として載せておきます。
- PerplexityのDeep ResearchにClineについて色々聞いてみた
- ティム・オライリーさんブログの全文和訳（by Claude）
PerplexityのDeep ResearchにClineについて色々聞いてみた
自分はChatGPTには課金しておらず、Deep Researchを使えないので、Perplexityを使いました。
指示
Clineについての社内のエンジニア向けドキュメントを作りたい。以下の4点を含めて、ドキュメントとしてまとめて。 英語で調べて、日本語で出力して。
- clineとは何か
- 従来のコーディングツールとの違いは何か。特に、GitHub CopilotやCursorと比較したときに、clineが優れている点、劣っている点は何か
- clineruleとは何か
- clineのコンテキストウィンドウの制約を克服する、memory bankとは何か
出力
とても長い&読みづらくなってしまったので、本ブログでは割愛させて頂きます。ご興味ある方は、ぜひ試してみてください。
ティム・オライリーさんブログの全文和訳（by Claude）
テキストメディアでは、ソフトウェア開発者がすぐにAIに仕事を奪われるという話が多く出回っています。私はそれを信じていません。
プログラミングの終わりではありません。私たちが今日知っているようなプログラミングの終わりなのです。それは新しいことではありません。最初のプログラマーは物理的な回路を接続して各計算を実行していました。彼らの後継者は、コンピュータの前面にあるスイッチを切り替えることで1ビットずつ入力するバイナリコードとして機械命令を書いていました。そして、アセンブリ言語プログラミングがそれに終止符を打ちました。これにより、プログラマーは人間に近い言語を使用して、データをメモリ内の場所に移動させ、その上で計算を実行するようコンピュータに指示できるようになりました。その後、Fortran、COBOL、そしてその後継のC、C++、Javaなどのさらに高水準のコンパイル言語の開発により、ほとんどのプログラマーはもはやアセンブリコードを書かなくなりました。代わりに、より高いレベルの抽象化を使用してコンピュータに要望を伝えることができるようになりました。
最終的に、デバッグがはるかに簡単な解釈型言語が標準となりました。
これらの中で最初に大ヒットしたBASICは、最初はおもちゃと見なされていましたが、すぐに未来の波であることが証明されました。プログラミングは、大企業や政府機関のバックオフィスの神官だけでなく、子供やガレージの起業家にもアクセス可能になりました。
コンシューマーオペレーティングシステムも大きな役割を果たしました。パーソナルコンピュータの初期には、すべてのコンピュータメーカーは、メモリボード、ハードディスク、モデムやプリンタなどの周辺機器への読み書きを行う低レベルドライバを書くことができるソフトウェアエンジニアを必要としていました。Windowsはそれに終止符を打ちました。それは単に未訓練の個人がコンピュータを使用するのをはるかに簡単にするグラフィカルユーザーインターフェイスを提供したからだけでなく、Marc Andreessen（彼の会社Netscapeはまさにマイクロソフトに圧倒されようとしていました）が軽蔑的に（そして間違って）「ただのドライバの集まり」と呼んだものも提供したからです。Win32 APIを前面に出したそのドライバの集まりは、プログラマーがマシンを制御するために低レベルのコードを書く必要がもはやないことを意味しました。その仕事は効果的にオペレーティングシステムにカプセル化されました。Windows、macOS、そしてモバイルではiOSとAndroidにより、今日、ほとんどのプログラマーは以前の世代のプログラマーが知っていたことの多くをもはや知る必要がなくなりました。
プログラマーは少なくなるどころか増えました しかし、これはプログラミングの終わりからは程遠いものでした。プログラマーの数は過去最多でした。何億人ものユーザーが彼らの創造性の成果を消費しました。需要の弾力性の古典的な実証として、ソフトウェアの作成が容易になるにつれて価格が下がり、開発者はより多くの人々が支払いたいと思う解決策を作成できるようになりました。
ウェブもまた「プログラミングの終わり」でした。突然、ユーザーインターフェイスは人間が読めるドキュメントで構成され、リンクを通じてリモートサーバー上のプログラムを呼び出すことができるブラウザで表示されるようになりました。最小限のプログラミングスキルでシンプルな「アプリケーション」を誰でも構築できるようになりました。「ノーコード」がバズワードになりました。すぐに誰もがウェブサイトを必要としました。WordPressのようなツールにより、非プログラマーはコーディングなしでそれらのウェブサイトを作成できるようになりました。しかし、テクノロジーの能力が向上するにつれて、成功するウェブサイトはますます複雑になりました。「フロントエンド」と「バックエンド」のプログラミングの間にますます分離が生じました。PythonやJavaScriptのような新しい解釈型プログラミング言語が主流になりました。モバイルデバイスは新しい、どこにでもあるフロントエンドを追加し、新しいスキルを必要としました。そして再び、複雑さはフレームワーク、関数ライブラリ、APIの背後に隠され、プログラマーは数年前には必須だった低レベルの機能について多くを知る必要がなくなりました。
ビッグデータ、ウェブサービス、クラウドコンピューティングは一種の「インターネットオペレーティングシステム」を確立しました。Apple Pay、Google Pay、Stripeのようなサービスにより、最小限のプログラミング専門知識で以前は難しかった高リスクの企業タスク（支払いの受け取りなど）が可能になりました。あらゆる種類の深く強力な機能がシンプルなAPIを通じて利用可能になりました。しかし、インターネットサイトとそれらを接続するネットワークプロトコルやAPIのこの爆発的な増加は、結局より多くのプログラマーの必要性を生み出しました。
プログラマーはもはや数年ごとに更新される静的なソフトウェア成果物を構築するのではなく、長寿命のサービスを継続的に開発、統合、維持するようになりました。さらに重要なことに、Google検索、Google Maps、Gmail、Amazon、Facebook、Twitterのようなこれらの巨大なサービスでの作業の多くは、大規模に自動化されていました。プログラムはAIではなく人間によって設計・構築されましたが、作業自体の多くは今日の汎用AIの特殊目的の先駆者によって行われていました。これらの企業で重労働の大部分を行う労働者はすでにプログラムです。人間のプログラマーは彼らのマネージャーです。現在、このような監督作業を行うプログラマーは数十万人います。彼らはすでにデジタル同僚を作成・管理する仕事の世界に住んでいます。
これらの各波において、古いスキルは時代遅れになりました—まだ有用だが不可欠ではなくなり—そして新しいスキルが成功の鍵となりました。コンパイラを書くプログラマーはまだ少数おり、人気のあるJavaScriptフレームワークやPythonライブラリを書く人は数千人いますが、ウェブやモバイルアプリケーションとそれらを可能にするバックエンドソフトウェアを書くプログラマーは数千万人います。何十億人ものユーザーが彼らが生産するものを消費しています。
驚くことではありませんが、ウォートン・スクールの教授でAI伝道者のEthan Mollickもまた、Bessenの研究のファンです。これが彼が「常にAIをテーブルに持ち込む」こと、仕事のあらゆる側面にそれを関与させること、そして何が機能して何が機能しないかの「ギザギザの端」を探索することを説得力をもって主張する理由です。また、彼が企業にAIを使用して労働者を置き換えるのではなく、彼らに力を与えるよう促す理由でもあります。新しいテクノロジーの適用方法について学ぶことはとても多いのです。ビジネスの最良の応用研究開発源は、あなたが持っている人々の探索であり、彼らがAIを使用して問題を解決し、新しい機会を求める時です。
プログラミングの形は変わるでしょう マイクロソフトの副CTOの一人であるSam Schillaceは私の分析に同意しました。最近の会話で、彼は私にこう言いました。「私たちはAIシステムを中心に新しいプログラミングパラダイムを発明する途中にいます。デスクトップからインターネット時代に移行したとき、スタックのすべてのレベルは同じでしたが、スタック内のすべてが変わりました。私たちはまだ言語を持っていますが、コンパイル型から解釈型に変わりました。私たちはまだチームを持っていますが、ウォーターフォールからアジャイルからCI/CDに変わりました。私たちはまだデータベースを持っていますが、ACIDからNoSQLに変わりました。私たちは単一ユーザー、単一アプリ、単一スレッドから、マルチ分散、何でもありに移行しました。私たちは今、AIでも同じことをしています。」
以下は、新しいAIスタックに組み込まれているテクノロジーの一部です。そしてこれにはAIモデル、そのAPI、そのクラウドインフラストラクチャの多数は含まれていません。そしてそれはすでに時代遅れです！今回は違うかもしれません 突然、非プログラマーが単にLLMや特殊なソフトウェアエージェントと平易な英語（または選択した人間の言語）で話し、Pythonで（または選択したプログラミング言語で）有用なプロトタイプを得ることが可能になったようです。これには新しいバズワードもあります：CHOP、つまり「チャット指向プログラミング」です。高度な推論モデルの台頭は、実行すべきタスクを説明する高レベルのプロンプトで複雑なプログラムさえも生成できるAIを示し始めています。その結果、「今回は違う」と言う人々が多数います。AIが人間のプログラマーのほとんど、そして実際、ほとんどの知識労働者を完全に置き換えるだろうと。彼らは、広範な人間の失業の波に直面していると言います。
私はまだそれを信じていません。高度なコンピューティングパワーをはるかに大きなグループの人々の手に入れるブレークスルーがあるとき、はい、一般の人々は以前は高度に訓練された専門家の領域だったことを実行できるようになります。しかし、同じブレークスルーは新しい種類のサービスとそれらのサービスに対する需要も可能にします。それは少数の人々だけが理解する新しい種類の深い魔法を生み出します。
今やってくる魔法は、これまでで最も強力なものです。そしてそれは、私たちが深い探索と創造性の時期を始めていることを意味し、その魔法をどのように機能させ、その力から新しい利点を引き出すかを理解しようとしています。テクノロジーを採用するスマートな開発者は、価値を追加する高レベルの創造性に焦点を当て、はるかに多くのことができるため、需要があるでしょう。
実践による学習 AIはプログラマーを置き換えることはありませんが、彼らの仕事を変革するでしょう。最終的に、今日プログラマーが行うことの多くは（組み込みシステムプログラマー以外の全員にとって）オシロスコープを使ったデバッグの古いスキルと同じくらい時代遅れになるかもしれません。マスタープログラマーで先見の明のあるテクノロバザーバーのSteve Yeggeは、置き換えられるのはジュニアやミッドレベルのプログラマーではなく、新しいプログラミングツールやパラダイムを受け入れるのではなく過去にしがみつく人々だと指摘しています。新しいスキルを獲得または発明する人々は非常に需要があるでしょう。AIツールをマスターしたジュニア開発者はそうでないシニアプログラマーよりもパフォーマンスが良くなる可能性があります。Yeggeはこれを「頑固な開発者の死」と呼んでいます。
私のアイデアは、Yeggeのような開発者の観察だけでなく、過去40年以上のコンピュータ産業での自分の経験や、1800年代初頭のマサチューセッツ州ローウェルの繊維工場で最初の産業革命がどのように展開されたかを研究した経済史家James Bessenの研究にも形づけられています。熟練した職人が「未熟練」労働者が操作する機械に取って代わられるにつれて、人間の賃金は確かに下がりました。しかし、Bessenは新しい産業工場の労働者の賃金記録と以前の家庭基盤の職人のそれを比較することで、何か特異なことに気づきました。徒弟職人が熟練した職人の完全な賃金に達するのにかかる時間は、新しいエントリーレベルの未熟練工場労働者が完全な賃金と生産性に達するのにかかる時間とほぼ同じでした。両方の体制の労働者は実際には熟練労働者でした。しかし、彼らは異なる種類のスキルを持っていました。
Bessenが発見した、産業革命の最初の50年間のほとんどの間、賃金が横ばいまたは下落したままで、広範な繁栄の増加につながる前に上昇し始めた大きな理由が2つありました。一つ目は、工場の所有者が新しい生産性の利益を労働者と共有するのではなく、独占していたことでした。しかし二つ目は、新しいテクノロジーを最も効果的に使用する方法の知識がまだ広く普及していなかったため、最大の生産性向上には数十年かかったということでした。発明家が機械をより堅牢にし、それらを使用する人々が効果的にするための新しい種類のワークフローを考え出し、それらで作ることができる新しい種類の製品を作り出し、より広範なビジネスが新しいテクノロジーを採用し、労働者がそれらを活用するために必要なスキルを獲得するには数十年かかりました。労働者は機械を使用するだけでなく、修理し、改善し、それらが暗示するがまだ完全に可能にしていない未来を発明するための新しいスキルが必要でした。これはすべて、Bessenが「実践による学習」と呼ぶプロセスを通じて起こります。
新しいスキルを採用する際にカーブの先を行く少数の個人だけでは十分ではありません。Bessenは「工場、産業、そして社会一般にとって重要なのは、個々の労働者を訓練するのにどれだけの時間がかかるかではなく、安定した訓練された労働力を作り出すのに何が必要かである」（実践による学習、36）と説明しています。今日、この革命によって影響を受けるであろう（つまり、すべての）企業は、車輪に肩を入れる必要があります。私たちはAIリテラシーのある労働力を必要としています。結局のところ、プログラミングとは、人間がコンピュータに私たちの命令を実行させる方法ではありませんか？「プログラミング」が人間の言語にますます近づいていること、私たちの機械が私たちを理解でき、私たちが0と1のネイティブな言語や何らかの特殊なプログラミング言語のピジンで彼らに話しかける必要がないことは、祝福されるべき原因です。
人々はより多くのプログラムを作成、使用、洗練し、新しい産業が誕生して私たちが作成するものの上に構築されるでしょう。歴史からの教訓は、自動化が人々が欲しいまたは必要とする製品を提供するのをより安く簡単にするとき、需要の増加はしばしば雇用の増加につながることを教えています。雇用が下がり始めるのは、需要が満たされたときだけです。私たちはプログラミングに関してはそのポイントからはほど遠いです。
しかし、新しいツール、フレームワーク、実践の爆発的な増加は、プログラミングがどのように変化しているかのほんの始まりに過ぎません。Schillaceが指摘した一つの問題は、モデルは人間が持っているような記憶を持っていないということです。大きなコンテキストウィンドウを持っていても、彼が「メタ認知」と呼ぶことに苦戦しています。その結果、彼はAIの共同開発者が操作するコンテキストの多くをまだ人間が提供する必要があると考えています。
Schillaceは最近の投稿でこのアイデアを拡張しました。「大規模言語モデル（LLM）や他のAIシステムは思考の自動化を試みています」と彼は書きました。「産業革命中の動きの自動化との並行性は驚くべきものです。今日、自動化はまだ粗いです：私たちは要約、パターン認識、テキスト生成のような基本的なタスク—認知的な水のポンプと打撃の同等物を行っています。私たちはまだこの新しいエネルギー源のための堅牢なエンジンの構築方法を理解していません—私たちはまだAIの機関車段階にさえ達していません。」
機関車段階でさえも、主に物理的なオブジェクトを移動する際に人間が適用できる力の強化でした。次の本質的なブレークスルーはその力の制御手段の増加でした。Schillaceは問いかけます：「もし伝統的なソフトウェアエンジニアリングがここで完全に関連していないとしたら？もしAIの構築が根本的に異なる実践と制御システムを必要とするなら？私たちは新しい種類の思考（私たちの動きのアナログ）を作成しようとしています：より高レベル、メタ認知的、適応的なシステムで、事前に設計されたパターンを繰り返す以上のことができます。これらを効果的に使用するためには、全く新しい作業方法、新しい規律を発明する必要があります。初期の蒸気力の課題が冶金学を生み出したように、AIの課題は認知、信頼性、スケーラビリティの新しい科学—まだ完全には存在しない分野—の出現を強制するでしょう。」
ビジネスでAI技術を展開する課題 以前Salesforceの共同CEOで、Meta（前Facebook）の最高技術責任者、そしてずっと昔にはGoogle Mapsを作成したチームのリーダーだったBret Taylorは現在、AIエージェント開発者Sierraのアルっであり、ビジネスにAI技術を開発・展開する心臓部にある企業のCEOです。最近の会話で、Bretは企業のAIエージェントがその主要なデジタルインターフェイスになると信じていると私に語りました。そのウェブサイトと同じくらい重要で、モバイルアプリと同じくらい重要で、おそらくそれ以上に。企業のAIエージェントはそのすべての主要なビジネスポリシーとプロセスをエンコードする必要があります。これは最終的にはAIが自力で行うことができるかもしれませんが、今日、Sierraは各顧客に実装を支援するためのエンジニアリングチームを割り当てる必要があります。
「クールなプラットフォームとあなたのビジネスプロセスの束を取り、エージェントを具現化するという最後の一マイルは実際にかなり難しいことです」とBretは説明しました。「エージェントエンジニアと呼ばれる新しい役割が今現れています。フロントエンドのウェブ開発者に少し似たソフトウェア開発者です。それがソフトウェアで最も一般的なアーキタイプです。あなたがReact開発者なら、AIエージェントを作ることを学ぶことができます。なんてスキルを再トレーニングし、あなたのスキルを関連性のあるものにする素晴らしい方法でしょう。」
彼らの問題を実際に解決できるAIエージェントと話せるなら、誰が顧客サービスの電話ツリーを通過したいと思うでしょうか？しかし、それらのエージェントを正しく機能させることは本当の課題になるでしょう。難しいのはプログラミングではありません。ビジネスプロセスを深く理解し、新しい能力を活用するためにそれらを変革する方法を考えることです。単に既存のビジネスプロセスを再現するエージェントは、紙のフォームを単に再現するウェブページやモバイルアプリと同じくらい恥ずかしいものでしょう（そして、はい、それらはまだ存在します！）
Google Chromeのユーザーエクスペリエンス責任者であるAddy Osmaniは、これを70%問題と呼んでいます：「エンジニアはAIで劇的に生産性が向上したと報告していますが、私たちが日々使用している実際のソフトウェアは顕著に良くなっているようには見えません。」彼は、AIコード生成ツールで作業する非プログラマーは優れたデモを作成したり単純な問題を解決したりできるが、複雑なプログラムの最後の30%で行き詰まる可能性があると指摘しています。なぜなら、彼らはコードをデバッグしてAIを正しい解決策に導くのに十分な知識がないからです。一方で：
「CursorやCopilotのようなAIツールでシニアエンジニアが作業するのを見ると、魔法のように見えます。彼らはテストとドキュメントを含む全体の機能を数分でスキャッフォールディングできます。しかし、注意深く見ると、何か重要なことに気づくでしょう：彼らはAIが提案することを単に受け入れているわけではありません... 彼らは何年もの苦労して得たエンジニアリングの知恵を適用して、AIの出力を形作り制約しています。AIは彼らの実装を加速していますが、彼らの専門知識がコードを維持可能に保っているのです。ジュニアエンジニアはしばしばこれらの重要なステップを見逃します。彼らはAIの出力をより容易に受け入れ、私が「トランプのカード」と呼ぶものにつながります - 完全に見えますが、現実世界の圧力の下で崩壊します。」
この点に関して、新著「AI Engineering」の著者であるChip Huyenは、私へのメールで啓発的な観察をしました：
「AIは新しい種類の思考を導入するとは思いません。それは実際に思考を必要とするものを明らかにします。
どれほど手動でも、最も教育を受けた一握りの人々だけが行えるタスクは知的とみなされます。一例は、紙に言葉を物理的にコピーする行為である書くことです。過去には、人口のごく一部だけが識字能力を持っていたとき、書くことは知的と考えられていました。人々はさらに自分の書道に誇りを持っていました。今日では、「書く」という言葉はもはやこの物理的な行為を指すのではなく、読みやすい形式にアイデアを配置するという高度な抽象化を指します。
同様に、コーディングの物理的な行為が自動化できるようになると、「プログラミング」の意味は、実行可能なプログラムにアイデアを配置する行為を指すように変わるでしょう。」
スタンフォード大学のCS学部長であるMehran Sahamiは簡潔に言いました：「コンピュータサイエンスはコードを書くことではなく、システマティックな思考についてです。」
AIエージェントがエージェントと話し始めるとき… …問題を正確に明確にすることがさらに重要になります。企業のすべてのビジネスプロセスへのアクセスを提供する企業のフロントエンドとしてのエージェントは、消費者だけでなく、それらの消費者のエージェントや他の企業のエージェントとも話すことになります。
エージェント方程式のその全体の側面は、はるかに推測的です。私たちはまだ独立したAIエージェント間の協力のための標準を構築し始めていません！エージェントインフラストラクチャの必要性に関する最近の論文は以下のように指摘しています：
「現在のツールは、既存の機関（例えば、法的および経済的システム）または主体（例えば、デジタルサービスプロバイダー、人間、他のAIエージェント）とエージェントがどのように相互作用するかを形作るように設計されていないため、大部分が不十分です。例えば、アラインメント技術は本質的に、ユーザーがエージェントに違法な行為を実行するよう指示したときに、ある人間が責任を負うことを相手に保証するものではありません。このギャップを埋めるために、私たちはエージェントインフラストラクチャの概念を提案します：エージェントの環境との相互作用と影響を仲介し影響するように設計されたエージェント外部の技術システムと共有プロトコル。エージェントインフラストラクチャは新しいツールと既存のツールの再構成または拡張の両方で構成されています。例えば、説明責任を促進するために、ユーザーをエージェントに結びつけるプロトコルは、OpenIDのような既存のユーザー認証システムに基づいて構築できるでしょう。インターネットがHTTPSのようなインフラストラクチャに依存しているように、エージェントインフラストラクチャもエージェントのエコシステムにとって同様に不可欠であると私たちは主張します。私たちはエージェントインフラストラクチャの3つの機能を特定します：1）特定のエージェント、そのユーザー、または他の主体に行動、特性、およびその他の情報を帰属させること、2）エージェントの相互作用を形作ること、3）エージェントからの有害な行動を検出し修正すること。
ここには巨大な調整と設計の問題が解決されるべきものがあります。私たちが想像できる最高のAIエージェントでさえ、人間の指示なしにこのような複雑な調整問題を解決することはできないでしょう。ここには、AIを超能力として使用する人間のプログラマーだけでなく、少なくとも次の10年間忙しくなるようなプログラミングが十分にあります。
要するに、発明されるべき新しいソフトウェアの世界全体があり、それはAI単独ではなく、AIを超能力として使用する人間のプログラマーによって発明されるでしょう。そしてそれらのプログラマーは多くの新しいスキルを習得する必要があります。
私たちは未来を発明する初期段階にいます 学び、行うべき新しいことがたくさんあります。はい、AIの共同開発者がプログラマーを10倍生産的にすると大胆に仮定しましょう（あなたの開発者が新しいスキルを学ぶのにどれだけ熱心かによって、実際の効果は変わるでしょう）。しかし、そうなったら、ビジネス、科学、私たちの構築されたインフラストラクチャの「プログラム可能な表面積」も並行して上昇するとしましょう。プログラミングが違いを生み出す機会が20倍あるなら、私たちはまだそれらの新しい10倍のプログラマーの2倍必要でしょう！
ユーザーの期待も高まるでしょう。単に生産性の向上をコスト削減に使用する企業は、新しい能力を活用してより良いサービスを構築する企業に負けるでしょう。
Simon Willisonは、AI時代においてプログラミングがより簡単で良いことを世界に示すことの最前線にいた長年のソフトウェア開発者であり、AIは彼のプロジェクトに対して「より野心的になれる」と指摘しています。
別の分野から教訓を得ましょう：今日のMarvelのスーパーヒーロー映画の1フレームをレンダリングするのにかかる時間は、CPU/GPUの価格とパフォーマンスがムーアの法則の恩恵を受けているにもかかわらず、最初のピクサー映画全体をレンダリングするのにかかった時間と同じくらいかかるかもしれません。映画業界は低解像度の粗いアニメーションをより速く安く提供することに満足していなかったことがわかります。余分なサイクルは、現実的な毛皮、水、雲、反射、そして多くのピクセルの解像度の何千もの小さな改善に費やされました。技術の改善は、単に安価/高速な配信ではなく、より高い品質をもたらしました。より安価/高速なものよりも高い制作価値を選ぶことで可能になった産業もあります（オンラインでのユーザー作成ビデオの爆発を考えてみてください）、そのため、どちらか一方ということはないでしょう。しかし、品質は市場で常にその場所を持っています。
AI支援ツールを使用する数千万人のアマチュアAI支援プログラマーがReplitやDevinなどのAIツールや、Salesforce、Palantir、Sierraが提供するようなエンタープライズソリューションで作業していると想像してください。彼らが何百万もの人々に訴えるユースケースに遭遇する可能性はどれくらいでしょうか？彼らの何人かはこの次世代のAIとのパートナーシップで作成されたソフトウェアの起業家になるでしょう。しかし、彼らのアイデアの多くは既存のプロフェッショナル開発者によって採用、洗練、スケーリングされるでしょう。
プロトタイプから製品へのジャーニー 企業では、AIによって問題に最も近い人々による解決策の構築がはるかに可能になります。しかし、それらの解決策の最良のものはまだ、PalantirのCTOであるShyam Sankarが「プロトタイプから製品へのジャーニー」と呼んだものの残りの道のりを進む必要があります。Sankarは企業にとってのAIの価値は「自動化、企業の自律性にある」と指摘しました。しかし、彼も指摘したように、「自動化はエッジケースによって制限されます。」彼は2005年にDARPAグランドチャレンジに勝利した自動運転車Stanleyの教訓を思い出しました：何か驚くべきことができますが、都市での運転のエッジケースを完全に処理するためにさらに20年の開発が必要でした。
「ワークフローはまだ重要です」とSankarは主張し、プログラマーの仕事は何が従来のソフトウェアによって行われるか、何がAIによって行われるか、何がまだ人々によって行われる必要があるか、そしてワークフローを実際に達成するためにどのようにそれらを連携させるかを理解することになるでしょう。彼は「フィードバックをキャプチャしてエッジケースを学習し、できるだけ早くそこに到達できるようにするツールチェーンが勝利するツールチェーンです」と指摘しています。Sankarが想像する世界では、AIは「実際に開発者をビジネスにより多く解放し、彼らが提供する影響においてより影響力を持つようになる」でしょう。一方、トップレベルの主題専門家はAIアシスタントの助けを借りてプログラマーになるでしょう。仕事を失うのはプログラマーではありません。それは—あらゆる職務において—AI支援プログラマーにならない人々でしょう。
これはプログラミングの終わりではありません。それは最新の再発明の始まりです。
Discussion