現在、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 アドオンディレクトリでそのアプローチを採用しています
私はこのアプローチを歓迎します。すでに実行する必要があると認識していたことを確認するのに役立ちました。また、コードに対する信頼性を高めるのにも役立ちます。
チームがあまり無理をせず、ここでも同様の仕組みを実装できるのではないでしょうか。