Vibe Reporting: When Your Bug Is Just A Feeling You Haven't Debugged

TL;DR: Vibe Reporting is blaming software for problems you created: wrong tool for the job, trusting LLM hallucinations, refusing to read docs, deploying on inadequate hardware, asking maintainers to fix your misconceptions. It’s bug reporting without debugging—and it’s killing open source.

What Is Vibe Reporting?¶

Vibe Reporting is when you:

1. Complain about performance of a technology you don’t understand
2. Blame the software for problems caused by your environment
3. Refuse to read documentation but demand custom solutions
4. Use LLMs to install things, trust hallucinated output
5. Deploy on inadequate infrastructure, call the software unstable
6. Act like enterprise customer while being solo dev with no budget

It’s bug reporting without debugging. It’s performance complaints without profiling. It’s demanding explanations for problems you created.

Vibe Reporting wastes maintainer time debugging your misconfigurations, not actual bugs.

The Six-Act Vibe Report: A True Story¶

This actually happened. I’ve changed nothing except removing identifying details.

Act 1: The Complaint¶

Developer reaches out: “My queries are really slow fetching a DAG.”

First question: “What’s your current stack?”

Answer reveals: SQLite3 as their main database. But they’re trying to use MongoDB to handle the DAG queries.

Red flag #1: Using MongoDB for graph queries. MongoDB is a document database, not a graph database. It has no native graph traversal. They’re probably doing recursive aggregation pipelines or storing adjacency lists and querying them manually.

I suggest: “Use an actual graph database. Memgraph or Neo4j. I built ActiveCypher gem specifically for this.”

Developer: “Oh thanks! I actually tried Memgraph earlier this year but it didn’t work.”

Act 2: The M2 MacBook Saga¶

Me: “What happened when you tried it?”

Developer: “It wouldn’t start. Just crashed immediately.”

Me: “When was this? What version?”

Developer: “Earlier this year. I used Cursor to help me install it.”

Red flag #2: They vibe-coded the installation. Asked an LLM for help. The LLM, trained on older data, installed a version before v2.2.0 (released February 2022). Pre-v2.2.0 Memgraph had no ARM Docker images - x86 only.

So they got ancient Memgraph (pre-2022), tried running x86 Docker on M2 Mac without Rosetta, and blamed the software when it crashed.

ARM support has existed since February 2022 (v2.2.0). They installed a version from before that because they trusted LLM installation commands without verifying the version.

The vibe: “Memgraph is broken on Mac.”

The reality: LLM installed 3+ year old version without ARM support. Never checked version number.

Act 3: The Second LLM Attempt¶

Fast forward. Developer wants to try Memgraph again. Asks LLM for help (again).

This time the LLM says: “Install Memgraph v2.”

Current version? v3.7.1 (v3 line started January 2025).

The LLM’s training data cutoff is mid-2024. It doesn’t know v3 exists. It recommends v2 as “the latest stable release.”

See: LLMs Gaslight Their Own Tools for why this happens.

Developer follows instructions. Pulls v2 Docker image. Tries integrating with modern client libraries that expect v3 APIs.

Gets compatibility errors. Reports to LLM: “Getting version mismatch warnings.”

LLM response: “v2 is the current stable version. Those warnings are normal during setup.”

(They’re not. The client library is literally telling you it expects v3.)

Developer spends hours debugging “installation issues” that are actually just version incompatibility.

Red flag #3: Trusting LLM version recommendations without checking official releases.

Eventually the developer either:

• Visited the actual Memgraph website (novel concept!)
• OR complained to ChatGPT with web search enabled, and ChatGPT found v3

Either way, not the original LLM that installed v2.

But before upgrading, the developer asks me: “Can you add v2.3 support to ActiveCypher?”

My response: “ActiveCypher supports the latest version. I’m not a historian. I don’t have time to support deprecated protocols.”

Context: Memgraph still supports old protocols for backward compatibility. ActiveCypher doesn’t. It’s a gem, not a museum.

The developer could:

• ✅ Upgrade to v3 (the current version)
• ❌ Ask maintainer to support 3-year-old deprecated version

They chose wrong.

Eventually they upgrade to v3.

