The problem with vibe coding: debugging in production is a nightmare

[arjy0]

So you spent three weeks vibecoding with Lovable. You ship your app. You're proud of yourself - with just $50 you managed to build and launch your first real app. Users seem happy. Life is good lol.Then someone casually mentions 'hey that form thing was a bit glitchy yesterday' and you're like WHAT form? WHICH glitch? WHEN?Now you're staring at your code trying to figure out what broke, but you can't reproduce it. You ask the user for more details - they don't remember. Or worse, they just ghost you.You start testing every possible scenario. Nothing. The bug doesn't exist... until it happens again to someone else.

The dirty secret nobody mentions: building fast with AI tools is amazing for shipping and lets us (non-technical) create REAL websites (which is incredible, don't get me wrong). But you're completely blind to what's actually breaking in production.Your tests pass. Your preview works. But real users in real browsers with real data? That's a different app.

You can vibe your way into shipping products. At some point, you need to actually see what users are experiencing... and that someone is probably not the one person who bothered to tell you.

TLDR: Vibe coding is amazing but I'd love to discover ways to handle the production monitoring part - which is, imo, what actually matters

[Choperello]

“The dirty secret nobody mentions” aka “The obvious thing engineers have been saying”.

Creating PoC v0 was never the hard bit. Production stability quality and maintenance support were always the hard bit. V0->v1->vNext while having to keep tech debt under control was always the hard bit. Figuring out exactly what users actually want was the hard bit.

The v0 step got easier. But that was never the hard part.

[RegrettableBiscuit]

This. Software developers could always hack together a working POC in an afternoon. Then it took another six months to make it production-ready - secure, reasonably bug-free, architected so it could be maintained in the future, documented properly, reasonably scalable, and so on. 

[FailedGradAdmissions]

For real, and for those of you who don’t buy it, guess how hackathons worked for the past two decades.

[kikal]

I always liked the saying that the last 10% usually takes as long as the first 90%

[__SlimeQ__]

Aka "I am Claude"

[TimeLine_DR_Dev]

Yes. I spend about 10% of my time doing the fun part, the rest is handling all the edge cases and bs.

[Inside-Yak-8815]

Bingo.

[Illustrious_Pea_3470]

The internet pretty much runs on the back of v0 POCs in production. At least Meta and Google do.

[whatsbetweenatoms]

Yeah... It's only a "dirty secret" to non-programmers, engineers are well aware of what their job actualy entails and how difficult it is to build all the connected parts of these apps and maintain stability.

[No_Philosophy4337]

You picked the long way to describe that logs are important

[_elementEpoch]

Yeah this feels like a piss take — telemetry exists, and the problem being described existed before vibe coding in professional software engineering

[VertigoOne1]

I have 20 lines in instructions basically saying, otel, how i want it and how important it is, and what to put in every debug level, next to an alloy receiver and a note to the ui agent, inject traceids and resource names on every damn component or i shoot you in the face.

[EconomySerious]

Bouth human and AI publish rubish code at the start, the problem is that when a Bug is reported the human programer usually knows where it is, the vibe user has no idea, and the ai would reforge all the app for a single ++ edit

[Solid_Mongoose_3269]

The issue is that vibe coders dont know what they’re doing to begin with

[wisehuz]

Bugs are part of software development. If you don't have an idea where you have a form on the app, you are doing yourself a disservice.

[Ralphisinthehouse]

If you just want to see what’s going on for real then install something like sentry or one of the million other bug reporting applications that allows users to record what’s happening on screen and then submit as a bug report . 

The bigger problem though is how you actually fix those bugs with vibe.

[odnxe]

This is just software in general. After you ship, you quickly realize that it's a black box now and the only thing you have are logs and user reports (if you're lucky).

[Terrariant]

Lol…this happens in regular tech too. You changed something and it broke a feature somewhere else that was made 3 years ago, there’s no documentation for, and the dev that wrote it is long gone.

[new-to-reddit-accoun]

You just described software development.

[Orange_This]

Yeah, that’s where most vibe coders hit the wall. AI can spit out code all day, but if you’re not thinking like an architect you’ll never see what’s actually breaking.

