VMarkbeta

Why We Accept Issues, Not Pull Requests ​

VMark doesn't accept pull requests. We welcome issues — the more detailed, the better. This page explains why.

The Short Version ​

VMark is vibe-coded. The entire codebase is written by AI under one maintainer's supervision. When someone submits a pull request, there's a fundamental problem: one human can't meaningfully review another human's AI-generated code. The reviewer doesn't understand the contributor's code because neither of them wrote it in the traditional sense — their AIs did.

Issues don't have this problem. A well-written issue describes what should happen. The maintainer's AI then fixes the codebase with full context of the project's conventions, test suite, and architecture. The result is consistent, tested, and maintainable.

What "Vibe-Coded" Actually Means ​

The term "vibe coding" was coined by Andrej Karpathy in early 2025 to describe a style of programming where you describe what you want in natural language and let an AI write the code. You guide the direction, but you're not writing — or often even reading — every line.[1]

VMark takes this further than most projects. The repository ships with:

  • AGENTS.md — Project rules that every AI tool reads on startup
  • .claude/rules/ — 15+ rule files covering TDD, design tokens, component patterns, accessibility, and more
  • Slash commands — Pre-built workflows for auditing, fixing, and verifying code
  • Cross-model verification — Claude writes, Codex audits (see Cross-Model Verification)

The AI doesn't just generate random code. It operates within a dense web of constraints — conventions, tests, and automated checks — that keep the codebase consistent. But this only works when one AI session has full context of those constraints.

The Comprehension Gap ​

Here's the core problem with AI-generated pull requests: nobody fully reads them.

Research from ACM's Foundations of Software Engineering conference found that developers — especially those who didn't write the code themselves — struggle to understand LLM-generated code. The study, titled "I Would Have Written My Code Differently": Beginners Struggle to Understand LLM-Generated Code, documented how even technically capable developers have difficulty reasoning about code they didn't author when an AI wrote it.[2]

This isn't just a beginner problem. A 2025 analysis of over 500,000 pull requests by CodeRabbit found that AI-generated PRs contain 1.7x more issues than human-written PRs — including 75% more logic and correctness errors. The biggest concern? These are precisely the errors that look reasonable during review unless you walk through the code step by step.[3]

The math gets worse when both sides use AI:

ScenarioReviewer understands code?
Human writes, human reviewsYes — reviewer can reason about intent
AI writes, original author reviewsPartially — author guided the AI and has context
AI writes, different human reviewsPoorly — reviewer has neither authorship context nor AI session context
AI writes for person A, AI reviews for person BNeither human understands the code deeply

VMark sits in the last row. When a contributor opens a PR generated by their AI, and the maintainer's AI reviews it, the two humans in the loop have the least understanding of any scenario. This is not a recipe for quality software.

Why AI-Generated PRs Are Different from Human PRs ​

Traditional code review works because of a shared foundation: both author and reviewer understand the programming language, the patterns, and the idioms. The reviewer can mentally simulate the code's execution and spot inconsistencies.

With AI-generated code, that shared foundation erodes. Research shows several specific failure modes:

Convention drift. AI has an "overwhelming tendency to not understand what the existing conventions are within a repository," generating its own slightly different version of how to solve a problem.[4] Each contributor's AI session produces code that works in isolation but clashes with the project's patterns. In VMark, where we enforce specific Zustand store patterns, CSS token usage, and plugin structures, convention drift would be devastating.

Context isolation. Vibe-coded features are often "generated in isolation, where the AI creates reasonable implementations for each prompt but has no memory of architectural decisions from previous sessions."[5] A contributor's AI doesn't know about VMark's 15 rule files, its cross-model audit pipeline, or its specific ProseMirror plugin conventions — unless the contributor has painstakingly configured all of that.

Review bottleneck. Developers using AI complete 21% more tasks and merge 98% more pull requests, but PR review time increases 91%.[6] The speed of AI code generation creates a firehose of code that overwhelms human review capacity. For a solo maintainer, this is untenable.

The SQLite Precedent ​

VMark isn't the first project to restrict contributions. SQLite — one of the most widely deployed software libraries in the world — has been "open source, not open contribution" for its entire history. The project does not accept patches from random people on the internet. Contributors can suggest changes and include proof-of-concept code, but the core developers typically rewrite patches from scratch.[7]

SQLite's reasoning is different (they need to maintain public domain status), but the outcome is the same: quality is maintained by having a single team with full context write all the code. Outside contributions are channeled through bug reports and feature suggestions rather than direct code changes.

Other notable projects have adopted similar stances. The Benevolent Dictator for Life (BDFL) model — used historically by Python (Guido van Rossum), Linux (Linus Torvalds), and many others — concentrates final authority in one person who ensures architectural coherence.[8] VMark simply makes this explicit: the "dictator" is the AI, supervised by the maintainer.

Why Issues Work Better ​

An issue is a specification, not an implementation. It describes what's wrong or what's needed, without committing to a particular solution. This is a better interface between contributors and an AI-maintained codebase:

Contribution typeWhat it providesRisk
Pull requestCode you must understand, review, test, and maintainConvention drift, context loss, review burden
IssueA description of desired behaviorNone — the maintainer decides if and how to act

