私のプロンプト作成方法

Think Harder: How I Prompt

Thorsten Ball · Laracon US · 2026年7月29日 · ビデオ · 自動生成されたキャプションからのトランスクリプト、フレームマッチングによるスライドへの同期。タイムスタンプはビデオへのリンクです。

イントロ — Aaron Francis

イントロ — Aaron Francis · 0:00

次に、Thorstenが登壇します。Thorstenを知らない方のために説明すると、あなたの好きな開発者に「あなたの好きな開発者は誰ですか？」と尋ねてみてください。おそらくThorstenの名前が挙がるでしょう。Thorstenは、この分野で最も明晰な思考を持つ人物の一人であり、長年にわたりその地位を保っています。彼は『Writing an Interpreter in Go』や『Writing a Compiler in Go』といった書籍を執筆しており、ここでサインをもらっている人も見かけました。最近では、共同設立した新しい会社Ampのために、ソフトウェアの考案、執筆、開発に時間を費やしています。今日はAmpについて話してもらいます。以前はSourcegraph、その前はZedにいました。つまり、彼は開発者ツール分野で非常に長いキャリアを持っています。深い専門知識を持つ彼が、フロンティアについてより深く考える手助けをしてくれるでしょう。ドイツから、Thorstenを温かくお迎えください。

［画像: Slide 2 (title)］

さて、ここにいます。ここに来られて嬉しいです。これが私の初めてのLaraconです。トークではFワードを使いすぎないように言われていますが、とにかく素晴らしい気分です。本当に素晴らしいです。今日は、私がどのようにプロンプトを書いているか、特にコーディングエージェントにどのようにプロンプトを書いているかについてお話しします。AIについて話す多くの人々が抱える問題は、彼らに「何をリリースしたのですか？」と尋ねると、「それは別の学校の話で、あなたは知らないだろう、 blah blah blah、難しいんだ、話せない」という答えが返ってくることです。そこで、私の経歴を少し紹介すると、私はAmpの共同クリエイターの一人です。Ampは昨年リリースされたコーディングエージェントで、Claude Codeの数週間後に登場しました。私たちは最初期のもので、多くの人がそれを「洗練されている」「センスが良い」と評しています。Aaronは妻に「それは喜びだ」と言ったそうです。なかなか良い評価です。

［動画］

これは昨年のTUI（テキストベースユーザーインターフェース）です。過去6ヶ月で劇的に進化しました。

［動画］

そして今、見た目はこんな感じです。これは本格的な開発環境です。オーブ（サンドボックス）を起動し、その中でエージェントを実行できます。Raspberry Pi、冷蔵庫、芝刈り機など、どこでも実行されているエージェントをリモートコントロールできます。プレビューなども可能です。多くのことができます。人々は私たちを、引用すると「コーディングエージェントのポルシェだ」と呼びます。あるTwitterユーザーはさらに踏み込んで、「いや、ポルシェのコーディングエージェントのフェラーリだ」と言いました。

［動画］

これは私がこれまでに携わった中で最も複雑な分散システムの一つです。さて、ここからが本題です。なぜ私がこれらすべてを話しているかというと、その99%はAIによって書かれているからです。私たちのチームの誰も、もはや手書きでコードを書くことはありません。私もそうです。2週間前にアンケートを取ったのですが、チームのメンバーに「手書きでコードを書くのはどれくらいですか？」と尋ねました。99%、95%、90%…という回答がありました。Camdenは「10%くらい手書きで書くかな」と言いました。私は「本当に？」と聞き返しました。彼は「いや、まあ、そうでもないかな」と答えました。つまり、これは複雑な製品であり、多くの人に愛されています。これは「クソコード」ではありません。今日は、私がどのようにプロンプトを書いているか、Ampの大部分をどのように構築したかについてお話しします。今日は、そのようなプロンプトを作成するために必要な努力、つまり規律とトレーニング、テクニック、職人技、あるいはこだわりと方法論についてお話しします。

［画像: Slide 6］

これらすべて、洗練さ、とでも言いましょうか。正直に言うと、これはエンジニアリングです。これを見てください。このトークの終わりに、あなたもこのようにプロンプトを書けるようになると約束します。冗談です。これでトークは終わりです。ありがとうございました。いや、私のプロンプトは実際にはもっとこんな感じです。