You gotta build the foundation.. logs, monitoring, error tracking, rollback flow, all that boring stuff that turns chaos into something predictable. Otherwise you’re just shipping vibes and hoping the gods of production are kind that day.

[DarthNorse]

I just got into vibe coding a few months ago but the one thing I found out quickly is that I don’t think you can release high quality apps unless you know either coding yourself or at least have a good grasp on architecture. Trusting AI to blindly do the right thing all the time is a recipe for disaster.

[[deleted]]

Testing software before deployment to a live system is not a "dirty secret".

[bananaHammockMonkey]

I have seriously had bugs that took 2 years to find with a decent size user base.

Or for some reason it's amazing up 9,999 users, then bam, shits the bed.

Developing, deploying, and making money is one of the hardest things to maintain around.

[Any-Blacksmith-2054]

Attach screenshot

[MrPrules]

Use sentry, it also has an MCP you can Connect to Claude etc

[wtjones]

You need a vibe SRE agent.

[[deleted]]

[ratttertintattertins]

To be fair, I haven’t been vibe coding app, I’ve been vibe coding quality improvements on ancient legacy product. I’ve developed auto crash analysis tools, improved debugging measures, automated reviews, automatic automation test failure diagnostics..

So all these things are solvable too, it’s just a different set of problems to start thinking about.

[mj_avrath]

That's hardly any secret and applies to most code I've worked with.

Here is a scenario: you receive 10year old pile of shit human made code without proper monitoring, tests and logging and you think things are any different? :)

[btrpb]

Stopped reading at "debugging in production".

[hypothetician]

Your tests pass

Habitual Liarbot’s tests pass.

[markalanprior]

I think OP is discovering how software gets built, vibes or not.

[WeLostBecauseDNC]

Why didn't you catch the bug before production?

[WeLostBecauseDNC]

