現在、LLMによって完全に生成されたプラグイン、テーマ、またはコンポーネントをアップロードしようとする人がいるかもしれません。また、それがLLM生成であるということを明示しない場合もあります。あるコンテンツが完全にLLMによって生成されたものであると知っていることは、さまざまな理由で有益であり得ます。現時点では、そうしたプラグインをLLM生成であると開示する義務はありません。個人的には、LLMプラグインに見られるようなパフォーマンス、最適化、UXに関する多くの問題を抱えた低品質なプラグインをインストールしてしまうのを避けるため、事前にそのことを知りたいと思っています。
もちろん、これは人々が正直に、事前に情報を開示してくれることに依存しています（AI生成のトピックを作成した人は、AIが生成した内容以上のことを知っていないかもしれません）。しかし、主にAIによって生成されたアセットに「#ai-generated」といったタグを付ける仕組みは、すべての人にとって有益であると考えます。
LLMで生成されたプラグインが本質的に低品質である、または必ずしもパフォーマンス、最適化、UXの問題を抱えるという見解には同意できません。結果の品質は、LLMを導き、その出力をレビューする人によって大きく左右されます。
私は過去40年間にわたって開発してきたソフトウェアに誇りを持っており、ワークフローにLLMを取り入れたことで、私の仕事の品質は低下するどころか向上しました。
逆に、手作業で書かれたプラグインの中で、セキュリティ上の脆弱性、パフォーマンスの問題、不適切な設計判断が散見され、本当に著者がLLMを使ってくれたらよかったのにと思ったことも何度もあります。最終的に重要なのは、開発者の質と結果として生み出されるコードの品質であり、LLMがその作成に関与したかどうかではありません。
LLMが生成したコードのレビューや更新について、皆さんはどうされていますか。新しい機能を実装したり、実際にリリースされている機能をカスタマイズしたりするために、いわゆる「バイブコーディング」に手を出し始めた私のような人に向けて、何かアドバイスがあれば知りたいです。
パブリックリポジトリでの集団的なレビューが理想的であることは承知していますが、まずは自分自身でできる限りの準備を整え、現在の自分の能力の限界を超えたバージョンのみを公開したいと考えています。
前回のコメントに同意します。AIに反対しているわけではありませんが、同時に、AIが生成する「すべて」を人間が監査し、検証し、更新する必要があることを認識しています。
関連する興味深いエピソードとして：
これはまったく公平な指摘です。最終的には、私は自分自身のことについてしか発言できませんが、私の観察では、低品質な「スロップ（粗悪品）」アプリが多数存在し、それらはすべて外見がほぼ同一で、機能面でもセキュリティ面でも全体的に品質が低いというものです。また、LLMに作業を大きくオフロードするようになったことで、品質が著しく低下した既存のアプリ（Visual Studio CodeやFormbricksなど、どちらも私はもう使用していません）もあります。たとえあなたのアプリが完璧だったとしても、倫理的な懸念は依然として残るため、提案されたような通知機能がこれらの生成物に対してあると良いですね。このタグに基づいて何かを判断しなければならないという意味ではありませんが、そうしたい場合に選択肢があるのは良いことです。
先ほども述べたように、これは本質的に信頼に基づくシステムであり、開発者が適切にタグ付けしていることを確認する責任は開発者自身にあります。もちろん、LLMがGitログ内で自分自身をタグ付けしている場合（多くの場合そうなります）もあります。その場合、GitHubを閲覧することで、TL3以上の権限を持つ人が必要に応じて対応できます。
ご返信いただきありがとうございます。私の質問はあなただけでなく、コミュニティの皆さんにも向けており、LLMによって生成されたコードを検証するための現在存在するツールについてです。
私は開発者ではありませんが、Discourseに存在しなかった機能を導入することに成功しました。そして、私の手が届く範囲で、最善を尽くしたいと考えています。
リポジトリを公開する場合は、タグ付けを検討します。現時点では、それらをテスト中であるため、意図的にプライベートにしています。コミュニティに配布する前に、正しく行いたいと思っています。
ほとんどのCoreコード（Coreプラグインを含む）が、コーディングエージェントを使って構築されていないなら、開発環境がここまで変化していることを考えると、非常に驚くだろう。
個人的には、コーディングエージェントを使わないことの正当化は、今やほとんどの作業に対して非常に難しい。効率の低下は、ビジネスとして意味をなさないからだ。
プラグインがどのように作成されたのか、あるいは作成者が鉛筆を使ったのかボールペンを使ったのかについては、まったく気にしていません。
テーマやプラグインをインストールする際に、「AIは使っていません」と言われることが、私の安心感に少しでもプラスになるとは思えません。
しかし……CDCKでは、より深刻な問題に取り組む必要があります。
Discourseのコアプラグインやソースコードは定期的にセキュリティスキャンが行われています。サポートされているチャネルをインストールするユーザーは、コードのセキュリティについて一定の安心感を持っています。
一方、こちらのサードパーティ製プラグインやテーマは「無法地帯」です。誰でも貢献でき、セキュリティスキャンも実施しておらず、ベストプラクティスへの準拠も確認されていません。これはコミュニティをリスクにさらしています。
私は、テーマの「バージョンXYZ」が少なくとも自動的にスキャンされ、セルフホスターに何らかの安心感を与えるような世界を望んでいます。
つまり、私のビジョンはまさにその逆です 
サードパーティ製テーマやプラグインのバージョンは、ここで公開される前に何らかのAIスキャンに合格することを義務付けるべきだと考えています。
LLMによるコードレビューは、「Claude、このアプリを作れ、ミスはするな」と指示して、ほとんど検証や編集もせずに出力を公開する行為とは全く異なるものです。少なくとも倫理的な観点からは、私はそう考えます。残念ながら、エンドユーザーに責任感を強いることはできませんし、どれほど努力しても、誰かが悪意のあるものをダウンロードする方法を見つけてしまうでしょう。とはいえ、LLMがどれだけ倫理的であるかは別の話であり、このスレッドとはあまり関係ありません。
それも全く問題ありません！AIが関与するものを全面的に禁止しようとしているわけではありません。Customization で適切にタグ付けしてほしいだけです。そうすれば、その「火蓋を切って落とす」ような状況に巻き込まれたくない人々が、誤ってそれを開くことがなくなります。
LLMベースのツール（とその結果）には多くの問題があります。セキュリティ、法的問題、信頼性、環境問題だけではありません。ただし、それはここでは主な論点ではありません。
ここでは、広義の「セキュリティ」が重要な問題です。コードがAIによって生成されたかどうかに関わらず。
CDCKはセキュリティチェックにどのようなツールを使用していますか？ さまざまなツールは、サードパーティ製コンテンツに対しても重要になります。
しかし、確認すべき点はそれだけではありません。サードパーティ製コンテンツは、どの外部システムと通信しているのでしょうか。多くのセキュリティ分析ツールは、ソフトウェアがハートビートなしで外部サーバーと通信することを許容します。しかし、純粋に装飾的なテーマコンポーネントが外部サーバーへの呼び出しを行うべきではありません。そのため、サードパーティ製コンテンツにはセキュリティ上の脆弱性が含まれている可能性があり、可用性を損なう問題が含まれている可能性もあります。また、データの漏洩を引き起こす可能性もあります。
これには95%同意します。そして今Discourseについて話していますが、もしWordpressの世界だったらどうなっていたか想像してみてください！
（残りの5%について：「無法地帯」とまでは思いません。セキュリティの問題はmetaを通じてサードパーティの開発者に報告されており、一般的にはかなり迅速に修正されています）。
しかし同時に、私の経験では、LLM（現在では）は平均的な人間のプラグイン作成者よりも安全なコードを生成します。プラグインをどんなにまともなLLMに投げても、「セキュリティの問題を見つけて修正してください」と頼めば、人間がセキュリティに関する知識がほとんどなくても、それをやってくれるでしょう。
私は過去10年間、プラグインを手動でレビューしてきましたが、多くのものを見てきました：SQLインジェクション（ActiveRecordが派手すぎると考えていた人々によるもの）、client: trueが設定されたAPIキーの設定、認証とアクセス制御の完全な欠如、レート制限の欠如。これらはすべて、LLMがすぐに、そしてあまり多くの労力をかけずに発見し修正します。
したがって、繰り返しになりますが、LLMはこれを悪くしたのではなく、良くしたと思います。
あなたは依然としてLLMが生成したコードを「厄介な問題（can of worms）」と結びつけていますが、それはあまりにも白黒つけすぎです。
Jack McDade は Statamic アドオンディレクトリでそのアプローチを採用しています
私はこのアプローチを歓迎します。すでに実行する必要があると認識していたことを確認するのに役立ちました。また、コードに対する信頼性を高めるのにも役立ちます。
チームがあまり無理をせず、ここでも同様の仕組みを実装できるのではないでしょうか。
低品質なプラグインやコンポーネントにも懸念を感じており、プログラミングに無知な人物が99%「バイブコーディング」で生成したものを信頼するのは難しいと考えています。
ただし、ここにいる経験豊富なプログラマーの多くが、AIが登場するずっと前から下手なプログラマーが存在したと言っています[1]。雑で信頼できず、欠陥のあるコードは、古くから手作業で書かれてきました。
私が本当に心配なのは、バイブコーディングされたアプリやプラグイン、あるいはその他のものを見て、作者がコードをレビューしていないと疑うことです。
私自身はプログラミングの基礎的な知識はありますが、長期間コードを書いておらず、以前から得意でもありませんでした。いくつかのプロジェクトでバイブコーディングを試してみました。
最初はメタに公式に公開することにかなり抵抗がありましたが、各コードの動作をレビューし理解する時間をかけた後、自分のアプローチをトピック内で公開的に説明することで、最終的に公開に至りました。公開前に読んだ内容をすべて覚えているわけではありませんが、少なくとも公開時点での信頼性とセキュリティを確保することができました。
バイブコーディングが、非常に安全性の低いプラグインをリリースさせてしまう可能性を説明する良い例があります。
🖼️ Topic Gallery を開発する前に、類似のプラグインのプロトタイプをここで作成しました: A way to monitor user-uploaded files 🖼️ - #2 by Canapin
これはうまく動作し、AIは私の指示に従っていました。
しかし、問題がありました：この機能は明らかにモデレーション（管理）用のものだったにもかかわらず、AIは権限を考慮に入れていませんでした。訪問者を含むすべてのユーザーが、このページを開き、全ユーザーがアップロードしたファイルを確認できてしまったのです。私には、これは管理者限定であるべきだと明白でしたが、AIはそのことを「考え」ませんでした。また、私がそれを要求しなかったため、デフォルトで公開ページが作成されました。
そのため、私とAIでさえこのようなセキュリティ漏洩を見逃すことができたなら、コードを書けない人々がバイブコーディングでカスタムテーマやプラグインを作成した場合、残念ながら同じことをしてしまう可能性がある、と自分に言い聞かせています。
ソフトウェアにおけるAI生成コードについての意見は、強く二極化しています。Claudeが最近のコミットの共同著者として記載されている人気のあるオープンソースプロジェクトを見てみると、一部の人間からの猛烈な嫌悪の波がわかるでしょう。
私は、これらのことには注意深く向き合い、意見をもっとニュアンス豊かにすべきだと確信しています。
vibe-coded というようなタグを導入し、適切にコードが書かれ安全性の高いカスタマイズやその作者の評判を不必要に傷つけることには、特に賛成ではありません。
今では誰でもカスタマイズを作成できるようになり、毎日さらに多くのものが出てくる一方で、それらをレビューできる人員は十分ではないことを知っています。
AIによるレビューが解決策かもしれません。私の直感は、さまざまな理由からこのアイデアをあまり好きではありませんが、Samがこのような解決策を提案するなら、おそらく良いものだと信じています。なぜなら、彼のスキルと判断力には非常に信頼を置いているからです。特に、私自身はプログラミングについて何もわかっていないので尚更です。 
もしかすると、プログラミングやDiscourseエコシステムに精通しているここにいる開発者たちに、この分野の専門性を明示的に示すタイトルを付与すれば、登録せずにカスタマイズを探している訪問者にとっても信頼できる開発者として認識されるようになるかもしれません。これはdarkpxlzさんが求めていることとは逆の方向性です。「信頼できない可能性のある」カスタマイズを「恥じる」のではなく、信頼できるものを強調するのです。
ただ、考えの種程度ですが。 
言えるのは、私もかつてその一人だったからです！ ↩︎
私が消費するメディアや、毎日接している人々の中に存在する反AIのエコーチェンバーに閉じこめられている可能性は、完全にあり得ます。このリクエストがこれほど不人気になることはないと、私はほぼ確信していました。しかし、もしここにいらっしゃる全員が実際にLLMを使ったコーディングを愛しており、純粋に透明性を確保するためのタグを望んでいないのだとしたら、それを止めるのは私ではありません。LLMコードの検出は依然として比較的容易なので、私のように本当にそれを避けたい人は、以前私が提案したように、貢献者の情報にLLMが自身をタグ付けしているかどうかを確認すれば済みます。
これは論争を呼ぶ話題なので、私は個人的にあなたの元の提案を支持します。それは、現在より懐疑的な立場にあるコミュニティの一部（それはもっともなことですが）のために役立ちます。
ただし、おそらくほぼすべてにラベルを付けることになり、それでは本来の意義が損なわれるのではないでしょうか？
また、他の人々の意見にも賛成ですが、AIが生成したコードはすべて同等ではありません。あるものは経験豊富な開発者の指示のもと、より最新で高価なモデルによって書かれていますが、他のものは、より能力の低いモデルを使用する経験の浅い人物によるワンショット生成である場合もあります。また、リポジトリがベストプラクティスを活用していない場合もあります。それらを判断するには、リポジトリ自体を調査し、人々が頻繁に問題を抱えていないかを観察する必要があります。
人間とAIの両方による徹底的なレビューは、ソフトウェアが元々人間によって書かれたものかAIによって書かれたものかを問わず、重要なソフトウェアにはすべて良いアイデアだと思います。ソフトウェアのレビューや、どのパッケージのどのバージョンを誰がレビューしたかを追跡するためのより良いツールがあれば、それは素晴らしいことです。現在、Rust/Cargoにはこれに似たものがあります：Crev、cargo-vet、そしてThirdpass。また、私はSwiftのフォーラムでディスカッションを開始しました。
私は「なぜラベルを使うのか」という立場です。ラベルを使うか使わないかは、多少は本質から外れた議論です。私にとって重要なのは、プラグインディレクトリにおけるコードや製品の品質を確保することであり、これが最優先事項です。この分野ではDiscourseが最終的な責任を負いますが、コミュニティも協力できます。その目的で、私の新しいBFF（最良の友人）と私は、DiscourseSkill.mdの作成に取り組んでみました。当初は社内で使うつもりでしたが、他の人にも役立つかもしれません。もし興味があれば、DiscourseSkill.md をご覧ください。