Act 4: The Documentation Paradox¶

Developer has a .AI company. Sells AI-powered solutions. But refuses to use AI correctly themselves.

I ask: “Did you read the ActiveCypher documentation?”

Developer: “Can I write Cypher queries ORM-style? That’s what I need.”

That’s literally what ActiveCypher does. It’s in the first paragraph of the README.

But their LLM context window? Filled with MRR screenshots from Twitter. Founder growth hacks. “How I scaled to 10k$ MRR” threads. Zero documentation.

They ask: “Is there a way to do something like User.where(name: 'foo') but for Cypher?”

# ActiveCypher, documented since v0.1.0
User.where(name: 'foo').match(:friend).return(:friend)

Red flag #4: Won’t fill context window with docs for the tool they’re using. Will fill it with aspirational revenue tweets.

Act 5: The 1GB Instance Disaster¶

Developer finally gets Memgraph running. Deploys to production.

The instance: 1GB RAM.

For context, Memgraph documentation states minimum 1GB RAM to run, but recommends 16GB RAM for production environments. 1GB is not production-ready.

What happens? OOM crashes. Constant reboots. Database can’t keep graph in memory because there’s no memory.

Developer’s complaint: “Memgraph isn’t stable. It keeps crashing in production.”

Red flag #5: Deploying database on hardware below minimum specs, blaming software for instability.

They didn’t check requirements. They didn’t monitor memory usage. They didn’t investigate why it was crashing. They just vibed that “Memgraph is unstable.”

When I point out the RAM issue, response: “But Neo4j works on 1GB.”

It doesn’t. Not well. Not for production. You’re comparing “technically boots” with “actually works.”

Act 6: The Corporate Persona¶

Throughout this, developer talks like they represent a company.

• “We’re evaluating Memgraph for our enterprise workload.”
• “Our infrastructure team is reviewing stability.”
• “We need this to scale for our customer base.”
• “We’re experiencing latency challenges with concurrent write operations.”
• “Our benchmarks indicate performance degradation under load.”
• “We need configuration options to optimize for our write volume.”
• “We’re considering ANALYTICAL mode for our use case, as our data model doesn’t require strict consistency guarantees.”
• “We’d like to understand the acceptable corruption thresholds in that deployment scenario.”

Reality? LinkedIn check: it’s one person. Solo founder. No team. No customers yet (hence the MRR tweet obsession).

The “benchmarks” were run on a MacBook Pro. The “infrastructure team” is them googling error messages. The “enterprise workload” is a side project with zero users.

The ”.AI company” is a Cursor subscription and a domain name.

Red flag #6: Playing enterprise customer while being solo dev who won’t read docs or provision adequate hardware.

The Finale: The Gemini Pivot¶

After all this, final message:

“Do you think it’s a good idea if I use Gemini instead? Because of the 1 million context window?”

Translation: “If I had more context, would that fix my refusal to read documentation and provision proper infrastructure?”

No. A 1M token context window doesn’t:

• Make M2 Macs run x86 Docker
• Prevent LLMs from hallucinating versions
• Replace reading documentation
• Add RAM to a 1GB instance
• Turn vibe reporting into engineering

What The Maintainer Sees¶

When a vibe report like this lands, here’s what the maintainer sees:

1. Surface-level observation with no depth

   • “It’s slow” (compared to what?)
   • “It doesn’t work” (what did you try?)
   • “It’s unstable” (what are the logs?)

2. Environment mismatch treated as software bug

   • M2 Mac without Rosetta = “software is broken”
   • Inadequate resources = “database is unstable”
   • No verification that environment meets minimum requirements

3. Fundamental misunderstanding of the technology

   • Doesn’t understand in-memory vs disk-based
   • Doesn’t understand ARM vs x86
   • Doesn’t understand graph databases vs relational
   • Thinks all databases are interchangeable

4. Zero effort spent on investigation

   • No reading documentation
   • No checking system requirements
   • No profiling or monitoring
   • No verification of LLM-generated commands

5. Implicit demand for free consulting

   • “Can you explain graph databases to me?”
   • “Can you troubleshoot my infrastructure?”
   • “Can you teach me the difference between Neo4j and Memgraph?”

