この推論にはかなり飛躍がありますね。
-
インターンを雇ったり、あなたが10晩かけて作業すれば、FLACプレイヤーを架空のアプリに追加できたはずです。LLMの使用に本質的に悪いプロダクト判断が含まれているわけではなく、無用の機能を追加することが開発努力の無駄かどうかは、常に議論の対象でした。
-
追加機能がアプリを必ずしも遅くしたり、RAM消費を増やしたりするわけではありません。その問題は40年前に動的ロードという概念で解決済みです。
まさにその通りです。強調したのは私です 
「いいね！」 3
いいえ、この区別はすべきではありません。
- ソフトウェアは安全ですか？
- 私の問題を解決してくれますか？
また、私の最初の指摘に戻りますが、
テーマにセキュリティ上の問題があるなら、審査システムについて話し合いましょう。
テーマに品質上の問題があるなら、審査システムについて話し合いましょう。
しかし、トピックに「Macで開発」「赤いキーボードで開発」「AI使用率93.2%」といったステッカーを貼ることはしません。そんなことはあり得ません。
私はどの程度AIを使っているか、別のトピックでワークフローを共有することは喜んで行いますが、もうvimで手動コーディングはしていません。
「いいね！」 7
AIが生成したプラグインを、AIが作成したという理由だけですべて拒否するのは、遺伝的誤謬に該当します。AI生成であることは以前までは低品質なコンテンツ（スラップ）を示す良いヒューリスティック（経験則）でしたが、モデルの精度が向上するにつれ、人間とAIの出力を見分けることはますます困難になりつつあります。品質やセキュリティへの懸念がある場合、すべてのコードは、何らかのクラウドソーシング型のピアレビューシステムによってレビューされるまでは安全ではないと仮定する方が安全だと考えます。
デザイナーからコーダー、さらには法務やマーケティング、その他の分野まで、現在チームがAIをどのように活用しているかというプロセスを共有すれば、多くの人に関心を持ってもらえると思います。
私のようにAIについて少し知識があるだけでは、企業が日常業務でAIを実際にどのように活用しているかを理解しているとは限りません。
「いいね！」 6
ここにある内容をすべて読みました。双方の立場がわかります。プラグインを簡単に作成して投稿できるのは良い面であると同時に、Discourseのインストール環境を危険にさらす可能性がある「潜在的な」セキュリティ脆弱性を含まれている場合もあるため、悪い面でもあると感じています。
少し本題から外れますが。
別のフォーラムソフトウェアの提供元（WoltLab）には、例えばプラグインストアがあります。リリース前に、プラグインやテーマはチームによってレビューされます。ここでは同様の仕組みを導入するのが良いアイデアかもしれません。しかし、レビューを行うのは誰なのかという問題が常に生じ、それにはかなりの時間と人員の投資が必要になるだろうと想像できます。
「いいね！」 2
100%の確信を持って言えるが、サードパーティ製プラグインやテーマをすべてレビューするのは、私たちにとって現実的なアイデアではない。（少なくとも、人間が手動で行うのは無理だ）
LLMが生成したプラグインやTC（テストケース）をテストするための、チームが監督・維持・更新するキュレーションされたツールセットはどうでしょうか？
各自が個別にテストを実行できることは承知していますが、正直に言えば、やり方を知らない人もいます。
それを実行するためのシンプルで信頼できる方法は、両者の長所を兼ね備えた最善の選択肢だと考えます。
このスレッドの核心はまさにここにあります：
この透明性がなぜ重要なのか、道徳的・セキュリティ的な観点から人々がそれぞれどのような見解を持っているのかを見るのは興味深いことです。個人的には、そのソフトウェアが30年間ソフトウェアエンジニアとして活躍し、古来よりRubyを扱ってきた人物によって作られたものなのか、それともコーディング経験ゼロのティミーによって作られたものなのかは気にしません。もしそれが100%「スロップコード」[1]であれば、私はそれを使いません。そうしたら自己矛盾を犯すことになるからです。それがなぜ人気があるかは理解していますが、それは私が支持するものではないだけです。もしこれらのモデルが倫理的に訓練され、部品不足やAI生成メディアの蔓延といった問題を引き起こしていなければ、これらのモデルに対する私の見方はもう少し否定的ではなかったかもしれませんが、それが私たちが生きている世界ではありません。
プラグインに関するセキュリティ上の懸念は、グローバルな視点から見て正当であり、「これはAIが作った」という点に限定されるものでもありません。ただし、これは対処が難しい問題であり、このトピックの範囲外です。このトピックは、完全にLLMによって生成されたアセットにタグを付けることを義務付けるという提案に過ぎません。
「バイブコーディング」や「エージェント型開発」という言葉は使うことを拒否しています ↩︎
「いいね！」 1
この問題が解決しようとしている課題が、いまだに見えていません。vibe codingで書かれたプラグインのうち、粗末で、セキュリティが脆弱で、パフォーマンスを大幅に低下させるような具体例を教えてもらえますか？完全に無価値で、誰の時間も無駄にするようなものだから、ここで宣伝されるべきではなかった、という例です。
もし実際にそのような例があるなら、それらは問題とされるに値するほど多いのでしょうか？
「いいね！」 1
私には、テーマについて何らかの自己認証チェックリストを用意するのが、おそらく同じくらい役立つように思えます。テストをどれほど実施したか、品質やセキュリティに関する報告を受け入れる準備ができているか、フィードバックに対して迅速に対応するかどうか、といった項目です。
あるいは、開発プロセスを最大3文で説明してもらうのもいいかもしれません。
回答の真偽はあまり価値がないかもしれませんが、自己認証済みテーマと未認証テーマの差は、そのテーマをインストールしようとしている人にとって、何らかのシグナルとして価値があるかもしれません。
「いいね！」 4
私は自分が作るアプリケーション、プロジェクト、ソフトウェアにおいて、バイブコーディングは一切行いません。AIチャットはアイデア出しや明確化のために使いますが、プロジェクト全体を任せることは決してありません。より手作業は増えますが、少なくとも自分が何をしているのかを把握しており、他のエンティティに盲目的に委ねるわけではありません。
しかし、ここ数ヶ月でAI支援コーディングが大幅に成長したのを目の当たりにしてきました。最初はコードが poorly-written（低品質）だったり、脆弱性が混入していたりしたかもしれませんが、その後劇的に改善したと言えるでしょう。バイブコードされたデザインはまだかなり特徴的（グラデーション、ボーダー、絵文字など）で、Metaで見かけた一部のプラグインにも見られます。しかし重要なのは、作成者がそれを自分の興味やコミュニティの利益のために共有したという点です。誰かに「スロップ」とレッテルを貼って叩きのめすためではなく、そのプラグインで真の成功を収め、同じ機能を探している他のフォーラムの人々に共有したいと思ったからです。
AIに関する倫理的懸念についてはあなたの意見は理解できますが、それは書籍の切り貼り、大量の水や電気の使用など、AI全般に向けたもののように見えます。あなたはこう言っています：
しかし、それがAI製のプラグインやTC（テーマ/カスタム？）の使用とどう関連するのでしょうか。AIが嫌なら、使わなければいいだけです。しかし、AIの登場によりプログラミングの風景は劇的に変化しており、プラグインやTCも同様に変化していくでしょう。一部のコードがAIの助けを借りて書かれたことを知って、Discourseの使用を完全にやめますか？ 私はやめません。なぜなら、その裏にはまだ人間がいることを知っているからです。
では、それを「スロップコード」と呼び、「バイブコーディング」という用語の使用をボイコットすべきでしょうか（個人的には後者のフレーズに問題を感じていません）。おそらくそうではないでしょう。それは厳しすぎませんか？ はい。あなたがそれを嫌うと思うほどに。しかし、時には適応しなければなりません。それは、私が今後はAI生成のTCを作って共有するということですか？ 私にとっては、いいえ。しかし、それを避けるべきものや見下すものではなく、一つの代替手段として見るということですか？ はい。私はそうしようと努力しています。だから、あなたもそうできるように願っています。
「いいね！」 5
このトピックに関連する厳選した記事を共有します。
Trail of Bitsは、AIエージェントが監査において最も有用なのは、単にバグを見つけることではなく、カスタムツールを構築することだと主張しています。Miden zkVMの監査において、彼らはClaudeとCodexを使用してLSPサーバー、デコンパイラ、静的解析ツール、およびLeanモデルを作成し、重大な署名偽装バグと、2つの微細な問題を検出する95件のLean証明を特定しました。
エージェントにより、野心的なサイドプロジェクトのコストが低下したため、監査の経済性は以前よりもはるかに徹底的に複雑なシステムを保護できるツール駆動型のレビューへとシフトしています。
私はAIをプラグインやコンポーネントの開発に補助として使っています。利用は自己責任でお願いします。ただし、私はそれらに免責事項やタグを付けません。Discourseコアがそうしているのと同じです。エージェントの操作を管理し、コードをレビュー（時には別のエージェントやLLMの視点で確認してもらうこともありますが）、テストも実施しています。使わないことは自由ですが、AIではなく人間が完全に書いたコードの方が、むしろ品質が低いものをよく見かけます。
「いいね！」 5
まさにその通りだと思います。何かの品質を知るための伝統的なアプローチは、そのものを作ったエンティティの信頼性を確認することです。個人の場合、オープンソースプロジェクトに積極的に参加している人であれば、その評判はよく機能します。一般的に、以前から良い仕事をしており、対応も迅速な人は、今後もそうであろうと期待できます。
「いいね！」 2