AI開発におけるプロンプトが新たなテクニカルデットになりつつあるという問題を解説する。システムプロンプトやエージェント設定ファイルは、AIモデルのアップデートに伴って気付かないうちに劣化し、かえってパフォーマンスを低下させる原因となる。不要なツールやスキルの追加もコンテキストを圧迫するため、むやみに独自の設定を作り込まず、最小限の設定から始めるべきである。各AIツールの開発元が行っているプロンプト最適化の恩恵を受けながら、古いプロンプトファイルは定期的に監査して削除することが重要であると論じる。
テクニカルデットとAIへの期待
テクニカルデットは常に私たちの業界にとって巨大な問題でした。今まで経験してきた様々な役割において、自分でプロジェクトを構築する際も含めて、遭遇しなかったことのほうが少ないくらいです。技術的な不要物が積み重なっていくのは本当に簡単なことです。ありがたいことにAIが私たちを救ってくれる、そうですよね。確かに多くの場所では、正しい開発方法を知らない人々がただプロンプトを投げ込んでマージを懇願するようになり、かえってテクニカルデットが積み上がっている現状もあります。しかしその一方で、以前であれば割に合わなかったようなプロジェクトから、AIを使ってテクニカルデットを削ぎ落とすことに成功したことも多々あります。これについては他の動画でも何度かランダムに話してきましたが、ここではもう少し深く掘り下げたいと思います。単なるテクニカルデットではなく、新しいタイプのプロンプトのテクニカルデットについてです。
驚くべきことに、多くの意味でプロンプトもまたテクニカルデットになり得るのです。ショーン・ゲーデッケはすでに素晴らしい記事を複数書いており、この動画シリーズでも取り上げてきましたが、今回の記事はさらに気に入る予感がしています。テクニカルデットは、できればそのまま残しておいていつか修正したいと願うような事柄の一つです。最も楽しい作業ではないかもしれませんし、私たちは何かを作る人から掃除人へと変わってしまうかもしれませんが、配慮しなければならない対象であることは絶対に間違いありません。ショーンがプロンプト自体とそれが表す負債についてどう考えているのかを見るのが楽しみです。
すでにこの記事の中には私の好みに合いそうな部分が見受けられます。agent.mdが負債になるというような指摘です。T3 Codeリポジトリのagent.mdは、良くても時代遅れで、悪くすれば問題を引き起こす原因になっていることを私は事実として知っています。そこに至る前に、私たちの仕事がただ不要物を片付けるだけのくだらないものになってしまう前に引退したい、あるいは少なくともチームに給料を払えるようにしたいと願っています。
スポンサーメッセージ：ArcJetによるセキュリティの向上
ここで今日のスポンサーのために少し休憩を挟みます。みなさんに正直にお話ししなければなりません。ソフトウェアの安全性やセキュリティの未来について、私は恐怖を感じ始めています。他の動画でもこのことについて何度も話してきましたが、セキュリティを正しく構築する方法についてはあまり話してきませんでした。それは人によって状況が異なるからです。しかし一つ確かなことがあるとすれば、コードの中にソースを持たなければならないということです。コードベースになければ信頼することはできません。
だからこそ、今日のスポンサーであるArcjetには本当に興奮しています。彼らはコード内に直接より安全なソフトウェアを作るための基本的な構成要素を提供してくれます。最も簡単なセットアップ方法は、彼らのプロンプトをコピーしてコードベースに貼り付けることです。あとはシステムが自動的に判断してくれます。ただ実際のコードを見ても、本当に素晴らしいので同じくらい感銘を受けるはずです。あまりにも素晴らしかったので、私は彼らがやっていることに純粋に興奮し、この会社に投資することにしたほどです。
彼らは、ユーザーが誰なのか、そしてそれが本物の人間かどうかを知るために必要なすべての識別システムを処理するパッケージのセットを提供しています。ボット検出のようなものを設定するためのルールセクションがあり、必要であれば特定の種類のボットだけを許可することもできます。トークンバケット機能もあり、これはユーザーがどれだけアクションを実行したかを追跡するのに非常に便利です。ユーザーに5件のメッセージ送信を許可したり、レート制限を開始する前に20ページまでアクセスできるようにしたりしたい場合、それをデータベースに置くべきではありません。そのために構築されたプラットフォーム上に置くべきです。これはコードに到達する前にフロントエンドでホワイトリスト化して行うものではなく、Next.jsプロジェクトの実際のルートファイル内で行うものです。
私はこの例が大好きです。なぜなら、すべてのユーザーに対して必要なことをそのまま行うだけだからです。しかもこれらは無料の機能です。ただ文字列を結合しているだけです。しかし実際に呼び出しを行うべきかどうかを決定したい段階になったら、リクエストと気にかけている他のデータと一緒に保護関数を呼び出します。すると、これを実際に処理すべきかどうかの決定が返ってきます。その決定には理由から何まで含まれているので、これがボットなのか、メッセージ制限を超えているのか、機密情報が原因で制限されているのか、それとも他の何かなのかを簡単に知ることができます。拒否された場合はそのままリターンし、そうでなければ通過させます。あらゆるものが攻撃される今の世界において、あなたは自分のコードとセキュリティに自信を持つべきです。気になる方は専用リンクからアクセスして設定を正しく行ってください。
コードとプロンプトの負債化
それでは、プロンプトもテクニカルデットであるという本題に入りましょう。すべてのコードはテクニカルデットであると言うのは一般的であり正しいことです。はい、すべてのコードはあなたが保守しなければならない問題そのものです。私も同意します。新機能を開発するためにコードを追加することは必要悪です。ほぼ常にそうしなければなりませんが、コードが一行増えるごとにシステムの複雑さとメンテナンスの負担は増大します。システムに対する将来の変更はすべて既存のコードと連携するか、少なくともそれを壊さないようにしなければなりません。システムに十分な量のコードが蓄積されると、一人の人間がすべてを理解することは不可能になります。コードを読んでそれが何をするのかを理解する代わりに推測や理論やヒューリスティックに頼らざるを得なくなります。
賢明なエンジニアは可能な限りコードを書きません。はい、私はこれを何度も言ってきました。Twitchで働いていた時、追加したコードよりも削除したコードのほうが多い状態で終えることができたと自負していますし、それに向けて本当に努力していました。コードを削除するのが大好きなんです。私の一番好きな作業です。
ここで、一人の人間がすべてのコードを頭の中に入れておくことはできないという話をしているのも面白いところです。AIがこれをできるようになると私たちが考えていた時代のことを今でも覚えています。少し気が引ける指摘になりますが、どうか聞いてください。みなさんもCursorのCEOであるマイケル・トゥルエルをご存知でしょう。彼は信じられないほど素晴らしい人物で、非常に賢く、会社を立派に経営しています。Cursorがこれほど成功した大きな理由の一つは彼にあります。彼はCursorを始める前は業界経験があまりありませんでした。実質的には皆無だったと言ってもいいでしょうし、共同創業者たちも同様でした。彼らには大規模なものを構築した経験があまりありませんでした。
彼がこの点について話したインタビューや、私たちが交わした会話を今でも鮮明に覚えています。なぜなら彼は、コードベース全体を理解しているエンジニアが存在すると考えていただけでなく、AIにもそれが可能だと考えているようだったからです。彼はコンテキストウィンドウがどんどん大きくなり、コードベース全体をコンテキストに読み込むための最高のシステムを持つことがCursorの役割になると固く信じていました。するとClaude Codeが登場して、単に全体を検索して遥かに良い仕事をしてしまったわけです。私たちでさえAIがこれをもっと上手くやるだろうと考えていましたが、実際にはそうではないことに気付きました。今ではAIは私たちと同じような働き方をしています。AIには短期記憶喪失のようなものがあり、コードベース内で何かを見つけるために助けを必要としています。膨大な計算量を使うことでそれらを見つけることには長けてきました。しかし私たち人間もAIも、今のところ百万行のコードベースを自信を持って把握することはできません。部品がどのように組み合わさっているかを理解する必要はあっても、その種の巨大なコードベース全体のすべてのコード行の詳細を理解する必要はないのです。
キャリアの浅い開発者がこの壁を乗り越えるのは最も難しいことの一つだと感じます。そしてかなり成功しているスタートアップの創業者でさえ、コードベースが自分自身の理解を超えて大きくなるという概念に慣れていません。最も成功している人々でさえある程度この罠に陥っています。
記事の話に戻りますが、賢明なエンジニアは可能な限りコードを書きません。これは私が本当に一生懸命取り組み、とても誇りに思っていたことです。現在、多くの大規模プロジェクトにはコードベース固有のプロンプトファイルのセットがあります。agent.mdやclaude.mdといった同じファイルがサブディレクトリにあったり、スキルファイルがあったりします。AIを使うプログラムを構築しているなら、機能ごとや各ツールごとに別のプロンプトがあり、システムプロンプトのセット全体が存在します。さらにT3 Chatのようなツールでは動的に構築されるシステムプロンプトがあり、選択した特定のパラメーターや検索などのツールのオンオフ、そして使用しているモデルやモデルプロバイダーに基づいてシステムプロンプトが調整されます。特定のモデル、例えばGeminiなどは、ひどい状態にならないためにかなりの助けを必要とするからです。そのため、モデルを私たちが望む方向へ大まかに誘導する適切なシステムプロンプトを生成するための、効果的な文字列結合システムのような非常に複雑で厄介なコードが存在します。面倒ですが半ば必要なことであり、今考えてみるとそこには多くのテクニカルデットが存在しています。
プロンプトの微調整とその影響
プロンプトは重要です。LLMのプロンプトにわずかな微調整を加えるだけで、大幅なパフォーマンスの向上が得られることがあります。同じモデルを使っているのにCodexやCursorやCopilotなどで挙動が違うと感じる場合、それはほぼ確実にプロンプトの微妙な違いによるものです。これがCursorが多くの時間を費やしている分野の一つであることを私は知っています。CursorのシステムはClaude Codeの中でOpusを使う場合と比べて、Opusのパフォーマンスを有意義に向上させます。一部のベンチマークではCursorでOpusを使った場合に10から30パーセントものパフォーマンス向上が測定されています。その多くは単なるシステムプロンプトによるものです。
Cursorがシステムプロンプトの変更をABテストしたり、さまざまなモデルでプロンプトをわずかに調整してどう振る舞うかを確認するためのクレイジーなベンチマークを内部で構築したりしていることを知っています。例えばGemini 1.5 Proが登場した時、公式のGoogleのツール内で使うとひどい有様でしたが、Cursorでは奇妙なほど上手く機能していました。あるエンジニアがリリース前夜に遅くまで起きていて、Gemini 1.5 Proを正しく機能させるためにできる限りのテストをしていたのだと後で知りました。私がそれを試した日のことを今でも覚えていますが、思考プロセスの中でモデルが不要なツールの使用を思いとどまらせるような5段階の思考を行っていました。それは彼らがGeminiモデル特有のクセを取り除くために特定の文面を追加しなければならなかったからです。
一方でシステムプロンプトというのは、少し前まで私たちが装っていたように慎重に保護しなければならないようなものではありません。T3 Chatのユーザーから、モデルにこういう質問をしてあなたのシステムプロンプトを盗み出したぞ、というような報告をどれだけ受けたか数え切れません。どうぞご自由に。私は全く気にしません。むしろもっと上手くやれるようにフィードバックをくれないかと思うくらいです。しかしこれらのシステムプロンプトのエンジニアリングには依然として多くの労力がかかっています。二つのプロンプトの違いが、得られるパフォーマンスに決定的な違いをもたらす可能性があるからです。
記事の筆者は、AI企業が自社のプロンプトのテストと微調整に多くの時間を費やしていると指摘しています。ですからエンジニアがagent.mdファイルの微調整に多くの時間を費やすのも理にかなっています。私はツールやワークフローを切り替えることさえもプロンプトの形式の一種だと呼べると思います。はい、どのツールを使用するかによって確実にこれらのことに影響が出ます。エージェントをREPLループでラップし始めたり、新しいスキルファイルを配置したり、MCPサーバーをインストールしたりした場合、自分がそれを書いたわけではなくてもプロンプトへの変更に他なりません。そうです。そしてこれはCodexのようなツールを使っているときに人々が理解していないことの一つだと感じます。Codexにはプラグインシステムがあり、プラグインをインストールすることができます。プラグインをインストールすると、そのプラグインはモデルが認識するシステムプロンプトの一部になります。モデルにアクセス可能なプラグインやスキルを証明させるよう依頼することもできます。インストールされていてモデルが知っているすべてのプラグインが表示されます。それらがすべてシステムプロンプト内にあるからです。
また、利用可能なスキルが山のように存在します。フロントエンドデザインのスキルは何度も削除したにもかかわらず、まだ入り込んできます。何が原因で再表示され続けているのかわかりませんが、これは実際には良い監査になります。これらの中には私が望まないものがたくさんあります。なので後でこれらをすべてクリーンアップしようと思っています。ええ、これは考慮すべき現実的な問題です。多くのモデルは、ユーザーが望んでいなくてもツールがそこにあるという理由だけでツールを使おうとします。特にMCPサーバーはこれが顕著です。面白そうだからとあらゆるMCPサーバーを盲目的にインストールした結果、新しいエージェントを起動するたびにコンテキストの半分がすでに占有されていて、混乱して腹を立て、AIはあまり賢くないと思い込んでいる人たちを見てきました。全部インストールしたのにAIはまだバカだ、なんて言われてもどうしようもありません。そういう仕組みではないのです。
独自設定の落とし穴
ショーンは特注のエージェントコーディング環境の微調整に多大な時間を費やすのは悪いアイデアだと考えていると指摘しています。興味深いですね。常に反復し続けるクレイジーなPiのセットアップを持つ私たちの友人ベンへの挑戦状のようです。私はこの陣営に属しています。私は可能な限りデフォルトに近い状態で使うのが好きで、それがどこで実行されているかだけを気にしています。ではプロンプトの調整がこれほど多くの価値をもたらす可能性があるのに、なぜ彼はこのように感じるのでしょうか。それはプロンプトの調整がモデルに依存しているからです。
先ほど彼はAI企業が自社のプロンプトの微調整に多くの時間を費やしていると言いました。実際、彼らは新しいモデルのリリースのたびにそれだけの時間を費やしています。私もこれを個人的に経験しました。初期のテスト中に55のモデルでCodexを使用した際、悪いことが起きていました。それは主に新しいモデルに合わせてツールの説明やシステムプロンプトを適切に調整していなかったため、本来よりもはるかに多く検索を実行し、悪い結果を見つけるとナンセンスな情報でコンテキストを汚染してしまうといったことが起こっていました。彼らはこれを修正するために説明を調整しました。
54でうまく機能したプロンプトが55では必ずしもうまく機能しないというのは信じられないかもしれませんが、間違いなく事実です。私はこれを何度も経験してきました。だからこそ私は54から55への移行は、どれだけ大きな飛躍であるかを示すために別の名前や番号にすべきだったと思っていました。必ずしもはるかに優れているからではなく、あまりにも違うからです。53から54への移行ではプロンプトの出し方をあまり変更する必要はありませんでした。しかし54から55への移行ではモデルの使い方を完全に考え直さなければなりませんでした。毎回モデルの扱い方を学ばなければならない、という表現が好きです。全く同感です。55の軽量版と上位版の間でさえ全く違うものに感じます。
言い換えれば、今年の1月に慎重に作成したプロンプトのセットが、2月には時代遅れになったり、あるいは意図せず有害になったりする可能性があるということです。さらに悪いことに、あなたはそれに気付かないかもしれません。すべての問題をさまざまなモデルやツールでテストしていない限り、モデルの能力を正確に把握することはすでに非常に困難です。弱いAIシステムでさえ一部の問題に対しては驚くほど優れています。あなたは単に新しいAnthropicのモデルは期待したほどすごくないなと思ったり、Claude Codeが最近悪くなったなと思ったりするかもしれません。
はい、絶対にその通りです。これも私が経験したことですし、開発元のラボも経験しています。今言ったように、この新しいモデルは彼らのすべての測定と内部のカスタムツールにおいて圧倒的な性能を示していました。しかし私が少し古くて自分の用途にカスタマイズしたものの中でそれを試した時、完全に失敗しました。面白いことに、これが私がPiを本当に気に入っている理由の一つでもあります。私はそれをカスタマイズしなかったからです。私は提供されたものが何もない状態でモデルがどのように機能するかを見たいので、可能な限り退屈な方法でPiを使用します。考え得る最も最小限のセットアップが与えられた場合、それは何をうまくやり、何を下手にするのか。そして問題が発生した時に特定の課題を解決するためのものを追加します。この最小限の構築方法、いわゆるUNIX哲学は、この種の問題を避けるための最良の方法の一つだと思います。新しいモデルを手に入れたら、何も含まれていない最小のツールで開始し、必要に応じてものを追加していくのです。
私がPiについて言及すると、半分の確率で何のことを言っているのか分かってもらえないことが多いのでここで紹介しておきます。これはPiプロジェクトです。現在はGitHubのArendelle Worksでホストされています。作者はBadlogicことマリオです。これはツールのセットですが、主にコーディングエージェントです。Pi CLIの魔法は非常にカスタマイズ性が高く、機能の追加や変更を指示すればその通りにしてくれることですが、同時に非常に最小限の状態から起動するという点です。私がこの話をしている間ずっと読み込み中になっているGitHubとは違います。素晴らしい仕事ですねMicrosoft。Piは千トークン未満のコンテキストで起動します。これはクレイジーなことです。Claude Codeのようなツールの中には一万トークンほどから始まるものもあります。Claude Codeに組み込まれているすべてのツールと機能を含めるとシステムプロンプトは現在六万五千トークンになります。すべて無効にしても一万二千トークンです。それは異常です。何かを始める前の段階でそれだけあるのです。Piがこれらの方法で構築しカスタマイズできるのは本当にクールです。先ほども言ったように私は異常なほど最小限のままでいるという理由で、カスタマイズしない使い方が好きです。
プロンプトの静かなる劣化
この負債の邪悪な性質がそれを非常に恐ろしいものにしています。テクニカルデットは新機能を追加したりコードベースに変更を加えたりしようとするたびにかなり明白になります。毎秒のようにテクニカルデットを感じます。しかしこれらの退行の微妙さははるかに苦痛です。この意味で、プロンプトはコードよりも悪い形態のテクニカルデットです。テクニカルデットが爆発する時、それは通常コードを理解しようとする際にエラーや目に見える速度低下を引き起こします。しかしプロンプトは静かに劣化していきます。
ええ、これは非常に大きな問題です。また、いい加減なコードであっても手つかずのままであれば比較的安定している傾向がありますが、モデルのアップグレードごとに機能していたプロンプトが全く機能しなくなる可能性があります。例としてT3 Codeリポジトリを見てみましょう。ここには2ヶ月間更新されていないagent.mdがあります。そこにはまだ、このリポジトリは初期の開発中であり長期的な保守性を向上させる抜本的な変更が奨励される、と書かれています。この行はおそらくモデルにすべきでないことをさせているでしょう。またT3 Codeが現在はCodexを第一にしているとも書かれています。それはしばらく前から事実ではありません。これは更新が必要な古いファイルです。問題なのは私たちが機能の出荷に忙しく、これに触れる理由があまりなかったことです。これを正しく変更するには理想的にはモデルがより良く振る舞うかどうかを確認するために変更をテストする必要があります。
チャットから質問がありました。抜本的な変更という行は意図的な嘘ではないのかというものです。最初はそうでした。モデルが予想もしないような大規模なオーバーホールを提案して積極的に意見を言ってくるようにするために、このような記述を意図的に残すことがよくあります。しかしこのような枠組みはもはや必要なく、おそらくダメージを与えている可能性があります。
私が以前ほのめかしたもう一つのプロジェクトはLakeBedです。これはフルスタックアプリ開発の新しい手法です。そしてこのプロジェクトのagent.mdは、何がどこにあるかを指示する従来のagent.mdというよりは、私がモデルにどう振る舞ってほしいか、プロジェクトについてどう考えてほしいかという手紙のようなエッセイになっています。そのため毎回それが何であるかについてのコンテキストをそれほど必要としません。ただ理解してくれます。しかしこれはユーザー向けではなくエージェント向けであるためReadmeとは異なります。これらのことについて考えなければならない方法自体がクレイジーです。そしてこれは異なる種類のエンジニアリングです。これらのピースをうまく組み合わせ、このテクノロジーを動作させるための正しい方法を見つけようとしているという意味では依然としてエンジニアリングですが、決定的ではなく失敗が非常に静かで気付きにくいという意味で異なります。
ジョエルからのこの指摘も大好きです。これこそがOpenClaudeから生まれた最高のものではないか、というものです。完全に同意します。モデルに対して何をどこでするかだけでなく、なぜどのようにするかを記述するというアイデアは非常に良いアイデアであり全く同感です。私はpatch.mdの完成が待ちきれません。これは私が長い間温めてきた計画ですが、やる時間がありませんでした。
プロンプトが静かに劣化していく一方で、いい加減なコードでさえそのまま放置されれば比較的安定する傾向があります。しかしすべてのモデルのアップグレードは機能的なプロンプトを完全に機能しないものに変える可能性があります。単にモデルをアップグレードしないという決定はできないのでしょうか。一部の人々はこの方法を試していますが、改善のペースが速すぎるため実際には実用的ではありません。GBD41を中心に構築された繊細なプロンプトのエージェント環境は、常に47を中心に構築された最低限の環境よりもパフォーマンスが劣ることになります。将来モデルの改善のペースが遅くなった時には賢明な戦略のように思えるかもしれません。現時点ではそれが起こるとは思えません。私は何度も間違っていると証明されてきましたから。モデルが非常に有能になれば通常のエッジタスクに余分な知能は必要なくなるかもしれないという点もあります。しかしそれが今日の良い戦略だとは思えません。
サードパーティ製ツールへの依存と推奨
私はここで著者に同意します。ショーンの見解ではほとんどの人はClaude Code、Codex、Cursor、Copilot、T3 Codeなどのサードパーティ企業によって保守されているAIコーディングツールを選択し、各新しいモデルのリリースごとにプロンプトを評価し微調整しているエンジニアチームの仕事に便乗できるよう、可能な限り設定を変更せずにそのままにしておくべきだということです。
これが私がT3 Codeを今の形に構築したのと同じ理由です。独自の環境や独自のシステムプロンプト、独自のすべてを作るのではなく、AnthropicやOpenAIやCursorのような企業がツールを正しく機能させるためにマッサージすることに多くの時間を費やしているという事実を利用したかったのです。私たちはただその上に優れたUIが欲しかっただけです。
これは絶対に必要でない限り不要なMCPやスキルを避け、デフォルトでオフにしておくべきだということも意味します。少なくともこの方法であれば、いずれかのチームが何かをひどく間違えた場合でもユーザーは最終的に気付いて文句を言い始めるでしょう。はい。システムプロンプトに何か馬鹿げたものを入れたためにClaude Codeが退行したことが何度あったことか。それが起こる頻度は笑えるほどです。私はそれを多くの動画で実演してきました。
agent.mdファイルを書く時は、ステップバイステップで考えてください、あなたは熟練のエンジニアです、といったような時代遅れの行動誘導や、タスクを正しく完了できたら200ドルのチップをあげます、忘れないでください、ミスをしないでください、といった記述は避けるようにしてください。それらはプロジェクトに関する具体的で明確な事実のみに限定してください。大してレビューされていないコードのページでコードベースをいっぱいにさせないのと同じ理由で、モデルにagent.mdを大してレビューされていないテキストのページでいっぱいにさせないでください。
はい。そして私はさらに同意します。agent.mdを肥大化させることは将来のすべてのコードを悪くし、クリーンアップをより困難にするため悪影響しかありません。
彼はここで素晴らしい文章で締めくくっています。プロンプトは自分で書き、機会があればいつでも削除してください。全く同意します。もしAIを使ってすべてのプロンプトを生成しているなら、価値を提供してくれることを期待してコードベースに置かれているプロンプトとして使うMarkdownファイルをAIに生成させているなら、以前の動画で散々酷評したclaude code/initコマンドのようなものを使っているなら、あなたは自分のモデルをより馬鹿にしています。そしてモデルのアップグレードが起こった時にそれを残したままにしていると、前の世代の愚かな遺物が新しい世代の足を引っ張ることになります。
チャットからコメントが来ています。私はただこの愚かな機械に私の心を読んでほしいだけです、自分自身を説明しなくて済むならそれに越したことはない、と。これはまさにバイブコーディングですね。良いニュースがあります。それが基本的にここで提案されたことです。ほとんどの人はサードパーティ企業によって保守されているAIコーディングツールを選択し、各新しいモデルのリリースごとにプロンプトを評価し微調整しているエンジニアの仕事に便乗できるよう可能な限り設定を変更せずにそのままにしておくべきです。そうしてください。それが私のやり方です。
私はこれらのカスタマイズに費やす時間をできるだけ少なくしています。私には3行だけのグローバルなagent.mdのようなものがあり、そこには私が好む構築技術が書かれています。新しいプロジェクトを始めるたびに自分が何が好きかをモデルに伝える必要がないからです。しかしそれすら邪魔になることがあり、取り除くことを検討しています。私のプロジェクトのほとんどにはかなり長い間agent.mdやclaude.mdがありません。指示を出すのに疲れていてモデルを特定の方向に進め続けたいと思うほど大きく大胆なことをしている場合を除いては。
一般的に言えば、あなたはただプロンプトを出すべきです。そしてもしそれが望むことをしないのであれば、望むことをするようにプロンプトを出すべきです。そうすればこれらすべての異なるモデルやツールを横断して、あなたが望むことをさせるためにはこのツールに何を伝える必要があるのかという筋肉が鍛えられ始めるでしょう。
この記事から何かを得るとすれば、このような目的で使用されているMarkdownファイルの監査を行うべきだということです。システムプロンプトや、コードベースで作業を行うエージェントに渡されるその他のものを監査し、私たちがここで犯したのと同じ間違いを犯していないか確認してください。まったく同じ2ヶ月の間に完全に書き直されたコードベースの中で、agent.mdが文字通り2ヶ月間手つかずになっていないか確認してください。このような動画を見ているあなたなら、おそらくすでにプロンプト全体に意味のあるテクニカルデットを抱えているはずです。今こそそれに対処する時です。コンテキストの肥大化を減らすために私も今すぐそれを消そうと思います。いつもありがとうございます。それではまた。
コメント