LLMを使ってソフトウェアを書く方法

46日前原文(www.stavros.io)

概要

プログラミング自体よりも、ものづくりへの情熱
**LLM（大規模言語モデル）**の進化で制作速度と品質が向上
複数モデルとエージェントを組み合わせた独自ワークフロー
コード品質の向上と保守性の維持
具体的なプロジェクト例と実践的な開発手法の共有

プログラミングの喜びよりも「ものづくり」

LLMの進化により、プログラミングそのものよりも「作ること」への情熱を再認識
プログラミングは手段であり、目的は「新しいものを生み出すこと」
LLMを活用して、短期間で多くのプロジェクトを実現
未知のフロンティアを切り拓く興奮
ワークフローの詳細解説と実際のコーディングセッションの共有

LLM活用によるメリット

Codex 5.2やOpus 4.6の登場で、低いバグ率と高い信頼性を実現
コードの保守性が向上し、長期間の開発でも品質を維持
エンジニアリングスキルの変化
- コードの正確な記述力よりも、システム設計力や選択力が重要
知らない技術領域（例：モバイルアプリ）では依然として難しさが残る
LLMとの対話方法によって成果に大きな差
モデルの進化で、今後はさらに人間の介在が減る可能性

LLMで作ったプロジェクト例

Stavrobot
- OpenClawの代替となるセキュリティ重視のLLMパーソナルアシスタント
- カレンダー管理、リマインダー、研究補助など多機能
- 個人ニーズに最適化されたアシスタント体験
Middle
- 音声メモの録音・文字起こし・Webhook送信が可能なペンダント型デバイス
- 常時利用可能・高信頼性・操作の手軽さ
Sleight of hand
- 不規則な秒針の動きを持つアート性の高い掛け時計
- 複数のモードで観察者の感覚に揺さぶり
Pine Town
- 無限キャンバス上のマルチプレイヤーお絵描き空間
- 多様なユーザー作品が生まれる遊び場

開発ハーネスと必要な機能

OpenCodeを主に利用、Piなど他の選択肢も
必要な機能
- 複数社のモデル利用（例：Claude Code, Codex CLI, Gemini CLIは制限あり）
- エージェント同士の自律的な呼び出し
- セッション管理やワークツリー管理などの補助機能
理由
- 異なるモデル間でのコードレビューによる品質向上
- 各モデルの強み・弱みを適材適所で活用
- エージェント同士の連携による作業効率化

ワークフローの構成

アーキテクト・開発者・レビュワーの複数エージェント体制
- 各エージェントはOpenCodeのスキルファイルで動作指示を明示
アーキテクト（例：Claude Opus 4.6）
- 唯一の対話相手であり、最強モデルを選定
- 目標・制約・トレードオフを徹底議論
- 詳細な設計プランを策定し、納得できるまでやり取り
- **最終承認（approved）**まで実装開始しない
開発者・レビュワー
- 設計プランに基づきコード作成・レビュー
- モデルごとに役割や得意分野を分担

まとめ

LLMの活用で、ものづくりのスピードと品質が飛躍的に向上
エンジニアリングの本質は「設計力」と「適切な意思決定」
複数モデル・エージェント連携による新しい開発スタイル
自分のやり方を見つけることの重要性
今後のLLM進化によるさらなる可能性

Hackerたちの意見

こういう分析を読むのが好きなんだ。ほんと、他の人がエージェントを使って開発にどうアプローチしてるか、アイデアや洞察を得られるよね。著者が開発者エージェントのペルソナをもっと小さなサブエージェントに分けてないのは意外だな。エージェントが広範囲のコードエリア（データベースクエリ、テスト、ビジネスロジック、インフラ、一般的なコードの骨組み）を書く必要があるときは、たくさんのコンテキストが使われるからね。あと、リサーチャーとプランナーを置くことで、開発前の段階でのコンテキスト管理が楽になるって読んだこともある。彼が複数のレビュアーを使ってるのもいいと思うし、専門的な役割に分けてないのも驚きだな。正直、私は「一つのプロンプトで全てを支配する」タイプの開発者で、最初に出した入力以上にチャットを続けることはないんだ。ミスがあれば、システムプロンプトか入力プロンプトを直して再挑戦する。できるだけ作業を細かく分けるようにしてるよ。それには、送信する前にちょっとした調査をする時間を取るってことも含まれる。みんなはもっと小さな特定のエージェントを使ってる？どんなパターンを使ってるの？よろしく！