［画像: Slide 7］

かなりテキストが多いです。良いニュースは、かなり…ああ、戻ります。すみません、もう一度…ああ、すみません。

［画像: Slide 8］

すみません。はい、これです。私のプロンプトの書き方は、実はかなり退屈です。MCPサーバーは使いません。必要ありません。1つか2つのスキルしか使いません。フレームワークも使いません。カスタムスラッシュコマンドも設定していません。このトークで見られるすべては、自宅でできることです。理想的にはAmpで、しかし、他のコーディングエージェントでも可能です。秘密のソースはありません。魔法のキーワードもありません。ただ、このトークのために調査している間に、私が送った過去2,000件のプロンプトを見返したのですが、非ネイティブスピーカーである私が人生で一度も発音したことのない、しかしエージェントと話すたびに毎回使っている単語が一つあることがわかりました。

［画像: Slide 9］

信じられないほどです。私のすべての会話に登場しています。それを入れるために、わざわざお金を払って発音を修正したほどです。だから、これが魔法のキーワードなのかもしれません。しかし、もし魔法のようなちょっとしたコツがあるとすれば、それはこの質問です。

［画像: Slide 10］

これがこのトークで皆さんに持ち帰ってほしい唯一のことです。プロンプトを書くときに、自分自身に問いかけてほしい唯一のことです。これは、頭を垂れて「情報はどこから来るのか？」と考えるような、存在論的な意味ではありません。私が言いたいのは、プロンプトを書くとき、あなたは大規模言語モデルと話しているということです。モデルはどうやって私の意図を理解するはずなのか？と考える必要があります。コーディングエージェントは、その下では単なる大規模言語モデルであり、コンテキストウィンドウを持っています。魔法のようです。誤解しないでください。これは確率的オウムだとか、そういうものではないと言っているわけではありません。しかし、結局のところ、それはモデルに送信され、完了される長いテキストなのです。だから、モデルに何かを依頼するとき、あなたのプロンプトを解釈するために使える情報は、いくつかの場所からしか来ないのです。

［画像: Slide 11］

一方には、トレーニングデータがあります。これは、ご存知の通り、観測可能なインターネット、すべての書籍、すべてのStack Overflowなどです。次に、より興味深いものがあります。それはあなたが影響を与えられるものです。コンテキストウィンドウです。コンテキストウィンドウには、システムプロンプト、ツール定義、MCPツール定義スキル、エージェント、メッセージ、つまり会話全体、ツール結果、つまりモデルが実行したすべてのもの、発行したすべてのツールコールが含まれます。結果はコンテキストウィンドウにあります。そして最も重要なのは、あなたのプロンプトです。

［画像: Slide 12］

だから、このようにプロンプトを書いた場合、モデルはどうやってバグが何なのか、アップロードが何なのかを知るのでしょうか？もしこれがあなたのプロンプト全体で、あなたのコードベースにバグやアップロードが何であるかを明確に定義したAGENTS.mdファイルがない場合、モデルは知りません。しかし、人間とは違い、モデルは「一体何を言っているんだ？どのバグ？どのアップロード？」とは言いません。「あなたは絶対に正しい。アップロードのバグを修正します」と言って、それが何であるかをモデルが考えた通りに実行するのです。そこで、皆さんに使ってほしいメンタルモデルがあります。

［画像: Slide 13］

これを想像してみてください。そして、これが一部の人には身につまされるかもしれませんが。あなたはシニアエンジニアです。すべてを経験してきました。Windows、Linux、Unix、macOSを扱ってきました。バックエンド、フロントエンド、クライアントを経験してきました。すべての言語を知っています。Stack Overflowを読みました。Stack Overflowで最も多くのポイントを獲得しました。あらゆる言語で匿名関数を呼び出せます。そしてある日、仕事に向かう途中、誰かに路上で連れ去られ、バンに押し込まれ、頭にフードを被せられ、どこかに連れて行かれます。そして突然、フードが剥がされ、目の前には何もない部屋にいることに気づきます。机があり、その机の上にはコンピューターがあります。コンピューターには、テキストエディタで開かれたコードベース、ターミナル、ウェブブラウザがあります。そして、魔法のように、あるいはこの場合は悲劇的に、誰かがあなたにメモを渡します。そのメモには「バグを修正しろ、アップロードの…」と書かれています。