What makes a great issue ​

The best issues read like requirements documents:

  1. Current behavior — What happens now (with steps to reproduce for bugs)
  2. Expected behavior — What should happen instead
  3. Context — Why this matters, what you were trying to do
  4. Environment — OS, VMark version, relevant settings
  5. Screenshots or recordings — When visual behavior is involved

You're welcome to use AI to write issues. In fact, we encourage it. An AI assistant can help you structure a detailed, well-organized issue in minutes. The irony is intentional: AI is great at describing problems clearly, and AI is great at fixing clearly described problems. The bottleneck is the fuzzy middle — understanding someone else's AI-generated solution — which issues neatly sidestep.

What happens after you file an issue ​

  1. The maintainer reads and triages the issue
  2. The AI is given the issue as context, along with full knowledge of the codebase
  3. The AI writes a fix following TDD (test first, then implementation)
  4. A second AI model (Codex) audits the fix independently
  5. Automated gates run (pnpm check:all — lint, tests, coverage, build)
  6. The maintainer reviews the change in context and merges

This pipeline produces code that is:

  • Convention-compliant — The AI reads the rules files on every session
  • Tested — TDD is mandatory; coverage thresholds are enforced
  • Cross-verified — A second model audits for logic errors, security, and dead code
  • Architecturally coherent — One AI session with full context, not fragments from many

The Bigger Picture ​

The AI era is forcing a rethinking of how open-source contribution works. The traditional model — fork, branch, code, PR, review, merge — assumed that humans write code and other humans can read it. When AI generates the code, both assumptions weaken.

A 2025 survey of professional developers found that they "do not vibe code; instead, they carefully control agents through planning and supervision."[9] The emphasis is on control and context — exactly what's lost when a PR arrives from an external contributor's unrelated AI session.

We believe the future of AI-era open source looks different:

  • Issues become the primary contribution — Describing problems is a universal skill
  • Maintainers control the AI — One team with full context produces consistent code
  • Cross-model verification replaces human review — Adversarial AI auditing catches what humans miss
  • Tests replace trust — Automated gates, not reviewer judgment, determine if code is correct

VMark is experimenting with this model in the open. It may not be the right approach for every project. But for a vibe-coded codebase maintained by one person with AI tools, it's the approach that produces the best software.

How to Contribute ​

File an issue. That's it. The more detail you provide, the better the fix will be.

Your issue becomes the AI's specification. A clear issue leads to a correct fix. A vague issue leads to back-and-forth. Invest in the description — it directly determines the quality of the result.

  1. Karpathy, A. (2025). Vibe coding. Originally described in a social media post, the term rapidly entered mainstream developer vocabulary. Wikipedia notes that vibe coding "relies on AI tools to generate code from natural language prompts, reducing or eliminating the need for the developer to write code manually." ↩︎

  2. Jury, J. et al. (2025). "I Would Have Written My Code Differently": Beginners Struggle to Understand LLM-Generated Code. FSE Companion '25, 33rd ACM International Conference on the Foundations of Software Engineering. The study found that developers who didn't author the AI prompt had significant difficulty understanding and reasoning about the generated code. ↩︎

  3. CodeRabbit. (2025). AI-Assisted Pull Requests Report. Analysis of 500,000+ pull requests found AI-generated PRs contain 10.83 issues each vs. 6.45 in human PRs (1.7x more), with 75% more logic and correctness errors and 1.4x more critical issues. ↩︎

  4. Osmani, A. (2025). Code Review in the Age of AI. Analysis of how AI-generated code interacts with existing codebases, noting AI's tendency to create inconsistent patterns that deviate from established project conventions. ↩︎

  5. Weavy. (2025). You Can't Vibe Code Your Way Out of a Vibe Coding Mess. Documents how vibe-coded features generated in isolated AI sessions create architectural conflicts when combined, because each session lacks awareness of decisions made in other sessions. ↩︎

  6. SoftwareSeni. (2025). Why AI Coding Speed Gains Disappear in Code Reviews. Reports that while AI-assisted developers complete 21% more tasks and merge 98% more PRs, PR review time increases 91% — revealing that AI shifts the bottleneck from writing to reviewing. ↩︎

  7. SQLite. SQLite Copyright. SQLite has been "open source, not open contribution" since its inception. The project does not accept patches from external contributors to maintain public domain status and code quality. Contributors may suggest changes, but the core team rewrites implementations from scratch. ↩︎

  8. Wikipedia. Benevolent Dictator for Life. The BDFL governance model, used by Python, Linux, and many other projects, concentrates architectural authority in one person to maintain coherence. Notable BDFLs include Guido van Rossum (Python), Linus Torvalds (Linux), and Larry Wall (Perl). ↩︎

  9. Dang, H.T. et al. (2025). Professional Software Developers Don't Vibe, They Control: AI Agent Use for Coding in 2025. Survey of professional developers found that they maintain tight control over AI agents through planning and supervision, rather than adopting the hands-off "vibe coding" approach. ↩︎

Copyright © 2026 VMark