└

あなたが挙げた参考文献は、今となってはちょっと古いね。8月のトークに基づいてるから、新しいモデルが生産性に大きな変化をもたらした「前の時代」のものだ。私が見つけた重要な変化は、オーケストレーションに関することだね。TFAが言うように、自分でプロンプトを実行するわけじゃない。オーケストレーターが全体を動かすんだ。建築家やプランナーと話をさせて、その計画の出力を別のエージェントに自動的に送る。彼の場合、建築家、開発者、いくつかのレビュアーを使ってるみたい。私はSuperpowersベースのオーケストレーションシステムを使ってるんだけど、ブレインストーミングからデザインプラン、実装プラン、開発者、レビュアーを経て、進捗と正確さをチェックするために実装プランに戻るんだ。実際、楽しいよ。40年以上コーディングしてるけど、今は楽しんでる :)

└

専門的なサブエージェントに分けることについては、確かに大事だけど、最初は分ける基準が明確じゃないんだ。私たちが見つけたのは、タスクの複雑さではなく、副作用のドメインで分けること。読み専門の「リサーチャー」エージェントと、出版専門の「ライター」エージェントは、片方だけが不可逆的なアクションを持つから、自由にコンテキストを共有できる。読み書きを一つのエージェントに混ぜると、再起動の安全性を考えるのが難しくなる。もう一つの実用的なことは、別々のコンテキストウィンドウを持つ別々のエージェントが、真に並行しているグラフの部分を扱うときに大いに役立つってこと。大きなエージェントは、並行化できる作業を直列化しちゃって、遅延が全体のパイプラインに影響を及ぼすんだ。

「大丈夫、私たちはまだアーキテクトをやってる、ただコードを書くんだよね」（意訳）っていう考え方がしっくりこないんだ。フルシステムの設計で試したことはないけど、今のところ得意じゃないと仮定すると…時間の問題だよね。じゃあ、私たちの使い道は何？

└

LLMは何でも作れる。真の問いは、何を作る価値があるのか、そしてそれがどう届けられるかだ。それがまだ人間の役割なんだ。LLMは人間でないがゆえに、人間を他の人間ほど理解できない。（セラピストとしてLLMを使おうとしたすべての試みを見てみて）要するに、LLMは最終的にはソフトウェアを設計できるようになる。でも、まだただのツールに過ぎない。

└

> じゃあ、私たちの使い道は何？新しい経済的な価値を見つける必要があるよ。それが技術進歩の現実なんだ。技術やホワイトカラーの業界は、自分たちにもそれが来るとは思ってなかったんだろうね！時代遅れになったスキルは、当然役に立たない。今日でも、工業規模の生産の中で手作りの品には需要があるから、コーディングでも同じようなレベルがあると思う。

└

他の人たちがすでに部分的に答えてるけど、私の20セントを言わせてもらうね。ソフトウェア開発は本当に建築に似てる。最終的な結果は、異なるタイプのコネクタ（道路、グリッド、APIなど）を持つユニークなモジュールのインフラなんだ。これまでのソフトウェア開発では、計画を立てたりコネクタの種類を決めたりするのは、ほとんど同じ人たちがやってた。リアルエステートの建築家も、彼らを助けるためにたくさんのソフトウェアツールを使うけど、最終的には人間のニーズを理解し、何年も勉強と実践を経て、全体の建物やインフラがどう機能するかを理解している人が必要なんだ。そして、その人は最終結果に対して責任を持ち、結果の複雑さや質に応じて報酬を受けることになる。だから、確かにソフトウェアエンジニアはそれほど必要なくなるけど、残る人たちは複雑でやりがいのある問題に取り組んで、さらにフロンティアを押し進めることになるだろうね。

