Duply
Launch Kit
Back to blog

21 August 2026

I hate vibe coding: what Reddit actually thinks

"I hate vibe coding" is becoming its own genre on Reddit, with high-engagement threads across r/vibecoding, r/ExperiencedDevs, r/programming and r/AskProgramming.

Quick answer: The hate is not about AI assistance. It is about three specific things: unreviewed code entering shared codebases, non-technical people treating prompting as engineering, and experienced developers feeling pressure to adopt a workflow that violates principles they spent years learning. The threads that defend vibe coding agree on the same boundary: it works when the person using it can evaluate the output.

The SERP for this query is 8/8 Reddit results, with a People Also Ask block and a Perspectives carousel featuring threads as recent as today. Here is what those threads actually say.

What the hate threads say

  • "I Now Understand the Hate...." (r/vibecoding, 220+ comments, 2 months ago): the most-commented recent thread. An SWE who initially dismissed the criticism tried shipping vibe-coded work and reversed position: "We as SWEs hate vibecoding because it violates so many principles that are paramount for building a real product. Slop is an excellent term."
  • "Why the hate for vibecoding?" (r/vibecoding, 70+ comments): the direct question, and the bluntest answer on any SERP result: "Programmers who have to work side-by-side with Vibe 'coders' hate it because to most standards, Vibe Coding is ass now."
  • "Why do people hate on vibe codes projects so much?" (r/vibecoding, 130+ comments): the project-level version. The top answer names three specifics: "It lacks security, character and efficiency. It's just bad spaghetti code with passwords and API keys in plain text."
  • "Why 'Vibe Coding' Makes Me Want to Throw Up?" (r/programming, 360+ comments, 441 votes): the highest-engagement thread on any vibe-coding SERP. A "scathing critique of 'Vibe Coding' as the dangerous trend of letting LLMs write code without understanding it."
  • "Am I falling behind because I don't want to fully adopt vibe coding?" (r/ExperiencedDevs, 110+ comments): the professional-identity thread. The OP already uses AI for "looking up functions and getting quick examples" but resists full vibe coding. The question isn't technical, it's career anxiety.
  • "I think I'm becoming a vibe programmer, and I hate it." (r/AskProgramming, 110+ comments): the confessional version. An "experienced back end dev across several stacks, with tons of devops experience" who finds the front end pulling them into vibe coding by default.
  • "Everyone Hates Vibe Coders. They Shouldn't." (r/ExperiencedDevs, 80+ comments): the defense. The OP pushes back on the pile-on: "There's been a weird amount of hate lately toward vibe coding, people just riffing with AI, throwing together ideas, building by intuition." The thread is the minority opinion on this SERP, but it holds the nuance the rant threads skip.
  • "Why do people hate vibe coding so much?" (r/SaaS, 60+ comments): the founder's perspective. The OP genuinely doesn't understand the pushback: "If someone can build a working app using AI tools" why does it matter how? The replies draw the line at "working" vs "maintainable."

Google's Perspectives carousel adds three very recent threads:

The discourse is active and growing. "Vibe coding sucks" gets around 70 US searches a month and has been stable since late 2025.

The pattern in the frustration

Reading across all eight SERP threads, the hate clusters into three distinct complaints:

1. Unreviewed slop in shared codebases

The r/vibecoding "I Now Understand the Hate" thread and the r/programming "Makes Me Want to Throw Up" thread are fundamentally about the same thing: generated code that nobody read before it shipped. The r/vibecoding answer is direct: "It lacks security, character and efficiency." The complaint is not that AI wrote it. The complaint is that nobody reviewed it.

This matches the evidence. A 2026 CMU benchmark found coding agents produce functionally correct output 61% of the time, but only 10.5% of those solutions were secure. Veracode's 2025 report across 100+ LLMs found security vulnerabilities introduced in about 45% of tasks. The security problem is real, but it's a review problem, not a generation problem. (Our is vibe coding bad? post covers the security data in depth.)

2. Non-technical management treating prompting as engineering

The r/SaaS thread and the r/AskProgramming thread reveal a different frustration: experienced developers watching organizations equate prompting with engineering. The r/SaaS OP asks "if someone can build a working app using AI tools" why complain, and the replies draw the line: working code and production-grade code are different standards. BGR's coverage of the broader trend names the same concern: the "dark side" is not the code itself but the organizational assumption that review is optional.

The Red Hat developer piece locates the root cause in specificity: vague prompts produce plausible-looking guesses, and "the code itself becomes the only source of truth" once the prompts are gone.

3. Professional identity and skill erosion

