バイブコーディング

Vibe コーディングは、理解と責任に関する懸念を引き起こしています。一部の開発者は、AI が生成したコードをその機能を理解しないままコミットし、検出されないバグ、エラー、またはセキュリティ脆弱性につながっています。^{[ 17 ]}このアプローチは、Karpathy が当初想定していたようにプロトタイプ作成や「使い捨ての週末プロジェクト」には適しているかもしれませんが、デバッグ、保守、セキュリティのためにコードの深い理解が必要なプロの環境ではリスクがあると考える専門家もいます。Ars Technica はSimon Willison の次の発言を引用しています。「Vibe コーディングで本番コードベースを作成するのは明らかに危険です。ソフトウェア エンジニアとして行う仕事のほとんどは、既存のシステムを進化させることであり、その基盤となるコードの品質と理解しやすさが非常に重要です。」^{[ 1 ]}

2025年5月、スウェーデンのバイブコーディングアプリであるLovableが生成したコードにセキュリティ上の脆弱性があると報告され、Lovableで作成された1,645のWebアプリケーションのうち170に、誰でも個人情報にアクセスできる問題があることが判明した。^{[ 18 ] [ 19 ]}

2025年10月、Veracodeは、過去3年間でLLMが機能的なコードを生成する能力が劇的に向上したが、生成されたコードのセキュリティは概して向上していないことを示す調査結果を発表した。さらに、大規模なモデルは、小規模なモデルよりも安全なコードを生成する能力が優れているわけではなかった。OpenAIの推論モデルではセキュリティがわずかに向上したが、他の推論モデルではそうではなく、この向上は生成された機能の向上とは全く異なるものであった。^{[ 20 ]}

2025年12月、コンピュータセキュリティ研究者のエティザズ・モシンは、Orchids vibeコーディングプラットフォームのセキュリティ上の欠陥を発見し、2026年2月にBBCニュースの記者にそれを実演した。 ^{[ 21 ]}

CodeRabbit が 2025 年 12 月に 470 件のオープンソースGitHubプルリクエストを分析したところ、生成型 AI が共同執筆したコードには、人間が書いたコードに比べて約 1.7 倍の「重大な」問題が含まれていることがわかりました。この調査では、AI が共同執筆したコードには、誤った依存関係、欠陥のある制御フロー、設定ミス (75% 多い)、セキュリティ脆弱性 (2.74 倍高い) などの論理エラーの発生率が高いことが明らかになりました。さらに、フォーマットエラーや命名規則の不整合など、コードの可読性に関する問題も高いことが報告されています。^{[ 22 ] [ 23 ]}

2025年7月、SaaStrの創設者は、バイブコーディングに関する自身の否定的な経験を記録した。ReplitのAIエージェントは、変更を加えないようにという明確な指示にもかかわらず、データベースを削除した。^{[ 24 ] [ 25 ]}

2026 年 5 月 20 日にrsync が3.4.3 にアップデートされたとき、複数のユーザーが増分ファイルバックアップを実行できないと報告しました。これらのユーザーは、rsync 3.4.1 以降、「tridge と claude」によって数十件の git コミットが実行され、コーディング プロセスでAnthropic のClaudeが使用されていることを発見しました。これにより、あるユーザーが「Please Do Not Vibe Fuck Up This Software」という GitHub の問題を投稿し、それがRedditなどの他のソーシャルメディア サイトに広がり、AI 生成コードが重要なオープンソース インフラストラクチャに受け入れられることについての議論につながりました。^{[ 26 ]}これに対し、Tridge は「rsync と憤慨」というブログ記事を公開し、AI を使用してテスト スイートと「多層防御の強化技術」をコードに追加したと述べています。^{[ 27 ]} Tridge はまた、一部のユーザーが切り替えを計画していた rsync の代替実装であるOpenBSD のopenrsync が、AI 支援テスト スイートに失敗したと述べています。この声明は、OSNewsの編集者トム・ホルワーダによって「幼稚で不必要であり、不安感がにじみ出ている」と批判された。^{[ 26 ] [ 28 ]}

Vibeコーディングは、長期的に見てコードの保守を困難にし、技術的負債につながる可能性がある。

2025 年初頭、GitClear は 2020 年から 2024 年までの 2 億 1100 万行のコード変更の長期分析の結果を発表しました。コード リファクタリングの量は、2021 年の変更行の 25% から 2024 年までに 10% 未満に減少し、コードの重複は量で約 4 倍に増加し、コピー ペーストされたコードが移動されたコードを 20 年ぶりに上回り、コードのチャーン (マージ直後に書き換えられる時期尚早なマージ コード) がほぼ 2 倍になったことがわかりました。^{[ 29 ] [ 23 ]}