The maintainer now has three options:

Option A: Spend an hour explaining in-memory databases, ARM architecture, minimum requirements, and why 512MB RAM doesn’t work. The reporter learns nothing, tries a 1GB instance next, complains again.

Option B: Close with “insufficient resources.” Get accused of being dismissive, unhelpful, elitist.

Option C: Ignore it. Let it rot. Watch them post on Twitter: “Tried Memgraph, completely unstable, would not recommend.”

All three options waste maintainer time and damage project reputation.

The Actual Fix (What Should Have Happened)¶

Not a software fix. Not a config setting. Fixing the approach:

Step 1: Choose The Right Tool¶

Problem: Slow DAG queries in MongoDB
Solution: Use a graph database (Memgraph, Neo4j)

Not “make MongoDB do graph traversal.” Use purpose-built tools.

MongoDB is for documents. Graph databases are for relationships.

Step 2: Check System Requirements¶

Memgraph minimum requirements:
- 1GB RAM (minimum to run, not recommended)
- 16GB RAM (production recommended)
- ARM support (since v2.2.0, February 2022)

Before deploying: read the requirements.

Step 3: Verify Installation¶

# Don't trust LLM output blindly
docker pull memgraph/memgraph:latest

# Verify version
docker run memgraph/memgraph:latest --version
# Expected: 3.7.1+

# If it says 2.x.x, the LLM gave you wrong instructions

Step 4: Provision Adequate Resources¶

# CI/CD: Minimum viable for tests
memgraph:
  image: memgraph/memgraph:latest
  mem_limit: 4g  # Not 512MB

# Production: Actual workload requirements
resources:
  requests:
    memory: "4Gi"
  limits:
    memory: "8Gi"

Step 5: Use The ORM That Already Exists¶

# ActiveCypher - documented, open source, maintained
User.where(name: 'Alice').match(:friend).return(:friend)

Don’t ask “is this possible?” Read the README.

Step 6: Monitor And Debug¶

# When it crashes, check logs
docker logs memgraph-container

# Check resource usage
docker stats memgraph-container

# Read the error message
# Common: "OOMKilled" = you need more RAM

None of these steps require filing a bug report.

Vibe Reporting vs. Actual Bug Reports¶

Vibe Report (What Actually Happened)¶

Subject: Memgraph keeps crashing

It’s unstable in production. Also tried on my Mac but it wouldn’t start. Is there a config setting? Can I write ORM-style queries? Thinking of switching to Gemini for the 1M context window.

What’s missing:

• Environment details (M2 Mac? Rosetta? ARM vs x86?)
• Resource allocation (512MB? 1GB? 8GB?)
• Version number (v2? v3?)
• Error logs
• Any investigation of why it’s crashing
• Evidence they read documentation

Actual Bug Report (What It Should Look Like)¶

Subject: Memgraph OOM on graph load with 4GB RAM for moderate dataset

Environment:

• Memgraph version: 3.7.1
• OS: Ubuntu 22.04 (Docker)
• Hardware: 4 vCPU, 4GB RAM
• Graph size: 50k nodes, 200k edges

Reproduction:

docker run -p 7687:7687 \
  --memory=4g \
  memgraph/memgraph:3.7.1

# Load graph data
LOAD CSV FROM "/data/nodes.csv" AS row
CREATE (n:Node {id: row.id});

Observed: Container killed by OOM during graph load. Docker stats show memory hitting 4GB limit.

Expected: For 50k nodes + 200k edges, 4GB should be sufficient based on sizing guidelines (2× data size). Graph load should either:

1. Complete successfully within 4GB for this dataset size
2. Documentation should clarify memory requirements for graph operations
3. Memgraph should fail gracefully with helpful error message

Logs:

[2025-11-29 10:23:15] Loading graph data...
[2025-11-29 10:24:32] Memory usage: 3.8GB
[2025-11-29 10:24:58] Killed

Question: Is 4GB sufficient for this workload, or is there overhead I’m not accounting for? Happy to help improve documentation with real-world sizing examples.

What’s included:

