Vibeのコードハイプは、大きな言語モデルが達成できるものに大きな制限がありますが、このコーディングエージェントはかなり良くなっています。彼らは新しいフロントエンドページをスピンアップし、APIをワイヤーアップし、またCI/CDの構成を構築することもできます。しかし、誰もがどれほど不一致であるかを知っています。同じプロンプトは一度働き、次に破ります。彼らはあなたのコードベースの部分を忘れ、削減されたSDKを混合したり、あるいは単に物を作ったりします。 問題は、モデルが悪いということではなく、それはそれはそうでないということです。 こちらがその証拠 - 誰かがプログラミング言語を純粋にコーディングエージェントを使用して書いたのだが、もしそれが可能ならば、何でもそうである。 あなたの文脈を知る https://cursed-lang.org/ 信頼できる出力を得るには、より良いプロンプトを提供することはできません。 エージェントが働く - インプットを形作り、構造を与え、正しい境界線を設定します。 . engineer the environment context engineering 1.LLMsはエンジニアのように考えない LLMs は私たちの方法でコードを「理解」しません。 彼らは以前の入力のパターンに基づいてトークンを予測し、アプリケーションのビルドや構造に基づくものではありません。 したがって、プロンプトや周囲のファイルの小さな変更さえ出力を変えることができます。 構造がなければ、彼らはあなたのバックを記憶から推測するインターンのようなものです。 You can't fix this by screaming at the model. (I can tell, I tried) You fix it by giving it the right 毎回有効なコードに向かって導く制約と環境。 scaffolding 2.制限はコードを予測可能にする 社員が一貫して行動することを望むなら、 彼らは可能な出力のスペースを狭め、モデルが設定と一致するように強制します。 constraints are your friend いくつかの有用な制約: タイプ — TypeScript または JSON スケジュールを使用している場合、エージェントは、どのような形態に従う必要があるかを正確に確認できます。 Lint + フォーマット ルール - Prettier、ESLint、または codegen ルールは、追加のプロンプトなしで出力が一貫します。 小さなタスク — 「バックエンドを構築する」の代わりに、「このルートを src/api/user.ts に追加してください」と尋ねます。 構成とテンプレート — Typeconf と Varlock などのツールは、環境変数、SDK、またはエージェントが従わなければならない構成パターンを事前に定義できます。 トリックは、あなたが常に強力なタイプでコードを書いていることを確認することです. あなたは柔軟性を失わない - あなたは単に間違いを早めに捕らえ、行動を繰り返すことができます。 3. 土の真実としてのシステムを構築する コードがうまく見える時でも、エージェントが物事をワイヤレスにする方法について間違った推測をしたため、ビルドタイムでしばしば破損しますが、しばしばエージェントはコードを正しく作成する方法さえ理解していません。 例えば: あなたはそれをテストを実行するように求めます、それはnpmテストを書きます - しかし、あなたのレポはpnpmまたは nxを使用します。 実際の環境さえ存在しないDockerfileを構築しようとします。 インストールされていないパッケージをインポートします。 The fix is to エージェントに、コードがどのように構築され、テストされ、展開されているかを明確なイメージを与え、プロジェクト環境のための追加エージェントツールとして考えてください。 abstract the build system エージェントがあなたの世界で「構築」という意味を知れば、推測する代わりにその知識を使用することができます。 Bazel、Buck、Nx、またはよく構造化されたpackage.jsonはすでに良い基盤です。あなたがこの情報を表すほど、あなたが扱う幻覚が少なくなります。あなたがさらに進みたい場合は、エージェントが間違ったビルドシステムを呼び出すのを防ぐために自分のツールハックを書くことができます。 . https://docs.claude.com/en/docs/claude-code/hooks-guide 4. 時代遅れのトレーニングの問題 ほとんどのコーディングエージェントは、1年か2年経過したデータで訓練を受けています。彼らは、もはや存在しないAPIや、誰もが何世紀も前に捨てたコードパターンを喜んで使用します。 おそらくあなたは、こういうものを見たことがあるでしょう: 古いライフサイクル方法 React 未使用の図書館機能 Next.js API を削除する 新しいバージョンに移行したライブラリの NPM コマンド トレーニングだけに頼ることはできません. あなたは、実際のドキュメント、実際のコード、実際のコンフィギュレーション、独自の文脈を導入する必要があります。 ギャップを埋める方法: 例えば、Context7 のような MCP を介して、図書館ドキュメントにフィードします。 エージェントが実際のコードファイルや依存性を読み取るようにしてください - node_modules を読み取るように指示し、それが API を修正するのにどのくらいの頻度で役立つか驚くでしょう。 AGENTS.md にカスタマイズされた指示を追加し、モデルが使用しようとしている問題のパターンを繰り返さないようにします。 モデルが実際にそこに何があるかを知ったとき、それは幻覚を止める。 第5章 文脈 良いコーディングエージェントは、あなたのノートを読み取るだけでなく、状況全体を読み取ります。 あなたは3つの層で文脈を考えることができます: Static context プロジェクト構造、ファイルレイアウト、タイプ、config、build コマンド、dependences。 Dynamic context 現在のタスク、開いたファイル、エラーメッセージ、テスト結果、ランタイムログ。 External context 必要に応じて、ドキュメント、SDK 参照、Changelogs、または Web からのスナップレット。 すべての3つを組み合わせると、エージェントは実際にあなたのコードベースに搭載されている誰かのように行動し始めます - 記憶から推測するランダムフリーランサーではありません。 6.現実世界からの例 私は現在、統合を自動化するためのコーディングエージェントである SourceWizard を構築しています。WorkOS AuthKit 統合を自動化し始めたとき、このモデルが私に生み出した問題の不完全なリストがここにあります。 deprecated withAuth と getUser API を使用し始めました。 Mixed frontend and backend logic; (such as usingState on server-side components) 間違った環境変数を生成し、 間違ったパッケージをインストールしました。 もちろん、モデルはすべてのパッケージマネージャー、時にはnpm、時にはpnpmを通過し、モデルにとって最も興味深いものは何でもあった。 制限を追加した後、エージェントが何を使用すべきかを直接指定し、最新のAPIを搭載した後、モデルは統合コードを生成し始めた。 . consistently 違いはモデルにあるのではなく、それが見ているものにある。 コンテキストは新しいインターフェースです。 ほとんどの人はまだチャットボットのようなコーディングエージェントについて考えています: プロンプトを与え、答えを得ます。 真の魔法は文脈の中で起こります - エージェントがアクセスできるファイル、タイプ、コマンド、フィードバックループです。 将来、私たちは単にコードエージェントと「話す」のではなく、彼らを私たちのビルドシステムに導入します。彼らは私たちのレポを理解し、私たちのツールを知り、バックの他のどの部分と同じルールに従います。 結論 コーディングエージェントが失敗するのは、彼らが愚かだからではなく、彼らが盲目的に働いているからだ。 彼らが信頼できるチームメイトになりたいのなら、彼らに構造を与えてください: どのようにコードするべきかを定義する制限 あなたのプロジェクトが実際にどのように実行されているかを示す抽象を構築します。 古いパターンの使用をやめるために最新の文脈 文脈が良ければよいほど、コードが良くなる。 あなたは単に新しいエンジニアをあなたのレポに投げ込んで、「見出してください」と言わないでください。