わかりますか？モデルが経験するのはこれです。だから、プロンプトを書くときは、読者のことを考えなければなりません。すべての文章の目的は、理解されることです。タッチタイピングの練習をしていない場合でも、読者があなたの言っていることを理解できるようにしたいですよね？コミットメッセージ、Slackメッセージ、テキストメッセージ、プルリクエストメッセージ、あるいはモデルへのプロンプトであっても。何かを書くたびに、ループの中で考える必要があります。「読者は何を知っているか？」「私は何を伝える必要があるか？」「読者が欠けている情報は何か？」だから、プロンプトを書くとき、あなたはモデルと話しているのです。それは同じことです。「モデルはどうやって私の意図を理解するのだろう？」「情報はどこから来るのだろう？」と自問自答する必要があります。トレーニングデータか？コンテキストウィンドウか？コードベースか？私のプロンプトか？だから、もう一度言いますが、このトークから何か一つでも持ち帰るとしたら、それはこれです。情報がどこから来るべきか、というメンタルモデルです。このトークの残りの部分では、私が書くプロンプトのいくつかを見ていきます。これは恐ろしく見えますが、そうではありません。

［画像: Slide 15］

これは、私が「デーモンモード」という機能を構築するために使用したプロンプトです。これにより、Ampをヘッドレスで複数のマシンで実行し、リモートコントロールできるようになります。これはかなり大きな機能です。これはおそらく私が書いた最も大きなプロンプトの一つです。もう言えますが、これはネタバレです。私はいつもこんな風にプロンプトを書くわけではありません。しかし、ポイントを強調するために、これを見てください。

［画像: Slide 16］

これが始まりです。

［画像: Slide 17］

私は、「何か大きめのものを作るのを手伝ってほしい」と書き始めます。「現在、サーバーとスレッドアクターでは、新しいスレッドとサンドボックスを起動できます。」そして、2つのディレクトリを指し示します。

［画像: Slide 18］

次に、「E2Bサンドボックスを起動し、amp --headless を実行します。これは私たちのCLIです。だから、このフォルダにあるのが私たちのCLIで、このプロセスです。」と書きます。

［画像: Slide 19］

そして、「次に、これに接続し、ユーザーがリモートコントロールできるようになります。」と続けます。詳細は重要ではありませんが、この段落の後、私はすでにモデルに3つのフォルダを指し示しています。情報があるのはここです。大まかに言うと、それらはこのように接続されます。

［画像: Slide 20］

次の段落では、「さて、サンドボックスマネージャーの背後でE2Bプロバイダーを抽象化しました。このファイルを見て、あのファイルを見て、それらのドキュメントを読んでください。」と書きます。つまり、再び3つの情報源です。2つの段落、3つのフォルダ、3つのファイル。もし私がシニアエンジニアにこの機能を作ってほしいと頼むなら、こう言うでしょう。「これを見てください。これは私の頭の中にあるもので、これについて知っていることです。これを見てください。」

［画像: Slide 21］

さらに下にスクロールして、私が考える機能の概要を説明します。「このCLIに amp --daemon という新しいモードが欲しい。」と書きます。

［画像: Slide 22］

「これはこれに登録し、起動するとこれを行い、その後これを行います。」詳細は重要ではありません。

［画像: Slide 23］

ポイントは、私がどのように機能が動作すべきかを大まかに説明していることです。なぜなら、それは私の頭の中の情報だからです。だから、「リポジトリ内に配置する必要があります。チェックアウトやワークツリーは行いません。」と書きます。なぜなら、それは制約だからです。私がそれを入れなければ、どうやってそれが制約だとわかるでしょうか？

［画像: Slide 24］

さらに、「プロセスのライフサイクルを管理する必要があります。」と続けます。これも制約です。

［画像: Slide 25］

そしてシャットダウンするときは、すべてを終了する必要があります。

［画像: Slide 26］

そして、これはステージで話すにはかなりワイルドですが、私は「非常に非常に薄く、主にこれに焦点を当てるべきだ」といったことから始めます。

［画像: Slide 27］

