Your vibe coded slop PR is not welcome
🔗 **Source:** [Your vibe coded slop PR is not welcome](https://discuss.samsaffron.com/t/your-vibe-coded-slop-pr-is-not-welcome/2492)
> [!note]+ Document Notes
> tags: [open-source, AI-assistance, code-review]
> author: Sam Saffron
> source: Sam Saffron's Blog
> reference: [https://discuss.samsaffron.com/t/your-vibe-coded-slop-pr-is-not-welcome/2492]
> date created:
>
> # 🏷️ Title: Your vibe coded slop PR is not welcome
>
<!-- deep-read:sections start -->
## 🧭 Table of Contents
- [📝 Summary](#-summary)
- [📖 Main Content](#-main-content)
- [🗒️ Notes](#️-notes)
- [📚 References](#-references)
- [🗣️ Paraphrase](#️-paraphrase)
- [📰 Newsletter](#-newsletter)
- [✅ Action Items](#-action-items)
- [🧪 Hypotheses](#-hypotheses)
- [📊 Methodology](#-methodology)
- [❓ Questions](#-questions)
- [🔮 Future Research](#-future-research)
- [💡 Implications](#-implications)
- [🧠 Learning Styles Assessment](#-learning-styles-assessment)
- [📊 Accessibility Assessment](#-accessibility-assessment)
- [🌍 DEIB Assessment](#-deib-assessment)
- [✅ Logical Validity](#-logical-validity)
- [🛡️ DARVO Analysis](#-darvo-analysis)
- [🎯 Conclusion](#-conclusion)
### 🔗 References
- Include links cited in or relevant to the article.
## 📝 Summary
- What happened: AI tools make code generation cheap but code review remains costly; maintainers are flooded with low-quality, “vibe-coded” prototype PRs.
- Why it matters: Maintainer time becomes the bottleneck; morale and project quality suffer.
- Key stakeholders: Open source maintainers, contributors using AI, project communities.
- Risks and tradeoffs: Security issues, technical debt, demotivation vs. faster ideation via prototypes.
- Bottom line: Share AI prototypes as demos, not PRs; only submit PRs you fully review, test, and vouch for.
## 📖 Main Content
- Core arguments:
- “The core issue: AI tools have made code generation cheap, but they haven’t made code review cheap.”
- Two buckets: prototypes (demos, exploratory, unvouched) vs. “ready for review” PRs (meets guidelines, reviewed line-by-line, tested).
- Maintainers should timebox reviews, close low-effort AI PRs, and direct prototypes to issues/forums.
- Context/definitions:
- Prototype: exploratory demo, likely off-standard, security-risky, missing tests; useful for idea exploration.
- Ready-for-review PR: contributor vouches for all code; complies with project rules; production-grade.
- Uncertainties:
- How teams adopt prototype workflows without derailing roadmaps.
- Enforcement feasibility of “no AI code” rules; author argues they’re counterproductive.
### 🗒️ Notes
- “Reviewing machine generated code is very costly.”
- Label clearly: prototype vs. ready PR.
- Prototype rules:
- Don’t open PRs; share branches/videos/quotes in issues or forums.
- Disclose AI use.
- Maintainers’ survival guide:
- Timebox; detect “vibe-coded” work quickly.
- Close politely; redirect to guidelines/discussion spaces.
- “Distance from a prototype to a ready to review PR can be deceptively vast.”
- Security: AI code often insecure; contributors must own and fix it before submission.
- “Alien intelligence” framing: LLMs are simultaneously great and terrible; treat them as non-human collaborators.
- Bans on AI are hard to enforce; set expectations instead: you must vouch for your PR.
## 📚 References
- “Your vibe coded slop PR is not welcome” (original article): https://discuss.samsaffron.com/t/your-vibe-coded-slop-pr-is-not-welcome/2492
- Andrej Karpathy on demo-to-product gap (contextual): https://www.dwarkeshpatel.com/p/andrej-karpathy
## 🗣️ Paraphrase
- Paragraph A: AI accelerates code generation but not code review, creating an imbalance that harms maintainers and project quality.
- Paragraph B: Use prototypes to explore ideas, but submit PRs only when you personally verify, test, and endorse every line.
## 📰 Newsletter
- This week: A must-read on AI-assisted contributions. Sam Saffron urges: prototypes are great for ideation, but PRs must be production-grade and fully owned by the submitter. WordPress contributors: share AI demos as issues or forum posts with videos; only open PRs you can defend in review. Helpful: WordPress Core Handbook contribution guidelines, secure coding resources, and project-specific test setups. Keep maintainers’ time sacred—label work clearly, timebox reviews, and raise the quality bar.
## ✅ Action Items
#### DevRel
- Publish “Prototype vs. PR” policy and examples.
- Run workshops on AI-safe review and PR hygiene.
- Provide PR checklists, test templates, and diff reviewers.
#### OSPO
- Codify contribution tiers; require AI-use disclosure.
- Integrate SCA/SAST and license scans into CI.
- Define embargo and vuln intake paths; sign releases.
#### Community
- Maintainers: triage clinics; fast-close proto-PRs with redirects.
- Contributors: sandbox branches + video demos first.
- Sponsors: fund review hours and security bounties.
#### WordPress
- Core: add “prototype” label and routing to forums.
- Core Performance: perf budgets in PR template.
- Core AI: guardrails for AI-assisted changes, eval sets.
- Documentation: examples-first PR guide; style/lint rules.
- Plugins/Themes: review queues with provenance checks.
- Accessibility: add a11y checklist to PR template.
#### The WPOCC
- Programs: maintainer stipends for review/backlogs.
- Projects: governance clinics; doc sprints.
- Funding: milestone-based payouts; transparent ledgers.
### FAIR
- Independence: require provenance notes and signature checks.
- Policies: clarity on AI use, disclosure, and sunset clauses.
- Artifacts: publish contribution charters and scorecards.
## 🧪 Hypotheses
- Clear prototype/PR labeling reduces review time per contribution.
- Mandatory AI-use disclosure increases PR acceptance rates.
- Timeboxed triage cuts maintainer burnout without lowering quality.
- Security issues per PR drop when prototypes are redirected to issues.
### 📊 Methodology
- A/B policy rollout across repos; measure review time, acceptance rate, reopen rate.
- Static analysis metrics pre/post-policy.
- Maintainer surveys on burnout and perceived quality.
### ❓ Questions
- What minimal signals best detect “vibe-coded” PRs?
- How to encourage prototypes without clogging review lanes?
- Which CI gates most reduce insecure AI code?
### 🔮 Future Research
- Automated PR provenance and AI-diff detectors.
- LLM agents specialized for test generation and security hardening.
### 💡 Implications
- Practice: stricter PR templates; prototype routes.
- Policy: AI-disclosure norms; security sign-offs.
- Funding: allocate budget to review time.
### 🧠 Learning Styles Assessment
- Reading level: ~10–11th grade (Flesch-Kincaid).
#### 👀 Visual learners
- Improve: add flows for prototype→PR; before/after diffs.
#### 🔊 Aural learners
- Improve: 3-minute audio summary of policy.
#### 🗣️ Verbal learners
- Present: clear definitions; action verbs.
#### 🧩 Kinesthetic learners
- Improve: sandbox exercises with labeled branches.
#### 🧠 Logical learners
- Improve: decision tree for triage outcomes.
#### 🧑🤝🧑 Social learners
- Present: forums; propose cohort review shifts.
#### 🧘♀️ Solitary learners
- Improve: self-check PR checklist.
#### 🌿 Naturalistic learners
- Improve: ecosystem impact notes (maintainer load).
### 📊 Accessibility Assessment
#### Screen reader semantics
- Improve: consistent headings in templates.
#### Keyboard navigation
- Improve: ensure focus states in contribution portals.
#### Contrast and readability
- Improve: enforce docs contrast >4.5:1.
#### Text resizing and reflow
- Present: responsive docs; add reduced-motion support.
#### Media and captions
- Improve: captions for demo videos.
#### Forms and interactions
- Improve: accessible PR templates and error states.
#### Standards reference
- Map gaps to WCAG 2.2 AA.
### 🌍 DEIB Assessment
- Cultural breadth: encourage multilingual contribution guides.
- Inclusive language: reduce jargon; add plain-language summaries.
- Neurodiversity: consistent structure; icon+text labels.
- Representation: balanced maintainer/contributor examples.
- Psychological safety: documented CoC and escalation paths.
### ✅ Logical Validity
#### Strong reasoning
- Causal: cheap generation vs. expensive review → bottleneck; aligns with maintainer experience.
- Classification: prototype vs. ready PR creates actionable categories.
#### Fallacies
- Potential hasty generalization from Discourse to all OSS; mitigate by inviting repo-level data.
#### Tone of voice
- Direct, pragmatic, protector-of-maintainers’ time.
### 🛡️ DARVO Analysis
- Deny: rejects blanket “ban AI” as unenforceable, not denying harms.
- Attack: critiques behavior (“vibe-coded slop”), not people.
- Reverse victim/offender: centers maintainers’ burden without victim-flipping.
## 🎯 Conclusion
- Bottom line: Share AI prototypes as demos, not PRs; only submit PRs you fully review, test, and endorse. Maintain clear lanes to protect reviewer time.
- Next steps: Adopt a prototype policy, update PR templates, add AI-use disclosure, and empower maintainers to timebox and close.
## 🧱 Refactor Appendix (append after 🎯 Conclusion)
### 📚 Literature Split Pad
- Purpose: Stage Konik CEE units that become per-source Literature notes.
- Split level: H3.
- Include verbatim quotes under 25 words and a [view highlight] link.
### [H1] Prototypes are demos, not PRs
> [!quote] [Your vibe coded slop PR is not welcome](https://discuss.samsaffron.com/t/your-vibe-coded-slop-pr-is-not-welcome/2492) by [[Sam Saffron]] via [[Sam Saffron's Blog]]. Published 2025-10-27. Accessed .
> “Don’t send pull requests (not even drafts)… share your machine generated code [as branches/videos].”
Clarifies lanes and preserves reviewer time.
[view highlight](https://discuss.samsaffron.com/t/your-vibe-coded-slop-pr-is-not-welcome/2492#H1) #xref #articleseed ID:rw_[MISSING]
### [H2] PRs must be fully vouched-for
> [!quote] [Your vibe coded slop PR is not welcome](https://discuss.samsaffron.com/t/your-vibe-coded-slop-pr-is-not-welcome/2492)
> “We reviewed all the machine generated code and vouch for all of it.”
Sets quality and accountability.
[view highlight](https://discuss.samsaffron.com/t/your-vibe-coded-slop-pr-is-not-welcome/2492#H2) #xref ID:rw_[MISSING]
---
### 🔖 Atomic Split Pad (Zettel Candidates)
#### [Z1] Prototype-to-product gap is large
- Applies to security-impacted code.
- Links: [[AI-Engineering]] [[Code-Review]]
#### [Z2] Timeboxed triage protects maintainers
- Use early signals to detect vibe-coded PRs.
- Links: [[Maintainer-Health]] [[Contribution-Policy]]
---
### ✏️ Fleeting Queue (Extract by Selection)
- [F1] Draft a “Prototype vs. PR” policy/{https://discuss.samsaffron.com/t/your-vibe-coded-slop-pr-is-not-welcome/2492} #fleeting #inbox
- [F2] Add AI-use disclosure field to PR template/{https://discuss.samsaffron.com/t/your-vibe-coded-slop-pr-is-not-welcome/2492} #fleeting #inbox
- [F3] Create triage decision tree for maintainers/{https://discuss.samsaffron.com/t/your-vibe-coded-slop-pr-is-not-welcome/2492} #fleeting #inbox
---
<!-- deep-read:sections end -->