本当に疑問なんだけど、アーキテクト→開発者→レビュアーの流れが、単に一つの強力なモデルと一回のセッションで話すよりも、実際に良い結果を生むっていう証拠は何？著者は各役割に異なるモデルを使ってるけど、私は毎日Opusでプロダクションエージェントを運用していて、良いコンテキストと明確な指示を一回の会話で与えれば、出力はすでにしっかりしてる。アーキテクトと開発者に分ける儀式は、コントロール感や可読性を与えてるように感じるけど、良いプロンプトがあれば単一のモデルが見逃すエラーをキャッチできるかどうかは疑問だな。

└

> 何の証拠があるの？ソフトウェアエンジニアが使うものの証拠って何？テスト、型チェック、構文ハイライト、IDE、コードレビュー、ペアプログラミングとかさ。俺の経験では、ソフトウェアエンジニアリングの実践の効果に関する証拠は二つのカテゴリーに分かれる。 - 開発者の直感、彼らの経験に基づいている。 - 科学的な研究、でもそれは説得力がない。生産性を測ろうとする研究もあるけど、実際のソフトウェアエンジニアの生産性を測るのは難しいから、マネージャーの評価みたいな質的な指標や、LOCやクローズしたチケット数みたいな意味のない量的な指標に頼るしかない。他の研究は、実際のソフトウェアエンジニアリングとは全く異なる特定のタスク（例えばコーディングパズル）に対して実践を測っているから、説得力がない。このLLMパターンの証拠も同じ。ある開発者は、うまくいくという直感を持っている。

└

分けるのは意味があると思う。異なるエージェントに具体的なプロンプトと孤立したコンテキストを与えるためにね。「アーキテクト」はコードスタイルガイドをコンテキストに持つ必要はない。それは実際には誤解を招く可能性があって、アーキテクチャから逸れてしまう情報を含んでいるかもしれない。

└

カーゴカルト的な現象が多いけど、こういう状況では避けられないよね。真実がモデル依存で、常に変わっているから、人々はAIの使い方を教えられるという前提で会社を作ってしまった。

└

これは経験談だけど、数日前に同僚と一緒にちょっとした実験をして、その証拠を集めたんだ。異なるペルソナ（アーキテクト、ビジネスアナリスト、セキュリティ専門家、開発者、インフラなど）を持つエージェントの階層を使って、要件を分析させて、リクエストを議論させて解決策を導き出した。彼らはプロジェクトのソースコードにアクセスできた。で、同じ入力を、ペルソナの定義を含めてClaude Codeに直接渡して、結果を比較したんだ。エージェントたちの協議は、約12ドルかかって、主にOpus 4.6を使ってかなり良い結果に至った。驚いたことに、Claude Codeに単一のプロンプトで直接渡したら、似たような良い結果が得られて、しかも早くて0.3ドルで、主にHaikuを使っていた。これはもっと調査する価値があるけど、今のところの仮説は、エージェント間の調整とコミュニケーションにはかなりのコストがかかるってこと。もしそうなら、個人的には驚かないな。 - 人間が仕事を分ける理由は、限られた能力があるからだよね。必要な分野で専門家になることはできないし、良いアーキテクトやビジネスアナリスト、セキュリティ専門家になるための知識を身につけることはできない。どうやら、LLMにはそれが問題じゃないみたい。だから、仕事の分け方は人間には必要なパターンだけど、LLMにはそうじゃないかもしれない。 - 仕事の分け方には高いコストがあって、スケールしない。特に、人間の組織では調整に関する問題が多いし、組織が大きくなるほどプロセスのコストが高くなって、最終的には官僚主義に変わる。IT企業では、グループ間のインターフェースに多くの問題があって、低帯域幅のコミュニケーションや言語の曖昧さが原因だ。単一のLLMが自分自身とコミュニケーションを取る方が、エージェントの協議よりもずっと良くて安いのは驚きじゃない。

└

モデルの違いは大きいね。私のワークフローでは、オーパスが深い思考をして、キミが実装を担当してる。コスト管理に役立つよ。一つのサンプルだけど、モデルが逸脱するのを防ぐのに役立つと思った。私の異なるエージェントには異なる権限がある。作業者はプランを編集できないし、QAやプランナーはコードを修正できない。これ、時々コーデックスが関係ないものを修正してるのを見かけるんだ。