このプロンプトではFableを使用しました。これはこれらの処理を非常にうまくこなしますが、明らかに少し曖昧です。しかし、これは私の頭の中にある情報です。モデルに知ってほしい情報です。

［画像: Slide 28］

そして、「この方向へ進みたい」といったことも書きました。そして、「これは私が心に留めていることだ。あなたも心に留めておいてほしい。それがうまくいったかどうかはわからないが、奇妙かもしれない。」と書きました。

［画像: Slide 29］

そして、「おそらく、これを行うべきだ。」と書き、その後に他の多くのことを続けます。

［画像: Slide 30］

ここでのポイントは、これらすべてが私が知っていること、またはどのように機能すべきかを知っていると思っていることですが、モデルはこの情報を持っていないことを知っています。トレーニングデータにも、コードベースにも、どこにもありません。だから、それを私のプロンプトに入れます。うまくいきました。

［画像: Slide 31］

あるいは、私が言うように、［鼻を鳴らす］これは奇妙ですが、2週間後、機能を変更したくなりました。

［画像: Slide 32］

それで、この大きな機能ができたのですが、気に入らなかったので変更したかったのです。

［画像: Slide 33］

どうやってやったかというと。

［画像: Slide 34］

「このファイルを見て、あのファイルを見て、それがどのように機能するか、そしてこのファイル内のこの次元を見て、どのように機能するかを分析してください。」と書き始めました。そして、それを完全に、少なくともある程度変更したいと思ったので、それは意味をなさないかもしれませんが、情報源を指し示しました。機能がどのように機能するかの情報はこれらのファイルとこのドキュメントにあるはずだと知っているので、エージェントをそこに指し示します。そうでなければ、どうやって知るというのでしょうか？

［画像: Slide 35］ ［画像: Slide 36］

そして、「画像1を見てください」と書きます。これは私がプロンプトに添付したスクリーンショットです。推測してください。これは長いSlack会話のスクリーンショットです。

［画像: Slide 37］

読む必要はありません。これは私とAmpの2人のティムとの間の、機能がどのように機能すべきかについての会話です。ポイントは内容ではなく、もしあなたがシニアエンジニアなら、私もSlack会話へのリンクを貼り、「ああ、情報はここにある」と言うでしょう。これには多くの情報が含まれていました。だから、プロンプトの最後で、私は再び書くだけで済みました。

［画像: Slide 38］

「これがどのように機能するか、多くのタイポがありますが、ここで光が見え始め、次にこれに接続し、 blah blah blah。」うまくいきました。

［画像: Slide 39］

機能をリリースしました。どこでもエージェントを実行できるようになりました。それができました。それは良いプロンプトでした。

［画像: Slide 40］

これが私たちが、あるいは私が言うことです。最初の2つのプロンプトは大きなプロンプトです。すべての情報をプロンプトに入れることができます。必ずしもそうする必要はありません。

［画像: Slide 41］

テクニックはここでは紹介しませんが、用語を造語しようとしました。私はこれを「ワンツーパンチ」と呼んでいます。もし誰かがこれに言及するなら、ここで、今、私が造語したことを知っておいてください。

［画像: Slide 42］

だから、すべてを最初のプロンプトに入れる代わりに、情報を見つけるように依頼します。「ニュースやクロニクル投稿をWeb UIに表示するために使用する、このトランペッターのガイの資産を見つけてください。」と書きます。

［画像: Slide 43］

添付されたスクリーンショットはこれのスクリーンショットです。Ampクロニクル、つまり固定された静的な文字列を取得し、それがどこにあるかを見つけられると確信していました。

［画像: Slide 44］

はい、できました。今、コンテキストウィンドウには画像の場所があります。スウェルコンポーネントがあります。別のOG画像バージョンもあります。すべてコンテキストウィンドウにあります。それから、私の依頼をすることができます。

［画像: Slide 45］

「このガイのバリエーションを4つか5つ作成してもらえますか？トランペットの代わりに、何でしょう？2つのシンボルと他のものが入っています。」と尋ねます。すると、「はい、できます。」と返ってきます。

［画像: Slide 46］

「どこにあるかわかっています。これを変更できます。ペインターを使用しますか？」

［画像: Slide 47］

