世界を動かす技術を、日本語で。
awslabs/mcp は、 AWS Labs が提供する オープンソースプロジェクト。 GitHub 上での通知設定や、 フォーク ・ スター などの基本的な操作方法を解説。 リポジトリの人気度や、利用開始時のポイントに言及。 ユーザーが 通知管理 を行うための前提条件。 コミュニティ参加のための基本情報まとめ。
ここで使われてる用語は間違ってるけど、ファイル全体のアドバイスはしっかりしてると思う。キロについて全然触れてないのが面白いね。キロは、雰囲気じゃなくてプロセスに焦点を当てたVSCodeのクローンみたいなもんだし。
「生成されたコードを徹底的にレビューして理解する」 それは雰囲気コーディングじゃないよ。雰囲気コーディングってのは、コードを見ないで、フロントエンドやバックエンドを見て、視覚的に期待に合ってればそれでOKってことだから、コードはこの場合関係ない。「見て、言って、実行して、コピー＆ペーストして、ほとんどうまくいく」って感じ。[1] もし変更が十分良ければ、つまりフロント/バックエンドがうまく動けば、それでいいし、どんどんプロンプトを出していけばいい。雰囲気に頼って、流される感じだね。[1] [1] https://x.com/karpathy/status/1886192184808149383
ゼロ番目のアドバイスは「フル雰囲気コーダーにならないこと」かも。誘惑に駆られることもあるけど、コードの小さな変更でも影響が大きいし、微妙な方法で影響することもあるから、少なくとも重要な部分はしっかりスキャンして読んでおくべきだよ。特にAWSでホスティングするのが現実的になってきたらね。君が引用したカーパシーの元の言葉でも、「使い捨ての週末プロジェクトには悪くないけど、かなり面白い。プロジェクトやウェブアプリを作ってるけど、実際にはコーディングじゃない」って言ってるし。もしかしたら「雰囲気プロンプティング」って呼ぶべきだったかも。
「やるべき作業の詳細な仕様を提供する」 雰囲気コーディングを数ヶ月やってみたけど、私の経験はこのアドバイスとはあまり合わないな。これが正しいやり方だと思ってたから、各機能のために大きなプロンプトを作ってた。実装のすべての詳細を指定した何百行ものマークダウンファイルの形になってた。最初は効果的なテクニックのように思えたけど、複雑になると崩れてくる。しばらくしてからプロンプトのサイズを減らし始めたら、改善された気がする。でも、具体的なデータはないんだ。もしこのトピックを探求したいなら、LLMに「既存の機能のためにチケットを作成して」と頼んで、出てきたフォーマットで遊んでみるのもいいかも。
2回目や3回目のイテレーションの機能セットについては、もっと強いスコープを持っておく方がいいと思う。特定の種類の機能やフィルター、データベースのスコープを追加するつもりがなかったからリファクタリングするのは、最初からそれを考えておくよりも悪い。ちょっと「仕様」とは違うけど、一発で決めるのは、目指すところまで行くにはいい方法だよ。その後に面白い機能を追加する場合、初期デザインが新しいアイデアに合わせてくれないから、ちょっとごちゃごちゃすることもある。例えば、最後の方でアンチDDoSライブラリを追加して、それを管理機能からスコープダウンしなきゃならないこともある。最初にその辺を仕様として決めておく方がずっといいね。
どうやって壊れるの？LLMが書いたことを無視したから？
こういうヒントやコツを見るたびに、フレームワークやツールの抽象概念をちゃんと学ぶ方が生産的だなって思うようになった。気まぐれなエージェントと格闘するよりもね。考えることが常にボトルネックだから、最も必要なのは： - システムの複雑さを減らすこと。 - 単純で繰り返しの作業を自動化システムに任せること（テスト、フォーマット、コード分析など） - 良い情報システム（ドキュメント、明確なチケット、良いコミット…） これで、タイピングや大量のコード生成に悩まされずに考えることに集中できる。コードは、機械が実行できる解決策の具現化だから、解決策が明確ならコードは単純なものになる。
俺もそうやってる。LLMが細かい説明をちゃんと守る保証はないし、セッションの最初に全部を一気に投げると、俺の場合はパフォーマンスが悪くなることが多い。まあ、LLMは大体はバカなタイピストだけど、たまに自分が考えてたよりもいいものを出してくれることもあって、制約をかけるとそれを失っちゃう気がする。
この意見には全く同意だわ。今のLLMが経験してるコンテキストの劣化に関係してるかもしれないね。使われるトークンが次のトークンを劣化させる感じで、入力や出力に関係なく。
このアプローチは、ウォーターフォールモデルがうまくいかない理由と同じで、結局崩れるよ。開発中に多くの情報が発見されるから、仕様が古くなったり間違ったりする。そうなると、LLMのコンテキストは深く毒されちゃうんだ。仕様自体からでも、コードベースの他の部分からでも。仕様を更新したり、大きなリファクタリングを頼んだりすることもできるけど、それが新しい問題を引き起こすことが多い。コンテキストが増えるにつれて、動くコードを生み出す可能性はかなり減っちゃう。その時点で進む方法は、自分で掘り下げてレビューしたり修正したりリファクタリングしたりすることだけで、果たしてこのワークフローが本当に生産性を上げてるのか疑問に思うことになる。
モデルと一緒に仕様をまとめて、盲点を見つけさせて、最終的な内容を明確で簡潔な言葉で書き出させるのが役立つことが分かったよ。次のステップとしては、モデルに仕様を実装するための詳細なステップバイステップの計画を提供させるのがいいと思う。この二つのステップは、Claude OpusやChatGPT5のような強力なプランニングモデルを使って、「私の開発者のために」と書かせてから、Claude Codeのようなものに切り替えるのがベストだね。
これは全然雰囲気コーディングじゃなくて、AIが生成したコードのレビューだね。