The r/ExperiencedDevs "Am I falling behind?" thread and the r/AskProgramming "becoming a vibe programmer" thread are about identity, not code. These are senior developers who built careers on deep technical understanding, now watching a workflow that explicitly skips understanding gain traction. The hate in these threads is not anger at a tool. It's anxiety about what their expertise means if the tool works well enough.

The defense thread ("Everyone Hates Vibe Coders. They Shouldn't.") addresses this directly: people "riffing with AI, building by intuition" are not threatening the profession, they're prototyping. The hate is misdirected when it targets explorers rather than organizations that ship unreviewed output.

What fixes the parts that deserve fixing

The threads that move past venting converge on the same boundary:

✅ Do this

  • Use vibe coding for prototypes, personal projects, and exploratory work
  • Review every line before it enters a shared codebase, the same way you would review a junior's PR
  • Keep prompts small and specific; large, abstract asks are where output quality collapses
  • Constrain the model's design decisions with a written spec before generating UI
  • Treat AI as a draft tool, not a deployment pipeline

❌ Avoid this

  • Shipping generated code without reading it, the single most cited complaint across all threads
  • Treating "it works" as the quality bar for production systems
  • Pressuring experienced developers to adopt vibe coding for work they can do better manually
  • Assuming prompt skill replaces domain expertise in security, accessibility, or architecture
  • Using vibe coding for the parts that need to be right (auth, payments, data handling) without expert review

Where design fits in

The hate threads focus on code quality and security, but the visible symptoms are often design. Every AI iteration makes independent micro-decisions about spacing, color, and type. Without constraints, the UI drifts even when the code works. This is why vibe-coded apps look the same and why the design drift discourse is a parallel conversation to the hate discourse.

The fix: load a design constraint before you start generating. Not a style prompt, but a file with concrete tokens and rules.

  1. Browse the duply library for a product whose aesthetic fits what you're building.
  2. Copy its DESIGN.md into your repo. It has exact design tokens, type scales, spacing, and written do's and don'ts.
  3. Tell your agent to follow it. Setup per tool (Claude Code, Cursor, v0, Lovable, Bolt) is in how to give your AI agent a real design system.

The model stops inventing values and builds against yours. The code still needs review, but the design stops drifting.

FAQ

Why do developers hate vibe coding? Three reasons surface across every thread: unreviewed AI output shipping to production, non-technical management equating prompting with engineering, and experienced developers feeling their expertise is devalued. The hate targets the workflow, not the tool.

Is the hate justified? Partly. The security data supports the review complaint: AI-generated code has measurably more vulnerabilities than human-written code, and most of them pass functional tests. The professional-identity anxiety is less about vibe coding itself and more about how organizations respond to it. The defense thread on r/ExperiencedDevs argues the hate is misdirected when it targets individuals rather than missing process.

What is the difference between this and "is vibe coding bad?" That question is about evidence: what the research says about security, maintainability, and quality outcomes. This question is about the experience: why developers feel frustrated, resentful, or anxious. Different threads, different angle, same underlying issue.

Is vibe coding dying? No. "Vibe coding sucks" gets stable monthly search volume, and the Perspectives carousel includes threads from today. The tools keep improving, and new threads still appear daily. What's changing is the boundary: teams are adding review rules for AI output rather than banning it.

Should experienced developers learn to vibe code? The r/ExperiencedDevs consensus is: use AI for the tedious parts, review everything, and don't let prompt fluency replace domain knowledge. The "Am I falling behind?" thread's most upvoted advice: you're not falling behind by reviewing your code.

Why do vibe-coded apps all look the same? Because the model averages toward its training data when given no constraints. Every generation picks slightly different spacing, color, and type values, but they all converge on the same generic look. A DESIGN.md file with concrete tokens is the fix.

Is vibe coding bad for beginners? The threads agree: beginners are the highest-risk group because they can't evaluate the output. The r/csMajors "ruined me" thread and the r/AskProgramming confessional both describe the same pattern: relying on generation before building the judgment to review it.

What is the constructive version of the hate? Review everything. Keep prompts specific. Constrain design decisions with a written spec. Use vibe coding for exploration and prototyping, not for the parts that need to be right on the first deploy. The threads that move past venting all arrive here.

Summary

  • The hate is about unreviewed output, organizational pressure, and professional anxiety, not about AI tools themselves
  • Security data supports the review complaint: 61% functionally correct, 10.5% secure (SusVibes benchmark)
  • The defense thread's point stands: the hate is misdirected when it targets explorers rather than missing review process
  • Fix the visible symptom (design drift) with a concrete design spec before generating
  • Fix the structural symptom (security, maintainability) with mandatory review
  • Browse 250+ real product design specs in the duply library

Related reading