ペインターはAmpにあるもので、新しい画像を生成するためのツールです。「どうぞ、それを使ってください。」と言います。6分で完了し、バリエーションが作成されました。次に、「彼がギブソン・フライングVを演奏しているような、そして『Master of Puppets』を演奏しているように見える別のものを作成してもらえますか？」と尋ねます。そして、うまくいきました。

［画像: Slide 48］

実際にギブソン・フライングVが気に入ったようです。それは良いプロンプトでした。

［画像: Slide 49］

その通りです。少しひねりを加えます。

［画像: Slide 50］

Ampにはメッセージをキューに入れる機能があります。メッセージをステアリングすることもできます。しかし、Web版が正しく動作しませんでした。CLI版は動作しました。そこで、Web版を修正することにしました。

［画像: Slide 51］

そこで、「CLIでキューイングがどのように機能するかを調査してください。それが理想的な状態です。」とプロンプトを始めます。そして、CLIのコードを指し示し、「これが、良い状態の例です。」と言います。「メッセージはキューに入れられ、ステアリング、アンステアリング、デキューが可能です。」つまり、見た目やフォーマットではなく、メカニズムに興味があることを伝えています。それがわかったら、依頼をします。「Web版がうまく動作していません。」と。

［画像: Slide 52］

「調査して、CLIのように動作するようにしてください。」と書きます。「これが情報です。これが理想的な状態です。さて、この他のものを機能させてください。」もし最初のステップを踏まずに、「私たちのWebキューイングは少し壊れています。」と言ったとしたら、どうなったでしょうか？壊れているとはどういうことか、良い状態とはどういうことか、モデルは知っていたでしょうか？だから、それを指し示す必要がありました。この時点で、あなたは「わかった。情報はどこかから来なければならないが、Thorsten、そんなにたくさんのプロンプトを手書きするつもりはない。多すぎる。」と思っているでしょう。私もわかります。そこで、もっとテキストを見せて、これをどうやって簡単にできるか話しましょう。

［画像: Slide 53］

これは、本番環境でデバッグする方法です。私は本番環境でよくデバッグします。

［画像: Slide 54］

しかし、このプロンプトの面白いところは、手書きしたのはこの部分だけだということです。

［画像: Slide 55］

それ自体はかなりひどいプロンプトです。「ここで何が起こっているのですか？なぜ起動しないのですか？」想像してみてください。部屋に座っていて、誰かがあなたの頭からフードを剥がし、「なぜ起動しないんだ？」とあなたは言います。「これ以上悪い日はない。」しかし、プロンプトの残りの部分は、これが何であるかを定義しています。

［画像: Slide 56］

それはドキュメントへのポインタの集まりです。IDがあります。データダンプがあります。多くの情報が含まれています。

［画像: Slide 57］

ここにはデバッグスクリプト、詳細情報を見つけられるURLまであります。これらすべては自動生成されています。だから、手で入力する必要はありませんでした。

［画像: Slide 58］

Ampでは、エージェントに問題がある場合、この例では、私のオーブワームに問題があったとしましょう。ここにあるボタンがあり、Ampの管理者や開発者は誰でも押すことができ、開発者サイドバーが開きます。

［画像: Slide 59］ ［画像: Slide 60］ ［画像: Slide 61］ ［画像: Slide 62］

そして、ここを見ると、「デバッグプロンプトとコマンド」があります。これらは自動生成されています。これは単なるマークダウン、単なるテキストですが、デバッグしているときは、これを本番環境からコピーして、本番環境への読み取り専用アクセスを持つエージェントに指し示し、「何が間違っているか調べてくれ」と言うのは非常に簡単です。多くのタイピングをする必要はありません。デバッグスクリプトやエージェントだけが使用する小さなコマンドさえ含まれています。それは便利なトリックです。

［画像: Slide 63］

もう一つはスクリーンショットです。もうお気づきかもしれませんが、私はスクリーンショットが大好きです。このトークの半分はスクリーンショットだと思います。そして、それらは明らかに情報の非常に良いソースです。

［画像: Slide 64］

このプロンプトはかなりひどいですね。

［画像: Slide 65］

「両方のディレクトリを読みますか？」また、頭にフードを被った状態で部屋にいる自分を想像してください。「両方のディレクトリを読みますか？」一体何を言っているんだ？どのディレクトリを、なぜ？しかし、添付した画像は、やはりスクリーンショットです。

