Stop Calling It Vibe Coding — It's Just Bad Code Review Practices

"That's just vibe coding." You've heard it, or maybe even said it. It's the dismissive phrase used when a code review comment feels subjective, unquantifiable, or just plain off. It implies a reviewer is operating on intuition rather than concrete principles, making the feedback hard to address. But what if most instances of "vibe coding" aren't actually about a reviewer's whimsical feelings, but rather a symptom of deeper, systemic issues in a team's code review practices?

At Stacks Horizon, we believe that effective code review is the cornerstone of high-quality software and a thriving engineering culture. When feedback is vague, it's not because the reviewer is necessarily being arbitrary; it's often because the tools, processes, or communication channels are failing.

What "Vibe Coding" Really Means (and Why It's Problematic)

When a developer receives a comment like, "This just doesn't feel right," or "I don't like the structure here," without further explanation, it's frustrating. It feels personal, subjective, and offers no clear path for resolution. This is what's often labeled "vibe coding."

The problem isn't necessarily the feeling itself. Experienced developers often develop an intuition for potential problems – an architectural smell, a pattern that historically leads to bugs, or a design that might complicate future features. The problem arises when this intuition isn't translated into concrete, actionable, and objective feedback.

Dismissing this feedback as mere "vibe coding" is problematic because:

• It shuts down valuable discussions: It invalidates a reviewer's legitimate concerns, preventing the team from addressing potential issues. If someone feels something is off, there's usually a reason.
• It hinders learning and growth: Both the author and the reviewer miss an opportunity to learn and refine their understanding of good code practices.
• It creates resentment: Authors feel unfairly judged; reviewers feel unheard.
• It perpetuates poor quality: If underlying issues aren't articulated, they can't be fixed, leading to technical debt.

The Root Cause: Bad Code Review Practices

So, if it's not just "vibes," what is it? It's often a breakdown in how code reviews are conducted. Here are common culprits:

1. Lack of Clear Standards: Without a well-defined coding style guide, architectural principles, or agreed-upon best practices, all feedback becomes subjective by default. What's "good" to one person might be "bad" to another.
2. Focus on Minor Stylistic Issues: Spending too much time on linting issues (which should be automated) distracts from more critical concerns like logic, performance, security, or maintainability.
3. Vague or Accusatory Feedback: Comments that state a preference without rationale, or worse, imply incompetence, are unhelpful. Examples: "This is bad design" vs. "This design might introduce tight coupling, making future refactoring difficult. Have you considered using a dependency injection pattern here?"
4. Insufficient Context: Reviewers may not fully understand the feature's requirements, business impact, or the constraints the author was working under, leading to irrelevant or misinformed feedback.
5. Lack of Psychological Safety: If the team culture punishes mistakes or discourages open discussion, reviewers might shy away from providing detailed, critical feedback, resorting to vague statements to avoid conflict.
6. Over-reliance on Manual Checks: Many "vibe checks" related to formatting, naming conventions, or simple anti-patterns can and should be automated, freeing up human reviewers for higher-level concerns.

How to Turn "Vibe Coding" into Productive Feedback

The good news is that these issues are fixable. By implementing structured and empathetic code review practices, you can transform vague "vibe" comments into actionable insights.

1. Establish Clear, Documented Standards

• Coding Style Guides: Adopt a linter (ESLint, Prettier, Black, etc.) and automate formatting. Document common patterns and anti-patterns for your language/framework.
• Architectural Principles: Define your team's approach to scalability, testability, security, and maintainability. Discuss and document these principles.
• Definition of Done: Ensure everyone understands what constitutes a complete, high-quality pull request.

2. Focus on Impact and Rationale

When providing feedback, always explain why a change is suggested. Connect it to concrete outcomes:

• Maintainability: "This logic is complex and could be hard to debug in the future. Can we break it into smaller, named functions?"
• Performance: "This N+1 query pattern could lead to performance issues under load. Consider batching or eager loading."
• Readability: "The nested if/else statements make this hard to follow. A guard clause or early return could improve clarity."
• Security: "This direct user input without sanitization could be vulnerable to XSS. Please ensure proper escaping."
• Business Logic: "This doesn't seem to account for edge case Y, which our requirements state we must handle."

3. Be Specific and Actionable

Instead of "This is bad," try:

• "Consider refactoring this for loop to use Array.prototype.map for better functional expressiveness, aligning with our team's preferred style for transformations."
• "The naming of processData() is too generic. Could we rename it to parseCustomerRecords() to better reflect its specific responsibility?"

4. Educate and Mentor

Code reviews are prime opportunities for knowledge transfer. If you spot a junior developer struggling with a concept, don't just point out the error; explain the underlying principle or suggest resources.

5. Automate Where Possible

Leverage tools to handle the low-level "vibe checks":

• Linters and Formatters: Automatically enforce style and formatting.
• Static Analysis Tools: Catch common bugs, security vulnerabilities, and complexity issues.
• Unit and Integration Tests: Ensure functional correctness.

This frees up human reviewers to focus on architectural decisions, design patterns, business logic, and higher-level reasoning.

6. Foster a Culture of Psychological Safety

Encourage open discussion. Frame feedback as suggestions, not commands. Remember:

• Focus on the code, not the coder.
• Ask questions instead of making absolute statements: "What was your thinking behind this approach?" or "Have you considered alternative X?"
• Acknowledge good work. Positive reinforcement is crucial.
• Embrace learning. Everyone makes mistakes, and reviews are for collective improvement.

Conclusion

"Vibe coding" is rarely about a reviewer's baseless intuition. More often, it's a signal that your team's code review process needs refinement. By establishing clear standards, focusing on impact, providing actionable feedback, and fostering a supportive environment, you can transform subjective "vibes" into a powerful engine for code quality, knowledge sharing, and continuous improvement. Let's stop dismissing feedback and start building better review practices together.