これを「隠れた要件」とするのは危険な道だね。Claude Codeや似たようなツールを使った経験から言うと、「隠れた要件」には以下が含まれるかもしれない。* DESIGN.mdが最新であることを確認する * ソースを変更した後はテストを書いたり更新したりして、ちゃんと通るか確認する * ユニットテストだけじゃなくて統合テストも追加する * 現在のタスクに関係ないコードはリファクタリングしない … これらはプロジェクトや言語特有の指示じゃなくて、ソフトウェアエンジニアリングでは常識や良いプラクティスとされてることなんだけど、時々コーディングエージェントにそれを守るようにお願いしなきゃいけなかったこともあったよ。（TypeScriptのコードベースで「any」を使わないように何回強調しなきゃいけなかったか知りたい？）人々は単にこれがコーディングツールの限界だって認めるべきだと思うし、それでも意味のある議論はできるはず。

重複を統一してほしいって言ったら、「問題ないよ、新しいメタモック抽象アダプターフレームワークがあって、すべての機能セットのスーパーセットに加えて、古いコードと新しいコード用の2つの新しいメタモックドライバーもあるよ！新しいアダプターのテストを書いてほしいなら教えてね。」って言うんだ。実際には5つの重複セクションのうち3つしか移行してなくて、今は死んでるコードは一切削除してないのに。

上から下に進めることを強くおすすめするよ。コーディングを始める前に、ちゃんとしたアーキテクチャをアウトラインするようにさせるんだ。それから、もしモジュールの一つが混乱し始めたら、そのモジュールのためにクリーンなコンテキストから始めて、悪い経験から得た注意点や教訓を取り入れる。LLMは、君が指摘した理由から、同じコードを作業したり再作業したりするのがまだ得意じゃない。でも、実装プロセスを何度も繰り返して正しくする「グラウンドホッグデイ」的なアプローチには結構向いてるよ。

コードの削除やクリーンアップのコーパスで訓練されたLLMがあってもいいかもね。

だから、ほとんどのプログラマーの労働力を置き換える準備ができていないって言う人たちに混乱するんだよ。

私の感覚では、コード生成は早いけど、その後に実装が適切で正しいか、しっかりテストされているか、正しい前提に基づいているか、技術的負債を生まないかを確認するのに数時間かかるんだよね。手動でコーディングする時も同じことをやるけど、AIツールが悪いコードを出力するスピードを考えると、もっと重要になってくる。

もし彼らがあまり良くないアプローチで何かを実装したら、後で制限にぶつかるたびにワークアラウンドや冗長なコードを追加し続けることになるよ。プランモード使ってる？昔はあまり良くないアプローチをして問題を掘り下げることが多かったけど、計画を立てることでそれがなくなった気がする。

皮肉を言うつもりはないけど、敬意を表して言うと…これはスキルの問題だよ。ツールなんだから。すごく効果的で能力のあるツールだと思う。なんでこんなに多くの人が似たような体験を語る中で、私の体験がこんなに違うのか分からないけど…ほぼ毎回、入力が出力を決めるって結論に至る。 > もし彼らがあまり良くないアプローチで何かを実装したら、後で制限にぶつかるたびにワークアラウンドや冗長なコードを追加し続けることになる。そう、プロンプトや指示が広すぎて、どうやってやるべきかを示すガードレールやガイドラインがないと、こうなるよね。プランモードを使ってないなら、それはスキルの問題。実装が始まる前に、すべてを整理しておく必要がある。もし実装が「あまり良くない」アプローチで行われたら、それはあなたの責任だよ。 > コードが遅いって言ったら、ふぅ。分かった。コードが遅いって言わないでしょ。自分の同僚に「ねぇ、君のコード遅いよ」って言って、いい結果が期待できる？コードのベンチマークをお願いして、どうやって最適化できるかを聞くんだ。それからその選択肢について話し合う（ここで前の段落の部分をやって、あまり良くないアプローチにならないようにする）まで進めて、気に入ったアプローチにたどり着いて、モデルが状況を理解していることを示したら、計画を受け入れてモデルに作業を始めさせる。この時点で、基本的にはアプローチを指示して、何もバカなことをしないようにしているはず。そうしたら、実行するだけで、あなたが設定した計画のパラメータや範囲内に収まる（もしバグがあるって言う代わりに具体的にバグについて言ったり、どう解決してほしいかを言わないと、脱線することもあるけど）。 > バグごとに10個の特注テストを持つこともできるし、前のフレームワークが目的に合わなかったら新しいモッキングフレームワークを毎回作ることもある。この点では、モデルが非常に無能だということには同意する。テストやテスト環境、モッキングに関して何が問題なのかを誰かが研究する必要がある。これに対する解決策は、掘り下げたり、無限に回ったりする問題の解決策と同じだよ…プロンプトや会話の初めに、最終結果に対する期待を述べる。出力を早めに定義して、その後に文脈を説明したり提供したりする。プロンプトや会話の早い段階で「要件」を設定すればするほど、より強固になる。テストについても全く同じ。自分でテストを書いて、モデルにテストから機能を構築させるか、モデルに計画された出力の一部としてテストを最初に構築させてから、事前定義されたテストから機能を埋め込ませる。テストシステムや環境の設定については非常に具体的に説明し、テスト関連の問題にぶつかった時にはモデルにそのことと解決策をTESTING.mdドキュメントにメモさせる。AGENTS.mdやCLAUDE.mdなどには、モデルがテストを扱う場合はTESTING.mdドキュメントを参照するように指示しておく。個人的には、機能に焦点を当てて、統合して動作する状態まで持っていって、ステージングや本番環境にプッシュする準備ができたら、モデルにその動作するシステムやソリューション、機能について分析させてテストを書かせる。一般的に、モデルに対するテスト環境のメモは、使用中の基本的なテストフローやプロセス、フレームワークを説明する段落のようなもので、どう動いてほしいかを伝える。慣習に従えば従うほど、うまくいくよ。そして、プランモードを使って。

この理由で、GitHub Copilotのチェックポイント復元/フォーク会話機能を多用してる。ほとんどの場合、何かが脱線するよりも巻き戻した方がいいから。