これらのAIコーディング記事は、ほとんどがグリーンフィールド開発についてのように見えるね。でも、プロのソフトウェアを作っている真剣なチームにいるなら、小さなタスクでない限り、AIにまず計画を立てさせることにはまだたくさんの価値があるよ。この投稿はそれをさらに進めて、形式化している。Cursorは計画モードを使って、出力をマークダウンで見直してからビルドする方が、ずっと信頼性が高いと思う。そんなに大きな負担ではないけど、確かに時間がかかるから、文脈の切り替えが多くなることがある。

なんでこんなコメントがたくさんあるのか、全然理解できない。昨日、Claudeにアプリ内のエンティティに対するすべての変更を追跡する監査ログ機能を書かせたんだ。多くのフレームワークではこれが無料でもらえるけど、うちのカスタムセットアップにはないんだ。いい計画を立てるのに5〜10分くらいかかって、その後Claudeが実装やテストに20〜30分かかった。これなら少なくとも1日、下手したら2日はかかってたと思う。他のタブで4〜5のタスクを進めながら、Claudeが機能を生成するのを20〜30分待ってた。生成後には、手動で動作確認をして、ちゃんと動いたよ。それからPRを出す前にコードを見直す必要があった。結局、小さな機能を追加するのに、実際には30〜45分くらいかかったかな。正直言って…ちゃんと使えてるの？AIツールの使い方を学ぶのに、本当に時間を投資した？

あなたには部分的に同意するけど、コードベースが大きくなると、変更を打ち込むのにも時間がかかるようになるよね。エージェントを使う最良の方法は、変更を書くつもりで考えをまとめて、自分のメモを取りながらエージェントに実行させることだと思う。エージェントは疲れないし、午後4時にミスをすることもないから、品質も落ちない。そして並行処理もできる。これによって、常に高いレベルに留まって「またこの簡単なことをやり直すの？」って悩まされることがなくなる。そうすると、頭の中の文脈が消えて、日中疲れてしまうからね。とはいえ、エージェントが書いたコードは100%見直すべきだよ。自分が「所有」していないコードをコミットすることは許さない。AIを使わせる仕事には絶対に賛成しないし、時には手で全部書きたいと思う。でも、このツールが使えるのは本当に強力だね。

Opus 4.5以降、かなり変わったよね。新しい機能やアイデアについて話すのにLLMがすごく役立つし、Sonnetはコーヒーを飲んでる間に計画を実行するのに最適だよ。

プロジェクトのリサーチや計画をするのは、一般的に役立つことだよね。これ、何年もやってきたけど、いきなりコードを書くよりもずっと良い結果が出てる。これがLLMの利用にもつながるのは当然だよね。

もちろん、アディ・オスマニはコーディングできるよ。彼自身もまず計画を立てることを勧めてるしね。 https://news.ycombinator.com/item?id=46489061

計画を立てたり、確認したり、促したり、調整したりするのは、自分でコードを書くよりもずっと大変だよね。これ！コードベースに慣れたら（すぐに慣れるように努力してるけど）、ほとんどのチケットについては、説明を読んだ時点でだいたいの計画ができてる。実装に関する質問がいくつかあるかもしれないけど、コードベースのどこに情報があるかはわかってるから。あまり具体的なアイデアがない場合は、ホワイトボードを使うかな。こういうメンタルプランのいいところは、ざっくりしたバージョン（スケッチみたいな）から始められること。例えば、新しいUI画面を作るときは、「Hello, world」みたいなプレースホルダーテキストを入れて、ナビゲーションに取り組む。そこが終わったら、データを引っ張ってきて、ビュー・モデルを作るためのマッピング関数を追加していく… 各ステップが確認可能なマイルストーンになるんだ。これを説明するのは、ただコードを書くよりも頭を使う。なぜなら、英語はコンピュータの動作を説明するのに向いてないから（ナビゲーションフローの有限状態機械を自然言語で説明してみて）。僕のメンタルモデルはすでにコードに合わせてあるから、自然言語で解決策を書くのは、わざと曖昧で不明瞭にするようなもんなんだよね。

精神的な負担が少ないからね。テスラのFSDみたいなもんだよ。俺はFSDより運転が上手いけど、ちょっとの間運転を任せるのはいいよね。たとえ最適じゃなくて、10%遅く着くし、後ろの人がちょっとイライラするかもしれないけど。それでも99ドル/月払う価値はあるかな。コードの実装は運転と同じように負担がかかるし、TFAの方法は全体的に開発者にとってストレスが少ないと思う。最終的には手動で修正もできるし、AIコーディングと手動コーディングはどちらか一方じゃないからね。

ソフトウェア開発の今はすごく混沌としてるね。誰も（1）LLMが特定のことをする原因を本当に理解してないし、ただプロンプトが確率を正しい方向に動かしてくれることを祈るしかない。以前は、決定論的な振る舞いや再現性を誇っていた分野だったのに。今は？親が子供に話しかけるようなAGENTS.mdファイルがあって、すべてが太字の大文字で強調されていて、ただそれが十分であることを祈っている（1 大手モデル会社のコアML開発者を除いて）。

乖離があるかもしれないのは、「ユーザーのために最終的な答えを生成すること」と「その答えに必要な情報を調べたり考えたりすること」の間に分離があるからかも。 「深く」と言うことで、ファイルのもっと多くの部分を読むように促している（つまり、実際にreadツールを使ってファイルのより多くの部分を文脈に取り込む）、そして「考える」トークンを生成する（つまり、ユーザーには表示されないが、モデルが自分の考えを洗練させ、答えの質を向上させるために書くトークン）。

