なぜ Issue を受け付けて PR を受け付けないのか
VMark はプルリクエストを受け付けません。Issue を歓迎します — 詳細であればあるほど良いです。このページでその理由を説明します。
短いバージョン
VMark はバイブコーディングされています。コードベース全体は 1 人のメンテナーの監督の下で AI によって書かれています。誰かがプルリクエストを提出すると、根本的な問題があります: 人間 1 人が別の人間の AI 生成コードを意味のある形でレビューできません。レビュアーはコントリビューターのコードを理解しません。なぜなら、どちらも伝統的な意味でコードを書いていないからです — それぞれの AI が書きました。
Issue にはこの問題がありません。よく書かれた Issue は何が起こるべきかを記述します。その後、メンテナーの AI がプロジェクトの規約、テストスイート、アーキテクチャの完全なコンテキストでコードベースを修正します。結果は一貫していて、テストされており、保守可能です。
「バイブコーディング」が実際に何を意味するか
「バイブコーディング」という言葉は 2025 年初めに Andrej Karpathy によって作られ、欲しいものを自然言語で説明して AI にコードを書かせるプログラミングスタイルを説明します。方向性をガイドしますが、すべての行を書いている — またはしばしば読んでいる — わけではありません。[1]
VMark はほとんどのプロジェクトよりこれをさらに進めています。リポジトリには以下が含まれます:
AGENTS.md— すべての AI ツールが起動時に読むプロジェクトルール.claude/rules/— TDD、デザイントークン、コンポーネントパターン、アクセシビリティなどをカバーする 15 以上のルールファイル- スラッシュコマンド — コードの監査、修正、検証のための事前構築されたワークフロー
- クロスモデル検証 — Claude が書き、Codex が監査（クロスモデル検証を参照）
AI はランダムなコードを生成しません。規約、テスト、自動チェックの密なウェブの中で動作します — コードベースを一貫して保ちます。しかしこれは 1 つの AI セッションがその制約の完全なコンテキストを持つ 場合にのみ機能します。
理解のギャップ
AI 生成プルリクエストの核心的な問題はこれです: 誰も完全に読んでいません。
ACM のソフトウェアエンジニアリング基盤会議の研究では、開発者 — 特にコードを自分で書いていない人 — が LLM 生成コードを理解するのに苦労することが判明しました。「自分だったら違うコードを書いていた」: 初心者は LLM 生成コードの理解に苦労すると題された研究では、技術的に有能な開発者でさえ、AI が書いたコードを著者でない場合に推論するのが難しいことが記録されています。[2]
これは初心者だけの問題ではありません。CodeRabbit の 50 万以上のプルリクエストの 2025 年の分析では、AI 生成の PR には人間が書いた PR より 1.7 倍多い問題 が含まれており — 75% 多くのロジックと正確さのエラーを含むことが判明しました。最大の懸念は? これらはレビュー中にコードをステップバイステップで歩まない限り合理的に見える正確なエラーです。[3]
両方の側が AI を使う場合、数学はより悪化します:
| シナリオ | レビュアーはコードを理解するか? |
|---|---|
| 人間が書き、人間がレビューする | はい — レビュアーは意図について推論できる |
| AI が書き、元の著者がレビューする | 部分的 — 著者は AI をガイドしてコンテキストを持つ |
| AI が書き、別の人間がレビューする | 不十分 — レビュアーは著者権のコンテキストも AI セッションコンテキストも持たない |
| A が A に書かせ、B が A にレビューさせる | どちらの人間もコードを深く理解しない |
VMark は最後の行にいます。コントリビューターが AI で生成した PR を開き、メンテナーの AI がそれをレビューするとき、ループ内の 2 人の人間はあらゆるシナリオの中で最も理解が少ないです。これは品質の高いソフトウェアのレシピではありません。
AI 生成の PR が人間の PR と異なる理由
従来のコードレビューは共有の基盤のために機能します: 著者とレビュアーの両方がプログラミング言語、パターン、イディオムを理解します。レビュアーはコードの実行を頭の中でシミュレートして不整合を見つけることができます。
AI 生成コードでは、その共有の基盤が侵食されます。研究はいくつかの特定の失敗モードを示しています:
規約のドリフト。 AI は「リポジトリ内の既存の規約が何かを理解しない圧倒的な傾向」があり、問題を解決する方法について若干異なるバージョンを生成します。[4] 各コントリビューターの AI セッションは独立してうまく動作するが、プロジェクトのパターンと衝突するコードを生み出します。VMark では特定の Zustand ストアパターン、CSS トークンの使用、プラグイン構造を強制しているため、規約のドリフトは壊滅的です。
コンテキストの孤立。 バイブコーディングされた機能はしばしば「AI が各プロンプトに対して合理的な実装を作成するが、以前のセッションからのアーキテクチャの決定の記憶を持たない」隔離された状態で生成されます。[5] コントリビューターの AI は VMark の 15 のルールファイル、そのクロスモデル監査パイプライン、その特定の ProseMirror プラグインの規約を知りません — コントリビューターがそれをすべて丁寧に設定していない限り。
レビューのボトルネック。 AI を使用する開発者は 21% 多くのタスクを完了し、98% 多くのプルリクエストをマージしますが、PR レビュー時間は 91% 増加します。[6] AI コード生成のスピードは人間のレビュー能力を圧倒するコードのファイアホースを作り出します。ソロのメンテナーには、これは持続不可能です。
SQLite の先例
VMark はコントリビューションを制限する最初のプロジェクトではありません。SQLite — 世界で最も広く展開されているソフトウェアライブラリの一つ — はその歴史全体を通じて「オープンソースだがオープンコントリビューションではない」です。プロジェクトはインターネット上のランダムな人々からのパッチを受け付けません。コントリビューターは変更を提案して概念実証コードを含めることができますが、コア開発者は通常パッチをゼロから書き直します。[7]
SQLite の推論は異なります（パブリックドメインステータスを維持する必要がある）が、結果は同じです: 品質はすべてのコードを書く完全なコンテキストを持つ単一のチームによって維持されます。外部のコントリビューションはバグレポートと機能提案を通じてチャンネルされ、直接的なコード変更ではありません。
他の注目すべきプロジェクトも同様のスタンスを採用しています。慈悲深き独裁者生涯モデル（BDFL） — 歴史的に Python（Guido van Rossum）、Linux（Linus Torvalds）、その他多くで使用 — は 1 人の人がアーキテクチャの一貫性を確保するために最終権限を集中させます。[8] VMark はこれを明示的にします: 「独裁者」はメンテナーに監督された AI です。
なぜ Issue の方がうまく機能するか
Issue は 仕様 であり、実装ではありません。特定の解決策にコミットせずに何が悪いか、または何が必要かを記述します。これはコントリビューターと AI が管理するコードベースの間のより良いインターフェースです:
| コントリビューションの種類 | 提供するもの | リスク |
|---|---|---|
| プルリクエスト | 理解し、レビューし、テストし、保守しなければならないコード | 規約のドリフト、コンテキストの喪失、レビューの負担 |
| Issue | 望ましい動作の記述 | なし — メンテナーが行動するかどうかを決める |
優れた Issue の条件
最も良い Issue は要件文書のように読めます:
- 現在の動作 — 今何が起こっているか（バグの場合は再現手順付き）
- 期待される動作 — 代わりに何が起こるべきか
- コンテキスト — なぜこれが重要か、何をしようとしていたか
- 環境 — OS、VMmark のバージョン、関連する設定
- スクリーンショットまたは録画 — ビジュアルな動作が関わる場合
Issue を書くために AI を使って構いません。実際に推奨します。AI アシスタントは数分で詳細によく整理された Issue を構造化するのを助けられます。皮肉は意図的です: AI は問題を明確に記述するのが得意で、明確に記述された問題を修正するのが得意です。 ボトルネックは曖昧な中間 — 誰か他の人の AI 生成ソリューションを理解すること — であり、Issue はそれをきれいに回避します。
Issue を提出した後に何が起こるか
- メンテナーが Issue を読んでトリアージする
- AI は Issue をコンテキストとして与えられ、コードベースの完全な知識とともに
- AI は TDD に従って修正を書く（テスト最初、次に実装）
- 2 番目の AI モデル（Codex）が独立して修正を監査する
- 自動ゲートが実行される（
pnpm check:all— lint、テスト、カバレッジ、ビルド） - メンテナーがコンテキストで変更をレビューしてマージする
このパイプラインは次のコードを生み出します:
- 規約準拠 — AI は各セッションでルールファイルを読む
- テスト済み — TDD は必須; カバレッジ閾値が強制される
- クロス検証済み — 2 番目のモデルがロジックエラー、セキュリティ、デッドコードを監査する
- アーキテクチャ的に一貫 — 完全なコンテキストを持つ 1 つの AI セッション、多くの断片ではない
より大きな絵
AI 時代はオープンソースのコントリビューションがどのように機能するかを再考させています。従来のモデル — フォーク、ブランチ、コード、PR、レビュー、マージ — は人間がコードを書き、他の人間がそれを読めると仮定していました。AI がコードを生成するとき、両方の仮定が弱まります。
2025 年のプロのエンジニアの調査では、彼らは「バイブコーディングをしない; 代わりに計画と監督を通じてエージェントを注意深く制御する」ことが判明しました。[9] 強調点は コントロールとコンテキスト — まさに外部のコントリビューターの無関係な AI セッションから PR が届くときに失われるものです。
AI 時代のオープンソースの未来は異なって見えると信じています:
- Issue が主要なコントリビューションになる — 問題を記述することは普遍的なスキル
- メンテナーが AI をコントロールする — 完全なコンテキストを持つ 1 つのチームが一貫したコードを生み出す
- クロスモデル検証が人間のレビューに代わる — 敵対的 AI 監査が人間が見落とすものを捉える
- テストが信頼に代わる — レビュアーの判断ではなく自動ゲートがコードが正しいかどうかを決める
VMark はこのモデルをオープンに実験しています。すべてのプロジェクトにとって正しいアプローチではないかもしれません。しかし 1 人の人が AI ツールで管理するバイブコーディングされたコードベースにとって、最高のソフトウェアを生み出すアプローチです。
コントリビュートする方法
Issue を提出してください。 それだけです。詳細を提供するほど、修正が良くなります。
あなたの Issue が AI の仕様になります。明確な Issue は正しい修正につながります。曖昧な Issue はやりとりにつながります。説明に投資してください — それが結果の品質を直接決定します。
Karpathy, A. (2025). Vibe coding. もともとソーシャルメディアの投稿で説明され、この言葉は急速に主流の開発者語彙に入りました。Wikipedia では、バイブコーディングは「自然言語プロンプトからコードを生成するために AI ツールに依存し、開発者がコードを手動で書く必要を減らすまたはなくす」と述べています。 ↩︎
Jury, J. et al. (2025). "I Would Have Written My Code Differently": Beginners Struggle to Understand LLM-Generated Code. FSE Companion '25, 第 33 回 ACM 国際ソフトウェアエンジニアリング基盤会議。この研究では、AI プロンプトを著者でない開発者が生成されたコードを理解して推論するのに大きな困難を持つことが判明しました。 ↩︎
CodeRabbit. (2025). AI-Assisted Pull Requests Report. 500,000 以上のプルリクエストの分析では、AI 生成の PR には各 10.83 の問題があるのに対して、人間の PR は 6.45（1.7 倍多い）、75% 多くのロジックと正確さのエラー、1.4 倍多い重大な問題が含まれていることが判明しました。 ↩︎
Osmani, A. (2025). Code Review in the Age of AI. AI 生成コードが既存のコードベースとどのように相互作用するかの分析。確立されたプロジェクトの規約から逸脱する不整合なパターンを作成する AI の傾向に注目。 ↩︎
Weavy. (2025). You Can't Vibe Code Your Way Out of a Vibe Coding Mess. 隔離された AI セッションで生成されたバイブコーディングされた機能が結合されるときにアーキテクチャの競合を作り出す様子を記録。各セッションが他のセッションで行われた決定の認識を欠いているため。 ↩︎
SoftwareSeni. (2025). Why AI Coding Speed Gains Disappear in Code Reviews. AI 支援開発者は 21% 多くのタスクを完了し、98% 多くの PR をマージするが、PR レビュー時間は 91% 増加することを報告 — AI が書くことからレビューするへとボトルネックを移すことを明らかにしています。 ↩︎
SQLite. SQLite Copyright. SQLite はその起源以来「オープンソースだがオープンコントリビューションではない」です。プロジェクトはパブリックドメインステータスとコード品質を維持するために外部のコントリビューターからのパッチを受け付けません。コントリビューターは変更を提案できますが、コアチームは実装をゼロから書き直します。 ↩︎
Wikipedia. Benevolent Dictator for Life. Python、Linux、その他多くのプロジェクトで使用される BDFL ガバナンスモデルは、一貫性を維持するために 1 人の人にアーキテクチャの権限を集中させます。注目すべき BDFL には Guido van Rossum（Python）、Linus Torvalds（Linux）、Larry Wall（Perl）が含まれます。 ↩︎
Dang, H.T. et al. (2025). Professional Software Developers Don't Vibe, They Control: AI Agent Use for Coding in 2025. プロの開発者の調査では、ハンズオフな「バイブコーディング」アプローチを採用するのではなく、計画と監督を通じて AI エージェントを厳格にコントロールしていることが判明しました。 ↩︎