• Exact version numbers
• Environment specifications that meet stated requirements
• Reproduction steps
• Understanding that this might be a docs issue, not a bug
• Actual logs
• Constructive question about improving docs
• Offer to help

This is debuggable. This respects maintainer time. This is engineering.

Why Vibe Reporting Kills Open Source¶

The Maintainer Burnout Cycle¶

1. Vibe report filed with no investigation
2. Maintainer spends 30 minutes reproducing, profiling, explaining
3. Reporter doesn’t understand explanation, asks for config flag
4. Maintainer explains fundamental database concepts
5. Reporter says “too complicated, just make it faster”
6. Maintainer closes issue as “working as intended”
7. Reporter complains on Twitter about “toxic maintainers”

Repeat this 50 times a month. Watch maintainers quit.

The Signal-To-Noise Collapse¶

When your issue tracker is full of vibe reports:

• Real bugs get buried
• Maintainers stop reading issues
• Contributors stop engaging
• Project looks “unmaintained” because issues pile up
• Actual users leave for projects with responsive maintainers

Vibe reporting doesn’t just waste time. It actively destroys projects.

The Consulting Trap¶

Vibe reporters treat open source maintainers as free consultants.

“I don’t understand transactions” becomes “explain transactions to me.” “I didn’t profile” becomes “profile it for me.” “I didn’t read docs” becomes “teach me how your software works.”

Maintainers owe you a working project. They don’t owe you a CS degree.

How To Not Vibe Report¶

Before Filing A Bug¶

Step 1: Reproduce in production-like environment

• Not your laptop
• Not synthetic load
• Actual infrastructure, actual workload

Step 2: Profile

• Where is time spent? (I/O, CPU, locks, network)
• What does the query plan show?
• What do server logs say?
• What’s the resource utilization?

Step 3: Read the documentation

• Does the behavior match documented semantics?
• Is there a config setting you missed?
• Are you using the wrong API for your use case?

Step 4: Understand the fundamentals

• If you’re using transactions, understand isolation levels
• If you’re using concurrency, understand locks
• If you’re using async, understand event loops
• Don’t report bugs in concepts you don’t understand

Step 5: Form a hypothesis

• Why do you think this is happening?
• What would prove/disprove your hypothesis?
• Is this a bug, or a misunderstanding?

If you can’t complete these steps, you don’t have a bug report. You have a question.

Questions Belong In Discussions, Not Issues¶

GitHub has discussions. Stack Overflow exists. Discord servers exist. Use them.

“Why is sequential faster than concurrent?” → Discussion/SO “How do I optimize concurrent writes?” → Discussion/SO “Is this a bug or expected behavior?” → Discussion first, then issue if confirmed

Issues are for bugs. Discussions are for understanding.

The Economics Of Vibe Reporting¶

Let’s put a price on this.

Your Time Investment¶

• Writing vibe report: 10 minutes
• Responding to clarification questions: 5 minutes
• Reading explanation you don’t understand: 5 minutes
• Arguing that it should be simpler: 10 minutes

Total: 30 minutes

Maintainer Time Investment¶

• Reading vibe report: 2 minutes
• Setting up reproduction environment: 10 minutes
• Running profiling tools: 10 minutes
• Writing explanation of transactions: 20 minutes
• Responding to “but why can’t you just make it faster”: 10 minutes
• Explaining CAP theorem because you still don’t get it: 15 minutes
• Closing issue and dealing with “toxic maintainer” complaints: 5 minutes

Total: 72 minutes

You spent 30 minutes to waste 72 minutes of someone else’s time.

If the maintainer’s time is worth 100$/hour (very conservative for senior engineers), you just cost them 120$ to avoid learning how databases work.

Multiply By Volume¶

Popular database project gets 50 vibe reports per month.

50 × 120$ = 6,000$/month in wasted maintainer time

72,000$/year. That’s a junior engineer’s salary. Vibe reporting costs projects an entire headcount.

And that’s time that could’ve gone to:

• Fixing actual bugs
• Writing features
• Improving documentation
• Mentoring real contributors

Vibe reporting doesn’t just waste time. It has opportunity cost that kills projects.

Real-World Vibe Report Patterns¶

The “I Ran It On Wrong Architecture” Report¶