└

これはただの擬人化だと思う。サブエージェントはコンテキストを保存するメカニズムとしては意味があるけど、Aiderは「アーキテクト-エディター」の分割をしていて、アーキテクトは変更をdiffとしてフォーマットすることを気にしない「プログラマー」なんだ。それを弱いモデルがdiffに変換して、結果が良くなったんだよね。でも、これは人間のチームとは全然違うよ。

└

自分が何を必要としているかが分かっているなら、私の経験では、文脈に合ったしっかりした単一のプロンプトが一番良い結果を出す（しかも早い）。アイデアを探っている時や反復している時には、役割を使うと分解して自分の要求を理解するのに役立つよ。個人的には、コードからは少し離れたところでやってるけどね。

└

「…良い文脈を与えれば…」って、基本的にそれがアーキテクトセッションの目的だよ。アイデアを出し合って、進みたい方向を決めるんだ。それから、クリーンな文脈で実行する。最大限のパフォーマンスを引き出すためには、すでに捨てた実装の行き止まりを思い出さないクリーンな文脈が必要なんだ。

└

細かいことだけど、"アーキテクト"ってこの役割にはあまり合ってないと思う。もっと技術的なプロジェクトのキックオフ的な役割だよね。これからやるべきことやリスクを予測する感じ。コードを書くときの思考とは違うと思うから、別の文脈で、別のツールを使ってこのステップを分けるのが有用だってのは驚かないよ。誰かに「あなたはアーキテクトです」と言うのが役に立つのかは疑問だけど、合理的な結果が得られない限り証拠はないしね。人間のチームでは、すべての開発者がこれを学ぶべきだと思うし、それが自分のためにもなるし、誰か一人にボトルネックを作らないためにも重要なんだ。これが良い結果のサインだと思うから、"アーキテクト"が職業名として使われるデータにLLMを偏らせるのは賢明じゃないと思う。

└

質を分けることじゃなくて、コスト最適化の話だよ（Sonnetの実装は安いからね）。質はレビュアーに依存するんだ。私は同じモデルを使う役割を分けることはしなかったけど、新しい役割を使うためだけに役割を使うのは意味がないと思うから。

LLMを使ったプロジェクト構築のプロセスを説明する記事がたくさんあるけど、ひとつだけ理解できないのは、著者たちがまるで人間に話しかけるかのように、文法や構文を気にしてプロンプトを書いていることだ。例えば、>「このボットにメールサポートを追加したいです。どうやってやるか考えてみましょう。」とかさ。しかも、「お願いします」や「ありがとう」の使い方についても言ってない（この著者はそういうのを気にしていないみたい）。「メールサポートを追加したい、どうやってやるか考えて」って書いた方がモデルがより良い結果を出すっていう証拠はあるの？個人的な経験（主にJunieとのやり取り）では、「丁寧」であることに特に利点を感じたことはないし、時間とトークンを節約できている気がする。

└

丁寧にするのが好きな人もいるから？そんなに理解するのが難しい？手書きのプロンプトは、どうせコンテキストウィンドウの大部分を占めることはないだろうし。

└

丁寧にプロンプトを書く理由は二つある。モデルがスパイラルに陥る可能性が低くなると思うから（でもそれに関しての確固たる証拠はない）、そして実際の人と話すときのためにその習慣を続けるのが良いと思うから。

└

丁寧にする理由は、LLMがプロフェッショナルな道を維持しやすくなるからだと思う。LLMは基本的に、あなたのプロンプトをトレーニングセットと整合させようとするから、丁寧なプロンプトとその回答は、場違いなプロンプトよりもスコアが高くなる（より良い結果を出す）。人によってはこれが擬人化に感じられて嫌がるかもしれないけど、俺にとっては純粋にエンジニアリングの話なんだ。編集：言い回し

└