こういうちょっとした嘘が役立つかもね。モデルの中の潜在空間を地形図みたいに考えて、プロンプトを与えると、地面の上のあるポイントにボールを落とす感じで、重力がその表面に沿って引っ張っていくんだ。だけど注意してほしいのは、これはトークンごとにいいけど、分布からトークンを選ぶことで信号が乱れちゃうから、再生成するたびに信号が歪むんだよね。ボールを深い地域に置くような言語を使うと、その歪みが望んでいる谷や盆地からボールを弾き出す可能性が低くなるんだ。もし得られるレスポンスが1000トークン長いなら、そこにたどり着くために1000の確率フィルターを生き残るための初期の軌道が必要なんだ。まあ、もしかしたら全部間違ってるかもだけど、そう考えることでうまくいってるから、十分だと思ってるよ。

実はこれ、すごく一般的なんだよね。Anthropicが書いたClaude Codeのシステムプロンプトを見てみると、「CRITICAL (RULE 0):」みたいな文がたくさん散らばってるし、他にも似たようなプロンプティングスタイルがあるよ。

コード生成をするときは、すごく論理的で明らかだよね。同じモデルに次のようにコードを生成するように頼むと、- あなたはPython開発者です...とか、- あなたはプロのPython開発者です...とか、- あなたは世界で最も著名なPythonの専門家の一人で、関連する本をいくつか書いていて、15年の経験がある、信頼性の高い生産品質のコードを作成しています...みたいに。生成された成果物の質が明らかに向上するのがわかるよ。

注意メカニズムが働いてるし、ネット上の優越感もあるよね。LLMはインターネット上のテキストやGithubのコードリポジトリ、プルリクエスト、StackOverflowの投稿、コードレビュー、メーリングリストなどを全部取り込んでる。そういうコンテンツの中には、「実は、詳細を見てみると…」とか「問題の複雑さを考えると…」とか「問題を深く理解していれば…」って言って、何をどう変えればよかったのかを専門的に詳しく説明してる人がいる。モデルには修正に使うコードを使わせたいんだよね、元のStackOverflowの質問のコードじゃなくて。だから「MITの教授になりきって」や「君はトップのPythonエキスパートだ」みたいなプロンプトが効果的なんだ。モデルにその用語が含まれてる部分に注意を向けさせて、他のプログラミングサンプルよりも重視させるんだ。

「スキム」みたいな言葉を含むトレーニングデータは、「詳細に」という言葉に近いトレーニングよりも浅い分析を提供してるかもしれないから、LLMはそれぞれの指示に応じてその言葉の分布を再生してるだけかもしれないね。

こんなことを読んで、なおかつ真剣に受け止める人がいるなんて信じられない。これはエンジニアリングの占星術に近づいてるよ。

LLMは、あなたが求めることをやってくれるけど、細かいニュアンスがないとダメだよ。自分も他の人も気づいてるけど、LLMはコードベースに大量のゴッドクラスファイルみたいなコードの匂いがないときの方がうまく動く。コードベースが明確で、頭に入るように分かれていれば、モデルの頭にもフィットするんだ。

どうやらLLMの質は感情的な刺激に敏感らしい？「大規模言語モデルは感情的な刺激を理解し、強化できる」: https://arxiv.org/abs/2307.11760

いい感じだね。質問なんだけど、この新しいAIの世界では、常にモノレポを使う方がいいのかな？それともアプリを別々のリポジトリに分ける方がいいのかな？うちの会社では、同じユーザーベースのために6つの別々のNext.jsアプリのリポジトリがあるんだ。全体的に楽になるはずだから、一つに統合しようとしてるんだ。

これがほぼ僕のアプローチだよ。今取り組んでるプロジェクトのために、いくつかの仕様書から始めたんだ。自分が書いた学術論文に基づいてね。Claudeと行ったり来たりしながら計画を立てて、情報を仕様書に戻して、広げていったら、複数の仕様書やアーキテクチャ、モジュール文書ができた。最終的には、自分のシステムを構築することになった（Claudeを使って）アーティファクトをキャッチして生成するために、もっとシステムエンジニアリングスタイルで（例えば、IEEEのコンセプト文書、要件文書、ソフトウェア定義、テスト計画に従って…）。セッションレベルの計画には使ってないけど、Claudeのツールはそれには問題なく機能してる。（スーパーパワーが好きだから、今のところは満足してる）コンテキストとガードレールを与えることで、Claudeとうまくやってる。基本的には「ガイダンスドキュメントに従って」って言うだけで、ちゃんとやってくれる。強力なテストと自己フィードバックのメカニズムを組み合わせれば、Claudeを簡単に軌道に乗せられるよ。トークンの使い方については、君と同じ経験をしてるけど、Codexの使い方には満足してない。Claudeは自分が求めてることを、求めてる方法でやってくれてる感じがするんだ。

あなたのスキルはオープンソースなの？

フィードバックをどうやって注釈付けしてるのか聞いてもいい？インラインコメントみたいに「# これをXに変えるべき」って感じで？著者は注釈について言及してるけど、Claudeにどうやって注釈を渡すかの詳細には触れてないんだよね。

同意する！だから、計画にはemacsでgptelを使うことが多いんだ。ドキュメントが会話のコンテキストになって、好きなように編集や注釈をつけられるから。