［画像: Slide 66］

これはSlackでの顧客からの質問のスクリーンショットで、彼らはこれらの2つのディレクトリについて尋ねています。「エージェントスキル」と「コンフィグエージェントスキル」のディレクトリを読みますか？また、別のGitHubイシューを指しています。これも情報源です。エージェントはウェブにアクセスできます。だから、両方のディレクトリが何であるかについてのすべての情報はスクリーンショットに含まれており、その後エージェントがそれを解明します。

［画像: Slide 67］

エージェントはそれが何であるかを知っており、その後、「両方のディレクトリを読むようにしてください。」とだけ言えばよいのです。このプロンプトを書くのにかかった時間は？30秒くらいでしょうか？それ以下かもしれません。

［画像: Slide 68］

私はスクリーンショットが大好きです。本当に、本当に良いです。このトークのタイトルにしようかと思ったほどです。スクリーンショットが含まれているプロンプトだけを見せようかと思いました。なぜなら、私のプロンプトの90%にはスクリーンショットが含まれていると誓います。私は信じられないほど怠惰で、スクリーンショットを撮ってプロンプトに放り込むのはとても良いからです。

［画像: Slide 69］

だから、これがこのトークで持ち帰ってほしい2つ目のことかもしれません。もっとスクリーンショットを撮りましょう。

［画像: Slide 70］

さて、［鼻を鳴らす］もう一つ小さなものがあります：Amp Reportsです。これも自宅でコピーして実行できるものです。

［画像: Slide 71］

このプロンプトを見ると、「このレポートを調査してください。」「本番環境のログにアクセスできます。」かなりひどいですね。情報が少ない、非常にひどいプロンプトです。

［画像: Slide 72］

しかし、これはAmpレポートIDです。Ampユーザーが問題に遭遇すると、ツール内でこのコマンドを実行したり、Webで実行したりして、診断レポートを生成できます。

［画像: Slide 73］

つまり、ローカルのデバッグ情報、デバッグログ、直近500行のログをコンパイルし、それを安全にampcode.comに送信します。

［画像: Slide 74］

そして、私たちのリポジトリでは、Ampエージェントがこのツールにアクセスできます。Ampでは、プラグインでカスタムツールを定義できます。これはエージェントがこのツールを生成するのに約20秒かかります。「Ampレポートデータを取得する。」レポートについて尋ねると、レポートをダウンロードし、レポートには何が含まれているかを知ります。

［画像: Slide 75］

情報だけです。デバッグ情報、デバッグ状態、本番環境の情報、連結されたログ、すべてが含まれています。

［画像: Slide 76］

それができたら、あとはバグが何だったのかを尋ねるだけです。なぜなら、エージェントはそれを理解する方法、デバッグする方法を知っているからです。

［画像: Slide 77］

さて、最後のプロンプトに来ました。これは少し異なります。これが私の好きなプロンプトの書き方です。見てみましょう。

［画像: Slide 78］

「Web UIのこのピッカーを変更して、説明を含めてもらえますか？一番下に控えめな『さらに読み込む』スクロールを追加してもらえますか？」と尋ねます。

［画像: Slide 79］

スクリーンショットにはそれ以上の情報は含まれていません。これは単に私の同僚Willが「これは少し控えめすぎる。スクロールできることがわからない。修正してもらえませんか？」と尋ねているものです。しかし、私はそれを添付しました。なぜなら、エージェントがスクリーンショットからコンポーネントを見つけられると知っていたからです。

［画像: Slide 80］

次に、「この修正を実装し、Storybookのストーリーのスクリーンショットを見せてください。」と言います。Storybookは皆さんご存知だと思います。UIコンポーネントをレンダリングして、さまざまな状態で見ることができる小さなウェブサイトです。だから、それを実行するように依頼し、このプロンプトだけで、実際に行いました。

［画像: Slide 81］

15分間、Ampのヘッドレスインスタンスで実行され、2つのスクリーンショットが生成されました。問題を修正しました。それだけです。さて、あなたは疑問に思うでしょう。「一体どうやって？Storybookのスクリーンショットを撮ったり、その他のことをする方法をどうやって知ったのか？」

［画像: Slide 82］