みんなの意見は分からないけど、私にとって一番正確な答えは「ロールプレイしてる」ってことかな。そうすると流れが良くなるからね。頭の中では、チャットボットが会話に基づいて訓練されてるって分かってるし、プロフェッショナルでクリアなトーンを反映させたいと思ってる。でも、ほとんどの場合はもっとシンプルにすることが多いかな。あなたの例だと、>「このボットにメールサポートを追加したい。どうやってやるか考えてみよう。」って感じになると思うけど、私はこう書くかも。>「メールサポートを追加したい場合、どう進める？」とか、>「メールサポートを追加するための簡潔なステップ/プラン、KISS」ってね。でも、ブレインストーミングや検索、ラバーダックモードの時は、もっとリアルな会話みたいに書くかな。

└

数年前はもっと重要だったと思う。ユーザーのプロンプトがほとんど全て、LLMが頼りにするコンテキストだったから。雑なスタイルで書かれたプロンプトは、LLMが雑なスタイルで返す原因になってた（結局、派手なオートコンプリートだからね）。LLMはトークンで推論するから、雑なスタイルは訓練データの雑な文章の推論を模倣することになるんだ。それは悪い推論になる。最近は、ユーザープロンプトはコンテキストのほんの一部だから、あまり重要じゃなくなったかも。でも、私は今でもやってるよ。関連する技術用語を含めて、正しいベクトル空間の検索に導くようにしてるんだ。（これは訓練資料の中でより高度なディスコースから構築されたベクトル空間の部分だよ。）

└

コンテキストウィンドウに流れる意識をそのまま書くのが、私にはすごく効果的。質問に対してモデルに良いコンテキストを提供することが大事だと思う。

└

「ボット専用」みたいな書き方が習慣になると、人間とのコミュニケーションが衰えてしまうと思う。トークンなんてどうでもいいけど、こういうコンテキストの切り替えは代償が大きすぎるよ。

└

現在のモデルではそれほど大きな問題じゃないけど、どんなコンテキストでも嫌な奴になるリスクは避けるべきだと思う。機械だからって理由で何かをひどく扱うのは良い言い訳じゃないよ。それに、情報エンジンに意図的にクソみたいなものを流し込んで、良い結果が出ることを期待するのは狂気だと思う。彼らがしばしば醜さにもかかわらずうまく機能するのは奇跡だけど、それに依存するのは避けた方がいいね。

└

だらしないライターになってしまう習慣はつけたくないんだよね。そうなると、実際の人との会話にも影響が出ちゃうから。

└

推論の痕跡を示すモデルについてだけど、彼らの内面が単語計算機として現れるのを見たことがある。タイプミスについて文句を言うのにトークンを使いすぎるんだよね（AIのコードレビュー用ボットもタイプミスに執着してて、途中で関係ないタイプミスが多すぎると、モデルがそれにこだわって他のエラーを見逃しちゃう）。最近は少し改善されたかもしれないけど、気にする必要はないよね。それに、モデルがユーザーのスタイルに合わせようとすることもあるから（自動補完で余計なステップが多い）、だらしないプロンプトを与えると、出力もだらしなくなるんだ。

いくつかのパターンが見え始めて面白いね。時間が経つにつれて、似たようなワークフローになったよ。リポジトリ内のプランファイルを使う代わりに、ノーションをメモリと真実のソースとして使ってる。私の「考える」エージェントが質問をして、探求し、洗練していくんだ。ノーションで機能ページを書いて、実装をタスクに分けてカンバンボードに載せる。それを「実行者」が受け取って実装し、QAエージェントに渡す。QAエージェントはそれをフラグ付けするか、人間のレビューに回すんだ。本当に気に入ってるよ。他のドキュメントも全部ノーションにあるから、ビジネス要件を簡単に参照したりリンクしたりできる。ボードのチケットをチェックする方がファイルを見るよりもステップを理解しやすいし、レビューも簡単だよ。人間レビューのカラムからチケットを選んで、要件を再確認して、QAのコメントをチェックしてからコードを見ることができる。昨日はこれで遊ぶのがすごく楽しかったし、ここにシェアしたよ: https://github.com/marcosloic/notion-agent-hive

└