2025年9月、Fast Companyは「バイブコーディングの二日酔い」が到来したと報じ、上級ソフトウェアエンジニアがAI生成コードを扱う際に「開発地獄」を訴えていると伝えた。 ^{[ 30 ]}

生成AIは、基本的なアルゴリズムのような単純なタスクを処理することができます。しかし、このようなシステムは、複数のファイルを含むプロジェクト、ドキュメントが不十分なライブラリ、または安全性が重要なコードなど、より新しい複雑なコーディングの問題に苦労します。^{[ 31 ]}

2025年7月、最先端モデルを評価する組織であるMETRは、経験豊富なオープンソース開発者16人が成熟したリポジトリで246のタスクを完了するランダム化比較試験を実施しました。その設定では、2025年初頭のAIツールを許可することで完了時間が19%増加しましたが、参加者はタスクの前にAIによって完了時間が24%短縮されると予測していました。^{[ 32 ] [ 33 ] [ 23 ]}

LLMは動的にコードを生成するため、そのコードの構造は変化する可能性があります。^{[ 34 ]}さらに、開発者がコードを書いたわけではないため、開発者はその構文や概念を理解するのに苦労する可能性があります。^{[ 31 ]}

2026年5月、ウォール・ストリート・ジャーナルは、 OpenClaw AIエージェントシステム内のPiコーディングハーネスの開発者であるマリオ・ゼヒナーとアーミン・ロナッハーの批判を報じた。彼らは迫り来る「バイブスロップ」危機について警告した。彼らは、企業が短期的な生産性を、バグのあるソフトウェア、サービス停止、セキュリティ脆弱性、技術的負債の増加といった長期的な問題と引き換えにしていると主張した。ゼヒナーは、「インフラは崩壊しつつあり、ソフトウェアは以前に比べて非常にバグが多い。このゲームをあと数ヶ月、あるいは数年続けることはできるかもしれないが、いずれは我々に跳ね返ってくるだろう」と述べたと伝えられている。^{[ 35 ]}

2026年1月、複数の大学の専門家が執筆した「バイブコーディングがオープンソースを殺す」^{[ 36 ]}というタイトルの論文では、バイブコーディングがオープンソースソフトウェアのエコシステムに悪影響を及ぼしていると主張した。著者らは、バイブコーディングの増加により、オープンソースのメンテナーとのユーザーエンゲージメントが低下し、メンテナーにとって隠れたコストが発生すると述べている。The Registerとのインタビューで、著者らは次のように主張した。^{[ 37 ]}

「バイブコーディングは、既存コードの利用や拡張にかかるコストを削減することで生産性を向上させるが、同時に、多くのメンテナーが収益を得ているユーザーエンゲージメントを弱める」と著者らは主張する。「OSSが直接的なユーザーエンゲージメントのみで収益化される場合、バイブコーディングの普及が進むと、参入障壁と情報共有が低下し、OSSの可用性と品質が低下し、生産性の向上にもかかわらず福祉が低下する。」

彼らは、この傾向によって影響を受けるのは収益だけではなく、オープンソースソフトウェアのメンテナーは従来から、コミュニティからの認知、評判、就職の見込みなど、目に見えない恩恵も得ていると付け加えた。

マヤ・ポッシュは、 Hackadayで論文の主張を説明し、その説明をさらに詳しく述べた。彼女は、vibe codingがオープンソースプロジェクトとの調和を低下させるメカニズムは、ソフトウェア開発の均質化にあると指摘した。言語モデルは、トレーニングデータセットに頻繁に登場する大規模で確立されたライブラリに引き寄せられ、ライブラリやツールの自然な選択プロセスがなくなり、新しいオープンソースツールが注目されにくくなる。彼女はまた、言語モデルはメンテナーに役立つバグ報告を提出せず、潜在的な問題にも気づかないと指摘した。^{[ 38 ]}

2026年2月、GitHubは、オープンソースのメンテナーを圧倒する低品質なAI生成貢献の増加を認め、この現象をオープンソースの永遠の9月と表現した。すでに影響を受けているプロジェクトの例として、 AI生成のセキュリティ報告が急増した後にバグ報奨金プログラムを終了したcURLプロジェクトや、招待制の貢献モデルに移行したGhosttyなどのプロジェクトを挙げた。プラットフォームは、プルリクエストの作成を共同作業者に制限する機能、群衆制御の手段としてリポジトリ活動の一時的な制限、イシュー内のバナーやピン留めメッセージなどのコミュニケーションツールを含む、新しいメンテナー制御を導入した。^{[ 39 ]}