しかし、15分間で行ったことを見ると、いくつかのファイルを読み込んでいることがわかります。

［画像: Slide 83］

最も注目すべきは、これらのAGENTS.mdファイルを読んだことです。ほとんどのコーディングエージェントでは、エージェントが兄弟ファイルを読み込むと、自動的にコンテキストに読み込まれます。だから、コードベースのあちこちにそれらを散りばめておけば、エージェントが別のディレクトリにいるときに、道しるべを残すことができます。

［画像: Slide 84］

これらのファイル、これはルートファイルです。ここでは、「開発サーバーを起動するにはこのコマンドを使用する」「ブラウザ自動化を使用する場合はこれ」「これを行う場合はこれを使用する」と定義しています。

［画像: Slide 85］

そして下に、「ストーリーブックを作成する必要がある場合は、このように記述してください。これはコンポーネントの名前です。」とあります。

［画像: Slide 86］

そして、ストーリーブックフォルダ自体には、別のAGENTS.mdがあります。「これはストーリーブックです。このURLで実行されます。ポートはここで見つけられます。チェック方法はこれです。」そして、うまくいきました。これは私にとって究極のプロンプトの書き方です。

［画像: Slide 87］

やり方をプロンプトから移動させ始めると、それはコードベースに格納されます。だから、時間をかけて、エージェントが特定のディレクトリをどのように扱うべきか、どのように物事を行うべきかについての情報をコードベースにますます多く含めるようにしたいのです。その情報はコードベースにあり、プロンプトから来る必要はありません。だから、それを保存して、「スクリーンショットを撮って。」と言うだけで、コードベースがそれをどう行うかをエージェントに伝えます。情報はどこかから来なければならないという事実は変わりませんが、コードベースにそれを含めるようにすれば、プロンプトに入れる必要がなくなります。これにより、良いプロンプトを書くのが非常に簡単になります。それが私が持っているすべてです。

［画像: Slide 88］

本当にありがとうございました。

Q&A — Aaron Francis との対談

Q&A — Aaron Francis との対談 · 22:53

Aaron: さて、見事でした。

Thorsten: ありがとう。

Aaron: あなたは最初に、Ampのコードの99%がAIによって書かれていると言いました。だから、多くの人がそれを聞いて、「一体何が起こっているのか、どうやって把握しているんだ？」と思ったはずです。あなたは一度、「どうやってやっているのか教えてくれ」と言って、それについて話しました。どうやってそのアプリケーションの全体像を頭の中に保っているのですか？自分で書いていないのに。

Thorsten: 「ロードベアリング（負荷を支える）」ものが何であるかを知る必要があると思います。私はエージェントがそれらを使い始める前から「ロードベアリング」という言葉を使っていました。しかし、何がロードベアリングなのか、つまり、何が重要なのか、このコードベースの揺るぎない基盤は何なのか、を知る必要がありました。それらについては、分散システムを書いたとき、コンポーネント間のプロトコル、何かがスリープしたときのランタイムの振る舞い、何かがウェイクアップしたとき、ビジネスロジックとそのエンコーディング方法など、手書きはしませんでしたが、エージェントがそれを変更するときは、まるでタカのように監視していました。ビジネス上の制約、ドメインロジックをドキュメントに書き留め、エージェントにそれらをチェックさせ、コードをレビューしました。コードを書かなくてもレビューでき、最も重要な部分が本当に堅牢であることを確認し、それがなぜ堅牢なのかを文書化すれば、次回エージェントを使用するときに、それらを再び変更することはありません。しかし、多くのコードはロードベアリングではなかったり、それほど重要ではなかったりします。コードベースの端に近づくほど、レビューする必要性は少なくなります。誰かを侮辱するわけではありませんが、例えばCSSにはそれほどこだわりません。ある側面では、 digging into する価値があるかどうかを判断する必要があります。コードベースで作業するほど、その感覚は強くなります。エージェントへの信頼も高まります。おそらく多くの人がまだやっていない最も実践的なことは、エージェントに非常に長いリードを与えて、どこまで行けるか試してみて、その後変更を元に戻したり、何を修正する必要があるかを見たりすることです。どこでうまく機能し、どこで機能しないかについての直感を発達させることができます。

Aaron: 信じられないほどの回答です。皆さん、拍手をお願いします。