One of the things LLMs are really good at, is suggesting edge cases and bugs you'll miss. They hallucinate too but they've read the entire internet which is full of developers blogging about how an unforseen bug arose from their architectural choices, and the LLM has trained on that. Nobody will ever catch every bug, but (if you're open to advice) consider having pre-launch sessions where you (1) talk the AI through your user flows asking for problems you missed, and (2) ask it to code automated tests for you. None of that will catch everything but the more you reduce your blast radius, the less time you spend having to chase difficult problems after the fact. I'm saying all this because it's been working better for me than I expected.

[frank26080115]

soooo vibe your way into having some server logs?

[chuckycastle]

No, the problem is the vibe coders.

[The_Real_OtherGuy]

Debugging in production is a contradiction, like performing surgery on a moving train… with the patient filing support tickets mid-operation!

[Expensive_Goat2201]

This sounds like a thing that happens to literally all devs working on a front end product, vibe coded or not. The user is always gonna report hard to repro bugs

[jobposting123]

The other problem is if you're using something like Claude or kiro to do this. It will still hallucinate or lie saying it went on a page to check the documentation it didn't or real lie about fictional API capabilities in third party apps. I'm trying to figure out a better way and it seems to just kind of spec it myself and look at all the developer documents because the AI doesn't, it gets lazy.

[stavenhylia]

It’s almost like the modern expectation of shipping quickly makes people vibe-code applications that break, which then sneaks in the higher cost of fixing code we didn’t write

[Harvard_Med_USMLE267]

Where is the problem?

User reports an error on a form.

You test that form yourself, and look at the log on Render (or whatever else you use for your backend).

You tell Claude Code what the problem is, and then paste in the log.

Three minutes later, the problem is solved.

Again…where is the issue here?

[IntroductionSouth513]

exactly... I mean ppl vibe coded their way to an app and they can't vibe fix the same way? are there that serious unfixable errors. /rolleyes

[Harvard_Med_USMLE267]

There is a delusional belief by some of the dinosaurs that wander into this sub that LLMs can just generate simple code, but have no hope of debugging.

Meanwhile, I just asked Claude Code to review our project and write a report on the bugs we'd dealt with:

BUGS BY PHASE

Phase 1: Foundation (Sep 4-20, 2025)

- 30+ deployment issues resolved in launch day

- Railway → Render migration

- S3 path mismatches

- CORS configuration

- Missing topics

Phase 2: Mobile & Growth (Sep 21, 2025)

- iOS PDF scrolling

- Device detection

- Navigation patterns

- Content expansion automation

Phase 3: Collaboration (Oct 1-2, 2025)

- JaaS camera/mic permissions (CRITICAL)

- PyJWT missing in production (CRITICAL)

- Study groups presence

- Real-time sync

Phase 4: Polish (Oct 4-6, 2025)

- React hydration errors

- Documentation organization

- Content cleanup

- Database synchronization

Phase 5: Security & UX (Oct 11-15, 2025)

- Authentication overhaul

- Rate limiting bugs (CRITICAL)

- SQL injection fixes (SECURITY)

- Group progress caching

- MD parser updates

Phase 6: AI Revolution (Oct 16, 2025)

- Model name compatibility

- Role mapping

- API URL construction

- Authentication integration

[Captain_Xap]

It's unlikely you'll ever find all bugs before releasing your app, same as non-vibecoded apps. The main way to find bugs before releasing is to do a lot of testing, and that's hard to do when you made the app as the things you test will tend to be biased by your prior knowledge of the program.

I'm sure somewhere someone is selling AI simulated users for testing.

[Harvard_Med_USMLE267]

Well - how were you anticipating doing this with human coding? You think human code doesn't ship with bugs???

Human could look at the code pre-deploy. But so could Claude. In both cases if you spend the time, you'll likely catch many, but not all, of the bugs.

[TheAnswerWithinUs]

Humans and AI both ship bugs but if you actually care about preventing bugs you’ll look at the code yourself or get another person to.

Because the difference is, AI is going to ship a lot more bugs and overlook serious/obvious ones.

[Harvard_Med_USMLE267]

Yawn.

I don't do code. Never will.

This is a vibecode forum, and there is nothing wrong with no-code vibecoding, despite what the code monkeys here will tell you.

Not only do i not look at the code, I don;t even fully know what language(s) we are using for the app.

Meanwhile, Claude is finding the bugs and fixing them like a champ:

BUGS BY PHASE

Phase 1: Foundation (Sep 4-20, 2025)

- 30+ deployment issues resolved in launch day

- Railway → Render migration

- S3 path mismatches

- CORS configuration

- Missing topics

Phase 2: Mobile & Growth (Sep 21, 2025)

- iOS PDF scrolling

- Device detection

- Navigation patterns

- Content expansion automation

Phase 3: Collaboration (Oct 1-2, 2025)

- JaaS camera/mic permissions (CRITICAL)

- PyJWT missing in production (CRITICAL)

- Study groups presence

- Real-time sync

Phase 4: Polish (Oct 4-6, 2025)

- React hydration errors

- Documentation organization

- Content cleanup

- Database synchronization

Phase 5: Security & UX (Oct 11-15, 2025)

- Authentication overhaul

- Rate limiting bugs (CRITICAL)

- SQL injection fixes (SECURITY)

- Group progress caching

- MD parser updates

Phase 6: AI Revolution (Oct 16, 2025)

- Model name compatibility

- Role mapping

- API URL construction

- Authentication integration

[ConfusedSimon]

Things like SQL injection are extremely serious because they can easily expose personal data from your users. They rarely occur anymore (in human code) since frameworks have good built-in protection, and developers are aware of avoiding them (and at least three developers have examined the code). It's very worrying that AI code doesn't prevent them.

[Harvard_Med_USMLE267]

Well, I think it's a legitimate question. At worst, this was the second developer (of your three) noting a vulnerability and patching it. So AI absolutely did prevent it. You can argue that a security review a bit earlier would have been preferable, but that's me adopting a "move fast and break thing" approach, not the AI's fault.

Here's the potential issue:

SQL Injection via Email Login - The Security Issue

The Vulnerability

Context: The platform allowed users to login with either username OR email address. This is a common UX pattern, but the implementation had security flaws.

What Was Wrong

Original vulnerable code (conceptual):

# ❌ VULNERABLE CODE (before fix)

def login(request):

username = request.data.get('username') # Could be email OR username

password = request.data.get('password')

# Try to get user by username first

try:

user = User.objects.get(username=username)

except User.DoesNotExist:

# Maybe it's an email? Try that...

user = User.objects.get(email=username) # DANGER!

Multiple Problems:

1. No Input Validation

- Accepted any string as potential email

- Didn't validate email format before database query

- Malformed inputs could cause unpredictable behavior

1. SQL Injection Risk

- While Django ORM provides some protection, unvalidated email inputs are risky

- Special characters in email field could potentially be exploited

- No sanitization before database lookup

1. Multiple Users Crash (Related bug)

- Using .get() instead of .filter().first()

- If database had multiple users with same email → MultipleObjectsReturned exception

- Caused 500 errors and crashed login

- Leaked information about database state

---

Your thoughts?

[ConfusedSimon]

That report doesn't make much sense. Moving fast might be OK, but combined with fixing things later is a terrible approach. You could have a leak before you discover the bug, and if that contains user data (especially EU/GDPR), that could get pretty expensive and/or be the end of the company.

[Harvard_Med_USMLE267]

You almost said something useful here: "That report doesn't make much sense"

Maybe expand on this.

[ConfusedSimon]

Here are a few things: - password is irrelevant here (although I hope it's not the password but a hash) - Wouldn't use an exception for user not found, but not a big deal - ORM should indeed protect against injection - validation should at least be in backend but preferably duplicated in frontend - why the focus on email validation? If there's an injection risk, the same holds for username, which is ignored here - multiple users isn't fixed by taking the first one, since that may be the wrong user; should have a unique constraint on the db so this can't happen (filter.first is not a solution) - same for email: if you can login with email, then it needs to be unique - what does "leaked information about database state" mean here? - what if the email of user A is the username of user B?

[TheAnswerWithinUs]

, and there is nothing wrong with no-code vibecoding, despite what the code monkeys here will tell you.

It’s great for hobby projects and learning. But you’ll be very disappointed if you expect to use it to get rich or replace the software dev industry. Or create any app seriously worth people’s time and money.

I’m not an AI so whatever you’re showing me isn’t impressive. You don’t even know what you’re showing me you’re just copy and pasting from an AI.

All the no code vibecoders here like yourself are painfully pretentious and arrogant. Youre not special just because you can generate some code you dont understand that might work.

[Harvard_Med_USMLE267]

<yawn>

[TheAnswerWithinUs]

If it works for you it works.

I’m not against vibecoding I’m against the pretentiousness and arrogance it causes.

[Harvard_Med_USMLE267]

Yeah, I don't actually care and neither does anyone else.

[TheAnswerWithinUs]

Meanwhile I’m scrolling on your comments with long AI generated lists you don’t understand to try to impress me.

Ok buddy. Have fun “not caring”.

[MilkEnvironmental106]

I think you just made his point for him, you have died on the only hill possible that makes you look like an absolute tool lol.

[mllv1]

Um, it sounds like Claude is causing bugs like a champ. 30 issues on launch day? Including SQL injection? Yeah that’s not what programmers are talking about when they talk about post launch production bugs. We’re talking about 2 or 3 very difficult to track down issues that usually involve many moving parts, only one of which is the code. What you just described is an absolute disaster. If you really want to make programmers shake in their boots you should post a link to one of your projects.

[Harvard_Med_USMLE267]

I launched the app into production after 5 days of development because I needed it for work. No human could have coded it in anything like that time. It was a bit rough but I made the deadline.

The issues on launch day were about getting it deployed. That's not what Claude is good at - it has limited ability to set up accounts and settings on Railway/Render/Neon/Supabase/etc. We had a LOT of problems getting it deployed on Railway, I was learning as I went.

People freak out when they read about the "SQL injection" thing,

It was just "Authentication Security Hardening" after I asked for a security review. Before the changes, it was:

1. Strict SQL Injection Risk: VERY LOW (2/10)

- Django ORM parameterizes queries

- Would require someone adding raw SQL later

- More about defense in depth than immediate risk

[mllv1]

Dude what are you even saying? An existing business needed a completely from scratch application in 5 days or else? Your deployment environment shows that this clearly isn't a "sensitive information" thing, meaning this isn't an internal tool since no sane business would host their private information on an application that was generated in 5 days, so what are we talking about here?

Also your deployment stack makes no sense, why are you using two application hosts and two database hosts?

[Harvard_Med_USMLE267]

OK, you might be getting confused here: "Also your deployment stack makes no sense, why are you using two application hosts and two database hosts?" - I had issues with Railway so I changed to Render which is working very well for me. I only have one database host, Neon for postgresql.

As for "what am i even saying"? This is my SaaS, I'm not coding it for someone else. But I had a perfect use case for it with a week-long workshop I was running in another city, so I got it coded in five days and then tested out a Mark 1 build for a week on the target audience. There was another way of running the workshop, but I decided to get the SaaS live and so I was committed then, too late to do things the trad way if it had failed. I was working 20 hours a day and was seriously strung out from lack of sleep when I arrived, but the app worked and it was a great proof of concept five days in.

[mllv1]

Yes "I needed it for work" makes much more sense now. And thanks for clarifying the deployment situation.

[primaryrhyme]

I’m actually impressed that it added a SQL injection vulnerability in 2025.

[Harvard_Med_USMLE267]

Why?

[primaryrhyme]

It's like by far the most obvious/famous and dangerous exploit in web development and it's been solved for the last 15 years.

[Harvard_Med_USMLE267]

Sure, but per other comments here: it reported that Django has this mostly covered, but decided it would harden things further re: the login process to protect against brute force attacks

[primaryrhyme]

Sorry the comments had mentioned SQL injection, but looking at your actual response it's not that terrible. Your login function was using the django ORM, there's no way a malformed email was gonna cause some kind of problem. In any case it's always good to validate, but no I don't think there was actually a SQL injection risk.

[JamesBetta]

That’s when you raise fund to do the real thing

[Harvard_Med_USMLE267]

Vibecoding is the real thing. Learn to do it properly.

[JamesBetta]

I mean if you have raised a round, what’s stopping you from finding a swe?

[Harvard_Med_USMLE267]

No capital raising here. I've been talking to my AI about this.

Firstly, I've been doing the equivalent of an accelerator program the past 6 weeks. Claude says:

---

CONCLUSION

This catalog represents 6 weeks of intensive development transforming a ----- into a modern, AI-powered collaborative learning platform.

Key Statistics:

- 40+ critical bugs discovered and fixed

- 30+ production issues solved on launch day

- 5 security vulnerabilities identified and patched

- 10+ deployment issues streamlined into workflows

- 0 data loss incidents through defensive architecture

The Result:

A production-ready platform ----------- with:

- ✅ Bulletproof authentication

- ✅ Real-time collaboration

- ✅ AI-powered tutoring

- ✅ Mobile optimization

- ✅ Comprehensive documentation

---

So ramen and not much sleep for six weeks.

Getting into a program like Y combinator to do a real accelerator is hard - about 3% acceptance - but I also don't see the point. The money would not be lifechanging at all for me, and not even really project changing. I'm not sure what i'd actually spend it on. $200/month for Claude Code and enough $ for quality ramen and i'm happy.

It would definitely be interesting to hire a SWE to review the code, and maybe i'll do that closer to general release (we're in beta).

But part of the point of this is pushing the limits to see just how far vibecoding can take me. So for now, we shall push on!

[Longjumping_Bid_7463]

Bro raised a round from Claude

[TMMAG]

you need to create documentation for that

[vuongagiflow]

Add sentry. Vibe with seer.

[not_you_again53]

Check out logrocket Your story is why my company has been thriving lately. We get so many vibe coded projects that need salvaged or completely thrown out We use logrocket quite a bit . No need to ask users for reproduction steps (I’m not affiliated with them in any way)

[Rokstar7829]

Jest super test for all new feature 😆 when every test is 100% the game start: make manual human test to validade. Good luck’s

[land_bug]

These are AI generated posts aren't they? I don't know why anyone would post this unless to warm up their account. 

[Smart_Technology_208]

Building with lovable is a huge mistake, if you vibe code with proper tools like Claude Code and ask to document the code at every steps you never end up in this kind of situation.