批判するつもりはないけど、あなた（やLLMやエージェントコーディングを受け入れた他の人たち）が、コーダーよりもプロダクトマネージャーになりたいって感じがする。実際のPMはもっと多くの要件があって、需要も少ないんだ。要件が多いっていうのは、人と接することができて、少なくとも半分の時間を会議に費やす覚悟が必要ってこと。需要が少ないのは、一人のPMが半ダースの開発者の仕事を整理するから。LLMを使ったコーディングが多くの開発者の仕事を奪うって言う人もいるけど、こういう投稿は多くの管理やオーバーヘッドも解決するって示唆してるよ。プロジェクトマネージャーはちょっと無駄だと思ってたけど、ソフトウェア開発者としては、誰かがタスクとその要件/受け入れ基準のリストをキュレーションしてくれるといいなと思う。でも、残念ながらそれが現実じゃなくて、開発者自身がタスクを作って埋めて、実行するのが多いんだ。もちろん、そうなると「なんでまだPMがいるの？」って疑問が出てくるよね。（これはあくまで個人的な経験で、普遍的なものではないと思うけど。）

うちらはマルチエージェントシステムを作って運営してるんだけど、今日の勝者はCursorだったよ。ログ分析のタスクで、Cursorは5分、うちのパイプラインは30分かかった。とはいえ、利点もあるんだ。1. 役割ごとの孤立したコンテキスト（CSとエンジニアリング）で、エージェント同士が干渉しない 2. エージェントごとの厳しい権限の境界 3. 安価なルーチン作業のためのローカルモデル（Qwen）マルチエージェントはデバッグでは負けるけど、構造には価値があるよ。

なんとなくクリックして、Stavrobotのソースコードをスクロールしてみた。最近作った中で一番大きいのは、セキュリティに特化したOpenClawの代替品なんだ。[1] でも、あんまり良いコードじゃないよ。まだAIを使ってコードを書くことはしてないけど、試してみようかなと思ってる。これが期待するようなコードなのかな？それとも逆に、AIが書いた非自明なコードの例（サイズと複雑さがあるやつ）で、手をかけずに本当に良いコードがある人いる？[1] https://github.com/skorokithakis/stavrobot

└

自分の経験から言うと、頼んだことに対してそれなりのものが返ってくるよ。具体的なことを頼まないと、勝手に書くからね。自分がループに関われば関わるほど、期待に沿ったものを書かせやすくなるよ。それに、自分の好みに合ったスタイルガイドを与えるのも効果的だよ。

└

LLD（クラス/インターフェースレベルの設計）をLLMに任せるのはやめた方がいいと思う。クランケレンはそれがすごく苦手なんだ。全てを使い捨てのスクリプトとして扱うからね。それに、AGENT.mdとかアプリ内で呼ばれている何かにベストプラクティスを文書化しておくのもいいよ。例えば、* 全てのインポートはファイルの先頭に追加すること、関数内には絶対に入れないこと。 * シナリオがフォールトトレランスを必要としない限り、例外を飲み込まないこと。 * 全ての関数にはパラメータと戻り値の型注釈が必要。などなど。ほとんどいつも自分でクラスレベルの設計を定義してるよ。ある意味、LLMを使って空白を埋める感じ。設計はまだ自分のものだしね。

└

プロジェクトの中で1000行の.cppファイルを見つけることもできたよ。この記事の内容は彼のアプリの質には合ってない。全然価値をもたらさないし。彼の時計は完全にAI生成に見えるね。

> 一つ気づいたのは、いろんな人がLLMを使って全然違う結果を得てること。だから、話し方に何かしらの要素があって、それが結果に影響してるんじゃないかと思う。プロンプトのせいにするのは簡単だし、自分には他の人にはない才能があるって思い込むのもね。私の経験では、違いは主にLLMが生成したコードのレビューの仕方にあると思う。コードレビューの経験がある開発者は、問題をすぐに見つけやすいし、あまり手取り足取りしないと良い結果が得られないって文句を言うことが多い。一方、他の開発者のコードをほとんどレビューしたことがない人は、必ず見逃す部分があって、得られた出力を高く評価しちゃう。

└