I tried your software on my M2 Mac and it immediately crashes. Completely broken.

Translation: I tried running x86 software on ARM without checking compatibility or enabling Rosetta.

The “All Databases Are The Same” Report¶

I watched a YouTube video about Neo4j in 2020. Why doesn’t Memgraph work the same way?

Translation: I think SQLite, PostgreSQL, Neo4j, and Memgraph are interchangeable because they’re all “databases.”

The “Can You Support My Deprecated Version?” Report¶

I installed v2.3 from 3 years ago. Can you add support for it in your library?

Translation: I refuse to upgrade to the current version. Please become a historian and maintain backward compatibility for my convenience.

When Vibe Reporting Becomes Malicious¶

Most vibe reporters are just inexperienced. They don’t know better. They’re learning.

But some patterns cross into bad faith:

The Consultant Vibe Report¶

File vibe reports to generate GitHub activity. Screenshot the “issue discussion” for clients. Claim expertise because you “contribute to popular open source databases.”

You’re not contributing. You’re farming credibility.

The Competitor Vibe Report¶

File vague performance complaints on competitor’s repo. Let them waste time responding. Meanwhile, promote your alternative solution that “doesn’t have these issues.”

This is sabotage, not community participation.

The Drive-By Demand¶

This should be simpler. Why can’t you just make it work like [different database]? I don’t have time to learn your system.

You have time to file bugs, but not to read docs. Your time is valuable, maintainer time is free?

To The Vibe Reporters¶

I’ve been the vibe reporter. Early in my career, I filed “bugs” that were just my misunderstandings.

The difference? When maintainers explained the concepts, I:

1. Learned them
2. Updated my mental model
3. Stopped filing the same class of vibe reports
4. Eventually became a maintainer myself

Vibe reporting isn’t a sin. Staying a vibe reporter is.

If your reaction to “this is working as intended” is:

• ✅ “Oh, I misunderstood transactions. Let me read about isolation levels.”
• ❌ “But it should be simpler! Add a flag to skip this.”

You’re either learning or demanding. One is welcome in open source. The other burns it down.

To The Maintainers¶

You don’t owe vibe reporters explanations.

Close with a template:

Thanks for the report. This is expected behavior given transactional isolation semantics. For help understanding database concepts or optimizing your workload, please use our discussion forum or Stack Overflow. Issues are reserved for confirmed bugs.

Relevant documentation: [link]

Don’t spend 72 minutes explaining CAP theorem to someone who won’t read it anyway.

Protect your time. Your project depends on it.

The Uncomfortable Truth¶

Most “performance bugs” are architectural misunderstandings.

Your database isn’t slow. Your queries are. Your API isn’t broken. Your usage pattern is. Your library isn’t buggy. Your expectations are.

Before you file a bug, ask:

• Did I read the documentation?
• Did I profile to understand what’s happening?
• Do I understand the underlying concepts?
• Is this a bug, or a gap in my knowledge?

If you can’t answer these, you’re vibe reporting.

And vibe reporting is why maintainers burn out, projects die, and open source gets harder every year.

The next time you’re about to report “your software is broken,” stop and ask yourself: Did I read the requirements? Did I check the architecture? Did I verify the LLM’s commands? Or am I just vibing that it should work?

P.S. - After this interaction, the developer DMed me weeks later: “Memgraph works great now! Switched to 4GB instance.”

No apology for the vibe reporting. No acknowledgment of the wasted time. No “hey, you were right about the RAM.”

Just “it works now” like the problem magically fixed itself.

Then: “Quick question - do you know if ActiveCypher supports batch inserts? Couldn’t find it in the docs.”

It’s in the docs. Second page. Under “Batch Operations.”

I sent the link.

No response. Two weeks later, new DM: “Is there a Memgraph consultant you’d recommend? We need help scaling our enterprise graph database.”

LinkedIn check: Still one person. Still no customers. Still calls it “enterprise.”

I didn’t respond.

This is why maintainers burn out.

Related reading:

• Hallucination Driven Development - shipping AI output on faith
• Agentic Dictatorship-Driven Development - being precise with AI
• LLMs Gaslight Their Own Tools - when AI overrides reality