世界を動かす技術を、日本語で。
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が生成したコードのレビューだね。
おい、雰囲気壊してるよ。
このページは、訴えられることをめちゃくちゃ心配してる大きな官僚機関の面白い展示だね。でも、AIバブルが弾ける前に何とか乗り込みたいっていう必死さも感じる。
「バイブコーディング」の定義が厳しすぎるのは残念だね。完全にAI生成のアプリがあったとしても、生成されたコードをちょっとでも覗いたり、小さな修正を加えた瞬間、それはもうバイブコーディングのアプリじゃなくなる。
コードに触れない限り、ただレビューしてLLMに変更を頼むだけなら、まだ「バイブコーディング」だよ。自分でコードに触れて、LLMが作ったものを編集したときが、本当のコーディングなんだ。
これはたくさんの（良い）実際のエンジニアリングやしっかりしたプログラミングのヒントだし、確かに「バイブ」じゃないね。指数関数的なものを受け入れたり、エラーをそのまま貼り付けたりすることはないよ。ほとんどの人は、本来の意味で「バイブ」することを本当に試みるべきだと思う。SuperWhisperを使って、差分も読まないでみて。全然違う体験だから。こういう感じで重要なコードを出荷しろとは言ってないけど、もしLLM AIツールを使う主な目的が、自分より速くコードを書くことだけなら（それは全然いいし、私も仕事でやってることだけど）、それは本当の「バイブ」じゃないよ。
「警告：AIアシスタントが生成したコードを盲目的に信頼しないこと。常に： - 生成されたコードを徹底的にレビューして理解する - すべての依存関係を確認する - 必要なセキュリティチェックを行う。」 もちろんこれは理にかなってるけど、雰囲気コーディングじゃないね。雰囲気コーディングのナンセンスから人々を遠ざけるために、用語を再定義する努力が見られるかもしれないけど、それは理解できる。
バイブコーディングがここでどう役立つのか全く理解できない。何も知らずに悪いコードを書くことに過ぎないよ。
「バイブコーディング」を「ピア/ペアプログラミング」と考え始めてる。効果は、私がどれだけ良いピアレビュアーになれるかにかかってる。ドライバーはAIで、すごく能力が高いけど、5%の確率で狂ったことをするから笑。私、ピアは慎重にレビューしてエラーを見つけるか、リラックスして「バイブ」しながら進めるかのどっちか。結果はもちろん、その関係性によって変わるよね。
「バイブコーディング」は、パートナーが作ったものに全く注意を払わず、ただその「バイブ」に乗っかって進めることを意味してたんだよね。どんなにひどくても関係なく。それに、あなたが説明してることにはもう名前があるし、自分でも言ってたよね。「バイブコーディング」って呼ぶのはちょっと冗長だと思う。
ちょっと関連する話なんだけど…AIを使ったコーディングについて、最近ちょっと疎くなってる。AIを使った面白いプロジェクトに取り組んでるユーチューバーを探してたんだけど、あんまりうまくいかなかった（「コーディングに使うべきトップ10のAIツール」みたいな動画からは進めなかった）。もし彼のプロジェクトに詳しかったら、tsodingスタイルの何かを考えてたんだけど。
自分の古いアプリを移植するためにClaudeコードを使ってみた様子を録画したんだ。初めてのユーザーとしてね。YouTuberじゃないから、自分を振り返るためにやってるだけで、あんまり面白くはないけど、君の質問に対するヒントにはなるかも。https://www.youtube.com/watch?v=d9YCkWjD7WQ&list=PLEWSTtjNAw...
https://x.com/steipete https://steipete.me/posts/2025/essential-reading-july-2025 https://steipete.me/posts/2025/the-future-of-vibe-coding
これ、ハッカーニュースで誰かが紹介してたチャンネルだと思うけど: https://www.youtube.com/playlist?list=PLm7RTomLsZo5PAWk0CpK0... あなたが説明してることそのものだよ。誰かがLLMを使ってコードを書いてる。結局あんまり見なかったから内容についてはあまり話せないけど、あなたが探してるタイプのものだと思うよ。
https://www.youtube.com/watch?v=qsTb9Y99qcQ これが私を惹きつけた理由だよ。この人は自分のために役立つツールを作って、そのプロセスを見せてくれるんだ。
私が「バイブコーディング」に対して取ったアプローチは、ただ擬似コードを書いて、それをLLMに翻訳させること。これがすごくいい体験で、映画の監督みたいに座ってるんじゃなくて、私がドライバーのままでいられるからね。しかも、細かい言語の詳細を気にしなくていい。例えば、fizz buzzのためにこんなプロンプトを書くよ。英語、Python、Rustが混ざってるのに注目してね。私が理解できることを書くだけで、LLMが私の望むものを出してくれる自信がすごく高い。fn fizz_buzz(count): loop count and match i: % 3 => "fizz" % 5 => "buzz" both => "fizz buzz"
これは本当に強力なアプローチだね。LLMは基本的に「スタイル転送」に関してはすごく強いから、ゼロからコードを書くよりもずっと上手い。最近のAIの大きな成功の一つは、逆のことをやったこと。Mulesoftのコードをそのネイティブストレージフォーマットで読む必要があって、結構厄介なXMLエンコーディングスキームとコード、他の変なものが混ざってたんだけど、AIに「これを擬似コードにして」って頼んだらかなり成功したよ。言語間の転送もすごく得意。完璧ではないけど、手作業よりはずっと良い。転送を検証することはまだ重要だけど、数十行ごとに一つか二つ間違えることがあるけど、ゼロからやるよりはずっと早いし、テストがあれば十分に使えるよ。
俺も似たようなことしてるよ。やりたい機能のシグネチャをコードで書き出す感じ。頭の中でアイデアが具体的になるほど、アウトラインやテストも詳しくなる。でも、これは vibe コーディングってより、実際の作業に近いと思う。全体的に vibe コーディングにはあんまり価値を感じてない。LLMは「価値を生み出す」けど、すぐにエッジケースやレビューされてないコードの重荷になっちゃう。バグが入り込んで進捗を妨げるし、その後は正気を保つために掘り下げなきゃいけなくなる。LLMがそこまで掘り下げてると特に難しいんだよね。
これって、知ってる言語で書くよりも本当に早いの？構文ハイライトやオートコンプリート、インデント、スニペットとかの恩恵がないじゃん。これって、俺がやってるよりも多くの作業を高コストで、しかも遅延がすごいって感じがするんだけど。
そういうことは、関数レベルに入って、役割に苦しんでいるアルゴリズムや最適化が不十分な場合にやることがあるけど、コードベースのアーキテクチャに優れたモデルは、そのレベルのマイクロマネジメントで手を縛られている感じ。結果は良いけど、他の返信者が言ってたように、LLMは厳格なルールセットを与えられたときにスタイル転送が得意だから。でも、この技術は時々、モデルがすでによく知っていることを無駄に定義するためにオペレーターのレベルで余計な作業をすることになる。「fizzbuzzの関数を書く」って言えば同じ出力の関数が作られる。「剰余を使ってfizzbuzz関数を書く」って言えば、より逐語的に近づくけど、ここで言いたいのは「これがタイピングによるRSIの痛みを軽減するのに近づくかどうか」という大きな視点では、擬似コードはLLMが関数レベルで何かバカなことをしたときにのみ必要になることが多いってこと。
最初は自然言語をプロンプトとして使ってたけど、コードの出力が理想的じゃなかったんだ。手順をリストにしたら、すごくうまく実行してくれたよ。
擬似コードは素晴らしいアイデアだね。何かがどう動くべきかを説明するのに似てる。
研究論文の擬似コードで大成功を収めたよ。文法をいつも理解してるわけじゃないけど、LLMにはそんな問題はないんだ。
いつも: > > 生成されたコードをしっかりレビューして理解すること。C++を使って、コード難読化コンテストのエントリーを読んでも、どのコードも完全に理解できたとは思えない。AIで「誰でもコードが書ける」と言っておいて、こんなことを言うのはちょっと矛盾してるよね。
「誰でもコードが書ける」と言っておいて、こんなことを言うのはちょっと矛盾してるよね。これだと「バイブコーディング」って言葉が全然当てはまらなくなる。最近は「AIの助けを借りたあらゆるコーディング活動」って意味に広がってるけど、「バイブコーディング」の本質は生成されたコードを理解してないことで、プログラミング自体ができない人がAIに全部やらせてる状態なんだよね。レビューして理解し始めたら、もうバイブコーディングじゃなくて、ただのコーディングになっちゃう。
C++を使って、コード難読化コンテストのエントリーを読んでも、どのコードも完全に理解できたとは思えない。そういう場合は、コードをレビューするときに「もっと読みやすくする必要がある」ってフィードバックするのがいいと思う。LLMに戻して、もっと理解しやすくするように要求すればいいんじゃないかな。
いつも: > > 生成されたコードをしっかりレビューして理解すること。これは実際に良いアドバイスだと思う。私の職場でもLLMエージェントを使ってるけど、自分が書いたり生成したりするコードのすべての行を理解する必要がある。それがあるから、まだ対面での面接もやってるんだと思う。