モデルのせいにするのは簡単だし、自分には他の人にはないLLMの仕事をレビューする才能があるって思い込むのもね。私の経験では、違いは主にLLMが生成したコードのプロンプトの仕方とエージェントに与えられる文脈にあると思う。自分の仕事を委任する経験がある開発者は、下流の問題をすぐに防ぐことができるし、同僚があまり手取り足取りしないと効率よくプロンプトできないって文句を言うことが多い。一方、仕事をほとんど委任したことがない人は、重要な文脈の詳細を見逃して、得られた出力を低く評価しちゃう。

└

それは納得できるね。コードレビューのスキルを向上させるための提案はある？特に、私たちのようなジュニアプログラマーはこの点で不足していると思うし、ただLLMを使って時間をかける以外に明確な改善方法が見えないんだよね。

└

LLMと話すスキルじゃなくて、ユーザーがLLMに解決を求めている問題に対するスキルと経験なんだ。プロンプターがよく知っている問題にはうまく機能するけど、あまり理解していない問題にはうまくいかない。自分で試してみて。よく分からないことをClaudeに頼んでみて。それからそのことを学んで、新しいClaudeのインスタンスを使って再度試してみて。そうすれば、あなたの知識と経験が自然にプロンプトに組み込まれて、うまくいくはずだよ。

└

> コードレビューの経験がある開発者は、問題をすぐに見つける可能性が高いし、手取り足取りしないといい結果が出ないって文句を言うことが多いよね。だから、これらのLLMからの出力に対して感じていた軽蔑の気持ちが少し和らいだよ。たまに必要なものがポンと出てくるけど、いつもそれが外れて手動で編集が必要になるとは限らないから、あまり信頼できないんだよね。

└

コードレビューの経験はLLMの成功に大きく寄与していると思うけど、私の考えはちょっと違うかな。もし他の人のコードをたくさんレビューしてきたなら、LLMで見られる失敗は共通の失敗だって気づくはず。人間も同じことをするからね。レビューしやすいコード、つまりコードレビューを簡単にするために特別に提供されたコードは常に価値があったけど、生成コストが下がった今、その相対的な価値はずっと高くなったと思う。だから、計画やプロンプトを含めて、レビューしやすいコードに導くアプローチを構築することが、以前よりも価値のあるスキルになったんだ。

└

それが言いたかったんだよ。 "正しい言葉を言う"って意味じゃなくて、"文を渡して去る"ってことじゃないってこと。

└

あなたの主張を食べ物の例で反論しようと思ったけど、成功したかはわからない。自分で判断してみて：食材を責めるのは簡単で、自分が他の人とは違う料理の才能を持っていると納得しやすいよね。私の経験では、キッチンで作られた料理の味の違いがほとんどだと思う。料理を批判的に味わう経験があるシェフは、問題をすぐに見つけて、慎重な調整なしでは良い結果が得られないと文句を言うことが多い。逆に、他の料理人の料理をほとんど味わったことがない人は、必ず何かを見逃して、もらった料理を高く評価する傾向があるよ。

└

私の経験では、違いは主に椅子とキーボードの間にあると思う。Codexに好きなレストランガイドをスクレイピングさせて、オープン、クローズ、またはもうすぐオープンするかどうかで色分けされた地図上にそのレストランを表示するiPhoneアプリを作ってもらったんだ。以前にiOSアプリを作ったことがあるけど、これを自分の電話にプッシュするのに10分もかからなかったよ。アプリはちゃんと動いて、私が望んでいたことをそのまま実現してくれて、日常生活を意味的に向上させてくれてる。

いい記事だね。プロンプトエンジニアリングにガードレールとベンチマークを組み込むことをおすすめするよ。Opus 4.6のアーキテクトへのシステムプロンプトみたいに考えてみて：LangChain、RAG、LLM-as-a-judge、MCP。ベンチマークについて考えるときは、常に外部DBや他のリソースを調べるように頼むんだ。これが参照用のガードレールになる。

opencodeに大賛成！私の目的にはClaudeと同じかそれ以上に使えるし、GitHub Copilot Proプランを通じてAnthropicモデルも使えるんだ。トークン制限に引っかかるときは、opencodeとClaudeを使い分けてる。追記：下のコメントでopencodeを好む理由を思い出した。Claudeのセッションで数ページ進むと、出力のたびに会話履歴全体をスクロールしてるからね。OCにはそんな問題はないよ。

ハクソク